We recently had to think very hard about how to define the problems our work was designed to solve, during some discovery work to inform an imagined new digital system.
At the start of the project, we spent time having thoughtful conversations with key stakeholders. This is an important part of our usual approach to discovery, where we canvas the opinions of stakeholders identified by the project team as being influential in the future direction of a service.
Very early on, we started to realise that stakeholders were not all telling us the same things about the problems that needed to be solved. They imagined future systems that would solve very different problems.
This in itself represents its own problem (and a huge project risk) – if senior stakeholders think a future system is going to solve a different problem, then they will be dissatisfied when the future solution inevitably fails to live up to all of these expectations.
This is not that uncommon in our Discovery projects (our current record is the articulation of 13 different problems across a single project).
The Service Manual states that a good discovery should define the problem that is being worked on to better inform the direction of a future service. Developing this understanding early on helps to both manage the expectations of stakeholders and help the project team to articulate the problem they should be trying to solve with their service.
Our experience in the initial stages of this project reaffirmed the importance of engaging stakeholders, but it also affirmed the overriding importance of user research. Because user research is the tool that enables us to distil the wide variety of perceived problem statements into a focused problem statement that aligns stakeholder aspiration with user need.
