Plumbr: year 2013 in retrospect

This post is the aftermath of our end-of-year team event a month ago, where we wrapped up 2013 and set the direction for 2014. At some point I realised that there is no reason to keep the retrospective conclusions internal, when our progress and the quality of our product so much depends on the community. So here you go – the progress of our company throughout 2013.

If the write-up provokes comments or ideas, feel free to drop me an e-mail or leave them in the comments section below. If you feel that I describe a company that you would like to work for, let me know as well. We are hiring!

The below notes are divided into three categories:

• Product
• Team
• Business

The Product

Data. During 2013 Plumbr detected more than 3,500 memory leaks for our customers. Considering that a typical memory leak takes roughly two weeks of troubleshooting and patching, we did make a small dent in the universe. The most important conclusion of 2013 is that Plumbr offers a solution for a common pain (you always wonder when you start a new business/product line).

Even more data. Plumbr evaluation version reports back statistical information of your application’s memory usage that our machine learning algorithms use to learn from (you can turn that feature off if it bothers you). During the year we got more than 1,000,000 snapshots from thousands of different applications. There is a lot we can detect and learn from this data and there are some cool new algorithms sprouting under our research department supervision.

New frontiers. We started the year with a gut feeling that memory leaks are not the only performance problems our approach might offer a solution for. As of now we have replaced the gut feeling with a clear understanding how we tackle additional domains. Our engineering team has built a rather cool process for quantifying the problem based on the data we have. Our onboarding team is equipped with the means to qualify the problem and test out solution hypotheses.

The first visible result of this process is stopping the development on collection overhead: we understood that the collection overhead problem is both not big enough nor is the solution simple enough to be rolled out. Considering the relatively small amount of effort that it took to reach that conclusion, it was clearly a positive outcome for us. By spending relatively little we managed to avoid building a solution for a problem which is not painful and would have been hard to use – a hugely important lesson and milestone on the road to building a scalable product development team.

Solution offerings. In the beginning of 2013 Plumbr was able to pinpoint you to the problem source. As we learned along the way – in many cases that is not enough. You might unknowingly be using a 3rd party module in a wrong way, or be using a leaking version of the module altogether. In cases like these clear instructions do come in handy. By today, more than 30% of leak reports also list clear specific steps you need to take to fix the problem.

Packaging. In 2013 January Plumbr was offered as a standalone Java application. As of last summer, we packaged the functionality into a SaaS offering. The impact has been significant – the solution is now more understandable and we are also able to roll out product improvements a lot faster (read: daily in most cases).

(No more) leaps of faith. We also learned a painful lesson with the launch of the SaaS offering – we screwed up product messaging and spent months to recover from it. A new web page and sign up flow resulted in confused users and plummeting sign-up rates. We did draw conclusions from this. And are now rolling out all changes as controlled experiments. As opposed to humongous leaps of faith that we used to take.

The Team

Quantity. Plumbr started the year with four people, and some part-time helpers. We ended the year with a team of eleven. Here is a picture of us on one evening after a long working day:

Responsibilities. From “case-by-case and ad-hoc” approach in the beginning of 2013 we have matured a lot. In the second half of the year we separated product development activities from engineering and onboarding from sales. Adding marketing and interaction design into the mix, we have built a foundation for supporting up to 30 employees with this model.

Recognition. Our open policy towards our daily development activities has not been unnoticed. Each and every piece of content we publish is read by thousands of readers and has (almost always) received positive feedback. Our most popular articles for the year got 20-25,000 readers during the first day.

We are also regularly being invited to various Java events to talk about performance related topics. I am sorry that we were not able to participate more – if we had to turn you down, it was only because of limitations of the laws of nature. 2013 saw us speak at 33rdDegree, JavaOne Moscow, Israel Jenkins User Conference, GeekOut, Topconf, JavaOne, Joker, JavaDay Kiev, Jazoon, Devclub Riga, and a few smaller local events. The quality of our talks was recognized by Oracle when Nikita received the title of JavaOne Rock Star.

The Business

Angels. First and foremost, we thank our angel investors for their help and trust. With the $1,000,000 round announced in November, we can now take longer term decisions knowing that the runway is longer.

Customers. We started the year with just a handful of paying customers. 2013 added 100+ paying companies in the list, which not only contributes financially, but also serves as an excellent pool of advisors and early product testers. We have learned a lot from you guys, thank you for your patience and support!

In the second half of 2013 we also started to sign up first enterprise customers. Plumbr has found its role in release and quality management processes in large financial institutions, government agencies and large multinationals.

Money. Regardless of growth and heavy R&D investment, we had two cash-positive months in 2013, which actually feels quite good. We have keeped cost under control, and have a long runway ahead.

Summary

All this leaves us in a rather good shape. As wise men have said – and I concur – you can only connect the dots looking backwards. There are many possible lines ahead and even if we don’t know which one we will draw in the end, I do see that the stage is set. The pattern created thus far makes a good foundation for a strong meaningful line in the end (please excuse the metaphor that’s getting over the top already).

We are building a company that will be defined by its products. Our internal processes will be transparent, all key areas will be measured and progress monitored. All of this will be enabled by clear separation of responsibilities and automated processes, to accommodate for scalable growth and customer needs.