Problem Statements - A New Team Game
John Barratt
Experienced Product Professional helping companies identify and solve customer problems with innovative solutions
In The Beginning...
In one of my former companies I printed off a banner and placed it on the wall above the teams area of cubicles stating:
‘Don’t come to me with solutions, come to me with problems!’
Aside from it being wildly passive-aggressive (I have adjusted my stakeholder management skills!), I was desperate to stem the tide of stakeholders rocking up to the team and asking for things to be built and start involving us earlier and exposing us to the problem that this solution would solve.
This was the start of a 6 year journey that led me to develop and evolve a problem statement framework.
Teamwork makes the (You know the rest)
It's very easy to say that product development starts with a customer problem. The difficulty is getting a shared understanding with stakeholders of actually what the customer problem is to be solved?
If your team and the stakeholders all have different ideas on what the customer problem is then what’s delivered will at best leave stakeholders feeling decidedly neutral or ‘meh’ and at worst open up rifts between Product, Sales, Operations, Engineering, Customer Service and a whole bunch of other stakeholders and lead to dysfunction.?
I developed the Problem Statement Framework to combat this. You need to gather your stakeholders (product, engineering, sales, operations, design, customer service, legal, compliance etc) and then the Miro template shows you how to progress through 5 different stages.
Simple right?
I think we know nothing is that simple. Stage 1 - defining the customer problem is the biggest challenge and where you will spend 90% of the time discussing and refining.
But how do you do that? You start with what you think is the customer problem and then work through the 5 stages and pretty quickly you’ll realise as a group that the problem you’re all discussing is not the right problem.
You can then do one of 2 things:
领英推荐
Eventually, you’ll arrive at the customer problem to be solved.
?Steps 2-5 help you define the approach, the measures of success in short the guardrails for everyone to work within. Engineers can come up with innovative ways to solve the problem and stakeholders are focussed on the outcomes of solving the problem.
Isn’t this just requirement gathering in disguise?
I find a common trap of requirements gathering with stakeholders is that you can quickly get into a solution mode rather than fully understand and define the problem. But with this approach, you can call out when people start to put in solutions and then stop and reset the process.
With this approach, the bonus outcome is you have a set of aligned stakeholders who are bought into solving the customer problem.
This isn’t a silver bullet and it’s up to you how you use it. I’ve found this works best when solutions are being pushed at a team from multiple directions. I even used it once when the initial problem was just 2 words on a post-it with a line in the budget.
Over To You
Please take a look at the framework and let me know your thoughts be they good, bad or ‘meh’. I’m always open to chat about how it can be improved and developed.
Try not to overwrite it but please feel free to copy and paste.
Plagiarism & Collusion
As I said this is around 6 years of tinkering and in that time I have read a metric tonne of articles and LinkedIn posts but I haven’t saved a lot of them (I used to save a lot to evernote and then the size of my saved notes was unworkable) so if you think any of this sounds familiar or looks like another framework call me out on it and point me in that direction. If it feels familiar then I will definitely give credit.