Issue #11 - Prove the Wedge, Then Replicate
Subscribers Edition
Velocity without proving the wedge is just error propagation at scale. The methodology pattern that converts parallel work from chaos into compounding output, and the single failure mode that wastes more time than any other.
Field Note
A few Saturdays back, I sat down after lunch to map eight domains of expertise into a consistent framework architecture. By dinner, eighty-six new frameworks had been authored. Not "ideas captured" or "outlines written." Authored. Each one named, structured, slotted into a master architecture, and ready to operate.
I want to be clear about why I'm telling you the number. Not to impress you. The number itself isn't the point.
The point is that the only reason eighty-six was possible in one afternoon is the discipline that came before it. The discipline isn't fast. It looks slow at first. But the discipline is the reason the parallel phase moved at the speed it moved. Without it, the same afternoon would have produced eight half-built domains, a defect propagated across all of them, and a week of cleanup waiting on Monday.
Most attempts at scale fail at exactly the same place. People move to parallel before they've proven the wedge. The work that was supposed to be fast becomes a series of overlapping rebuilds. The error compounds. The velocity disappears.
The framework worth this week's issue is the discipline that makes parallel scale actually work. The pattern shows up everywhere good systematic work happens. It doesn't have a glamorous name. I call it prove-then-replicate.
The Deep Dive
The instinct under deadline pressure is to start everything in parallel because parallel feels faster. Eight domains at once should take an eighth of the time, right? It doesn't work that way. The reason is that you don't know which of your assumptions about the work are wrong until you've completed one instance from start to finish, in production conditions, with all the rigor you intend to apply to the rest.
If you start in parallel, you discover the flaw on instance five. By then it's already been propagated through instances one through four. Now you have to fix five copies of the flaw or rebuild from scratch. Either way, the velocity you thought you were buying with parallel is gone.
The prove-then-replicate pattern works because it lets the first instance break your approach in cheap, recoverable conditions. The first instance is the proving batch. It exists to expose your assumptions. It exists to surface the defects you didn't know were lurking in your methodology. It exists so the parallel phase can fire cleanly.
The proving batch is supposed to fail. Not in the sense of producing a bad final output. In the sense of catching things. If your proving batch completes cleanly and finds nothing wrong, you've either built something trivially simple or you're not looking hard enough. In a real production build, the proving batch always surfaces something.
The first domain caught a real defect. Eight of the files in the proving batch referenced a cross-reference that did not exist. Not a typo. A name that had been invented somewhere upstream and propagated through the spec as if it were real. If I had moved to the other seven domains before catching it, the same invented reference would have lived in dozens of files across the system by dinner. Finding it later would have required a full audit. Fixing it later would have been hours. Fixing it in the proving batch was twenty minutes.
Velocity in the parallel phase is downstream of confidence from the proving batch. Once the methodology has been hardened against one full instance, the remaining instances don't require the same mental load. You're not building eight things. You're running the same proven sequence eight times. The work feels less like creation and more like execution. People watching from outside often interpret the parallel phase as proof of speed talent. It isn't talent. It's the discipline showing up as apparent ease.
Case Slice Teardown
Role: Founder of a small SaaS company about to launch a new feature across three customer segments
Situation: The feature had been built and tested for the largest segment. The plan was to ship it simultaneously to all three segments on the same Friday, with tailored onboarding materials for each. The team was confident. The build looked clean.
Constraint: Marketing had committed to the announcement date. Reversing the launch would damage credibility with subscribers who had been waiting. The team had two weeks before the announcement.
Intervention: Instead of building all three onboarding flows in parallel, the founder applied prove-then-replicate. The largest segment's onboarding was completed end-to-end first. Real users were taken through the flow. The team watched where users got stuck, where the messaging didn't land, where the feature's value wasn't clear without context the team had assumed users would have. The proving batch surfaced four things the team hadn't anticipated. Three were copy fixes. One was a structural issue with how the feature was introduced that would have broken trust in the smaller segments where users had less context.
Outcome: The proving batch took an extra five days. The remaining two segments shipped on schedule because the methodology had been hardened. The structural fix that would have damaged trust in the smaller segments was caught before launch. Across all three segments, the feature was received as one of the cleanest launches the company had done.
What's notable here: The team's instinct was to move all three segments in parallel because "we already know how to build onboarding flows." That sentence is the most dangerous one in any replication scenario. Knowing how to build the thing in general is not the same as knowing how to build this specific thing well. The proving batch's job is to surface the specific things you don't yet know about this specific work. Skipping it means propagating the things you don't know across every instance.
The Prove-Then-Replicate Test
1. Specify the work in full before any of it starts.
The spec describes all instances, not just the first. Every instance follows the same structure. If you find yourself making structural decisions while building the proving batch, the spec isn't done yet. Stop building. Finish the spec.
2. Select the proving instance deliberately.
Pick the one most likely to expose flaws. Not the easiest. Not the most familiar. The one with the most edge cases, the highest variability, the conditions most likely to surface assumptions you didn't know you were making. Easy proving batches are useless proving batches.
3. Build the proving instance completely.
Do not move on. Do not start instance two. Finish the proving instance to production standard, with the rigor you intend to apply to all the others. "Basically done" is where defects hide. The proving instance has to be actually done.
4. Audit the proving instance against the spec.
Look for what the spec failed to anticipate. Look for assumptions you made that the spec didn't require. Look for defects in the methodology, not just in the output. The audit isn't about whether the proving instance is good. It's about whether the methodology is ready to fire in parallel.
5. Fire the remaining instances in parallel.
Only after the proving instance is clean. Only after the methodology has been hardened. Only after the audit has surfaced and resolved the issues the proving batch was supposed to expose. Now parallel actually means parallel, and the velocity is real.
The hardest step is three. The instinct is to move on as soon as the first instance is "basically done." Resist it. "Basically done" is the most expensive sentence in replication work.
Identify your next proving batch
Pick something on your near-term list that involves replication.
A product line. Multiple locations. A course curriculum with multiple modules. A sales onboarding sequence. A series of articles. Anything where several similar instances of work are about to be created in parallel.
Name the proving instance.
Which single instance, if completed first with full rigor, would most likely expose the assumptions in your approach? Not the easiest one. The one with the highest variability or the most edge cases. The one where the methodology gets tested.
Commit to finishing it before any of the others start.
The whole instance, to production standard, with no compromises. Audit it before the rest fires.
Watch what the proving batch catches.
The defects, the unstated assumptions, the gaps in the methodology. Patch the methodology, then fire the parallel work. The velocity downstream of a clean proving batch is what makes the upfront discipline worth it.
The principle generalizes. Anywhere multiple instances of similar work are about to be created in parallel, the prove-then-replicate discipline is the difference between scale and chaos.
What's a project on your list right now where you're tempted to start everything in parallel?
Reply with the project type and which instance would make the strongest proving batch. The most useful examples (anonymized) will appear in a future issue.
Prove-then-replicate is one of the patterns underneath every methodology that produces output at scale. Once you see it, you see it everywhere. Naming it makes it teachable. Teaching it makes it transferable.
Explore Strategic Thinking AcademyOr learn to build your own frameworks, a step-by-step methodology course.
or
Subscribe for a new framework every week
Subscribe - $17/mo
Strategic Thinking Weekly - Published every week
Unsubscribe anytime - Tampa, FL