Dear founder,
I want to talk to you about bias today, in two ways. You will find an essay on conversational biases further down in the Bootstrapping in Practice section, where I reflect on my own past and present unquestioned assumptions when it comes to talking about technical issues. But let’s first talk about a sneaky bias that entrepreneurs often encounter: our tendency to avoid validating our beliefs, particularly when it comes to Solution Validation.
We have great ideas; we see solutions where others don’t. We have an entrepreneurial spark. People tell us it won’t work, and we ignore them. They want faster horses instead of cars, and we ignore them.
And then we start ignoring our own doubts. We have the nagging feeling that we might be too optimistic, but we suppress it — after all, we’re told to “stick with it,” to “hustle more than anyone else,” so we take our idea and try to make it happen, against all the odds.
Well, the startup graveyards are full of projects that founders have “stuck with” for too long. Too many tombstones with cheaply chiseled “they hustled, but had no customers.”
How can we avoid this, you ask?
Validate your assumptions. Verify that what you expect to be true is actually true.
It all starts with your audience. After you picked a niche, you’ll need to determine the size of your market and make sure it can support your business. Once you’ve verified that you’re in the Goldilocks zone of being small enough to avoid giant competitors but big enough to sustain your bootstrapped business, you will need to find out what their critical problems are, and pick one. Again, you will need to validate your perception: is the problem you’re solving really critical? Is it a common problem in your niche?
Let’s say you have done this. You’ve found a great niche and a critical problem that will make people spend money on your solution. You start working on your solution. You know precisely what they need, so you build your prototype and start selling the first version.
But people don’t buy it. They try out your solution, but they don’t convert.
What happened? You did all the validation, right?
No. You missed a crucial step, one of the most costly steps to miss. You never validated that your solution would solve your customer’s problems in a way that worked for them.
Solution Validation is different from Problem Validation. When you were searching for problems to solve, you were trying to discover problems. You were listening to your customers to see where they needed help. Solution Validation is a very different conversation. Your goal here is to find answers to these two questions:
“Does my solution fit into my customer’s existing workflow?”
You’re trying to find out if you’re compatible with their existing approach to doing their work. Find out if your assumptions about where in that workflow your tool is used, and find out if there are surprising side-effects and use cases you may have missed.
“Does my solution solve a job-to-be-done?”
If it does, look out for ways your product could be interfering with existing structures: what or who are you replacing? A script? An intern? A whole job, maybe even a department? Depending on what is already in place, your solution may or may not be welcome. Find the friction points and envision ways to avoid it.
Solution Validation does not require a finished product. All you need is to talk to a prospect. Make your prospective customer understand how you would be solving their problem, and have them think of where it fits in their workflow, what they would do before and after solving their problem, and who is involved.
If you want to read more about Solution Validation, please enjoy the article called Solution Validation Doesn’t Happen In a Vacuum: How to Talk To Your Future Customers
Links I Found Interesting
Harry Dry posted one of his articles on Twitter, which was greeted with an attack from the Twitter mob. The ensuing chaos shines an interesting light at the conversational dynamics of Twitter, and the Indie Hackers thread provides some good insight into how you can deal with this, should it ever happen to you. I particularly like how Harry shows his interaction with his sponsors.
Rodolphe of Remotive, a remote job board, published a list of 2,500 Startups Hiring Remotely in 2020. If you’re looking for a work-from-home gig as you’re preparing for your bootstrapping journey, which I would highly recommend, check it out.
David Darmanin from Hotjar talks about bootstrapping the business to $25m in ARR in the SaaS Revolution Show. He presents his experience with having an Operations Manual, how to deal with burnout, and how to run a fully remote company. The episode has several interesting learnings about content strategy as well.
Bootstrapping Successes
Moonlight being acquired by PullRequest was a big success this week. The remote-developer-hiring-platform was acquihired, with both founders joining the Code-Review-as-a-Service business. This strongly reminded me of selling FeedbackPanda, as we were just two people selling to a much bigger entity as well, and we also sold around the $55k MRR mark. Congratulations, Philip and Emma. Well deserved!
Adriaan of Simple Analytics reported reaching $4k MRR. He also started sharing more information publicly: it’s looking good for Simple Analytics. I feel that posts like this are genius: you show how ambitious you are, what risks you take, what goals you have, and how this maps onto the reality of your business. Business is about building trust and relationships. Adriaan has that figured out.
In an unusual and rare case of (supposedly impossible) Open Source monetization, Zeno launched the theme Dracula Pro and made $3,149.37 in less than 24 hours. I love this. Selling to developers is hard (which I talked about this last week), and he points out one major thing that he focussed on: selling future productivity, not just a mere theme. Sell where people want to be, not the contraption they need to get there. An important lesson for those of us who have yet to learn the core tenants of sales. Particularly when it comes to selling to developers.
Bootstrapping in Practice – Biased Edition
Talking about developers, I have been noticing a fascinating trend on Twitter: my followers are very attentive and thoughtful in conversations about entrepreneurial topics, but almost ruthlessly determined to defend their views when it comes to talking about engineering.
It’s not that I’m surprised: most people that I follow are developers or at least have an affinity for tech. Being a developer myself, I know the feeling of having a strong position of “how things should be” and defending it staunchly. I know the feeling of wanting to be right and showing other people “the way.”
Only recently have I learned that this is a very limiting belief. Let me explain how that happened, what restrictions it imposes, and how I think it can be overcome.
I consider myself an “engineer-turned-entrepreneur.” An engipreneur, even. For most of my professional life, I have been paid to solve someone else’s problems using technology. As a developer, I talked a lot about “the right tools,” “the best stack,” and “the perfect abstraction.” Most other engineers I met at my day job or meetups and conferences, would speak about their work the same way.
If there were debates, they would be fierce and full of supposedly “non-emotional” and “logical” arguments. People would proverbially bash their heads in over programming language choices or which database is the most reliable. It was almost comical: whole communities would go to war over which programming languages are the best, even though all of them would be able to solve the business problems they needed to address.
I believed that the technologies I had been using so efficiently to solve problems were the best technologies for the task. I knew there were other options, but if they were indeed better, wouldn’t I have chosen them instead? In retrospect, it was a self-fulfilling prophecy: the tools I had used before became the tools I used exclusively, and they were the tools I would try first on every job. Talk about everything looking like nails when you have a hammer!
It was running a business that made me realize how dangerous and limiting my prior perspective was.
When I was a salaried employee, my work was focussed on a specific subset of problems, with a particular suite of technical solutions that someone else had deemed “the best set of tools.” They had hired me because I was experienced in using them. The CTO wanted the team to learn a new language to solve the problems better? Sure, I’ll learn that. Now I knew another “best tool” that I could tell other people to use if they encountered similar problems.
But when I started to build FeedbackPanda back in 2017, there were no guidelines. There was no “best tool,” there was just an audience, a problem, our idea, and me. There were no similar problems; everything looked unfamiliar, daunting, and complicated. I could draw on my engineering experience, sure. But there was a lot of undiscovered space on the map of the world I had just entered.
Let’s just say that I learned that I was heavily biased. And once I understood that, I saw the bias in my former colleagues, and I see the same bias in the discussion on Twitter now.
These biases that served us well as engineers are holding us back as entrepreneurs. We’re venturing into the unknown, and clinging to limiting beliefs will make the journey much harder.
As technical specialists, we’re biased in a few ways, and I would like to point them out so that you can search inside yourself.
Availability Heuristics: “This happened to me before, and I solved it using X, so X is the right way to do it.” Relying solely on anecdotal experiences from my own engineering adventures often caused me to think that I made correct choices. Ultimately, I merely made informed guesses and then executed well on them. It helps to recontextualize things to avoid this bias. Ask, “What is different this time?”
Confirmation Bias: The classic. Whenever I read something about the programming language Elixir being used successfully for a project, I made a mental note that I made a great choice. When I read that it wasn’t a good fit, I questioned the skill level of the engineers that made those statements. Instead of learning from someone’s experience, I would dismiss it. It seems incredible to me now what an ignorant person I used to be. But it made perfect sense: I knew what I was talking about, being the self-proclaimed expert. Whenever I detect this tendency now, I force myself to slowly and consciously read the other person’s arguments, taking their perspective, as I understand that they, like me, are working from the standpoint of anecdotal evidence.
Inattentional Blindness: We don’t see things we don’t expect, even when they’re staring us in the face. How often have I brooded over a problem, buried deep in technical details, only to start over from the top and immediately finding a critical misconfiguration I had missed before. This happens on a broader scale, too: we know what we know, we think we know what we can expect, and if reality deviates from our expectations, we subconsciously dismiss the truth right in front of us.
Authority Bias: This is the most prevalent and fiendish bias I encounter, and it’s everywhere. We follow our heroes, and we ignore our enemies. If you’re a Rails developer, you will be inclined to trust the musings of the thought leaders in that field, and this tendency extends into much smaller circles as well: you’re encouraged to believe and do what your technical team lead tells you. Being consistently rewarded for obedience bores into your cognition, forming unquestioned assumptions. “Of course we’ll build our deployment toolchain using Jenkins, that’s what our CTO has been using for years, and look how well it seems to have worked for him. Of course, we’ll build a microservice architecture; the newly hired lead developer has written a book on the issue.” It’s hard to see bias when your paycheck depends on not speaking up too much about it.
While this turned from a rant to self-reflection and back to a rant, I want to end with this: even biased discussions allow for reflection, growth, and the production of knowledge. Running a business, charging head-first into challenges with often anxiety-inducing complexity, I have learned to be a bit more humble and to listen to others’ opinions instead of standing my ground.
I’ve learned that engineering and business advice is highly anecdotal, including my own, so it’s neither right nor wrong: it works for you, or it doesn’t. Just like your tech stack.
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 and wherever you like, or reach out on Twitter at @arvidkahl.
See you next week!
Warm Regards from Berlin,
Arvid