The Only Question a Product Owner Needs to Ask
I've spent hours working with a new product team in preparing their roadmap and backlog requirements for the first half of 2017. In coaching this business team through their list of backlog items and priorities, I was reminded of the most valuable question a product owner or product manager asks and must keep asking to be successful in his or her role — and to ensure the product is successfully received by customers. It’s essentially a variation of the same question and one most children ask and annoy adults with as they're learning new things.
Great product owners always ask why.
Whether in business or in life, it makes a lot of sense to know why we're doing any task or activity on a given day. But think about it. Have you ever spent time at work plugging away at a project and then wonder why your company ever decided to spend money on it in the first place? Do you even know the “why” of your own work, or do you struggle to see how it connects to the bigger, strategic picture? Have you ever asked why when stuck in one of these spirals of seemingly meaningless activity — and then dealt with the aftermath of your boss’s reaction?
Asking why is not popular because even a lot of smart people don’t always ask this retrospective, one-worded question enough before taking action. And it can unearth decisions that reveal you or your company failed to understand the problem … and no one likes to admit they’ve failed.
Why ask why?
As product owners, we've been tasked with the tremendous responsibility of knowing why a customer or stakeholder would want our product or feature. We need to ask why we're considering a feature or roadmap priority because it ensures we're delivering value to our customers. According to Scrum.org, the primary responsibility of the product owner is to maximize the value of the product or product increments we deliver. How do we know we're delivering value if we don’t know why we're developing something in the first place?
What happens when we don’t ask why?
When we don’t ask why, we end up making a lot of assumptions about what a customer wants. Is the product backlog item coming from a sales rep with a very unhappy customer? Is the rep requesting you do exactly what the customer says (even if it creates a feature no one else will care about)? Product owners need to ask why to make sure there's a vision and purpose behind product development — and to avoid making reactionary choices. Saying no can be very difficult with important customers or stakeholders, but it's also an important word for product owners to learn and say to protect the product.
Variations on the why question
There are numerous ways of asking open-ended questions to get to the why, but here are some that have proven useful in my conversations with clients or stakeholders:
- What problem are we trying to solve?
Instead of hearing, “I want X, Y and Z,” this question gets to the heart of why a customer might be struggling with a current product. And for new products, it can help identify opportunities to innovate or provide a unique solution. To get a customer to pay attention to a product, there has to be something in it for them. If you as a product owner can find a way to make customers' lives better or easier by using your product or certain feature, you'll gain their purchase. From there, it will be up to you to keep their trust and engagement.
- What unique value will X feature or product provide?
This would be a question to pose to stakeholders who may have already jumped to a solution before even knowing the answer to question 1 above. Especially if the solution recommendation sounds like something else you’ve seen in a competing product, we need to make sure that if it's a similar product or feature, something makes it a unique and compelling value to a customer.
- How do you/customers perform X activity today?
And what frustrates you when using this product or feature presently? This question works well when working directly with customers using a current product. Or, if slightly reframed, the question can provide a way to learn a process or activity a prospective customer could use help with that your unique product solution would deliver. Knowing the pain points of a current product or feature can also point the way to developing in a much smarter way.
- The 5 whys
There are many articles written on this root cause analysis technique brought to us by Lean, so I'll only summarize here. The idea of this approach is to ask an open-ended variation of the why question applied to a particular problem or process. It goes something like this:
- You start with a problem statement: We cannot use the summary report provided.
- Why? Because the report isn't generating correctly.
- Why? Because the report is missing five fields in the export.
- Why? Because the five fields weren't requested to be part of the original report export when initially capturing the requirements.
- Why (root cause)? Because customers didn't need these fields when we originally gathered the report requirements.
Finding the why yourself without even asking
Did you know there are ways to find out why without even asking anyone? It’s true, and the following methods of getting to why behind the scenes are also critical to being a great product owner. Here’s how:
- Usage metrics points us to why.
When faced with the decision to continue developing a product, or product features, having actual metrics based on the usage of our products and features is critical to understanding customer behavior and where we’re providing value. These key points show where the customer is most engaged and reveal a lot about where we should invest valuable development time and resources, and where we shouldn’t.
- Research points us to why.
We’re only assuming we know what a customer wants if we don’t ask. Customer research and feedback are critical to understanding the problems we can solve and the value we can deliver to a customer. Anything less can leave us short of meeting customer expectations — or creating products no one will value.
- Test your product.
How often do you test-drive your own products and experience firsthand use of them as your customers would? Is the user experience painful? Is it OK but a little bit clunky in some features? If you find something difficult, painful or annoying to use, wouldn’t somebody else?
Successful product owners are great communicators and question askers. This inquisitiveness, even if at times received as you being a bit of a pest, will ultimately be met with appreciation when you deliver products people love. And really, that means asking why is critical to your success and to the success of your product.