Have you ‘lived’ the problem you propose to solve?
Problem solution hypothesis.
For any startup, beginning with the problem you plan to solve is generally sound advice. Of course, there are some startups with a ‘future vision’ so groundbreaking that the market didn’t even realise it wanted it yet (iPhone, Chat GPT, Uber). These are not strictly solving a problem, they are a different category and perhaps a topic for another post.
How much do you actually need to know about the problem?
In my ‘Hardware is hard!’ post, I emphasised that “you don’t need to have lived the problem”, but if you haven’t, you must immerse yourself in it. Why the emphasis?
Pretty much every ‘problem-oriented’ startup pitch I’ve seen includes an origin story about how founders experienced the problem and then set out to solve it. You might ask, “Isn’t this them ‘living’ or ‘immersing’ themself in the problem?”
Real-world evidence suggests this isn’t necessarily the case.
All the research I’ve encountered shows that the most common reason for startup failure is not that they couldn’t get the technology to work, but rather that they built something for which there was no market need. From my own experience, observing post-launch startups struggling to find product-market fit, I would wholeheartedly agree with this.
It is rare that the product built is completely ‘wrong’ (although I have seen these extreme cases). More commonly, the underlying technological capability could indeed benefit users, but there is something subtly ‘wrong enough’ in the details that limits or even acts as a barrier to adoption. It’s also common that far fewer real potential users exist than projected (or hoped), often due to a significant overestimation of the problem’s scale and, consequently, the number of people experiencing it.
These ‘near misses’ can be devastating for the startup. Frustratingly, it would often have been no harder or more costly to develop the ‘right’ product (or at least ‘right enough’) from the start. The issue here is with the founder’s limited domain knowledge, ignoring potential ‘unknown unknowns’ and also being unaware of the assumptions they are making—assumptions that would need to hold true for their ‘problem : solution hypothesis’ to be valid.
Whether the founder realises or not they start out with ‘problem solution hypothesis’. The ‘problem’ part is no doubt based on some facts, real knowledge, and accurate observation, but also a significant number of assumptions.
Founders who have ‘lived the problem’ often don’t even realise what they know—they just know it. While they may not have a solution yet, they instinctively understand what the solution must achieve. On the other hand, founders who, when it comes to the crunch, only superficially understood the problem, have far more assumptions in their risk stack—more than they even realise.
Having a set of assumptions isn’t a problem in itself. The real issue arises when founders push forward and build without understanding, validating or challenging their assumptions. When they do this, they ‘bake in’ their worldview into their product. When it later becomes clear that at least some of those assumptions were incorrect (which is almost guaranteed the case), they are left with a rigid product offering that will be very costly and time-consuming to unwind and rebuild, to solve actual need.
This issue is absolutely not limited to hardware development alone. It is completely applicable to all ‘problem solution’ oriented startups. However, the costs and time required to correct course and meet real need is much higher for hardware than software. For a hardware startup, get your offering too far off and you probably don’t have enough cash or time to rebuild and it could very well be game-over.
This is also not only related to the ‘product’ you build, this indeed relates to all aspects of your solution offering, within the whole business model you plan to operate.
Contact us to learn about how we can help you understand the assumptions within your startup, how deeply you need to immerse yourself in the domain problem and to do this without adding significant time delay into your early stage development process.
