We were building a product with high stakes and expert users - a payroll platform to pay film and tv crews.
We had a small, inexperienced product team and a very ambitious roadmap.
Development was organised around three key features of the product; contracting, timesheets and payroll. Each squad was lead by a Product Manager and a Lead Developer.It was a development-focused culture.
There were no researchers, analysts or other designers - it was between the PMs and I to define the problem space and get the answers we needed to build.
Problem
Errors in payroll would undermine our reputation and cost us business.
None of our team were accountants.
Large studios and streamers (Disney, Apple, Netflix etc) have high compliance and security requirements and even higher user experience expectations.
We needed to minimise the amount of time and number of people it took to confidently define user needs (without increasing the total hours worked per person, per week) so that we could minimise the risk of research or design becoming a bottleneck.
I was the sole designer working across three squads, each with at least one product manager.
Challenges
I got the product managers together to discuss the challenges of our current way of working.
❌ Inexperienced team; 100% of the product managers felt their research skills were poor
❌ Siloed information; There was little opportunity to share findings between teams
❌ Badly organised files; All the answers lived powerpoint presentations in badly-organised shared drives
We defined what “good” would look like:
✅ A defined discovery process with templates and guidance
✅ One research repository for all teams
✅ Shared assets (user personas etc)
✅ Regular time to get together and share our findings
How I built us a research OS
The new discovery process
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:
Define the personas involved (eg. crew) and their desired outcomes (eg. minimise the time it takes to complete my timesheet)
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
Conduct an assessment that looks at how well each user story is met by 1) our service and, 2) our competitors
Collaborate with developers to assess the feasibility of solving the problem(s)
Hypothesise solutions and assess their feasibility
Provide a recommendation, based on the assessment
The operating 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 for each job to be done
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 front page of our repository
An evergreen view of our personas
An individual job map from one of our personas
Assessing user needs
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 achieved), ‘possible’ (achieved 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.
I published the repository as a free-to-copy Notion template and it is in use by product teams from around the world.
It’s fully documented, with all the additional spreadsheets etc you need to complete the process.
Results
We needed to minimise the amount of time and number of people it took to confidently define user needs (without increasing the total hours worked per person, per week) so that we could minimise the risk of research or design becoming a bottleneck.
100% of product managers agreed the new process saved them time and had helped them to meet the demands of the business.
This process has now become a core part of our team’s operating systemIn no uncertain terms lead to my promotion to a Lead Product Designer role. 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