
At Dila, we combined two Jobs-to-be-Done frameworks—Bob Moesta’s approach to why people seek progress, and Anthony Ulwick’s approach to how they get there—to turn customer interviews into a system for setting product priorities. The pairing solves a problem most product teams recognise: research everyone agrees with, and a roadmap nobody can agree on.
Customer interviews can leave a team with a difficult kind of agreement. Everyone accepts the findings. People want more clarity, less effort, greater confidence. Then the roadmap discussion starts, and almost every proposed feature seems to address one of those needs. In this article, I will focus on how we brought two Jobs-to-be-Done approaches together—and what that means for turning research into priorities.
The missing step is explaining how a particular finding should change a particular decision.
Applying the frameworks at Dila
We explored how people at Dila thought about their health, how they had tried to manage it, and the alternatives they considered. We also examined the steps involved in getting things done and the difficulties people encountered along the way.
Working across those levels gave us a way to connect people’s circumstances with choices about the service. My argument for combining the approaches is practical: understanding why something matters and defining what better would look like gives a team more to work with when setting priorities.
Start with the decision in someone’s life
Moesta’s work directs attention to the circumstances behind a choice: what prompted someone to look for a different solution, what attracted them to it, and what made them hesitate. His approach examines the competing forces involved in making progress: existing habits, anxiety about change, and the pull of a new solution. Moesta maps these forces in The Rewired Group’s guide to Jobs-to-be-Done. I also recommend reading his book, Learning to Build.
This changes the starting point of an interview. Asking what someone wants from a laboratory app already places the app at the centre of the conversation. Asking how they dealt with a recent health concern gives them room to describe what mattered before a digital product entered the picture.
At Dila, our research included conversations about what health meant to people and how they approached it. That broader context mattered because a laboratory visit could sit within very different circumstances: investigating symptoms, monitoring a condition, preventing problems, or trying to improve wellbeing. We described these differences in our account of the Dila project.
A product team needs to understand those circumstances before treating everyone who completes the same transaction as having the same need.
It also needs to know what to do with that understanding. A finding such as “people want reassurance” still leaves a large amount of interpretation to whoever designs the next screen.
Define what successful progress involves
Ulwick’s work offers useful discipline here. It breaks a functional job into steps and defines desired outcomes: the measures people use to judge how successfully they can accomplish it. Those outcomes describe improvements independently of a particular feature or technology, the structure Strategyn lays out in its Jobs-to-be-Done canvas.
The distinction between a job map and a customer journey matters. A journey describes interactions with an existing service. A job map describes what someone is trying to accomplish, regardless of the solution they use—a distinction Strategyn draws out in its guide to job mapping. Both can inform design, but they answer different questions.

At Dila, we used Ulwick’s job map to break the experience down into its functional details. We were examining the existing service: preordering tests through the website or online account, visiting a branch for the procedure, and receiving results by email or Viber. The difference we were interested in was the level of detail. Alongside understanding how people felt about the experience, we wanted to examine what they needed to accomplish within every step and what would help them do it.
A broad description of the visit might cover arrival, reception, waiting and blood collection. We needed to understand the functional details within each step: how someone recognises the right entrance, what the signs on the door tell them, how they know where to wait, and whether they identify themselves at reception with a QR code or a phone number. Each detail could help the person understand what was happening and move through the service more easily.
We documented the steps, examined the details within each one and prioritised what needed improvement or was missing. This gave us a way to look closely at the whole experience, including the transitions between digital channels and the physical laboratory. Where Strategyn’s job map describes the underlying functional structure, our work carried that thinking into the specific interactions through which people used Dila’s service.
In our application, the two approaches worked at different levels of abstraction. Moesta helped us understand why someone was seeking progress and what job they were trying to get done. Ulwick helped us examine how that job unfolded, step by step. Moving between those levels connected a person’s broader motivation with the functional details that could make Dila stand out.
Make the judgment behind priorities visible
A full Outcome-Driven Innovation study uses quantitative research on the importance of desired outcomes and satisfaction with existing solutions to support opportunity analysis, prioritisation and segmentation—the process Strategyn maps out in its ODI methodology.
At Dila, we took a qualitative approach to prioritisation, drawing on what people described in interviews and our interpretation of what deserved attention. When respondents explicitly emphasised an issue, that contributed to its priority.
For this kind of prioritisation, I would make five considerations explicit:
- 𐩒The evidence: What did people describe, and in which circumstances?
- 𐩒The consequence: How did the difficulty affect what they were trying to accomplish?
- 𐩒The proposed response: Why should this change help, and what alternatives remain plausible?
- 𐩒The uncertainty: What would we need to learn before committing further?
- 𐩒And one of the most important: taste. What does our judgment suggest will make the experience clearer, more useful and more distinctive?
Taste is something we cultivate at The Gradient. Each partner brings personal judgment and intuition to decisions about how an experience should work and feel. Methodology helps structure those decisions, but it leaves room for human taste: several responses may address the same finding, and choosing between them calls on our experience and sensibility. That judgment is part of what makes The Gradient’s work stand out and gives each project its distinct character. We still explain our reasoning to the client, making clear where we are drawing on customer evidence and where we are applying our own judgment.
Keep the experience connected through implementation
Research insights can be lost as work passes between teams and agencies. A detail that matters in an interview may disappear during conceptualisation or implementation. The customer encounters the consequence when moving from the app to the laboratory: the digital experience creates an expectation that the offline experience does not carry through.
This is why The Gradient maintains oversight of the whole experience, from research and experience conceptualisation through implementation with the various agencies involved. We keep the customer’s experience connected across that work, so the people responsible for each channel are working towards the same understanding of what should happen.
At Dila, that means considering the online order, the branch procedure and the delivery of results together. The information and expectations established in one channel need to carry into the next. Each team may deliver a different part, but those parts need to work in sync for the person using the service.
Maintaining that continuity requires attention to the details throughout implementation. The research needs to remain available when teams make decisions about a screen, a message or an offline interaction, so they can understand why a detail matters and preserve its purpose as the solution develops.
Follow the implications across the business
At Dila, the research helped focus work on three areas: identity, the application and physical branches. Those areas provided a starting point for wider changes in communications, marketing, contact-centre work and business processes.
For an agency partner, this is where the discussion extends beyond the feature list. A customer’s difficulty may involve something the app team can change, something branch staff must handle, or an expectation created before the person visits either channel.
Take uncertainty about what happens next. Depending on the circumstances, the response could involve clearer preparation instructions, a change to the branch visit, or more useful communication when results arrive. The team has to identify where the uncertainty arises before deciding who should address it.
A broader view also requires restraint. Discovering more of a person’s job does not mean a business should take responsibility for all of it. Some needs sit outside its expertise or its intended role. In healthcare, helping someone organise information for a doctor is a different responsibility from making a clinical decision.
The strategic question is how far the service should extend, given the customer’s needs and the organisation’s ability to meet them well.
Frame the interview. Stay close to the end customer
The value of this work begins in the conversation with the end customer. Sitting with someone, listening to how they describe their experience, and asking about the details gives us material that a framework alone cannot supply. It also asks something of the business: a willingness to change how it works to make the experience more comfortable for the people using it.
NPS and similar measures can provide useful signals about how customers view a service. In-depth qualitative research helps us stay close to the experiences behind those signals. In a conversation, we can ask what happened, follow up on an unexpected detail and understand why it mattered to that person.
Moesta’s and Ulwick’s approaches help structure the interview and the interviewer’s thinking. They give us ways to explore why someone acts, what they are trying to accomplish and how they go about it. The conversation still needs room for the person to explain something we had not thought to ask about.
That is where the nitty-gritty details emerge: an instruction someone had to check twice, a moment when they were unsure what would happen next, or information they needed when moving from one channel to another. These are the kinds of details to listen for. They can reveal practical changes a business can make to help people complete the job more comfortably.
Once we have heard those details, we need to carry them through conceptualisation, building and delivery. That means keeping the original context close enough for each team to understand what it is trying to improve, and returning to customers to see how the shipped experience works for them.
The beauty is in those details. Someone takes the time to explain how a service fits into their life. Our responsibility is to make sure that understanding survives the work and reaches them again as a better experience.
How would this change your roadmap?
Discuss with your AI.

Dima leads digital transformation where human behaviour meets business logic. From launching capital-markets fintech to reinventing healthtech at scale, he helps organisations turn deep behavioural insight into products people trust and use.


