Learning Plan 3: Shared Context Is The Process

Replace Sequential Handoffs with Parallel Discovery

The Problem
Process creates documentation. Shared context creates understanding.
The Solution
Teams that build together ship the right thing faster
Time Investment
1-2 weeks to transform your first project
Prerequisites
Completed LP1 & LP2 (or equivalent experience)

You've learned to eliminate bottlenecks and bring your lens to execution. Now let's blow up the old way teams work and rebuild it around shared context, not handoffs.

The Payment Delegation Lesson

"At one company I worked at, we spent an entire quarter building payment delegation for executives. The idea seemed solid. Executives need their assistants to book rides on their behalf, so let's create a complex payment delegation system..."

Every ceremony executed. Every checkpoint cleared. Perfect process, perfect documentation.

When it launched, nobody used it.

Turns out executives just hand their phone to their assistant when they need a ride booked. All that process, all that time, and we built an elaborate solution for a problem that didn't exist because we never built shared context around how executives and assistants actually work together.

Your Exercise: Think of a feature your team built that nobody uses. What context was missing? Who wasn't in the room when decisions were made?

Section 1: Understanding the Shift

Why sequential handoffs are obsolete when everyone can build

Exercise 1.1: The Room Where It Happens

Imagine this scenario (then make it real):

"A PM, designer, and engineer are all watching the same user struggle with your product. The engineer suddenly goes 'oh shit, that's the API call that's taking three seconds' while the designer is noticing how the user squints at costs buried in tiny text. The PM connects it to conversion data showing people bail at exactly that price point..."

Now plan your version:

  • Pick a real problem area in your product
  • Get PM, design, and engineering in the same room
  • Watch 3 real users together (or review recordings)
  • Document what each discipline notices through their lens
  • Find where the insights intersect

Goal: Experience how different lenses seeing the same thing create deeper understanding than any research report

Exercise 1.2: From Insight to Prototype in 30 Minutes

The game-changer: AI collapses the gap between insight and action.

"The designer sketches a new flow and has AI turn it into a working prototype while you're still talking. The engineer spins up a test environment with a faster API implementation. The PM pulls real conversion data to model what fixing this would actually mean..."

Try it yourself:

  1. During your observation session, sketch a solution
  2. Use Claude/ChatGPT to turn sketches into code
  3. Have engineer validate technical approach with AI
  4. Have PM model impact using AI for analysis
  5. Time how long from "what if" to testable artifact

Goal: Experience how AI enables immediate action on shared insights

Section 2: The Rhythm That Works

Structure parallel discovery without chaos

Parallel Process Workflow - Together and Apart rhythm

The Parallel Discovery Cycle

Together (Day 1)

Problem exploration — Watch users, review data, hear from customers. Build shared understanding of what you're solving.

Apart (Days 2-3)

Lens-specific investigation — Designers sketch flows, engineers test technical approaches, PMs model business impact.

Together (Day 4)

Synthesis and iteration — Share rough work, spot connections, identify conflicts. "Your prototype changes my assumptions about the data model."

Apart (Days 5-6)

Refined building — Take insights from synthesis, build more refined versions. Still rough, still shareable.

Together (Day 7)

Integration and testing — Combine approaches, test with users, make decisions based on what you learned together.

"This cycle compresses months of sequential handoffs into weeks of parallel discovery."

The visual above shows how this looks in practice — notice how "together" moments create shared context while "apart" time allows deep exploration through each lens.

Exercise 2.1: Run Your First Parallel Sprint

Take a real project and run it through this rhythm:

Monday Together (2-3 hours):

  • Customer interviews or user observation
  • Each discipline shares what they notice
  • Align on the core problem (not solutions)

Tuesday-Wednesday Apart:

Share progress in Slack. Keep it rough:

  • "Hey, look at this workflow view I'm trying"
  • "Oh that connects to how I'm thinking about the data model"
  • "Wait, that could change our entire pricing approach"

Thursday Together (1-2 hours):

  • Share explorations (no presentations)
  • Find where approaches align or conflict
  • Decide what to refine

Goal: Experience how this rhythm maintains shared context without constant meetings

Exercise 2.2: Sharing Rough Work

The secret: Share thinking as it happens, not polished work for approval.

Stop Doing This:

  • Polishing before sharing
  • Waiting for "approval"
  • Presenting findings in decks
  • Documenting everything

Start Doing This:

  • Screenshots of sketches
  • Loom videos of thinking
  • Half-baked prototypes
  • Questions not answers

Create a #project-rough-work channel. Post something unfinished every day this week.

Goal: Break the habit of polish that slows everything down

Section 3: Making It Stick

Navigate objections and scale the approach

Exercise 3.1: Handle the Objections

You'll hear these. Here's how to respond:

"But who makes decisions?"

When three people genuinely understand a problem together, the right path usually becomes obvious. Test both approaches if needed—since everyone can build, the cost is low.

"This sounds like chaos!"

Show them your parallel sprint results. Compare: 1 week to testable solution vs 3 months of handoffs. Which delivered value faster?

"We need documentation!"

Documentation captures decisions. Shared context prevents bad decisions. When everyone was in the room, you need less written down.

Goal: Prepare responses based on results, not theory

Exercise 3.2: Measure What Matters

Track these metrics for your parallel vs. sequential projects:

Speed Metrics:

  • Time from problem identified to solution tested
  • Number of "waiting on X" blockers
  • Rework due to misunderstood requirements

Quality Metrics:

  • User adoption of shipped features
  • Post-launch fixes needed
  • Team satisfaction scores

"You stop measuring progress by how many tickets got closed and start measuring how fast you're learning."

Goal: Build an evidence-based case for this way of working

Your New Reality

From 3-month waterfalls to 1-week cycles. When everyone builds in parallel, you compress discovery to days, not quarters.

From handoff delays to continuous progress. No more "waiting on design" or "blocked by engineering."

From building features nobody uses to shipping what users actually need. Shared context means you solve real problems.

Remember: We're not talking about improving your existing process. We're talking about recognizing that the entire old foundation—specialists do specialist work, coordination requires documentation, handoffs are necessary—is obsolete. When everyone can build, the old rules don't apply.

Tools & Templates

Slack Channel Structure

#project-together - Shared discoveries, user insights

#project-rough-work - Daily progress, sketches, prototypes

#project-decisions - What we've agreed to test/build

Keep conversation in the open. Transparency builds context.

AI Prompts for Parallel Work

Designer → Prototype:

"Turn this hand-drawn flow into a working React component..."

Engineer → Validation:

"What's the fastest way to test if this API approach would scale..."

PM → Impact:

"Model the revenue impact if we improve conversion by X%..."

Your Mission This Week

1. Pick one project to run as a parallel sprint

2. Get PM, design, and engineering in the same room for user observation

3. Follow the Together → Apart → Together rhythm

4. Share rough work daily

5. Measure how much faster you ship the right thing

The question isn't whether you're ready for this. It's whether you're ready to stop wasting months building the wrong thing.

Shared context is the process. Everything else is theater.