Author: Rhys

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 :

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.

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.

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.

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.

Up until this point I’ve grown Agile Docs to over $4000 MRR without a personal audience. My main marketing channel has been the Atlassian Community Forum. The Atlassian Marketplace App Store brings a little traffic, I get some from posting on Jira feature requests, but the bulk comes from posts to the Atlassian’s community forum.

But over that time I’ve noticed it’s become increasingly difficult to post on the forum suggesting my product as a solution. There are now restrictions on where you can post. For example, now I’m unable to post on the forum to suggest my product as a solution when the thread is over 6 months old. This includes most threads where my app might be helpful and most threads which generate lots of search traffic through google.

I’ve grown traffic and revenue consistently over time by starting with a forum I could post on and working backwards to the product or feature. This worked well. I’d find a forum where people were complaining about the absence of a feature in Jira, add the feature to my app and write about the feature in the forum.

Now many of my posts go directly to spam filters and I have to speak to the community managers to be able to continue posting. Product suggestions are seen as spammy, even if they solve the user’s problem. This is nothing against Atlassian’s approach to community management. They have to run their forum in a way which makes sense for them.

But this has caused me to rethink my approach to marketing. When your main acquisition channel changes, you become hyper aware of how vulnerable your business is. Sure, you can find other acquisition channels, but this breaks your model. You built the product because you identified you had an acquisition channel. You built a feature because you knew it expanded that channel to get more traffic. When this breaks it makes you question whether you should be in the market at all.

This makes the alternative of having a personal audience look enticing. A group of people who want to hear from you. No gate keepers guarding access to forums or posts. A channel which increases in size over time organically. Sure, if you build an audience on Twitter in a way it’s Twitter’s audience. But the key point is your audience genuinely wants to hear from you. If Twitter bans you, a large segment of your audience will follow you to another platform in a way which won’t happen if you’ve hacked a channel like SEO or forum posts.

There are downsides to marketing your app through your personal audience. It’s been suggested a personal audience is great to sell infoproducts, but not as good for selling SaaS apps. When you sell a SaaS app, users care more whether they have the problem your app solves and that your app solves it well. Other founders have noted that a personal audience isn’t necessary to grow a SaaS app. That you ultimately need to rely on other channels eventually to continue growing. I find this isn’t a real problem until you want to scale. Many people who talk about a personal audience not being necessary to grow a SaaS app are often talking from the perspective of having gotten to 2k-10k MRR and reached the limit of how helpful their personal audience is in growing further.

Then there’s the problem of whether your personal audience overlaps with the market for your product. This is a subtle, but makes a big difference as to whether your personal audience is an effective acquisition channel. In my case, Agile Docs helps solve the problem of rolling up estimates and tracking estimate progress for product managers in larger companies using Jira, but when I tweet and write articles it’s often targeted at other indie hackers. This disconnect can be a problem.

But even with my bespoke audience of 70 followers I’ve averaged 1-2 views a day to Agile Doc’s sales page since I started posting. Even without advertising it directly. A bigger following and a product with greater overlap with your personal audience could amount to something substantial.

Ultimately the appeal of a personal audience is not that it’s the most effective way to grow your SaaS app from 10 to 100 users. It’s that having an audience is a distribution moat. You can lose your number one spot on Google to a competitor, get banned from posting on a forum but your audience will still want to hear from you. This is the big appeal.

Going forward I’m going to build on what I have and expand into other channels to market Agile Docs such as content marketing for SEO. But I’m also going to endeavour to grow my personal audience. It may not be the most efficient way to market Agile Docs, but I see now what a massive advantage it is for marketing future products.