From Silos to Partnership
Creating the PM + PD Discovery Framework
Role: Director of Product Design
Partners: Product Management Leadership, Sr. VP of Product (Executive Sponsor)
Impact: 124% increase in discovery work (2.1 → 4.7 artifacts per person/quarter)
Workflow of new discovery process
The Problem
Product designers and product managers didn't know how to partner on discovery and research. It sounds basic, but the confusion was real: Where does PM's work end and PD's work begin? Who leads user interviews? Who owns the research plan? Who synthesizes findings?
Without clear boundaries, teams defaulted to one of two extremes — either PMs did all the discovery work while designers waited for requirements, or designers ran research in isolation without PM input. Neither approach worked.
The result? We were stuck in reactionary design mode. Teams jumped straight to solutions without understanding the problem first. Research happened inconsistently, if at all. And when it did happen, the insights didn't translate into better product decisions because PMs and designers weren't aligned on what needed to be learned.
We needed a structured way for designers and product managers to partner effectively — not just on execution, but on the discovery work that happens before anyone writes a spec or opens Figma.
What Made This Hard
No one agreed on roles. Ask five PM-designer pairs how they collaborate on research, and you'd get five different answers. Some teams had it figured out. Most didn't.
Discovery wasn't valued consistently. Product leadership talked about being customer-centric, but the incentive structure rewarded shipping features, not understanding problems. Teams felt pressure to skip research and jump to building.
We needed cross-functional buy-in. This wasn't just a design problem or a PM problem — it required both disciplines to change how they worked together. That meant getting leadership alignment before rolling anything out to teams.
How We Approached It
I partnered with a product management senior leader, to co-create a framework. We secured our Sr. VP of Product as the executive sponsor, which signaled that this mattered to both design and product leadership.
Phase 1: Understand the Gaps
We started by talking to designer-PM pairs across the organization. What worked in their partnership? What didn't? Where did they get stuck?
The pattern was clear: teams wanted structure, not more process. They needed to know who owns what at each stage of discovery, but they didn't want rigid processes that slowed them down.
Phase 2: Build the Framework Together
We created Discovery/Research Swimlanes — a visual framework showing PM and PD responsibilities across four phases:
1. Discovery Planning
Together: Fill out discovery brief, align on timeline and milestones
PM Leads: Timeline and milestone planning
PD Leads: Research criteria and plan definition
2. Research Execution
PM Leads: Market analysis and competitor research
PD Leads: User interviews and usability studies
Together: Participate in each other's research activities
3. Synthesis & Direction
PM Leads: Business recommendations and success criteria
PD Leads: Experience vision and design principles
Together: Opportunity assessment and prioritization
4. Documentation & Planning
PM Leads: Business case and product roadmap
PD Leads: Design requirements and input on roadmap
Together: Joint recommendations and implementation plan
We also defined communication frameworks (weekly syncs, daily standups during research) and decision-making principles (who leads what type of decision, where joint ownership matters).
Phase 3: Socialize and Iterate
Before rolling this out broadly, we tested it with a few teams and gathered feedback. We refined the language, clarified edge cases, and made sure it felt practical, not theoretical.
Then we presented it to the product and product design orgs — my product peer and I co-led the session. That joint ownership at the top set the tone for how teams should partner.
The Decisions That Mattered
1. We Co-Led From the Start
This couldn't be a design initiative that PMs tolerated or a PM initiative that designers followed reluctantly. My product partner and I built it together, presented it together, and championed it together. That partnership modeled what we wanted teams to do.
2. We Made It Visual and Practical
The swimlanes format made it immediately clear who does what at each phase. No need for dense documents. No theoretical frameworks. Just a clear visual that teams could reference when they got stuck.
3. We Built in Flexibility
The framework showed ownership, but it wasn't prescriptive. Teams could adapt the specifics to their context as long as they followed the principle: both disciplines need to be involved in discovery, with clear outcomes at each stage.
4. We Got Executive Sponsorship Early
Having the Sr. VP of Product as our executive sponsor meant this wasn't optional — it was how we work. That top-down support gave teams permission to prioritize discovery work instead of jumping straight to delivery.
What Changed
The Product Discovery KPI tracked how consistently teams dedicated time to understanding user needs before building solutions. The metric measured deliverable artifacts per person per quarter (Discovery Snapshots, Research Summaries, etc.).
Baseline (before framework): 2.1 artifacts per person per quarter
One year after rollout: 4.7 artifacts per person per quarter
Improvement: 124% increase — teams more than doubled their discovery output
The improvement wasn't immediate — it built quarter over quarter as teams adopted the framework and made discovery work a habit rather than an afterthought.
But the numbers only tell part of the story. Here's what really changed:
Teams stopped asking "should we do research?" The framework made it clear that research isn't optional — it's part of how PM and PD partner. The question became "what research do we need?" instead of "do we have time for research?"
Designers and PMs knew where to collaborate. Instead of stepping on each other's toes or working in silos, teams had clear swimlanes showing where their work overlapped and where each discipline led.
We moved away from reactionary design. As one designer put it: "We've effectively moved away from reactionary design and actually getting research done before the work needs to start. Attribute that to the processes that have been put in place."
What I Learned
Co-creation builds better adoption. Working with product senior leadership to build this framework meant we had buy-in from both sides from day one. When leaders from different functions champion something together, teams take it seriously.
Clarity beats flexibility without structure. Teams don't need freedom to invent their own processes — they need clear guardrails that show them how to work together effectively. Once you give them that structure, they can adapt it to their needs.
Executive sponsorship makes things real. Having the Sr. VP of Product behind this signaled that discovery work mattered as much as delivery work. That top-down validation gave teams permission to invest time in research.
Start with the pain point, not the solution. We didn't lead with "here's a new framework." We led with "you've told us you don't know how to partner on research — let's fix that together." When people see you solving their actual problem, they engage differently.
Project Details
|
My Contributions
|
Team Credits
|