Stop. Wait a minute.

Before jumping into solutions, we need to take the time to analyse the problem we’re trying to solve. I’ve worked with companies who wanted to improve their communication, so bought a communication tool; they wanted to improve the transparency of work, so bought an issue tracking tool; they wanted fresh ideas on how to improve their product, so hired a Product person without any regard to how the role looks 3 months, 10 months, 2 years down the line.

Whenever the first good idea comes up that looks like it’ll solve the problem, we go for it, shutting out any other potential ideas that might be a better fit. Instead of being open-minded and considering the advantages and disadvantages of each idea, so we pick the path of least resistance.

Problems often have many layers, they challenge us by making us consider assumptions and the gaps in our knowledge. They’re uncomfortable, and in our quick race to be comfortable again, we settle on a solution that doesn’t completely solve the problem. That’s not to say you should should discount the first idea completely - write it on a flipchart in your office, your wiki, wherever - as long as it’s somewhere that is used everyday and doesn’t just get written down to be forgotten about.

By taking the time to think about what problem you’re trying to solve, and what your desired outcomes are, you’ll be better equipped to make comparisons between ideas. Think about the different people and roles that are affected by the problem - is it a company wide thing? Department wide? Does it affect our users? Then go and speak to a subset of those people you’ve identified - do they have the same needs and wants for solving the problem? When you have a better understanding of the problem, you have a better chance of solving it.

Once you’ve analysed the problem, consider whether there’s a workflow attached to it. For example, if noone has any idea what anyone else is working on because there’s no visibility of the process, visualise it. You might think this is an unnecessary step, you know how incidents and feature requests get to the relevant teams, but quite often no one person has a true picture of the ins and outs of a workflow. Map it out. If it’s a communication problem between teams, draw out an interaction map, you’ll often uncover things you didn’t know before.

At this point, it’s useful to write a problem statement - make sure this is a joint effort so everyone affected by the problem can chip in. The problem statement should be people centric - you should write it from the point of view of the people affected by the problem - and balanced i.e. neither too broad nor too narrow so that it’s a manageable problem to solve. There are many different ways to write problem statements, but I prefer to use the Point of View (POV) template - using this a start-up might have the following statement:

As the first-hired Product Manager in a start-up I’m trying to understand the existing backlog of work items but it’s difficult to know what is important because there’s no visibility over what teams are currently working on which makes me feel frustrated and unable to do my job

— DeVos, J. Design problem statements — what they are and how to frame them, Medium, 2018.

or a company with legacy code might have:

As a software engineer I’m trying to find out who looks after a particular feature but noone else seems to know who developed it because there’s no documentation about it which makes me feel nervous when I need to update dependencies in that codebase

— DeVos, J. Design problem statements — what they are and how to frame them, Medium, 2018.

If you have different user groups or roles affected by the same problem, make sure to consolidate the problem statements into one - it should be to the point and should focus on the existing problem you’re trying to solve. You might already have a software tool in mind as a possible solution - write it down - but explore other options rather than committing to the first thing you thought of. You can write a second sentence to address this, which should be a question such as:

How might we improve [our process] so that our [colleagues] are better able to do their jobs based on [throughput]

— Gothelf, J. (2013). This question was created by me but is based on the Problem Statement Template from Jeff Gothelf's book, Lean UX

Once you’ve got the consolidated problem statement, you can then start to think about your success criteria for your solution. To do this, try to envisage what the ideal world looks like - for example, how much detail is required for the Product Manager to get a good overview of the current priorities? What needs to be documented in order for everyone to know which teams are accountable for specific features?

I’ve mentioned that we’ll measure throughput (delivery rate) to determine whether we’ve solved the problem. Another metric that could be used is number of repeat purchases per customer, or an increase in the company’s Net Promoter Score (NPS) as a result of making this change. Just make sure it’s something specific - it’s easy to mention the what e.g. happier customers - but how will you measure that happiness? It’s best if it’s something you’re already measuring - make sure to record the statistic as it stands today so you can refer back to it in a few months. Yes, months. There’s not much value in measuring how your throughput fluctuates from one week to the next, you want a fairly consistent rate over time, so if you want to check your throughput has improved in 2 months, take the current measurement for the past 2 months.

After defining the problem statement and having some definition for what success looks like, you can start to identify possible solutions. I recommend time-boxing this activity, and use a comparison chart like the one shown below, for the different solutions you identify - especially if you’re using software to solve the problem, you should compare the various features and how these might help to achieve your goal.

Then, try to narrow down your options to 2 or 3, and then try to gauge which of these solutions are doable now versus those which will take a lot of time, for example if there’s a lot of configuration to do up front in a software tool vs one that you can start using right away. At the same time, don’t cut corners that won’t serve you well in the longrun - the cheapest solution may not be so cheap if you have to find an alternative in 6 months from now.

So if you’re working at a company who likes to dive straight into solutions, stop and take some time to really figure out the problem first. Are you treating a symptom or the root cause of the problem? By truly understanding how different people are affected by the same problem, you’ll be better equipped to find the right solution, rather than trying to force something that only addresses one group of people.