Guiding Principles: Diagnose Before We Prescribe
When anyone has an idea for a new product, application, or business - they usually take a mental shortcut straight to the solution. Many times it’s because we’ve experienced the problem in our own lives, or someone close to us has talked to us about a problem they were having. Even with this preliminary knowledge about the problem, if we truly want to create the right solution, we need to dive deeper into the problem to understand the motivations, pains, and gains we achieve by solving it.
We diagnose before we prescribe
Don't let inventor's bias control your destiny
When anyone has an idea for a new product, application, or business - they usually take a mental shortcut straight to the solution. Once we’ve formed a solution in our minds, it’s really difficult to step away from it and see the forest through the trees to identify why we’re creating it in the first place.
Many times it’s because we’ve experienced the problem in our own lives, or someone close to us has talked to us about a problem they were having. Even with this preliminary knowledge about the problem, if we truly want to create the right solution, we need to dive deeper into the problem to understand the motivations, pains, and gains we achieve by solving it.
Doctors don't and neither do we
A doctor wouldn’t prescribe you medicine or surgery just based on how you said you felt, and we vow not to do that through software here at Headway as well.
A doctor is going to poke, prod, and run tests on you, maybe compare it to a pool of previous results, and then offer up a potential solution for you based on what they’ve found.
At Headway, it’s no different. You come to us with an idea for a solution and we immediately start to unpack the assumptions around that solution. Why are you creating it? What’s the actual problem? What do we know about our users and their motivations? What are the pains and gains in our customer’s life? What’s the value we assume they’ll get out of it?
Rank our riskiest assumptions
Once we understand the problem space, we start to rank our assumptions from riskiest to most certain and start to create hypothesis for our top assumptions and how we’ll validate them.
It’s really important that we do this because there can be major roadblocks that if we don’t put those first, we could end up wasting time and valuable resources - both of which are not on a startup’s side to begin with.
What happens if you don't diagnose before you prescribe?
Building on assumptions is dangerous. In most cases, it’s fatal.
Unfortunately we’ve seen it happen too many times. Teams put a high value on their assumptions and no value on gathering actual data from users, actions, and even revenue-generating activities.
It typically ends in an unsuccessful launch after a year of development with only a couple sign-ups and no go-to-market strategy.
One of the biggest myths in building a business, a building, and even your product, is this idea that if you build it, they will come.
“If you build it, they will come.”
It’s hard to de-couple the mental bias we have towards our proposed solution in the beginning. “If I just build it and launch, I know that people will love this, they have to!”
Start small and make progress
Find out why people need your product, what motivations they have to purchase your product, and what makes them buy!
Again, businesses don’t fail because they can’t build it or execute, they fail because they build something no one wants and therefore can’t generate the sales necessary to build a business.
Start now. Start small. Build evidence.
Fall in love with solving the problem, not your solution.
