Blind spots are harsh. You can struggle with something for years, only to realize that an obvious problem in your thinking has been undermining your efforts all along. In the past I wasted a six-digit investment by starting a project with many incorrect assumptions and didn't realize it until the company ran out of money. While failures like this helped me to discover some of my blind spots, I am pretty sure that several big ones are still right in front of me.
Running a software business is hard, and developers who are trying to build their own products tend to have similar issues. It probably happens because our previous software engineering experience has given us a similar set of cognitive biases—so-called professional deformation. Unfortunately, I can't say that it's easy to unlearn these biases completely, but knowing where to look can reduce their negative effects.
The gravity of engineering
Engineering constantly acts like a strong gravitational force that drags you from business tasks again and again. Nontechnical entrepreneurs usually perceive development as a cost center. Their main goal is a profitable business, and creating software is an expensive obstacle on the way there. But for developers, writing code is relatively easy, so we often jump into adding extra features or overcomplicating the project without thinking twice.
Probably the worst case is picking features or even business ideas because they look technically challenging and fun. It may work every once in a while, but generally these decisions should be made based on the market research—like talking with potential or existing customers.
90% of the results of your business, and somewhere around 90% of the effort, are caused by non-coding activities: dealing with pre-sales inquiries, marketing, SEO, marketing, customer support, marketing, website copywriting, marketing, etc.
Then there is the black hole of building and maintaining internal tools. While sometimes this work may seem unavoidable, if it takes more than a week to hack together, beware! Its gravity can completely collapse your project. Most of the time, you can find an existing solution that will save you a lot of money in the long run, even if it requires an expensive subscription.
Less dangerous but still a serious problem is using development to escape another entrepreneur's chores. Even hard engineering problems start looking really comfortable when you face vague tasks like "do marketing" or "improve the landing page." So it's useful to have your priorities arranged with something like the Eisenhower Matrix.
Recommendations
- Don't write any code without doing market research first.
- Use time-proven "boring" tech stacks, especially if you know them already. Avoid the trendy ones because they have more bugs, less documentation, less libraries, and less developers available for hire.
- Pick the simplest implementations possible: a third-party service, a bash script, an automation via Zapier, or even something manual on a support request.
- If you have higher priority business tasks, treat writing code as procrastination.
Overthinking and perfectionism
When you are designing and managing your first independent products, the freedom may become overwhelming. During one of my first projects, I studied the available tech solutions for almost a month, only to abandon the idea later. Not a single line of code was written.
To avoid situations like this, it's useful to set some constraints and then actually follow them. For example, go with the best available option after a week of research, or impose a deadline for the release and try your best to meet it. Don't worry about the release not being perfect: there's no need to have a 100% finished and polished product before starting to sell it. You can offer fewer features than competitors, but still solve some problems better than they do.
In general, features are not your friends. Every single extra feature clutters the UI, adds more bugs, complicates code maintenance, and increases the number of support requests. This is why the "minimum viable product" approach is so efficient: it both validates the core idea and collects customer feedback to develop the correct set of features according to the real needs of the market.
As a developer, I always think features first and I have to actively ask myself, so what? The app can do this, this, that, and this. So what? Then that gets me to the benefits. I think marketers tend to think that way and developers tend to think in terms of features.
The customers also don't care if your software has a perfect code base or uses complex algorithms—they "hire" products to get some jobs done. A lot of successful software was hacked together initially, but gradually improved after obtaining its first customers. On the other hand, there are countless products that didn't make it into release because their authors tried to "make it right this time" and got lost in perfectionism.
Recommendations
- Set and follow deadlines to overcome perfectionism.
- Focus on benefits, not features.
- Aim to release as soon as possible to validate your idea and let the market direct further improvements.
- If it's your first try, start small.
Introversion
As a person who forces himself to be public, I totally understand the desire to stay comfortably reclusive. Sadly, it significantly reduces the probability of success: nobody will know about your product unless you talk about it loudly across the internet. It is especially true for business software that can't go viral, but even virality requires a lot of initial promotion to break through the noise and get traction.
Regular publicity and networking increases the chances of getting noticed by somebody who's interested in what you are doing— be they future customers, other entrepreneurs with a useful second opinion, or even a reporter writing about products like yours. Yes, there is a limit after which you can be labeled as a "self-promoter," but developers often worry too much about the stigma, and barely act as a result. If you’re working on business software, doing sales is essential: business people send and receive offers all the time and won't get offended by a personalized pitch.
Most hackers who start startups wish they could do it by just writing some clever software, putting it on a server somewhere, and watching the money roll in—without ever having to talk to users, or negotiate with other companies, or deal with other people's broken code. Maybe that's possible, but I haven't seen it.
Missing the opportunities for promotion is not the only consequence of introverted development. When working on something for too long, you get to know it “too well”. This leads to sneaky blind spots that you won’t be able to catch. Every bootstrapper has encountered this before: your perception becomes narrower the more you work on a project, and you end up missing things that should be obvious. In order to combat this, we need fresh eyes on our projects. Ask for feedback often and from different people; they have a "beginner's mind" and can give you a new perspective because other people have different expectations.
Another unexpected danger of coding too much and socializing too little is the decrease in empathy. It’s mostly the side effect of staying in and analytical state of mind all the time. I don't know if it's that strong for everyone, but I definitely feel social numbness after weeklong coding marathons. Apart from complicating your personal life, the loss of empathy is harmful for marketing and product management because it inhibits the understanding of how others perceive your product.
Recommendations
- Work on marketing and promotion at least once every week. It doesn't matter if you don't have anything to show — talk about your idea and the building process.
- Don't shy away from contacting people you don't know — it is the core of doing business.
- Regularly ask for feedback from others to tune your own perception.
Living in a tech bubble
Modern software development is extremely demanding: we have to constantly learn and update our knowledge of languages, frameworks, tools, and ever-changing platform APIs. Professional growth often takes up our time outside of work hours, and many software engineers tend to choose tech-related hobbies. But unfortunately, being so invested in technology can also undermine your success in a few ways.
The first problem is losing the sense of how the majority uses software products because you mostly interact with "power users." In tech communities, you can often see people puzzled and even enraged by facts like Slack being so popular when it's "basically IRC" or the iPhone selling so well when Android devices are more flexible and affordable. Usually the explanation is along the lines of "consumers are fooled by marketing," but this is an example of lazy thinking. There's a lot to learn from these products about user experience and its importance for a nontechnical person.
Of course, it is possible to create software for other developers, but this niche is already too crowded. The same goes for the obvious consumer and business ideas: if you can think of some generic problem, then the market is probably oversaturated with decent solutions. For this reason, finding great ideas depends on forcing yourself out of the tech bubble and exploring the obscure needs of other industries or unusual lifestyles.
If something about your life is really unique, then you can use "scratch your own itch" in that area. If you are a freelance graphic designer in San Francisco who likes yoga and green juice, you're going to need a different strategy.
The other challenge for entrepreneurs with tech backgrounds is getting more familiar with fields beyond natural sciences and engineering. Every business relies heavily on psychology and social intelligence: product design, UX design, marketing, sales, and PR are are all based in understanding the needs and behaviors of others. Finally, regular news about the disturbing behavior of tech companies indicates that we all should be more skilled in philosophy and ethics.
My mind was formed by studying philosophy, Plato and that sort of thing.
It may seem that just by being rational engineers we can easily deduce all the answers in these fields, but from my own experience it's the Dunning–Kruger effect in action. These are complex disciplines that were developed through centuries of research, and they can improve your thinking tremendously.
Recommendations
- Observe how nontechnical people interact with software and what assumptions do they have.
- Study the popular products, even if you don't like their use cases.
- Look for opportunities to get in touch with different niches and industries to understand how they function.
- Spend some time weekly on diving into subjects like design and marketing — to start, check the links in my guide to useful skills for a founder.
Wrapping up
The aim of this article isn’t to discourage developers from bootstrapping; in fact, it’s quite the opposite. Armed with this information developers who journey to “the other side” of SaaS should come out unscathed and excited for the future of their product. Keep these recommendations in mind when exploring the full extent of your startup project, and I promise you’ll feel more effective (on top of feeling mentally healthy). Best of luck, indie hackers!
Illustrations by Irina Mir
Hey Ivan,
This is quite on point!
I'm not a developer, but I have some friends who do coding for a living, and they're at the beginning of their startup journey.
A lot of them seem to struggle with people skills, and that has a significant effect on their ideas and products.
The main mistake they make is they try to create the product more for themselves than the people who would use it. In many cases, the people who are about to use their products are not that tech-savvy and use entirely different lingo.
That makes the products seem quite advanced for people, and it is hard to understand what they actually do.
I've found that it's quite beneficial to watch non-technical people using a product for the first time. It's a painful experience to see someone missing an "obvious" UI flow you created but it helps to internalize the non-tech-savvy perception of software.
Great post Ivan, totally agree. There's a separation between the "problem space" and the "solution space" (to quote Dan Olson from The Lean Product Playbook) and too often we jump into the solution without considering the problem. (Because let's face it we get really excited about the solution.)
Nice post, thanks
But where are "Illustrations by Irina Mir"?
Thank you! Both the header illustration with a vortex and the "separators" between the article's sections were made by Irina.
This comment was deleted 4 years ago.
This comment was deleted 5 years ago.
This comment was deleted 2 years ago.
Thank you! Yep, we can progress faster than others but it also means we can go in a wrong direction much further.