- I never give solutions to developers, - says one fresh product owner, - I give them problems! And then he drops one line as a story title. Job done? Not quite.
"I want..." is not yet a problem
Despite using the right words, describing problems not solutions, this PO makes crucial mistakes. Problem definition is much more than just a problem statement. Before a story could be ready for development much more details should be added.A good problem definition includes:
- information about a user/customer
- wider context
- value it likely to bring when solved
- current solutions customer uses
- a sense of size - how many customers have this problem
- a sense of urgency this problem has for customers
1. Persona
Describing a problem you first need to describe who exactly experience this problem. Good product teams have personas. Archetypical descriptions of their primary users and customers. If you have personas - always describe which persona experiences a problem. If you don't have personas developed - do it, first of all. Describe a target user/customer. Who is this person? Short bio. What is this person's background? More about creating personas here.2. Context
Your users/customers do not operate in a vacuum. A good problem definition includes the description of a wider context persona operates in. This could include a persona's role, business or personal setup, any limitations or dependencies. Context is a short story about a persona and a surrounding as it would be written in a novel.3. Value
Is this problem worth solving? Explain the value persona would gain when the problem is solved. If you don't know - estimate and validate. Your estimations later would be validated by real users/customers. Yet it's highly beneficial to validate a value of a problem before development. Alternatively: you can describe how painful a problem is for the persona. If something pains us a lot wouldn't we find a solution very valuable?
4. Current solution
Chances are high your persona already uses some solution for the problem you're describing. Surely it's the case if the problem is painful. This solution might not be optimal. This solution might be an avoidance, a workaround, a hack. Still, it does the job. Somehow. You need to know that solution. So when you and your team would be figuring out your solution, you'll be able to compare and test if your solution is much better than the existing one. Talk to your customers, observe how they work and add the solution they're using now to your problem definition.5. Sizing
Is a problem you're describing experienced by one customer or a customer group? How large is the group? This information is critical when figuring out possible solutions. Your developers might take drastically different architectural decisions if it's a "one of" for a single customer or it's a problem of an entire customer base. Sizing also helps you to decide whether a problem worth solving and how much effort you can spend on it.6. Urgency
This aspect of a problem definition has to do with time. It also has to do with painfulness of a problem. When your customer is in severe distress and needs a solution ASAP - it's a good sign of a problem worth solving. It's quite tricky to validate due to humans natural tendencies to overestimate pain. In other words, we moan a lot. Still, it's valuable to get a sense of urgency for a problem. One way to get a sense of urgency is to use Kano-style functional-dysfunctional question pairs.How does it work in practice?
An example of a bad problem definition: Customer needs an expense reportAn example of a better product definition: Accountant needs to edit employees expense report to shorten the approval time.
Persona
Accountant.29 - 37 years old. Economics background. Not tech savvy. Works as a part of an accountant department with supervisors and approval lines.