The Bootstrapped Founder - Bootstrapped Founder #35: Roadmaps

Dear founder,

This newsletter has no sponsors. I want to keep it that way. If you would like to support me, please consider purchasing a copy of my book Zero to Sold: How to Start, Run, and Sell a Bootstrapped Business. If you're interested in how the first week of sales for that book panned out, please check out this article on Indie Hackers, where I share every detail, from page views to revenue. I'm incredibly grateful for all the support and encouragement I have received over the last week. It's been a whirlwind of joy for me.

Back to bootstrapping! Today, I would like to tackle roadmaps, a feature that is often both underrated and overrated. Let's look into why that is.

It's great to know where you are going. It's even better to know that your customers approve of that.

Both goals can be reached by establishing roadmaps. Usually, that's a document that lays out what you want to do in the future, ordered by when you want to do it, with more or less accurate guesses on how long it will take. When a feature prioritization framework is a compass, then a roadmap is… well, a map.

The purpose of this roadmap is two-fold: it's supposed to give you a clear plan for the future and help your customer trust that your service will be useful to them for a long time. Let's look at this one goal at a time, after we look at a foundational choice.

One Roadmap, Two Roadmaps

You will encounter founders who tell you that you should have an internal roadmap and a different external roadmap so you can manage expectations. You will also meet founders who tell you that, for transparency's sake, you should only have one solitary roadmap.

This is a question of how much you want to communicate with your customers, and it will heavily depend on the industry you're in, your competition, and how much transparency you're going for.

I think that a workable solution is somewhere in the middle: have an internal roadmap with all the details, and show a slightly redacted version to the public. Where internally, you use your best estimates and detailed descriptions, for the external roadmap, use generalized date ranges and fewer details. The customer-facing should always be a limited view of the original. That way, you retain control over what is visible, but it's never too far from your internal roadmap.

Internal Roadmaps

For every single project I've worked on in the past, I eventually had a road map. Sometimes it existed before I started working on the product; other times, it was established months after the project already had paying customers. It's one of many tools that help to structure and plan your work in a dynamic and often-changing company.

You'll benefit from having a plan, even if you don't necessarily stick with it all the time. After all, you're an agile bootstrapper, everything is essentially an experiment, and no decision is set in stone, particularly not the things you'll be doing a few years from now. So treat it as a flexible guideline.

Internal roadmaps should contain goals and dates for all sections of your business: product milestones, sales and marketing goals, and your plans for operative activities like building a team, integrations, and partnerships. Don't limit a roadmap to features or releases; it can reflect the future of your whole business. In fact, the more different sections of your business are involved, the more insight you might glean into the connection between things.

There are several formats for roadmaps, and they all have their pros and cons.

• Timeline Roadmaps. These are great when you're one of those founders who need deadlines for motivation and peace of mind. You can see which things need to be done in parallel at what time, allowing you to know when and where to focus your attention. You can easily miss those dates, though, so better use high-level terms like "by April" instead of "April 21st."

• Roadmaps without Dates. I personally really like these, best if they come in the form of a Gantt chart. Roadmaps like this show dependencies and connections between tasks more than any discrete date when they should be accomplished. "It's done when it's done, and here is what needs to happen to get there" — what a bootstrapped-compatible sentiment.

• Kanban-style Roadmaps. Unlike the more common timeline-based roadmaps, Kanban-style roadmaps categorize your planned activities and features into groups, like "Backlog," "To Do," "Doing," and "Done." This is a great way of sorting things if you don't want to commit to any particular order but still want to keep an outline of what the future holds.

No matter which style you choose, you will benefit from having a document that sketches out the steps you can and should take with your business. You don't have to keep it all in your head.

Public Roadmaps (and More)

Let's look at the other useful side of roadmaps: making them available to your customers. Future revenue is much more likely to happen when those who pay are happy to continue to do so. If you involve the people who use your product in its development, you will be able to get immediate feedback about the desirability of your planned features. The best way to do this is to have a public feature roadmap (like the one offered by the Roadmap SaaS Canny).

A benefit of a public product roadmap is that it might incentivize customers to commit to yearly plans both as a sign of confidence and to lock in your commitment. While it's great to have those funds available, be aware that this also sets expectations. If you don't deliver on your promise, there will be some damage to the trustworthiness of your brand.

In addition to the roadmap, allowing your customers to suggest features and vote on them is also an excellent idea to measure what people are looking for (and which of those problems are commonly felt). It doesn't absolve you of doing your own research though. The suggestions generated through these tools should start your research process, not conclude it.

A warning about public roadmaps: they become a commitment once you show it to your customers. Once you communicate intent, customers see it as a promise. If you don't follow through, your public roadmap is pointless. If you have dates on your public roadmap, customers expect things to be finished by then. People are drawn to concrete figures, and nothing is more concrete than a date.

Keep in mind that the public roadmap is completely optional. You are at perfect liberty to tell people that your plans are your own, and you won't share them. If you think that this might give your competitors too much information, don't make it public. Just know that customers are used to not being told what is going to happen, and your service could stand out as being the one that shares their plans for the future.

You can find this article on the blog and in my book Zero to Sold. I also recorded a podcast episode with additional thoughts and my experiences with roadmaps. Please check it out!

Links I Found Interesting

It appears to be quite the week for book launches. In a very extensive article describing his book launch journey, swyx describes the ups and downs of launching The Coding Career Handbook. It includes the decision-making process, the writing process, and the random interruptions that caused his launch date to shift significantly. A great read for every aspiring author, and, as I have noticed as well, for every kind of founder. Writing and launching a book is remarkably similar to building a SaaS business since it is not that different: you have an audience, they need a solution to a problem, and you're providing a product.

I've been very happy to see that the term "Indie Hackers" is growing significantly in web searches, according to explodingtopics. It is such a great feeling to know that more and more people, worldwide, are thinking about starting a sustainable, bootstrapped business to elevate their lives and those of the people around them. It only fits to see that the trend itself is also a slow-growth, sustainable trend.

In the world of bridging the virtual with the real, I really enjoyed Uicard, a wireframing ruler that allows designers (and those who think they are but have problems drawing) to quickly wireframe things on paper. It's a neat idea, and you can tell that people like the idea, with the Kickstarter being significantly overfunded already with two weeks to go.

Bootstrapping Successes

Bart Boch, the owner of idea validation service Almost Cake, had a very surprising moment this week when he routinely checked his order submission. It turns out that he had landed a celebrity customer, Conan O'Brien! What a beautiful moment to have as a founder, having a person of public interest use your service for their equally public work. Congratulations, Bart.

Marko Saric, a co-founder of Plausible Analytics, reported hitting $2000 MRR from 300 paying subscribers. The last MRR increase of $1000 happened in just over one month. That is significant growth, and that is just amazing. Marko shares a lot of insights in the comments and the post regarding conversion rates, pricing, and much more. Check it out.

Preetam Nath, co-founder of Superlemon, a WhatsApp app for Shopify, reported an equally amazing MRR milestone: the business just hit $25,000 MRR, after just 14 months. It just goes to show how connecting two platforms can present an amazing opportunity.

Thank you for reading this week's edition of The Bootstrapped Founder. If you like what I wrote about, please forward the newsletter to anyone you think would enjoy it too.

If you want to help me share my thoughts and ideas with the world, please share this episode of the newsletter on Twitter or wherever you like, or reach out on Twitter at @arvidkahl.

See you next week!

Warm Regards from Berlin,

Arvid