How to validate product ideas quickly

Image Credits: https://fugenxmobileappdevelopment.medium.com/

Ideas are amazing.

In a perfect world, we’d want to build everything based on our gut feeling.

The issue is, it’s a world with limited resources and a limited human attention span. If you build something that takes up time, energy and a lot of resources to build, and in return doesn’t create much value for your customers and your business, then it gets rolled back, gets a ‘lesson learned’ tag, and could also hurt your business numbers — sometimes severely.

If I break down why something you build could fail in the market, it comes down to three key things:

1. Inadequate understanding of your market
2. Overthinking, concerning how customers make purchase decisions
3. Insufficient or low-quality data used for idea validation before it gets implemented

Unlike how everyone writes or talks about data-driven or data-informed product development, somehow, all of that seems too structured and idealistic to me.

In the real world, not all organisations will have properly organised data, an excellent data ecosystem that helps the Product team make super decisions.

Teams are also expected to move and ship faster. That’s why improvisation becomes crucial in the real world.

Once something is shipped, the data it generates should be great to work with. This excellent historical data would help make solid product decisions in future.

Typically, data-driven product development relies on the following:

1. Quantifiable data

2. Brainstorming

3. Observing Competition

4. Anecdotal Evidence

5. Qualitative data

• Quantifiable data is fun but hard to acquire. It requires expensive tools and a data wizard to use them. Do understand, even that person could get “data-fatigued”. ;) Also, new ideas won’t have any quantifiable data, and buying data reports from researchers can be a costly affair
• Brainstorming is my favourite activity. If you work in a super-competent Product team, you’ll see the wonders of brainstorming almost every week. If you are luckier, you will find enough team-time to do those brainstorming sessions. Problem is, even the most capable Product people will experience tunnel vision, as they begin to fall in love with their ideas very early (the downside of primarily being a strategist)
• Observing your competitors is good - if your product ecosystem is well-matured and you are just looking to make tweaks. In new product development, this becomes an issue because you might risk mimicking your competitors. Lack of uniqueness in a new product would mean the product won’t gain traction in the market and will be rejected faster than it gets built
• Anecdotal evidence could go a long way if you have experienced Product builders in your team. They bring in stories from their past projects and help you get a headstart on what NOT to do. However, anecdotal evidence can get you biased very quickly. Besides, the focus could quickly shift from product to people management, if you disagree with their stories, which eats away from your bandwidth for product-centred tasks!
• Qualitative data is easy to collect but the sad reality is they are usually not robust and become increasingly unreliable over time. If a customer says they like an idea today, qualitatively — go back to them after a month and they may say they are not so sure about your idea anymore. Constant feedback gathering is the key to this, but how frequently can you do that without annoying them out to give you low-quality feedback? Incentives would fail, if they decide to not respond to your surveys, reply to your emails, or pick your calls ;)

It’s always fun to talk about running product experiments which are easy and low-cost in nature.

• Something as simple as a basic A/B Test, maybe with an HTML element change on a group of 50 people can give good results.
• Another quick one would be to run a poll on Slack and see what the 100+ people in your organisation are saying.
• You can get sciency by creating control and treatment groups, running your experiments, and performing statistical analysis on the results.

All of these sound great on paper, but only after you test a few of your hypothesis would you start seeing the challenges that these experiments bring.

It’s the same as thinking about a solution vs putting it out on a piece of paper — it can be tricky, and messy.

The best approach, in my opinion, is to get creative.

If you get creative, you will know how to categorise your product ideas. Do that well, and you’ll understand what tests would apply to which category, and how thorough you’ll need to be with them.

A strong categorisation approach would mean most of your ideas will always fall into the existing categories and rarely would you sense the need of creating a new category for every new idea (although, a word of caution: don’t get too rigid here, proactively shake things up, before your customers do that for you!)

If validation is quick and done well, you can:

• quickly convince your internal stakeholders about the idea
• execute, implement and ship fast
• iteratively track the data your newly-built product/feature is generating
• decide what to do next and how to go about it (possible that the next version of your implementation can see the light of day without any prior validation, and any smart-worker would love to be in that situation!)

Timing and time-boxing are the keys to quick and successful idea validation.