Discovery process

TL;DR

I implemented a discovery process to help my team map and prioritise user needs (via job maps and jobs-to-be-done), enabling them to confidently estimate the scope of work required to address them. Since then we have:

• Created a process that means we always have an up-to-date view of our users and their needs
• Conducted >150 user research sessions
• Mapped >50 jobs-to-be-done across the entire lifecycle of a production
• Documented nearly 900 user stories from 11 personas
• Created 3 phased roadmaps for each distinct product area

Skip to: 🎯Problem 🎯Process 📈 Results

Strategy

One of the objectives set for me upon my return to Entertainment Partners was to ensure that all new feature build was phased appropriately, minimising the time and effort required to meet the user needs. Our strategy (at the time) was to expand our UK market share by creating an end-to-end digital payroll service that was 1) end-to-end (contracting and timesheets integrated with payroll) and 2) differentiated from our competitors.

In order to meet these conditions, the team and I needed:

• A way to prirotise which user needs were most valuable
• A way to determine which needs were met and unmet by our current solution(s)
• A way to determine where we were beating (or being beaten by) the competition

Process

The process

In order to get what we needed, I borrowed from the jobs-to-be-done theory to design a process that would enable us to objectively measure how well any solution (ours, or a competitors) met the user needs:

1. Define the personas involved (eg. crew) and their desired outcomes (eg. minimise the time it takes to complete my timesheet)
2. Speak to users, quantify their problems (eg. hours taken) and use a cross-section of their answers to map the critical and value-adding user stories against each job-to-be-done
3. Conduct an assessment that looks at howwell each user story is met by 1) our service and, 2) our competitors
4. Hypothesise solutions and assess their feasibility
5. Provide a recommendation, based on the assessment

Assessment criteria

• Each user story is assessed for it’s objective criticality to the job-to-be-done, eg. ‘critical’ (outcome cannot be achieve without this step), ‘high value’ (outcome is reached faster or is more effective) or ‘low value’ (no material effect on the outcome)
• Each solution is then assessed to see how well it meets the user story, eg. ‘impossible’ (outcome can’t be acheived), ‘possible’ (acheived via a workaround), ‘simple’ (specific tools built for this outcome) and ‘does it for me’

The resulting data can be plotted on a matrix to show which user needs are met. This can be repeated for any solution, whether you’re assessing a competitor or future build.

The objectives of each scope of work differ depending on the maturity of the product/service, eg. an MVP just needs to make the critical jobs possible, whereas a more mature service may choose to focus on the unmet, high value stories

The discovery process

Displaying the resulting data in a matrix diagram to visualise the assessment

Conducting on-site research to populate the system

The underlying system

By combining the relational structure of Notion and the theory behind jobs-to-be-done, I constructed a relational research directory to enable the team to create a living view of our users and their needs. This system enables everyone to conduct and document user research, making it immediately available to everyone else.

We created the following databases:

• Our personas
• The job maps
• The user stories
• Research participants
• User research session dates
• Quotes/transcripts for the sessions

All of this data is linked. By visiting each persona, you can see all of their jobs-to-be-done, every participant that we’ve spoken to and everything they’ve told us about their role.

The relational research system

Viewing an individual job map from one of our personas

Anyone on the team can go to a persona and search the quotes for keywords to see what research participants have said to us - a great tool for secondary research when ideating something new

Summary and reflections2

Wins

• This process has now become a core part of our team’s operating system
• In no uncertain terms lead to my promotion to a lead role
• I’ve had excellent feedback from non-product senior stakeholders

Challenges

• While we’re in a great position now, the initial effort to set this up was considerable and, under pressure from other deadlines, some of the less experienced team members struggled to maintain this process