Shared Context Is The Process

Part 3 of 8: The Capability Expansion Series

---

Take the free assessment to gain insight into your UX Generalist journey, and receive regular free learning plans via email.

---

Let’s be honest. Process conversations are usually boring as hell. Nobody gets excited about RACI matrices, checkpoints, sprint ceremonies or stakeholder alignment sessions. But here’s what should get you excited… we’re entering a very cool new phase of product development where we can completely blow up how products get built and rebuild it from scratch. The old processes that take months and still ship the wrong thing? They’re done. The handoffs and documentation and approval chains that everyone pretends work but actually create a swirly morass of confusion? We can throw them out too.

What we’re talking about isn’t tweaking your agile implementation or adding another ceremony to your sprint. It’s recognizing that when everyone can build, when AI makes baseline execution accessible to anyone, the entire premise of sequential handoffs collapses. Process was designed for a world where only specialists could execute. That world is gone.

I talked about this in the last article What Happens When Everyone Can Build — The new way of working is parallel, not sequential

Handoffs are the enemy of shared understanding

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 where executives can share payment profiles and assistants can manage bookings. We followed all the processes, did the research, wrote the specs, designed the flows, built the features. Every ceremony executed, every checkpoint cleared. 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 coordination, 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.

Here’s what’s actually exciting. Imagine sitting in a room where 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 in the funnel. Nobody’s presenting findings. Nobody’s packaging insights into decks. Everyone’s seeing the same thing through their lens, and the actual problem emerges. It’s not slow loading or unclear pricing or bad design in isolation. It’s how they compound at specific moments.

Now here’s where it gets wild. Because everyone can build with AI, that realization turns into action immediately. 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 for the business. Thirty minutes ago you were watching a user struggle. Now you have three different approaches to test, built and ready. That’s the shift we’re talking about.

“But who makes decisions? This sounds like chaos!” If that’s your first concern rather than whether you’re building the right thing, you’re missing the point. When three people across roles genuinely understand a problem together, the right path usually becomes obvious. You might argue about implementation details, but you’re not wasting time debating whether the problem exists or what success looks like. That shared understanding creates momentum that hierarchical decision-making can’t match.

Moving beyond the speed of documentation

Process exists because we assume people can’t or won’t collaborate effectively without it. We create elaborate matrices mapping responsibilities because we expect territorial disputes, approval chains because we assume critical things will get missed, documentation requirements because we expect finger-pointing when things go wrong. These mechanisms are insurance policies against misalignment, but like all insurance, they come with a premium. We move at the speed of documentation rather than the speed of understanding.

The teams shipping breakthrough products aren’t following better process. They’re building shared context through doing. Look at any startup that disrupted an incumbent; they didn’t win through superior project management or more detailed requirements. They won because fewer boundaries between thinking and building meant faster learning cycles. When five people in a garage can out-execute a thousand-person organization, it’s not because they’re smarter or work harder. It’s because they share context by default. Everyone knows what everyone else knows. Decisions happen in real-time based on shared understanding, not through approval chains based on documented interpretations.

Of course this terrifies the process people. The PM who’s built their career on being the “single source of truth” for requirements. The design systems team that gates every component. The tech architecture reviewers deciding what’s “technically feasible.” These roles exist because we built organizations around the assumption that coordination requires dedicated orchestrators. But when teams build shared understanding through actual work, when everyone can prototype and test ideas, those orchestration roles start looking like expensive overhead.

Cool, cool, cool… but how?

Let me show you what this actually looks like. Say your team needs to reimagine how enterprise software gets implemented. Instead of the usual research-then-design-then-build waterfall, you get the PM, designer, and engineer in the same room for customer interviews. Everyone hears the same stories, the same pain points, the same workarounds customers have built.

The insights that emerge come from shared experience. Maybe you discover that what you’ve been selling as an integrated platform feels like disconnected modules to users. Or that customers care more about specific workflows than your comprehensive feature set. These aren’t insights filtered through a research report that gets interpreted three different ways. They’re shared realizations that everyone understands because they heard the same conversations.

After that discovery, people build. But not in silos. What makes this different is how the work happens. You’re in Slack seeing rough prototypes, half-baked schemas, pricing models sketched on napkins. “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.” Everyone’s working on the same core insight through their own lens, but they’re sharing thinking as it happens, not presenting polished work for approval.

This constant sharing changes everything. Problems get spotted while they’re small. A design assumption that would have caused weeks of rework gets caught in a Slack thread. A technical constraint that would have killed a feature gets surfaced while it’s still a sketch. When disagreement happens, you’re not debating abstract ideas. You pull up the actual interview. “Remember when the procurement manager said they can’t get budget approval for big implementations?” “Yeah, but the legal ops person said modular doesn’t work for compliance.” The shared reference points make resolution faster. And since everyone can build, you test both approaches and let reality decide.

This is the difference between rituals that build understanding and ceremonies that waste time. A standup where people share “I tried this approach and here’s what broke” beats status theater. A working session with rough prototypes beats a review meeting where stakeholders pretend they understand what they’re approving. It’s not chaos. It’s replacing coordination overhead with actual collaboration.

The rhythm that works looks something like this:

• Together: Problem exploration (one day) — Watch users, review data, hear from customers. Build shared understanding of what you’re solving.

• Apart: Lens-specific investigation (2-3 days) — Each discipline explores through their expertise. Designers sketch flows, engineers test technical approaches, PMs model business impact.

• Together: Synthesis and iteration (half day) — Share rough work, spot connections, identify conflicts. “Your prototype changes my assumptions about the data model.”

• Apart: Refined building (2-3 days) — Take insights from synthesis, build more refined versions. Still rough, still shareable.

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

It can look like this! 👆

This cycle compresses months of sequential handoffs into weeks of parallel discovery. More importantly, it maintains shared context throughout instead of losing it at every handoff.

Look, if you’re manufacturing widgets or processing transactions, keep your process efficiency. But if you’re building products that don’t exist yet? Your ability to build and maintain shared context through actual work determines whether you ship something people want or another feature nobody uses.

Love the theory, but what does this actually do?

So what changes when you work this way? Everything. You stop hiring for people who are amazing at their narrow specialty and terrible at collaboration. You stop measuring progress by how many tickets got closed and start measuring how fast you’re learning. You stop having meetings where half the people are seeing work for the first time and pretending to have useful feedback.

The constraints are still real - deadlines, budgets, quality standards. But instead of using process as protection against failure, you use shared understanding to move faster toward success. Instead of three-month cycles with perfect documentation, you get one-week sprints with rough prototypes and real user feedback. Instead of hoping your handoffs don’t lose critical context, everyone has the context from the start.

Here’s the thing that should blow your mind. AI makes all of this possible at a speed that would have been insane two years ago. When everyone can spin up prototypes, run analyses, test ideas in real-time, shared context isn’t just theory - it’s immediately actionable. The gap between “what if we tried...” and “here, click through this prototype” collapses to minutes. The cost of being wrong is so low you can explore five different directions before lunch.

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. The question is whether you’re ready to blow up the old way and build something that actually works.

In the next article, we’ll explore how to keep parallel exploration from becoming chaos -- the approaches that allow teams to converge without consensus or endless meetings.

---

---