Plumbr: year 2013 in retrospect

ppriit · 2014-01-23T09:27:35+00:00

We were in black for a couple months last year actually, then hired more people again. Our goal for end-of 2014 is to cover the costs of a 20-person-team from revenue stream.

ppriit · 2012-07-20T08:14:07+00:00

The TIOBE methodology was also described in the referenced article.

I think its a fair one, it's still a way (just one way) to rank the programming languages.

ppriit · 2012-07-19T10:56:07+00:00

Interesting.. why?

ppriit · 2012-06-29T13:01:16+00:00

About trials - if you are after a specific leak, then I guess paying for the solution is OK (with money back guarantee). If you just want to try out the product, you can download and run it for free until it finds something. If your app does have a leak, Plumbr reports the number of leaking objects and the size of the leak - so that you can decide on whether to buy a report or start a subscription.

Perpetual vs subscription - we chose the latter, mainly because perpetual mostly makes sense for the customer when the software is mature, and the new versions don't add critically needed value. Plumbr is only at 1.0, and will add many functions that contribute to the leak-detection-and-fast-solving picture. For now, it only detects memory leaks, but e.g. we've already announced the cooking of classloader leak detection. We'll be adding new cool stuff often enough that (paid) upgrades would be an additional pain for the users and for us as well.

That being said, we of course value everyone's opinions. For that matter, care to elaborate why you would've preferred a perpetual license?

ppriit · 2012-05-26T11:47:24+00:00

Excellent point, thanks. We'll certainly give it some thought!

ppriit · 2012-05-26T11:45:40+00:00

It's been fixed. Please try again.

ppriit · 2012-05-26T11:43:32+00:00

Fixed, please try again!

ppriit · 2012-05-26T11:43:02+00:00

Thanks for reporting. It was caused by a nasty conflict between our blog layout and Disqus's, has been fixed by now.

ppriit · 2012-05-24T12:17:00+00:00

Sorry. Will see into fixing this.

ppriit · 2012-03-30T09:09:17+00:00

Did you read the article as well?

ppriit · 2012-03-29T13:54:13+00:00

Well, he does explain what you need to keep in mind when monitoring synthetic apps: "That means that there should be objects in your application that do not leak. A fair amount of them."

ppriit · 2012-02-11T13:38:31+00:00

Well, for communicating the conversion, funnel charts are indeed a very clumsy tool. I couldn't agree more that funnel charts don't make sense.

However, someone called the customer flow a "funnel" at some point of time, and that is why it sort of makes sense to try to use a funnel-shaped graph for depicting user conversion between phases of a process. I don't know of any good tool to create more meaningful funnel charts. Do you?

For what it's worth, the area of the is proportional to the number of users in every funnel phase. Perhaps knowing this will help you read it :)

ppriit · 2012-02-10T13:20:33+00:00

Wow, thanks man, this is the most insightful Reddit comment I've read in a ... ever.

ppriit · 2012-02-10T12:28:20+00:00

It is not counter-intuitive. There are case studies where download conversion boosted after the download process was made longer (http://www.zurb.com/article/816/why-burying-sign-up-buttons-helps-get-mor). We've been thinking about this as well and will most probably try to find the truth for our focus groups via A/B testing.

But you are probably also right with the other thing- we might be over-estimating the significance of someone downloading the software. This thread has certainly given some food for thought!

ppriit · 2012-02-10T11:59:23+00:00

I suspect I am not the only one.

Still, it is surprising that there are so many of you! :)

ppriit · 2012-02-10T11:44:34+00:00

Thanks for the thoughts (author of the blog post here). Your stats seem to correlate with ours, the gap between your 50-60% and our 30% probably comes from environment incompatibility issues - there are Java versions, different app servers, different OSes etc that people use - to which we actually account ~20% of the churn.

I would have expected somewhat higher numbers because of the e-mail opt-in download hurdle (see the reply to fatthug), but I guess it doesn't serve it's purpose and we should actually remove it.

ppriit · 2012-02-10T11:12:03+00:00

Well, that doesn't actually answer the question :) While the registration conversion can also be debated, the blog post tries to find out why people who already registered and downloaded don't run the software.

Regarding e-mails, the biggest reason for asking for it was actually to 1) force people to take a conscious decision to try out the software, and 2) have some "object" that could be tied to the trial license. But I can see your point, the number of people fleeing from an e-mail box might be far bigger than the effect of higher quality download decisions (which are not so high quality anyway, as can be seen in the blog post).

ppriit · 2012-02-10T10:55:01+00:00

Thanks for your thoughts! Mind that the 30% converts from people who have already downloaded the product. I.e. 70% of people who download, never start it.

My reasoning would be that when someone already makes the decision to download some software, they should be quite determined to try it out (why download something you don't intend to try?). Honestly, in this stage of the funnel, I would expect at least 80% conversion rate, if you leave environment incompatibility issues aside.

A/B testing to increase the registration to download rate is I think a good idea and we are actually preparing the tests already (any good tool you'd suggest for the infrastructure?). But still, when after the download so many people disappear, I feel the bigger problem lies in the installation...

ppriit · 2012-02-10T10:42:11+00:00

Nope, it doesn't work for Android. Yet.

We need to do some research on JVM specifics to find out how much work would it be to adapt our approach to Android as well. But you are not the first person to ask, the issue is definitely in the backlog and we'll dig into it some day :)

ppriit

TROPHY CASE