As product managers, how do we arrive at delighting customers? There are organizational and tactical lessons that I’ve learned through the Lean Enterprise book, like finding the one metric that matters. These flow into team-level initiatives that I’ve learned through the Kanban book, like defining an input queue and structuring your standups in a better way. But I believe the fundamental change agent lies in how a product manager approaches requirements analysis.

I believe requirements analysis boils down to four fundamental questions. The maturity of the team is dependent on which of these questions are being asked. This is in order from lower maturity to higher maturity, but they are all essential.

What do you want to do?

It’s essential to really understand what people want and make sure you understand exactly what’s being asked. I’ve been in the situation multiple times when a change was asked, but when I asked probing questions about the exact desired behavior, the request fell apart. Also, it’s important to understand what’s being asked for, so we don’t deliver the wrong thing with the same name. It’s a terrible feeling to declare victory on something when celebrating with the development team to realize that the requester is not equally celebratory of what you just did because it was the wrong thing.

This is the foundational question. You have to understand.

Why do you want to do that?

This is the question many people don’t get to. The thought is that a customer knows what they want and why is their business. I’ve learned over the years that this can be dangerous. If we don’t understand why they want what they are asking for, then how can we know we are delivering the right thing?

I’ve seen time and time again the scenario I like to call Declare Victory Yet Nothing Changes scenario. This is where you do what was asked for, but the outcome everyone was looking for doesn’t materialize. But it’s easy to declare victory in that situation since you did indeed do what was asked for.

Without asking this second question, you’ll be lost in not being able to empathize with your customer.

How will this make you more successful?

This is a difficult question to ask without sounding condescending, because sometimes the answer seems obvious. The crux of this question is: how do you define success? The requester should be able to explain that and in addition tie the request to this definition of success. This makes everything clearer. The customer might say something like, “I want to speed up service to increase revenue,” and want a feature to enable that.

That’s where we want to be. We want to have a clear definition of our goals.

How can we measure success?Í

This is the tough part, but it’s a key element I’ve learned from the lean literature I’ve read recently. If you can’t measure something, you can’t manage it. We need to define success and create a measurement that will get us close to that. We then tie our product development strategy to the measurement of success and iteratively create new capabilities that are shown to influence our success metric. This is the essence of the Lean Startup Cycle.

I’ve only recently discovered the second two questions, and they have made a world of difference. You are much more efficient in achieving your goals when you have defined shared success and have found a way to measure it.