skip to content

Search

Why Discovery and Delivery Can't Be Separate Teams

Less than one minute read Updated:

Separating the people who decide what to build from the people who build it creates a gap that no handoff document can close.

# product-management
# strategy
# leadership
# continuous-discovery
# organizational-design
Not in series

If an engineer has to guess what a user meant, the org chart already failed them.

Most product organizations split into two halves. One half figures out what to build. The other half builds it. Dell ran this way when I was an engineer there, before I moved into product. The two teams call it “discovery” and “delivery,” and they run it like a relay race: one team carries the baton for three weeks, hands it off in a document, and the other team sprints from a standing start.

It looks tidy on a slide. I have sat on both sides of that handoff, first as the engineer reading someone else’s spec, later as the product manager writing one. Neither side of that boundary line has ever made a product better.

So that’s today’s post.

Today’s Post

Why the handoff is the actual problem, not the phase, and what one Pixis team did instead.

  • Why every handoff loses context, no matter how good the spec is
  • Why dual-track agile only makes the same handoff faster
  • What Pixis’s Prism team did differently, with the numbers to show it
  • What leadership actually has to give up for this to work
  • What staying separate costs, measured in features nobody can point to

1. The handoff is where judgment dies

Discovery and delivery are not the problem. The boundary between them is.

A product manager spends three weeks talking to users, mapping pain points, and building a feel for the problem that took three weeks to earn. Then they write it down: a spec, a brief, a set of stories.

That document is a lossy compression of everything they learned. It keeps the conclusion. It drops the texture: the dozens of small judgment calls, the tone of voice on the fifth interview, the thing a user almost said but didn’t finish.

A spec is a lossy compression of a room Same four steps, in order. Each arrow is where texture turns into a guess. Grey monospace text names what is held at each step. Scroll slowly, this plays once. FROM INSIGHT TO CODE Three weeks of interviews conclusions and the texture e.g. Prism's 15-plus interviews Synthesis becomes a spec conclusions kept, texture cut one paragraph, one hypothesis The spec is handed off now the only thing carried words on the page, not the room Engineer fills the gaps every ambiguity, a best guess not the researcher's intuition what the room held the compression step the document, now the record where the guess gets made
Four steps, one document, and one place where the guess gets made. No later step in this chain gets the room back. (animates as you scroll to it) PNG ↓

The engineer reads the spec and builds exactly what it says. That is not the failure. The failure is that every ambiguity the spec didn’t resolve gets resolved by the builder’s best guess instead of the researcher’s earned intuition.

You cannot fix this with a better spec template or a longer kickoff call. The loss is structural. It happens because the people who built the understanding are not the people making the fifty small calls that turn understanding into code.

2. The dual-track illusion doesn’t fix it

Some teams try to solve this with dual-track agile: one track researches, one track builds, running in parallel instead of in sequence.

This is better than a pure waterfall handoff. It is not a fix.

Dual track keeps the org chart, not the fix Same four rows, two tracks. The right column overlaps in time, but the handoff is still there. Grey monospace text names the concrete cost of each row. SEPARATE / DUAL TRACK INTEGRATED TEAM DECIDES The discovery track decides delivery track executes the brief translation is faster, not thinner The whole team decides PM, design, and engineering, together no brief to translate SEES Requirements, already translated the summary, not the raw feedback a document stands in for the room The raw feedback, first-hand engineers on the customer call e.g. Pixis Prism's 15-person team ACCOUNTABILITY Clean, and that is the problem wrong product: theirs. Late: yours. nobody owns the outcome Messy, and that is the point everyone owns whether it worked no handoff to point at VERDICT Integrated on the org chart Integrated in the room Same four rows every time: what looks structural is decided by who is in the room, not by the org chart.
Same four rows, two columns. The right column isn't cleaner. It just has one less document standing between the room and the code. PNG ↓

The discovery track still produces conclusions that get translated into requirements for the delivery track. The translation is faster because the timelines overlap, but the loss of context is the same loss.

Worse, dual-track quietly creates a hierarchy. The discovery track decides; the delivery track executes. I have watched this breed resentment on one side and detachment on the other, at more than one company. Engineers stop feeling ownership of the direction. Researchers stop feeling accountable for whether the thing they specified was buildable on budget.

The result looks integrated on an org chart and operates as two groups with a polite boundary between them.

3. What Prism did instead

At Pixis, I led the team behind Prism, a natural-language and voice co-pilot layered over ad campaigns. Fifteen people, spanning engineering, design, and product, and none of them read a summary of the customer problem. They were in the room for it.

Fifteen-plus interviews, five features that shipped Pixis Prism, with engineers and designers inside discovery, not reading a summary of it. Bar length is proportional to the count. The gap is the discipline: forty ideas declined, not lost track of. Voice-of-customer interviews 15+ every launch, not a one-time research sprint Features that made the roadmap 5 the other 40 were declined, on purpose What those five did +25% trial-to-paid -40% onboarding time the design was: AI proposes, human commits raw input, the interviews what survived the cut the outcome, measured after ship
Fifteen-plus interviews narrowed to five features on purpose. The gap between the two bars is the discipline, not a shortfall. PNG ↓

Fifteen-plus voice-of-customer interviews turned into exactly five roadmap features, not the fifty a requirements document would have generated by trying to honor every request equally. The discipline was saying no to the other forty, and the people saying no had heard the forty themselves.

The product that came out of that room shipped 25% more trial-to-paid conversion and cut onboarding time by 40%. The hardest design call inside it, how much to let the co-pilot act on a user’s behalf, got decided in the same room as the customer feedback that made the call necessary: the AI proposes, and the human commits.

I run this pattern deliberately now: 15-plus voice-of-customer interviews per launch, every launch, with the people who will build the thing sitting in on some of them. Once fifteen people have described the same problem to an engineer directly, “did we get this right” stops being an abstract question for someone else to answer later.

4. The organizational tax leadership won’t pay

If integrated discovery works this well, why do most organizations still split the teams?

Because separate tracks produce clean accountability, and clean accountability is easy to manage. “The product team decides what to build. Engineering builds it. If the product is wrong, that’s a product problem. If it’s late, that’s an engineering problem.” Every miss has exactly one owner, and nobody has to sit with the messier truth that most misses have several.

Integration removes that convenience. Everyone owns the outcome. Nobody gets to point at a handoff and say “I did my part; the input was wrong.” That ambiguity is genuinely uncomfortable for an organization built around tidy reporting lines.

It also demands different skills than most people were trained for. A product manager on an integrated team has to build shared understanding across a room, not just produce a document that survives review. An engineering lead has to sit through a customer call and take it seriously, not just estimate the ticket that comes out of it. A designer has to argue a technical tradeoff, not just deliver a mockup and wait.

These are not the natural defaults for people trained inside functional specialties. Building them takes deliberate practice, and most organizations would rather redraw the org chart than fund that practice.

5. The cost of staying separate

The cost of keeping discovery and delivery apart shows up slowly, in ways that are easy to feel and hard to put a number on.

The most expensive version of it is the feature that passes every acceptance criterion, ships on time, and moves no metric at all. Everyone did their job exactly as the process defined it. The process was built to optimize for shipping, not for learning, so shipping is exactly what it delivered.

The second cost is cultural. “They don’t get it” becomes the standing complaint on both sides of every handoff, because from each side of a document, the other side genuinely doesn’t get it. Neither side is wrong. Neither side was in the room the other side was in.

Compare that to what I own today at InMobi: the system of record under a demand-side platform and an ad exchange that measure 200M-plus devices’ worth of ad events a day. That work does not tolerate a translated understanding of the problem. The people closest to the reconciliation logic have to be the people who understand what finance actually needs from a monthly close, or the close doesn’t happen on time. Proximity is not a nicety there; it is the only way the system stays correct.

Takeaways

Discovery and delivery, the same team Four sections on why the handoff, not the phase, is the actual problem Hoshank Ailani · hoshank.vercel.app 1. The handoff loses context Interviews compress into a spec Conclusions survive; the texture does not Ambiguity gets resolved by a guess This is structural, not a template gap every claim survives two sentences before a proper noun shows up, then the guess starts 4 steps, 1 handoff, 0 documentation fix 2. Dual track is not the fix SEPARATE INTEGRATED track decides, executes team decides together clean accountability messy accountability looks integrated is integrated timelines overlap; the handoff does not close 2 tracks, 1 boundary, same lossy translation 3. What Prism did instead 1 Engineers sat on customer calls 2 15+ interviews, not a summary of them 3 5 features shipped, 40 declined the discipline was saying no +25% / -40% trial-to-paid up, onboarding time down 4. The cost of staying separate Features that pass every criterion, move nothing Late-stage surprises force rework "They don't get it," said by both sides New skills required, not a new org chart a launch review that only says "did it ship?" never asks the second question paid in slow, diffuse ways, easy to feel The shortest distance between insight and implementation beats the cleanest handoff document, every time. The test: pick the last feature your team shipped and ask who was in the room when it was decided. Full post: hoshank.vercel.app/posts/why-discovery-and-delivery-cant-be-separate Takeaways
The whole post on one card. Save it, share it, argue with it. PNG ↓

Four panels, one per section. The callout is the test to run on the last feature your team shipped.

Final Words

Discovery and delivery are not phases that belong to different people. They are one habit of paying attention, and the habit only survives when the same team holds both halves of it.

Pick the last feature your team shipped and ask a blunt question: who was actually in the room when the decision got made, and who only read about it afterward. If the answer splits cleanly along a team boundary, you already know where the next miss is coming from.

Reply and tell me how your team splits it. I am collecting examples for a follow-up.

Cheers, Hoshank