My last blog post was about why and how to validate products and in this article I’m going to go a bit more in depth into what to actually do in the validation session.
I was first exposed to validation when I was working at Softimage/Avid on a 3D software called XSI. This is the 3D software used to make many games and movies such as 300 and Metal Gear Solid. While I was there, I was exposed to validation through the Director of Product Management at the time. We had a consultant from SyncDev. While SyncDev itself is somewhat proprietary and has some components of it such as their software which aids in the validation process, I found that the most useful part about it was just getting into the behaviour of doing validations and asking the right questions. This is what this post is about.
The Validation Wave
A validation Wave is basically a series of 6 validation meetings. Each validation meeting is with a single customer or group of people. A validation wave typically covers 3 intense days, of 2-3 meetings each.
Due to constraints, we at Ballistiq just do validations online. We’ve done them on GoToMeeting. It’s not as good as doing it intensely over a 3 day period in person but it works. It’s the data that you collect that counts.
Who should be there?
Your core product team: Product Management, Product Marketing, Development Lead should be there. The goal is to get alignment. Product Management, Marketing and Development should all be hearing what the customers are saying and get the full understanding of what’s important and what isn’t.
The Voice of the Customer (VOC)
When doing the meeting, one person talks — generally the product manager. Others can talk at certain points but one at a time. People who aren’t talking should be typing everything that the customer says as the “Voice of the Customer”. This is extremely important. Collecting the VOC means that you have real quotes from real people. This brings a lot of weight later on when you have people saying, “My problem is x. This really solves my problem. I would pay $y for this.” Real quotes from real people bring about immense weight later on when you are debriefing with management, investors, or even just among yourselves.
The presentation generally follows the this pattern:
- The problem statement. What are you trying to solve? E.g. “As a parent, I want to see my baby if I need to on a baby monitor” (hypothetical video baby monitor product).
- How we do it. Your solution to the problem statement. This is your hypothesis. Present your product as if you were selling it. Max 2 slides. E.g. “Baby Monitor Plus App for iPhone – A video baby monitor and app that turns your iPhone into a remote control for a video baby monitor.”
- About you. Find out about the customer. On this slide, find out any pertinent information about the customer that is relevant to qualifying your customer. E.g. for enterprise products, sometimes you want to know how many people in the company would possibly be using your product.
- The problems. Write about 10 quoted statements “Voice of the Customer” validating the problem that you have. E.g. for the video baby monitor product, “I want to be able to see my baby instead of just hear him.”, “So many things could happen where an audio monitor won’t cut it, like suffocation.”, etc. As you do more validations, people will validate the statements and come up with new ones for you to drop in. As you do the validations, remove the old ones that aren’t resonating and replace with statements that do resonate.
- Product demo. Give the product demo. If your product doesn’t exist, just show concept sketches, designs, wireframes, anything.
- Summary of features. Review the product features with bullet points. Ask the questions: What stood out most to you? What are must have features? What don’t we need? This is how we validate what our Minimum Viable Product is.
- Limitations. Go through the limitations of your Minimum Viable Product. Ask if there are any deal breakers. Again, this helps to validate your MVP.
- Product roadmap. A single slide deck showing your roadmap and key features in each version that you intend to release and when. Ask what features they would move. This helps you to ascertain what features really are necessary in the MVP and what can be deferred into future releases.
- Buying. Would you buy this? How should we price this? Who would make the buying decision? What is the buying process? Who is our competitor? Where is this on your priority list? This helps you to check if people are willing to pay for this, how and what the process is.
- $100 R&D test. Put up a table of features (in Powerpoint you can embed an Excel sheet). Each feature has a dollar amount allocated to it – start with $0. Have a total that sums it all up. If I gave you $100 to spend on research and development, what features would you allocate it on? This is a fun exercise as it helps again to ascertain what features really are that important to your customers.
- Wrap up. Did we solve the problem? Were there any missing/must-have features? How would you rate this product (A-F)? How would you describe this to someone else (this helps you form an elevator pitch/marketing messaging)? Do you know anyone else we should speak to?
And that’s it! Each presentation typically takes minimum 1 hour, to about 2 hours to do. It gets you a ton of information about the customer, what’s important to the customer and more importantly, helps you to validate and guide you in formulating your idea.
The hardest thing about validation is just starting. It’s about momentum. Once you get the ball rolling and talking to people, you’ll keep refining the idea and pivoting until you’re onto a winner.