6 Thoughts from Fifteen Discoveries

Eighteen months ago I initiated a review process for product discoveries at the Ministry of Justice(separate post explaining our framework for discovery coming soon). It’s been an eye-opening and fascinating journey, through which I couldn’t help but discover and learn some things myself. I had the somewhat unique opportunity to do deep-dives on the outcomes of 15 discoveries. I got to hear team stories and see problem spaces in a new light — from prison core records to making arrangements for children when parents separate. This is where my head’s at after all that:

1/ User first does not mean user only

Many of us have answered the call to be user-centred and focus on user needs — many have done that quite well. But, it is possible to take that focus too far and ignore the other important elements of good services. The call to consider users first does not mean ignore the structures around them. It does not mean ignore their processes or ‘the business’ paying to build services for them. Yes, we ought to put user needs at the heart, but we also should keep in mind that the heart does not constitute the whole of the body. To focus only on the user is to ignore the conditions necessary for useful work and success. When the conditions are not right, success is elusive no matter how much we understand user needs.

2/ Team makeup and size can make or break a discovery

Most product discoveries I’ve come across have been research-focused. The focus is usually on gaining insight into users and into problem spaces. In practice, this often means defining research plans, designing and running research sessions. With that as the focus, the roles of non-researchers in a discovery phase vary and seldom need full-time engagement. If the goal is to figure out whether a digital or technological intervention has a good chance of solving a problem, then a team of 4 or more will be inefficient and often dysfunctional. Applying the generic, Agile delivery team model to a product discovery phase leaves a lot to be desired. In my experience, product discovery teams have worked best where the teams are made up of 2–3 people. The user researcher works full-time and the others dial their involvement up or down as necessary. Design by committee is bad, research by committee is worse.

3/ Research projects can exist independently within the digital/product ecosystem

Research to get a good view of the people, structures and processes within a problem space should not be dependent on the existence of a product or a product team. Not all research projects in Digital must be framed as product discoveries. This is especially important where there are big, complex societal problems to tackle. These types of problems cannot be detangled and resolved with the generic Agile product delivery team model. They need massive combos of research methods, partnerships and time.

4/ Scrum and sprints are seldom appropriate for product discoveries

Nowadays, product teams strive to apply Agile principles and the Scrum model everywhere. They instinctively try to apply what has worked elsewhere and I’ve seen it become a blocker for many.

When you do not know who you need to talk to or what you’ll get from them when you do talk, how do you sprint?

When a big chunk of your focus is on setting up, why cobble together shows to explain to stakeholders how your setup is going?

When insights are taking you in unpredictable directions(sometimes rabbit holes) how do you ‘scrum’?

When you are pushing to identify what you do not know and you are nowhere near building or iterating on anything, what’s the point of sprinting?

5/ Without understanding of value, success is indefinable, unmeasurable and unachievable

We need to understand what we value as an organisation and what users value, to focus on the right things. When we define value only at team or individual level, conflict is unavoidable. We also don’t see when we are going off piste. In addition, when we have to give account to stakeholders and provide evidence of success, we have issues. A shared definition and understanding of value is necessary to succeed and to know when we have succeeded.

6/ Deciding to stop is success

I’ve observed too many people/teams agonise about stopping work after a product discovery phase. These teams discover:

• the conditions are not right for their product ideas
• there are too many constraints to work through
• the problem they explored is not actually a problem
• there is no user need for the product(s) they have in mind
• there are already other products that can solve the problem at hand

and they agonise. They agonise, because they see stopping as failure. Well, I see stopping for any of the reasons above as success. To do the work to come to these conclusions is in itself an achievement. To weigh the options and make a call to stop work for the right reasons is success in my book.

Summary

There is always so much to learn about human behaviour, thought processes and experiences. 15 discovery reviews went by in a flash, but the learning continues. So, which/how many of the 15 discoveries were great? What made them great? What were their outcomes? How did the six points above factor in any of them? Do we know what good looks like? Well, all that’s going to take some more hard-to-read sentences… coming up soon…watch this space.