Typical problems of technical founders
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.
— Patrick McKenzie
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 percent finished and polished product before starting to sell it. You can offer fewer features than competitors but solve some problems better than they do.
In general, features are not your friends. Every single one of them 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.
— Rob Walling
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 increase the chances of getting noticed by somebody who's interested in what you are doing — 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 a lot of developers worry too much about it and barely act as a result. And if you are 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.
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, which leads to filtering out some aspects. Your perception becomes rigid. This is the reason to 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 because of staying in the 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 possible difficulties in the daily 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.
— Tyler Tringas
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.
— Werner Heisenberg
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.
Hope all of this helps. Follow me on Twitter where I share tips and stories about indie software business.
