FOR REASONS I’m reading a lot of startup literature right now, including Zero to Sold, The Mom Test, Four Steps to the Epiphany, and The Lean Startup. One thing all of these books have in common is that they say the old line of “build and they will come“ is wrong.
Considering myself a technical type, and being quite self-critical, I’ve started to pay a lot of attention to my own thinking to make sure I won’t fall into this “build trap” (another book I should probably read, btw).
I think that judging technical people as being too solution oriented is too simple. Certainly, jumping to the technical solution is something that comes most natural to us, but it’s premature to dismiss solution oriented thinking.
Here is why:
- Typically, a lot of thinking has gone into shaping these solutions. These are often based on first hand struggles and pain points, which is very valuable real-world validation.
- Potential consequences and constraints have also been considered in depth. Thinking about “but what happens if” is one of the strength of engineering thinking. “What happens if people are in a tunnel and have no Internet access?” “What happens if people have an empty cart?” The solution will typically already have considered and adapted to many these constraints.
- I never believed that you could get to new innovative products by just making a list of what customers want. I believe there is always some creative act in creating a product, however small it may be, and that’s exactly what a creating a solution does.
Uncovering Assumptions
That doesn’t mean that solutions are always great. In fact they often aren‘t (as is probably the case with most first iterations). Often there is an over emphasis of feasibility over desirability or viability.
I think the aspects that are already considered need to be actively unearthed. Who is this for? Why would they need it? Would they be willing to pay for it? How do we make money? Who are the competitors? How would we sell and market this? Four Steps to the Epiphany has very nice templates to guide these discussions.
Then you can take a good look at all those assumptions and see whether there is any evidence for or against them. Which brings us to the next part.
Where Technical Thinking Struggles
Engineers like to think about “what could go wrong” because they need to design systems that are resilient and failure proof. We are trained to look for edge cases. What happens if we run out of memory? What happens if the input is empty? What happens if there is a denial-of-service attack? This kind of thinking makes total sense if you run a website with a thousand visitors each second. Sooner or later some of these edge cases are bound to happen.
While this kind of thinking is great for making systems failure proof, it can lead to loosing focus of the big picture and focussing on irrelevant aspects. If you build a product for customers, it should solve a problem for the majority of the customers, not just the edge cases. In fact, you might not even care about the edge cases. When building MVPs you need to simplify your products. That’s the opposite of trying to cover all the edge cases.
Another aspect of technical thinking is that we are used to mathematical truths and hard facts. If you can prove that from A follows B then that is always true. If you need to sort numbers, there is an algorithm that always works. If you want to store 500GB of data, you know how different technologies will perform for which access patterns.
But when developing a product, you don’t deal with facts but with uncertainty. Machines and programs predictable because they are designed this way, but humans are different.
As an engineer, you’re used to taking a problem, coming up with a solution, seeing some unintended consequences, fixing those till you have something that looks good.
But when you apply that kind of thinking when creating product or businesses, you might go from an unvalidated problem statement to a solution that does not actually solve the problem, to a consequence, which is an edge case and not relevant, to an overly complex solution that doesn’t solve a real world problem.
(Note that this is a worst case scenario argument. Look how I’m trying to appeal to technical people!)
In Summary
I think technical founders have a bad reputation which is unwarranted. Solution oriented thinking is an essential creative step that already considers many aspects of the problem. But you need to take a step back and make the underlying assumptions explicit so you can start to test them.
In addition, there is a difference between thinking when the facts are clear and when there is uncertainty. Uncertainties can often not be resolved purely by thinking. You need to devise experiments to test your hypothesis. Just like a physicist.
Reading the Mom Test was a real eye-opener for me. When you ask people „what do you think, would you use this?“ you won‘t get hard data. They might like you and tell you what they think you want to hear. They also have no stake in this. „Sure I could be using this…“ has no commitment so there is nothing to consider for people.
Interestingly, there are more patterns that indicate that some things aren’t hard data, like overgeneralizations, predictions which are only opinions, and assumptions of what people think, versus things that actually happened and can be objectively observed.
For the non-technical people reading this, my plea is to not dismiss the solution centric approach but engage in a discussion about the underlying assumptions and implications. I‘m sure you’ll often find a treasure trove of thinking that already went into exploring all kinds of product related aspects.
Marginally Interesting by Mikio L. Braun 