Skip to main content

6 basic mistakes in describing a problem


- 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 report
An 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.

Context

Currently, when an employee submits an expense report an accountant cannot edit it, only the chief accountant can. This creates a bottleneck when a very busy person should do the smallest edit.

Value

If an accountant were able to edit expense reports, it would save the entire department approx. 20h of work per week.

Current solution 

Presently chief accountant allows accountants to edit expense reports on her computer. This saves a bit of time but creates additional security risks.

Sizing

For 20 of our 120 customers, it is a problem. Those 20 customers are large enterprises with large accounting departments and a lot of expense reports.

Urgency

5 of 20 customers currently evaluating a competitor's solution. 10 of 20 said they would consider switching to a different solution if it would have the problem solved.

Summary

A problem definition is much more than just a statement. It's never a one-liner. It needs to explain: a persona which has a problem. The wider context of this persona. Value it will bring when solved. How a persona currently solves the problem. A sense of sizing and urgency for the problem. Carefully described problem leads to a successful solution.

Popular posts from this blog

Product management and operations tools - Jira Product Discovery review

  JPD is a new player in the market of product management software. Jira (and the whole Atlassian suite) has been one of the most popular tool stacks for teams to deliver software products. Now they're adding a missing piece - product discovery.

Product management and operations tools - Productboard review

  The second product management tool I've decided to review is Productboard . It is widely regarded as one of the most popular tools for product teams and the main competitor of Craft.io that I reviewed in the previous post .

Trust - the currency of leadership

  Here's a lesson I learned relatively late in my career - when it comes to leadership there is only one thing that truly matters - do you have the trust?