Notes on Product Development: What Do We Need To Solve This Problem?

Introduction

When building a product or system there is always another feature to implement. Sometimes it’s very specific in form of a task, describing the required steps in detail, sometimes it’s in form of a story or an epic and might be very vague.
Very often we’re already presented with a solution to a problem. This leaves a sole developer or development team with figuring out the technical details in best case, only implementing the technical solution at worst.

But what if we were able to talk about the problem not the solution?

Let’s try to get a better understanding via an example.

Defining The Feature

The development team has the following feature in the pipeline:

As a business analyst I want to be able to export my data,
so we can process the data inside Excel.

This feature is written as a user story, but might come in different shapes and forms. It already provides us with a solution: "export the data". So we need to export the data as a CSV file f.e.
At this point we’re already focused on figuring out how to get the data out of the system. We already have a solution and we need to figure out how to implement this feature on a technical level.

But what is the actual problem we're trying to solve?

The story card doesn’t provide any further information on what happens once the data is exported.

* Is there a specific calculation that needs to be run outside the system?
* Could the solution be provided by the existing product, instead of having to export the data?

These are just hypothetical questions, but once we’re provided with the solution it becomes harder to step back and understand the problem.

Let’s take the original feature and rewrite it:

As a business analyst we will need to calculate the median and mean 
of all recruiting costs on a per month and department basis 
so we can control the costs during the year.

Even if this story might sound a little exaggerated, this formulation provides us with a very specific problem now.

* Now we might even take another step back and ask what happens with these costs?
* Do they need to be exported as a PDF or CSV?
* Are the results imported back into the existing system?

We can keep stepping back and ask further questions, which might help us to better understand the actual underlying problem.
The outcome might be that we will solve the actual problem differently, instead of being presented with a solution to part of the problem.

Thinking Beyond Features

Now you might be trying to argue that this is a process or methodology problem, that the stories need to be done in a way, that leaves room for asking questions. Take a look at at an existing backlog and see how theses stories are formulated and if they help to step out of a specific feature and enable to understand the bigger picture.

Mostly there is room to discuss the acceptance criteria within a feature, as the solution is often already provided directly or indirectly. What mostly happens is that we shift from thinking about the overall outcome to number of features.
The number of features becomes the driving factor, not the underlying problems these features are set out to solve. Often there is a product owner or manager or a product team tasked with ensuring that there is backlog with prioritized features. This also means that the development team is involved later in the process.

We already have concepts for defining the larger picture, think in terms of epics or even themes.
Themes or epics are vague and help to bound features together, to provide context for these features.

When we want to think about solving problems, this level of abstraction is the interesting part. But very often the solution is broken into multiple features in form of stories or a different format, and discussed in sprint planing or another development team focused meeting.
We’re interested in an abstraction level that helps us to focus on the problem.

Talking About The Problem

What do we gain from talking about the problem?

There are a number of benefits that we can derive from this approach. It enables a team to have the opportunity to provide valuable feedback early on. It enables everyone involved, especially the team doing the actual work, to get a better understanding of the bigger picture.

What is the problem we are trying to solve and why do we need to solve it?

It creates a platform where we can learn and understand the problem first. Now we can also ask the following question:

What Do We Need To Solve This Problem?

This is different from “Here is the solution, now solve it”. Instead of handing-off a problem from A to B, there is a groundwork for discussing what is actually needed to solve the actual problem.

* It helps to clarify the problem not the solution.
* It helps to derive a solution.
* It opens up room for collaboration.
* It opens up a dialogue.
* It’s not simply outsourcing the problem.
* Is this problem even solvable at given time?
* Is there a different problem that needs to be solved first?
* Can we break up the problem in multiple parts?
* Are the right people involved in solving this problem?

Summary

Very often we’re focused on metrics like number of features or development speed and other quantitive metrics.
But sometimes it makes sense to think about what we are actually trying to solve.

If you have any questions or feedback please leave a comment here or connect via Twitter: A. Sharif