Case Study · Tangerine · 2025
Building the discovery playbook I wished existed.
Product teams at Tangerine wanted to better define their process for continuous exploration, but there was no shared definition of what it meant, who owned it, or where to even start. I researched, interviewed, and built the playbook that answered those questions.
The problem
Everyone used the word "discovery." Nobody meant the same thing.
Continuous discovery was a term people at Tangerine used a lot. But when you actually asked what it meant, you got different answers depending on who you asked.
There was no shared definition of what continuous exploration was, or what it was supposed to look like in practice. The bigger question was who owned it. Was it the PMs? The POs? Service designers? Leadership? And even if you wanted to do it, where would you start? Which teams could you tap into for research? What data existed? Who should you be collaborating with?
The information and the people were all there. Strategic Insights, Digital Analytics, and Service Design teams each had valuable research capabilities and data. But product teams had no clear path to any of it. Discovery ended up being something people intended to do rather than something that actually ran consistently.
Why it matters
Where continuous exploration lives in the product lifecycle.
Design thinking is usually taught as a linear sequence: Empathize, Define, Ideate, Prototype, Test. In practice, product teams skip straight to Ideate or Prototype because the Empathize and Define stages feel slow, expensive, or unclear who's responsible for them.
Continuous exploration is what makes the first two stages actually happen on a regular cadence, not just at project kickoff. It sits at the front of the loop, feeding every downstream decision with real customer signal. When it's missing, teams build based on assumptions.
Continuous exploration anchors the front two stages and feeds back into each cycle, keeping the whole loop grounded in current customer reality.
Without continuous exploration running consistently, the Empathize and Define stages happen once at the start of a project. And then teams coast on those assumptions for months. The playbook was designed to fix that by making the front of the loop a repeating habit, not a one-time event.
What I did
Research, interviews, framework, playbook, then teach it.
The project came together in a few distinct phases.
Industry best practices first
I started by going broad: reading up on industry best practices for continuous discovery and customer research, and getting a clear picture of what the PM community generally considers good exploration practice. This gave me a foundation and a vocabulary and frameworks before I started any internal conversations.
Three research teams, separately
I then set up conversations with Strategic Insights, Digital Analytics, and Service Design teams. For each team, I wanted to understand what data they were collecting, how they collected it, where it lived, and how product teams could realistically access and use it. A lot of this information essential to continuous exploration existed internally but was scattered and not visible to the people who needed it most.
Opportunity mapping with an agile consultant
To make sense of everything I'd gathered, I worked with Tangerine's agile consultant to build out an opportunity mapping framework. This gave the playbook a concrete structure that connected customer signal to backlog decisions in a way teams could follow and repeat.
The actual playbook
With the research done and the framework in place, I built the playbook. It defined continuous exploration in plain terms, laid out when and why product teams should be doing it, and made clear which teams to go to, what those teams could offer, and where to find everything. That last part turned out to be just as valuable as the framework itself.
The playbook mapped out four phases of the lifecycle:
Weekly signal intake
Establish a regular intake of signal from CX surveys, support data, analytics, and research — all feeding into one consistent review cadence.
Opportunity mapping
Convert raw signal into ranked opportunities, every one tied to a real customer outcome. If it can't be traced back to signal, it doesn't belong on the map.
Smallest possible bet
Identify the cheapest experiment that would confirm or challenge each opportunity. Bias toward learning fast.
Backlog with evidence
Sprint planning starts from the opportunity map. If it isn't grounded in customer signal, it doesn't get committed.
Workshop sessions and the Lunch & Learn
The playbook launched through a Lunch & Learn called Secrets to Effective Product Research, presented to over 72 PMs, POs, and other professionals at Tangerine. Rather than walking through slides about discovery in the abstract, I introduced the three research teams, explained what each one could offer, and showed exactly where to find their resources. Workshop sessions gave teams a chance to work through the framework with their own projects.
Key decisions
What made this one actually stick.
Clarity over comprehensiveness.
The goal was never to build an exhaustive document. It was to answer the questions that were actually blocking people: What is this? Who does it? Who do I talk to? Where do I go? Keeping that focus made the playbook something people could act on.
Going to the source.
Spending real time with each of the three research teams before writing anything meant the playbook reflected how things actually worked at Tangerine. It also meant those teams understood what the playbook was trying to do, which made them natural advocates for it.
Workshop, not a memo.
Distributing a document and hoping people read it would not have gotten the same result. Running a live session where people could see the resources, ask questions, and connect the framework to their own work made the difference. Adoption came from people seeing the workflow run, not reading about it.
Anchored to Tangerine's actual tools and data.
The playbook named the specific internal dashboards, research artifacts, and team contacts PMs needed. All resources + tools + contacts were centralized in one location.
Impact
How it landed.
Adoption of continuous discovery practices went up 64% across the teams I worked with. The 72+ people who attended the Lunch & Learn left with a clearer picture of what resources were available to them and how to use them.
The less quantifiable shift was in how teams talked about their backlogs. Conversations that used to be about which feature to build next started becoming conversations about which customer problem to prioritize. That change in framing is what continuous discovery is actually supposed to produce.
Learnings
What I took away.
The hardest part of this project was not building the framework. It was figuring out that the framework alone would not be enough. People needed to know the what, the who, and the where, and they needed to see it all in one place before any of it became usable.
- Frameworks are products. Just shipping the artifact doesn't result in any real adoption. You get adoption by co-creating with the people who have to use it, marketing, truly showing how it provides value, and then teaching it in person.
- Specificity beats elegance. A 90% solution mapped to your team's actual tools beats a 100% solution mapped to a generic textbook.
- Cross-functional research builds cross-functional buy-in. Coordinating with three separate teams before launch created a built-in network of advocates who understood and believed in the output.
- Internal tools fail when they assume people already know how to navigate the org. The most useful thing this playbook did was remove that assumption.