Anatomy of a great Problem Description
Building software is hard, and there are many pitfalls along the way. One anti-pattern is so common that it has become the norm: Solutioning.
We've all seen this. Someone comes up with an idea for a feature, spells it out in Jira tickets, and throws those at the developers. At the heart of this mindset lies the mistaken belief that software development is merely about implementing solutions. That, if we specify what we want, coders can slap it together.
Software development is about designing solutions, and great designs can only come from a collaboration between domain experts and technical experts. Having Business think up a solution means half-assing it. We need to take advantage of valuable insights from our key problem solvers.
The advice is always to give developers problems, not solutions. That makes sense.
But how does that work in practice?
The key to better solutions is a well-defined, written-down problem. A Problem Definition document describes a pain point, challenge, or opportunity. We often move straight to features rather than take time to think about what we're trying to achieve. A Problem Definition is a product management tool that feeds into solution design.
Problem Definitions should be articles rather than tickets. They should live in Notion or Confluence, not in Linear. Business people or domain experts are usually in the best position to write these documents.
A good Problem Definition contains these sections:
Title
A problem definition has a title that describes the problem in one sentence.
"Bad onboarding flow" is too vague.
"Most users drop out of onboarding flow" is better.
"Create new onboarding wizard" is a feature. We don't want that here.
Audience
We don't build features for the sake of features. We solve problems for someone.
Who gets impacted by the problem? All users? The first-time buyer? Our operations team?
When addressing a problem, we must know who we're solving it for. Here we list all actors or user personas that feel the pain.
Problem synopsis
Now that we know who has the problem, we start by describing the experience in detail. This is where product people should shine. Describe the pain our users feel in such a way that team members clearly understand. Write prose and add diagrams if helpful. Think of this as the As-Is situation.
Depending on the problem, these summaries can get pretty long. That's OK. What we do want to avoid here are one-liners.
"It's hard to switch accounts" just isn't enough.
User research
We can't solve problems without talking to those involved. This section describes the user research and links to surveys, data, or reports. When the team starts discussing solutions, this should give them all the tools to deep-dive into the problem.
It can be helpful for the author to add their findings to this section as well. e.g., A pie chart that summarizes a survey.
If there hasn't been any user research yet, note down the hypothesis you want to test. This could feed into user experiments.
Workarounds
What do our users currently do to circumvent the problem? Do they export to Excel? Do they share passwords? Workarounds tell us exactly how our product is failing the customer. They are great sources of inspiration for the solution.
If the users have no workarounds, proceed with caution. That's usually an indicator that the problem might not be so relevant.
Constraints
Problems often occur as a side effect of other user behavior or design choices. We may want to solve the problem only for the Premium users to incentivize Free users to upgrade. The Constraints section is there to give those that design the solution some business caveats that they need to keep in mind.
What we have now is a detailed dossier on the problem. When domain experts and developers sit together to design a solution, they have all the information at their disposal.
Note how these problem definitions don't mention features, priorities, estimates, or outcomes. It's too early for that. A good problem definition allows the team to come up with multiple solutions.
This approach gives us various benefits:
It forces problem-centric design. One-liners or problems without user research won't make it to the development stage.
Developers don't need to be included in early "refinement sessions". They are only involved at the right time: when we start designing the solution.
Product Managers can prioritize the problems and place them on the roadmap. Problem Definitions make great roadmap items.
Teams can come up with solutions that fit the allotted timebox. We can build a simple Excel export or a full-fledged report engine, depending on how much time we want to invest in solving this problem.
The system is perfectly asynchronous and scalable. Multiple people can write Problem Definitions without the need for all-hands ideation sessions.
Solutioning is the number one way software product companies shoot themselves in the foot. It's an old habit that's hard to shake.
Starting from problems is a much, much better way to build awesome products.
Try it out.
As an example, I've created a simplistic Problem Description for the world's most well-known issue.
I'm thinking of running a workshop on how to build an actionable high-level, long-term plan. We would use a fictitious company with multiple teams and turn their to-do lists into long-term planning tools.
Who would be interested in joining the pilot for such a whiteboard workshop?
Let me know!