Dear founder,
I have started a podcast. The Bootstrapped Founder Podcast goes alongside this newsletter and the blog, and it will be released every Friday as well. On the podcast, I will expand on the topic I am writing about each week and give additional commentary that did not fit into the article. Please come check it out!
Ever since I released Zero to Sold last week, I have been talking to a lot of founders (and a few consulting clients) about validating problems, and I often heard one particular notion. They had talked to their prospective customers, but the results were inconclusive.
In most cases, the problem was not that the founder was asking the wrong questions. The prospective customers themselves were the issue. They were just not the right people to talk to.
I’ve talked to many customers for problem validation purposes over the years, in many different startups. I’ve compiled this experience into a blog post called Problem Validation: Making Sure You’re Talking To The Right People.
I learned that the best case is an in-person conversation with an industry expert who has skin in the game and is aligned with your goals.
- In-person because you need the subtleties of face-to-face interaction. You need to be able to steer the conversation back to the problem when it derails.
- Industry Expert because your time is valuable, and you want to extract information from all stages of being inside an industry. A veteran has gone through all of them before.
- Skin in the game because your goals will only be aligned on long-term success if your prospect has something to gain from being better at their job (and conversely, something to lose if they don’t perform)
In preparation for any prospective customer communication, I highly recommend reading Rob Fitzpatrick’s Mom Test. The book will allow you to ask non-leading questions, listen more, and focus on extracting problems instead of having people agree with you.
I recommend avoiding these kinds of prospective customers:
- People who are trying to please you: If all you’re getting is compliments, stop talking to them. They may be great cheerleaders, but they won’t help you find painful problems.
- People without real skin in the game: Don’t talk to people on their way out of an industry. Avoid people who are only in it for the money, or don’t care about their work. Real impact can only happen where people feel responsible and determined.
- People who only tell you their ideas: You’re talking to them to do your own research, not to blindly take an idea and go with it. If they barrage you with ideas and requests, try getting back to the problems that made them think of it.
- People who love complaining: If everything is a problem, you won’t see the forest for the trees. Dismiss prospects who can’t see the good in life, as their reality is tainted and distorted by finding fault in everything.
Dismiss candidates when you notice one of these things happening in your communication. There might still be value in talking to them, but the results will be less than ideal. Instead, ask them to introduce you to other people they know that might be a better fit. Warm introductions will help you pre-filter unfit candidates.
Finally, be aware of your own biases when talking to your prospects. Don’t overload them with expectations, and stop talking about your ideas. Listen to their problems, listen to their reality, and find out how you can solve their critical issues. That is what problem exploration and validation is all about.
You can read the full article about Problem Validation: Making Sure You’re Talking To The Right People on the blog.
Bootstrapping in Practice
As a developer, half of my business ideas revolve around programming problems I had in the past. It’s tempting for developer-entrepreneurs to build for the audience they know best: themselves. But is that really a good idea?
Let’s look into developers building for developers. Why are so many SaaS businesses started in this space, and why do so few of them succeed? What are the opportunities and risks here?
First off, let me give you a hint of what my own idea catalog looks like. During building FeedbackPanda, I jotted down a few ideas of things that could warrant a SaaS business. Let me show you the top three ideas on that list.
The first thing on this list is to “build a SaaS to show custom banners on websites.” This idea came from my own need to quickly inform customers of downtimes, maintenance, and product updates.
The second item on this list is “build an API to render PDFs from HTML templates.” I needed something like this to create invoices for our customers.
Finally, there’s a “browser extension generator from a single code base,” a SaaS that would automatically create extensions for Chrome, Firefox, Safari, and Edge from a single javascript repository and deploy them to the respective stores. FeedbackPanda has a popular browser extension, and deployment always took hours by hand.
All of these ideas have something in common: they would probably not allow me to build a great business around them. They are concrete solutions for the problems I had. But none of these problems are critical. They felt important, but I always found a solution that worked well enough for me.
As professional software engineers, we operate with a lot of assumptions. We are often over-estimating our understanding of other developers’ needs. We often assume we know the best solution for a given problem, and that we know the priorities of other developers.
We assume that we don’t need to talk to other developers. How could they disagree with what we already know? That keeps us from adequately validating the problems that we assume to exist.
Would other developers genuinely need a service to show a banner on their applications? Or would they just build a simple module that would display something, or use the built-in flash message functionality of their frameworks?
If I jumped into developing such a service without validating the problem first, I would learn that no one would pay money for this much too late. Just because I am a member of the audience that I would build this for, this does not mean that I don’t need to validate my market and the problem I am trying to solve.
In fact, with all three examples above, I have made the cardinal mistake of many entrepreneurs: I’ve approached this from a product-first perspective. As an engineer, I needed to come up with a solution that was good enough to solve these issues when I encountered them. And then, I just generalized them into a SaaS idea. Do I really want to take the first thing that came to my mind when I had to come up with a solution quickly? Is it smart to turn this flaky idea into a business that is supposed to pay my bills for many years?
If I were to build a developer-focussed SaaS right now, I would look for a niche in the industry and then try to find the most critical problem that keeps them from where they want to be. There will be product ideas aplenty, but they come after you’ve researched the issues, not before.
Because I want to shine the light on the assumptions and risks of developers building for developers, let’s take an honest look at the industry and the common talking-points about it.
Assumption #1: Everything already exists
While there are definitely saturated fields in the software industry, you see successful niche products be successful every day. Look at Github’s recent acquisitions: code analysis tools, deployment automation systems, all particular kinds of services that could be cobbled together with open-source tools.
So what’s the secret here? Platform integrations that have interoperability as a first-class citizen. Understanding that developers don’t want to use your tool in isolation, but integrate it into their existing workflows. The market may be saturated with solutions, but few of them integrate well.
Build your developer product, assuming that it will be part of a toolchain — offer developer-friendly APIs and integrations from the start.
Assumption #2: Developers don’t pay for things
This is true, but only for a specific kind of developer. Hobbyists and freelancers will likely shy away from paid services. But inside the corporate world, people are well aware of the value of existing solutions to painful problems. If you’re trying to sell to the Indie Hacker crowd, you might notice that few developers there have any meaningful budget for tools. If instead, you target software businesses with a few employees and an MRR north of $30k, you will notice that all of a sudden, you have customers who can afford to pay a few hundred dollars per month for specific solutions to specific problems.
Build your developer product for an audience that can reliably budget for tooling. Avoid selling to hobbyists.
Assumption #3: There are too many free options
When I started building FeedbackPanda, I realized that I could save a lot of money by running my own PostgreSQL database. Two minutes later, I had scrapped that idea and paid for a DBaaS subscription. As a solo developer, I didn’t want to be responsible for yet another thing. And I’d rather pay a business that has admins and engineers on-call than having to wake up at three in the morning to restart a database.
You can assume that even though there are a lot of free options, many of them open-source, serious developers will want to focus on the things they care about instead of maintaining a zoo of installations and servers. Remember the famous Dropbox criticism on Hacker News, stating that this could be built with free tools? The comment is correct, but it’s also completely missing the point. A solution to a problem is only useful if it removes responsibility and decreases effort, not add to it.
Build your developer product, assuming that people who genuinely need a solution to their problem will choose to pay experts, not expect themselves to solve it.
Assumption #4: Competitors can push newcomers out of business easily
Most large software businesses have built platforms. These often allow them to release completely new features quickly. When Intercom released its highly integrated onboarding tool Product Tours, a lot of SaaS businesses that only offered guided onboarding tools and widgets suddenly found themselves pushed into the fringes of the market.
You won’t be able to avoid that risk entirely. But you don’t have to control the full market either. Serving a niche will be more than enough for your bootstrapped SaaS, and solving one problem extremely well will make sure that no competitor can easily clone your business.
Build your developer product as a laser-focused solution to a critical problem of a niche audience.
Assumption #5: The industry is continuously changing
New services are launched every day. New requirements and regulations get introduced regularly. Remember the GDPR craze? The introduction of that legislation allowed for the creation of a lot of SaaS businesses that deal exclusively with cookie banners. There will be an opportunity; new niches are forming every day.
That also means that established businesses need to react to shifts in the industry landscape. Your company might run well for many years, only to become completely obsolete with one change in regulation. It might be enough for your customers’ industry to encounter these regulatory changes: at FeedbackPanda, we had to react to a change in Chinese law that didn’t affect us, but our freelance customers’ employers in China. In an interconnected world, you will need to pay attention to a lot of things.
Build your developer product, assuming that it will need to change substantially over time.
So, is it worth for a developer to build a SaaS for other developers? It definitely can be a fantastic experience, and there are many opportunities.
If you’d ask me what to build today, I would suggest creating a developer B2B product that integrates and can be integrated with easily, solves a proven niche market problem, and is extensible enough to withstand the tides of time. It can definitely be done.
Links I Found Interesting
This article about the coffee-cup pricing fallacy and the surrounding discussion on Hacker News are thought-provoking takes on pricing, anchoring, and relative value. If you’ve ever had trouble finding the right price for your product, this will help you think about framing the conversation the next time you talk about prices.
Have you ever worked with influencers? We’ve done that at FeedbackPanda, to significant effect. Afolabi gives a few helpful tips on how to approach and interact with influencers as a bootstrapper. My main takeaway: build a relationship and give before you receive.
If you want to take your startup to the next level, this comprehensive list of over 230 incubators and accelerators compiled by Bugra might be beneficial. And if you don’t, it’s still good to see what is being funded, and where the communities are.
Bootstrapping Success Stories I Noticed
Pascal Precht self-published an eBook called REBASE (about the internals of git and rebasing) a few weeks ago, and he has been documenting his success on Indie Hackers. He pre-sold a lot of copies and has now reached $4000 in revenue. I sure hope he writes about how to self-publish a book because you can learn a lot from his approach to marketing and sales.
Makerpad now made it to 1000 paying Pro members, reported Ben Tossell this week. This is a blessing for what I consider to be a community that will impact whole future generations of Indie Hackers and makers, and I am so glad to see it being a sustainable business.
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
