Congratulations, your potential customers have confirmed that they want your product. That they can’t live without it! Your next step is to define your product in more detail. Which you will need in order to get input and feedback from your customers about what you plan to build.
“Take a human desire, preferably one that has been around for a really long time . . . identify that desire and use modern technology to take out steps.”
~ Ev Williams
Define the Product
I’ve mostly used Agile and Scrum over the past several years, so for me this step involves creating the release backlog. Here you flesh out your user stories and prioritize them.
Make the initial release as small as possible. Aim for your minimum viable product (MVP). In my experience, the scope can be much narrower than you think (a topic for another day). But the product needs to be significant enough to deliver meaningful business value (MBV) to your customers. Once your stories are well formed and your release backlog is prioritized, call your larger team together for release planning.
Meet with Engineering
Use the release planning to not only size the stories and create your sprints, but to also identify what questions you need to ask customers. The team will come up with plenty of questions. Some you can answer. Others will require customer input. Keep track of all these questions. Get the answers the team needs when you show customers the product definition.
At this point your stories are largely done. The team has had a lot of productive conversations and has made many important decisions. You have a whole new level of detail to share with your customers. Next create the materials you will use to test specific product characteristics.
During the release planning I always make sure engineering knows when I will be speaking with customers next. Invite some engineers to participate in the next round of discussions with customers.
Create Your Materials
Some teams simply do an export of the user stories and create a document that can be presented to the customer. I think that’s too much detail to go over with the customer.
“Make the initial release as small as possible. Yet significant enough to deliver meaningful business value to your customers on day one.”
I like to create a high-level summary of the product details. Visuals and interactivity work best at this stage. The more realistic and concrete the better. I’ve used slides, illustrations, mockups, and wireframes. Don’t ask the customer to read anything – they won’t. Schedule a meeting and walk them through your product definition.
So what’s important to include in the product definition? These materials may describe or illustrate the product’s functionality, features, flows, architecture, design, and platforms supported. Or maybe you have some other product characteristics that are important to test.
Collect Customer Feedback
We’ve already gotten input from customers on the product concept. Now we are going back a second time to get input on the the more detailed product definition. You’ll have a lot more detail to share this time around.
You should also have a prioritized list of open issues and questions that need a final decision, either by you or other members of the product team.
I almost always ask Engineering to participate with me on this round of discussions. Engineering should have the opportunity to talk directly with the customer at this stage. It not only engages the team more on the project, but customers like talking with the folks who are actually building the product.
At this stage you’re testing very specific points of the product. Often the areas most important to test are those with the most uncertainty or risk. The team may have questions about the architecture, customer’s environment, workflows, or business priorities.
You’re getting into some nitty gritty here. But don’t make it painful for customers. Do your testing with the people who will be your real users. Take detailed notes of their feedback.
At this stage you will also get feature requests from customers. Be prepared to handle those. One thing I’ve done at this stage is create a roadmap for the new product. This tactic is especially useful if there are capabilities that customers want beyond your initial MVP. Use the roadmap to show customers how you are viewing the priorities and the general timeframes you are targeting (if you have them). It’s also fine, of course, to simply tell the customer you are recording their feature request and will consider it for a future release.
My Closing Thoughts
Your overarching goal is to build what your market requires, set the product up for long-term success, and remove as much risk as possible. You’re testing the product definition to ensure your product will deliver immediate business value and create happy customers.
I’d like to hear what methods you’ve used to test your product definition with customers. Please share in the comments.