As a product owner and Agile coach, I’ve spent countless hours helping teams, product owners and stakeholders ask questions that help them understand product-related decisions. With the stress to meet leadership and customer expectations, I am often reminded of the most valuable question a product owner must ask to be successful in his or her role. It’s a variation of the same question endlessly asked by young children, often to the annoyance of their parents: Why?
Great product owners always ask why.
In life or in business, it makes sense to know why we’re doing a particular task or activity on any given day. But think about it — have you ever spent time at work plugging away at a project, only to wonder why your company ever decided to spend money in the first place? Do you 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 those spirals of seemingly meaningless activity — only to deal with the aftermath of your boss’s reaction?
Asking why is not a very easy, or very popular, thing to do. Even the most intelligent among us have difficulty asking this simple, one-word retrospective question before taking action. Doing so can unearth decisions that reveal you or your company have failed to truly 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 asking why a stakeholder or customer would want a particular product or feature. We need to ask why we’re considering that feature or roadmap priority because it ensures we deliver value to our stakeholders.
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 can 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?
Failing to ask this all-important product owner question means 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 that one customer says, even if it means creating a feature no one else will care about?
Product owners need to ask why in order to ensure there’s a clear vision and purpose behind product development — and to avoid making reactionary choices. Saying no to important customers or stakeholders can be difficult. But it’s also an important skill for product owners to master in order 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 examples that have proven useful in my conversations with clients or stakeholders:
- What problem are we trying to solve?
Stakeholders have a tendency to focus on functionality, so product owners often hear things like “I want X, Y and Z.” By asking what problem we are actually trying to solve, we quickly get to the heart of why a customer might be struggling with a current product. And for new products, it can help us identify opportunities to innovate or provide unique solutions.
To get a customer to care about 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, 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 is a good question to pose to stakeholders who may have already jumped to a solution before fully understanding the answer to the question above — especially if the solution recommendation sounds like something you’ve seen in a competing product. We need to make sure that similar products or features find a way to stand out by providing a unique and compelling value to customers.
- How do you/customers perform X activity today? What about the existing process, product or feature is most frustrating?
This question works best when working directly with customers who are already using a current product, but slightly reframed, it can provide a way to learn about the processes or activities that a prospective customer needs help in solving. Understanding the pain points within existing procedures, products or features can point the way to developing meaningful solutions in the most effective 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 open-ended variations of the why question applied to a particular problem or process. It goes something like this:
- 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.