I joined SendGrid in July 2013 as the company’s first Product Management (PM) leader. At that point, the company was four years old, with 150 employees and an impressive revenue growth rate. Installing and optimizing PM at a rapidly scaling company is hard, so I’d like to share some of our learnings as we tackled various challenges, in hopes that it benefits the broader PM and technology community.
This post is the fifth in a series (here are links to earlier posts on Growing the Team, Prioritizing Usability, Maturing the Planning Process, and Leveraging Product Usage Tracking Data) and addresses the topic of how to establish good habits around customer validation.
Are You Staffed Up?
To really nail customer validation, you need healthy ratios of Product Managers to Engineers and Designers to Product Managers. As discussed in my prior post on Growing the Team, we strive for a PM:Engineering ratio of no less than 1:10. We also strive to have a 1:1 ratio between PMs and Designers on UI heavy areas of the product. If you do not have sufficient PM and Design bandwidth, PMs will spend most of their time surviving the day-to-day scrum team demands of the PM role, and will struggle to make time for customer validation duties.
If your Product Team does not routinely validate ideas with customers, it can be difficult to build these new habits. To jump start our team’s ability to pull off real customer validation, we set up an all day training session to help each PM understand a) why we were asking them to take on this validation work and b) help them build some basic skills. We hired a 3rd party customer validation expert named Jeff Patton (author of Story Mapping), who did a great job teaching the team fundamentals of customer validation.
Validate the Problem
When deciding what to build, it’s important to be problem focused, rather than feature focused. The first step in our validation journey is problem validation, using an Opportunity Canvas artifact. There are various flavors of canvases that are regularly used in the tech industry, including Lean Canvas, Opportunity Analysis Canvas, Business Model Canvas, etc. We use a hybrid version that suits our needs and call it an Opportunity Canvas. The Opportunity Canvas answers the following questions:
- Who is the target user persona, what are her problems, and how will we solve them differently?
- Why must we do this now?
- How will we describe the value of this to the market? (Think of this as a mini press release.)
- What is the business opportunity?
- How will we take this to market?
- How will we measure success?
- What risks or blockers could get in our way?
Product Managers are expected to speak with at least 10 users who fit the target persona and validate she in fact has this problem and would highly value a solution to it. We then have a review to pressure test the canvas and harden the thinking around the problem. If we are satisfied that the problem has been successfully validated, we move onto the solution validation phase.
Validate the Solution
Once we have identified an acute problem, the next step is to validate how we intend to solve the problem for the target persona. In the solution validation phase, the Product Manager first builds out a story map. A story map is a common Agile artifact that is used to map out the key elements of what we would like to build, framed around user actions. It is much easier to read, consume, and collaborate on than a traditional product requirements document. Also, when we combine a story map with an opportunity canvas, it becomes easier to develop thinking around an MVP. What must we have in v1 to solve our target user’s main problem?
Once the story map is articulated, the Product Managers work with User Experience designers to build out “right fidelity” design mockups, which are then taken back out to at least 10 target users to validate that the solution we envision does in fact solve her problem. After the interviews are conducted, we have a second review featuring the Story Map and findings from customer interviews. If we now have a problem worth solving, plus a solution that target users will value, then we consider it as a candidate for the following quarter. For more background on how we do quarterly planning, see this post.
Running a customer validation process like this will test your organization’s patience. It takes a ton of PM time and energy to run this process the right way and truly validate your ideas before beginning development. Too often Product teams choose to trust their gut, get moving, and pivot later as necessary. Unfortunately, as evidenced by the fact that 72%1 of new product launches fail, trusting our gut often isn’t enough.
The beauty of this process is that it forces failure points earlier in the product development lifecycle, which is far cheaper than building something that later needs to be re-worked or scrapped. Plus, ideas that survive the process have much higher odds of actually solving customer problems, which typically leads to financial success for the project.
Implementing a robust customer validation process requires a large commitment of PM staffing, PM time, and organizational patience to succeed. However, if done correctly, you fail cheaply and generate products that customers will love and value.
I hope you took something from this post, and best of luck getting your product validation engine humming! Stay tuned for Part 6, which will cover the topic of “Prioritizing Effectively.”
1 Sarah Green Carmichael, “The Silent Killer of New Products: Lazy Pricing” Harvard Business Review, September 9, 2015