Should you validate your product vision?
I think it was Paul Graham who once said, “Most startups fail because they’re solving problems that nobody has.”
Fact is, he’s right. Companies often fail because they don’t take the time to understand if the product they are building is solving real-world problems. (Does anyone remember Juicero?)
Today I’d like to take some time to talk about product concept validation, some common mistakes, and how to break out of a cycle of ongoing derailment and potential failure.
TLDR
Remove bias by testing your hypotheses, not validating your assumptions.
Stay focused and on course and avoid shiny object syndrome.
Share your concept and roadmap with your entire company - not just a select few.
Validation does not literally mean validation
The term “validation” is a bit of a two-edged sword. While the idea behind it is to understand if the product you’re building will find market fit, a lot of people take the word “validation” as the process of proving themselves right.
Validation is about testing and understanding where your product solves a problem, where it does not, and what gaps you can potentially fill to truly find a competitive edge. It does not mean going out and proving that you’re right - because the reality is, most of the time you might not be.
Not being right is the best thing that can happen to any product leader or founder. It means you have the opportunity to learn things you weren’t previously aware of, and even find ways to solve problems that you hadn’t thought of before.
As you’re getting ready to validate your product concept, remember you’re not there to prove yourself right. Instead, open up to the possibility that there are a lot of things you might not know - and understanding those will help you build a better product.
Stay focused and on course
Once you have found a product-market fit and you’re in the process of developing your product, it’s easy to get excited by the feedback of others. But there is also such a thing as too excited.
Avoid the temptation of completely pivoting what you’re working on just because someone said they may sign up for your product if it only did that one thing they’re looking for. If that feature or functionality does not currently fit your goals, you’re likely adding more distraction to your team.
But also don’t take the opposite approach and never listen to feedback. There’s a middle ground here! Listen to feedback, link that feedback to problems, and see how those problems potentially align with your product concept, goals, and overall vision.
What you really want to avoid is derailing your team because one customer said they’d like a feature that you don’t have. It is far more important to build things that have a higher impact on a wider audience, rather than a high impact on a single customer.
A good way to focus on solving the right problems is by asking two really simple questions: What problem are we solving, and why might this be important to the customer? Supplement this with research and feedback, and figure out what the best solution might be for your wider audience.
In other words: don’t build features for a single customer, but solve problems for your target market.
Visibility and transparency for your entire team
I’ve seen several companies keep the vision and roadmap siloed within the product team. There appears to be this fear that somehow sharing these documents will cause leaks, false promises, and derailment when often the opposite is true.
The best thing you can do for yourself and your team is to be transparent about what your product concept is and the future direction. Features are promised when there’s little understanding of what the product is actually meant to do (and not do.)
When you fail to align teams, it is only then that things really start breaking apart. Rally everyone around your vision and roadmap, and work together to achieve your goals and outcomes.
