Lessons learned growing to 5k MRR as a single developer in 2020

Since December 2019, Agile Docs has grown from $1285 to $5003 MRR. In that time, I’ve added a number of features, launched 2 other products, and made a boilerplate for launching Atlassian Apps quickly using Next.js.

My biggest learnings from 2020 are :

2020 Revenue Growth for Agile Docs
2020 revenue growth for Agile Docs

1) Double down on what’s working (quit the “small bets”)

Over the course of 2020, I launched 2 other products in an attempt to diversify my product base. I felt all the risks of competitors eating into my market share and even having some features of Agile Docs built into Jira itself. It felt like a good strategy to take some “small bets”. Around that time Atlassian was holding a hackathon which promised prize money to the best apps. This seemed like the ideal time to take the focus off my main revenue producing app and launch some other apps.

Ultimately, I didn’t end up winning anything in the hackathon, but took many months to launch 2 new products: Program Tree and JQL Sum Up. JQL Sum Up struggled to get traction and is now free and Program Tree gets a new trial every week or two. Not exactly raging successes. Granted there were other factors which contributed to their lack of traction. Changes to the Atlassian Community meant I couldn’t market them the same way I marketed Agile Docs.

JQL Sum Up and Program Tree

In that time, despite only adding a new feature every month or two and fixing the odd bug when a customer brought it to my attention, Agile Docs grew from $1285 to $5003 MRR. In retrospect it seems silly to have focused so much time on other apps when my main app was growing MRR every month, but fear of a changing market where Agile Docs might become irrelevant propelled me to diversify into other apps.

The “small bets” philosophy is growing in popularity but I think it can be counterproductive when you have something which is really working. When you double down on what’s working you often get a disproportionate return on your efforts. The effort required to improve the conversion rate of trial to paid 5% for an app generating 4k MRR often dwarfs the ROI of spending the same effort on increasing the conversion rate of a $100 MRR app by 5%. This is the problem with “small bets”. It’s a great way to throw lots of things at the wall and see what sticks. But you don’t want to reach a point where you’re constantly abandoning what’s working right when your return on invested effort is reaching record highs.

2) Invest in great documentation

Improving my documentation throughout the year made a big difference to both my conversion rate from trial to paid, and reducing my customer support burden. Between September and October I went through every customer support request and created a comprehensive FAQ section which addressed every issue which didn’t involve a bug fix or feature request.

Agile Docs Documentation

I was surprised by the effect his had on my conversion rate from trial to paid. Relative to the time invested the improvement was phenomenal. I learned that new features are wasted if they aren’t communicated effectively to your users.

If you’ve been putting off updating your documentation, the best bang for your buck is simply improving that. You’ll get the added benefit of freeing up more of your time from customer support.

3) Triple check your main distribution channel before launching a new product

In launching two new products, I learned that I couldn’t assume the same distribution channel I used for Agile Docs would be available for my new products. This sounds like a pretty elementary mistake, but I still made it.

Before I built Agile Docs I’d find threads in the Atlassian Community where people were complaining about not being able to do something they wanted to do. I’d post a link to a demo solution in the thread and observe how many people signed up. When the app was built, I’d email everyone that signed up and link directly to the app in the app store instead of the sign up page.

original-landing-page
Original Agile Docs Opt-In Landing Page

Once it was released I’d prioritise features which were both requested by customers and where there were threads in the Atlassian Community where people were complaining about the absence of that feature. This meant I could both satisfy existing customers and open up a distribution channel for new customers with a single feature. This worked well for Agile Docs in 2019 and early 2020.

But the mistake I made for Program Tree and JQL Sum Up was not creating a demo to link to in forums to validate demand before building the products. This was because I planned to enter both in the Atlassian hackathon and wanted to focus on getting the apps done as quickly as possible. When I finally completed the apps and posted in the forums, they were immediately caught in a spam filter. The Atlassian Community had become more hostile to posts suggesting a product to solve users’ problems. It was also harder to post on threads older than 6 months which was a problem because these threads often generated the most traffic via SEO.

If I had my time over, I’d post in forums linking to a pre launch landing page before building the products as I did with Agile Docs. This would validate that my posts would not be taken down and people were definitely interest in the product.

In a way, some of these forums were like mirages in the dessert. It looked like you’d found a bountiful distribution channel. But it was only when you tried to post a link to your product in the forum that you realised what you thought was fresh water and a delicious buffet was actually just hot sand.

4) Keep the conversation going with every user who reaches out to you

One of the unintended downsides of improving my documentation and reducing customer support requests was it became increasingly difficult to chat with customers. I set up emails to go out to the Jira admins of an instance when they signed up or cancelled. I also had a button for support and one for requesting new features directly within the app. However, not many people responded to me or reached out with feature requests.

I learned that when a user reached out to me, I had to keep the conversation going. Ask them more about the problems they’re facing in their workflow. What are the main things they’re using the app for? What are they struggling with? The advice “talk to your users” is common but this isn’t always easy to do. That’s why when you get some engagement, keep the conversation going.

It also helps to use your email for customer support instead of software. This is less structured, but makes it easier to continue a conversation with a user beyond their specific feature request.