Background
Kiwi.com had a research team doing genuinely good work. The problem was what happened after. Insights from user interviews, usability sessions, and analytics would be written up, shared, and then gradually forgotten as the backlog filled with vague, barely-supported ideas that had accumulated from all directions. There was no structured process for moving from insight to confidence. Things went on the roadmap because someone thought they were important, not because there was evidence they were the right things to build.
I had come across Teresa Torres' work on continuous discovery and saw in it a framework that addressed this directly. The methodology was sound. The question was whether it could be adapted to Kiwi's specific culture, team structure, and the amount of stakeholder coordination that any meaningful change in process would require.
The preparation
Before designing anything, I did the groundwork. I read Torres' book thoroughly and studied how other product organisations had implemented similar frameworks, including what had worked and what had not transferred well. I ran informal conversations with team members across design, research, and product to understand how they were currently making prioritisation decisions and where they felt the most friction.
These conversations also served a second purpose: building early buy-in. A process change of this kind touches how PMs run their roadmaps, how researchers plan their work, and how design frames its priorities. Without genuine support from the people closest to those decisions, any framework would stall within a quarter. I was especially focused on securing leadership support before going further, because without it the process would lack the organisational weight to sustain itself when it got uncomfortable.
The framework
The design was built around three interlocking components. Each one was chosen to solve a specific failure mode I had observed in how insight was being handled.
A core team with clear ownership
The first failure mode was diffuse responsibility. Insights arrived without a clear owner, which meant nobody felt accountable for doing anything with them. I established a small core team, one representative each from product, design, and research, responsible for preparing insights ahead of sessions, tracking the state of each opportunity, and facilitating documentation. This was not a committee. It was a working group with specific jobs.
Weekly public discovery sessions
The second failure mode was that discovery happened in isolation. Research findings were shared but rarely debated across disciplines in a structured way. The weekly sessions brought the full cross-functional team together to discuss new opportunities and develop ones that had already been prioritised. Strong facilitation was critical: the sessions needed to produce decisions, not just discussion, and the group was multidisciplinary enough that it required careful management to stay productive.
Structured documentation
The third failure mode was that nothing persisted. Insights lived in research repositories that people rarely revisited. I designed a three-part documentation system: an inbox where new insights landed, a playground where prioritised opportunities were developed into well-formed problem statements, and an opportunity map connecting each opportunity to the solutions designed to address it, tracked subsequently in Jira. The documentation made the process transparent to people outside the core team and gave leadership a clear view into how roadmap items were being developed.
Getting teams to actually do it
The most consistent objection I heard during the preparation phase was time. PMs in particular were stretched, and a new standing process looked like another fixed cost on a calendar that was already full. The objection was legitimate. Asking busy people to invest time in a process before they can see its value is a hard sell, and trying to argue your way through it rarely works.
My response was to design the pilot so that the initial commitment was as low as it could be while still being real enough to produce results. I asked for two quarters: one to build the habit and run the process, a second to see the compounding effect as more opportunities moved through the system. The time ask was tiered: weekly involvement from the researcher and myself, who were running the process, and bi-weekly involvement from the PMs, who needed to be present for decisions but not for all the preparation work that went into them.
We ran the pilot with the team where I already had the strongest buy-in, knowing that it would be easier to demonstrate value there first and let results make the case to others. Transparency was part of the strategy throughout: the documentation was public, the sessions were open, and the retrospective at the end of the first quarter included the full team and relevant leadership, turning a review into a natural moment to bring more stakeholders into the core team ahead of the second phase.
The turning point
By the end of the pilot, more than half of the roadmap items for the following quarter had originated from opportunities developed through the process. That was the argument that no one could dismiss. The items had evidence behind them, they were well-formed, and the teams could articulate why they were prioritised. That is a different kind of roadmap from the one we had started with.
Outcome
After the retrospective, the process was formalised and rolled out to a second team, adapted to fit their specific rhythm and stakeholder structure. The core components stayed the same; the cadences and facilitation style were adjusted to what worked for them.
The longer-term impact was not just in the quality of roadmap items, though that was real and measurable. It was in how teams talked about prioritisation. Opportunities were discussed with specificity: what evidence supported them, what had been explored in discovery, what was still unknown. That change in how decisions were framed was harder to quantify but more durable than any single quarter's output.
Outcome
Over 50% of the following quarter's roadmap came from opportunities developed through the process. The framework was subsequently adopted by a second team, with the core structure intact and the implementation adapted to their context. Backlog items went from vague to evidence-backed, and prioritisation conversations became substantially more specific.