Too often, customers have a “fake certainty” about the problems they want to solve. They might not have defined the real problem, but they have frequently defined the solution anyway.

The risk is that we might build the wrong thing. Software teams want the ability to explore the uncertainty of the problem in order to create a great solution. When the product owner works with the customers to define the problem, then works with the team to define the solution, everyone can win.

Here’s how one product owner learned to embrace uncertainty and create a solution that actually solved the problem.

Get the Key Players Together

Paul, the product owner, was frustrated. He’d worked in insurance companies before, so he had a pretty good idea of what they might do to change how they sold insurance and what kind of insurance to sell. But he couldn’t get his sponsors to agree with each other.

He had a conference call with his sponsors, the vice presidents of marketing, sales, and training. The VPs couldn’t agree on the problems Paul thought the team was supposed to solve. Paul thought they should focus on people buying more insurance products as end-customers. That would mean changing the suggestion engine.

The marketing VP thought they were all set with the suggestion engine. He wanted to highlight the features their product had over their competitors.

The sales VP was all excited about the logo placement on the page. He thought it was an issue of branding.

The training VP wanted to make sure her staff was able to train both internal people and customers on the product. How could she help the internal people and customers realize they had more options?

Paul secretly thought they were all full of stuff and nonsense. He thought the VPs hadn’t articulated the actual problems the team needed to solve.

First, Paul worked by himself for a couple of days, trying to write small stories. But he didn’t understand the goal of this effort. He stopped writing stories and decided to try to meet with everyone again.

Share the Problem Uncertainty

Paul managed to get the VPs in a meeting room and addressed his lack of understanding of the business outcomes. Initially, the VPs seemed irritated with him. “Don’t you know what you're doing?” they asked. He pushed on, and asked them each in turn, “How will the business benefit from the proposed changes?” 

He heard these answers, with a little snark thrown in:

• “We’ll make more sales”
• “We’ll have an attractive webpage”
• “We’ll be able to train our customers”

Paul explained that he wanted a way to measure how successful a change was. “How will we know that what we are proposing is effective?”

This question stumped them.

They sat in silence, pondering. Finally, the training VP said, “If we can train the customers early and often, they might buy the add-ons we want to sell them. And they might encourage more people to buy licenses for their organizations.”

The sales VP agreed. “That’s what we want to sell: more licenses through bundles.”

Paul now understood the overall business problem: being able to sell more licenses because more people bundled more of their insurance.

He repeated this goal to the group. They all nodded, suggesting some agreement and understanding.

Share the Definition Uncertainty

Now that Paul understood the problem they wanted to solve, he was ready to work with the team to define and refine the definition of this problem: the stories.

He wasn’t enamored of the idea of “stories,” although he did like the way thinking about the customer helped him describe problems.

In the past, Paul had broken requirements apart into use cases. He’d used use cases for many years and liked that he could create happy paths and alternative paths. But he wasn’t excited about having to break the use cases apart as much as the team wanted, into those infernal user stories.

Armed with a large black coffee, he set to work. Using the VPs’ definition of the problems, he wrote a series of use cases. A couple of hours later, he left the office with a stack of cards on his desk ready to present to the team in the morning.

Share the Answer Uncertainty

The next morning, armed with an equally large coffee, Paul sat down with the team to present his answers to the VPs’ problems.

He didn’t discuss how he arrived at these answers with the team. As he explained the cards, he heard these concerns:

• “Well, this will never work”
• “This is impossible to test”
• “This won’t fit into our architecture, so it won’t work”
• “How do these stories or cases or whatever you want to call them even solve the problem?”

Ouch.

Each team member had been working on the product for at least two years. Paul, however, had been in this organization for only six months. The team members were much more familiar with the product and the customers.

Move from Requirements Uncertainty to Experiments

Paul was tired and frustrated. He asked the team, “Well, what would you do, then?”

One of the more senior developers said, “Let’s consider experiments so we can get feedback from our VPs. I think you’ve done what you can with the data you have, but I don’t think you have enough data.”

Other team members chimed in. They create a list of possible experiments:

• Paper prototypes to check how the flow for insurance bundles might work
• A/B testing to validate the effectiveness of logo positioning
• After the initial paper prototypes, gather usage data for up to one week to see if the user interface for ordering insurance bundles makes a difference in sales

They generated several more experiments. As the team worked through hypotheses, they discovered more opportunities to solve the problems. For instance, the team found that order made some difference: If they showed the add-ons in increasing price, people were more likely to add more products to their bundles.

POs Don’t Have All the Answers

Too often, we ask the product owners to have all the answers. They can’t know everything, especially not in advance. The PO has to rely on the people who solve the problems. They might not be experts in identifying problems, but they are experts in solving them.

Respect the abilities of both the problem identifiers and the problem solvers. When each party extends each other respect, they have useful conversations and often make better decisions.

Presenting a solution is both patronizing and creates fake certainty. The word solution implies certainty that just isn’t there.

When you present a solution to the customer, you create a shared certainty around how the team will solve the problem. You have no assurances the team will solve the problem that way. And the customer believes they will get what you promised, when you promised it.

It’s even more dangerous when you present a solution to the team. When you say how you want a team to solve a problem, you preclude their ideas and possibilities. You might even end up with the team creating code when they didn’t need to do so.

In reality, you only have problems until you have a solution—the working finished product that solves your customer's problems. Before then, all you have is a hypothesis. And the only way to build certainty around a hypothesis is to experiment and learn.

Great teams are brilliant at experimentation, which is the core of problem discovery. Let them work to solve the problems you bring them, and you show them you respect their thinking. And you might just end up with something brilliant.