P-Cubed

Prepare → Prove → Produce

I used to present P-Cubed with more authority than it had earned. Prepare, Prove, Produce: the cycle for executing an Epic. Clean. Memorable. Mine.

A colleague I respect pushed on it hard. Where did it come from? What had tested it? How was it different from the discovery and delivery practices that already existed, other than the name? Had the idea earned the confidence I was teaching it with? His larger point was fair: practices survive or die through years of real use, and a memorable name is not evidence.

I could defend the model or test it. The stance I landed on: ideas either collapse under pressure, which means they were not good, or they come out the other side stronger. Push.

This chapter is what survived.

What P-Cubed is, and is not

P-Cubed is a mnemonic, not a methodology.

You have an Epic (see Levels of Work): too big to just start coding, too concrete to plan forever. P-Cubed names the shape of moving through it: Prepare, then Prove, then Produce. The names are mine. The practices inside them are not, and pretending otherwise was exactly the overclaim my colleague caught.

Discovery work and story mapping^[1] live inside Prepare. Spikes^[2] and the walking skeleton^[3] live inside Prove. Iterative, criteria-checked delivery lives inside Produce. If you already run those practices well, P-Cubed adds nothing except a way to remember which one the moment calls for. That is the entire claim. For me it has been enough: the mnemonic is what surfaces under pressure, right when I am about to skip a phase.

What makes the phases more than labels is that each one has an exit criterion. Without exit criteria, the phases are vibes, names you apply after the fact to whatever you were already doing. With them, each phase becomes a decision: what must become true before continuing? The criteria below are my synthesis, still being tested. Treat them as a starting point, not a standard.

Prepare

List what you do not know. Rank the unknowns by what kills the epic if you are wrong. That is Prepare's whole job; everything else in the phase serves it.

Discovery comes first. You do not fully understand the terrain yet, and that is expected; discovery is the work, not a delay before the work. Ask questions. Read the code. Talk to the people who have context. Write down the unknowns as you find them, and keep the list honest.

Declare your status while you are in it: "I'm in discovery on this. I'll have questions. Once I understand it, I'll come back with a plan." That one sentence sets expectations better than any estimate you could fake.

Surface the tradeoffs. For each significant decision: what are the options, what does each optimize for, what does each make harder, what would it cost to change later? There is no best practice waiting at the bottom of the analysis. There is only "what are we giving up, and can we live with it?" Write the answer down, so that when someone asks why it was built this way, the reasoning still exists.

Then plan. Break the Epic into tasks of one or two days each. Give every task one sentence: "This is done when ___." Sequence the load-bearing work first, and make the dependencies explicit.

Prepare exits when you can name the critical unknowns and, for each one, the evidence that would resolve it. The second half is the real test. If you cannot name the evidence that would resolve an unknown, you may have found an anxiety instead of a test. Anxieties are real, and no spike will resolve one. Work it instead of carrying it: decompose it until a testable unknown falls out, or accept it as an explicit residual-risk decision. What it must not do is gate the epic silently.

Prove

First decide whether the decision in front of you needs proving at all. Two questions:

1. How expensive is this decision to reverse?
2. How much better will the information get if I wait?

Expensive to reverse and little to learn by waiting: decide early. Cheap to reverse and much to learn: defer. Expensive to reverse and much to learn by waiting: build a cheap proof before committing. That third category is where Prove lives. (Architecture vs. Design carries the fuller reversibility model.)

The spike is the classic proof: a focused experiment with a specific question, a timebox measured in hours, and clear criteria for what answers it. Spike code is throwaway by definition. Prove code has no entitlement to survive.

When the epic crosses systems, the strongest proof is a walking skeleton: the thinnest end-to-end slice that touches every layer and returns hard-coded answers. Militaries rehearse an operation before executing it: walk the ground, in sequence, before it counts. The walking skeleton is the engineering rockdrill, and Prove is where it runs.

What the rehearsal targets is the contact surface: the genuinely-new boundary where the system first receives from, emits to, or translates for something outside itself, or across a new path. An inbound webhook. An outbound partner write. An app-wide callback sink. A new adapter, import path, or cross-system call.

Two field results shape how you use it:

Finding the contact surface collapses the work. On one integration, the design diagrams pictured a whole new subsystem. A close read found that authentication, dispatch, persistence, and the user model already existed in production. Exactly one thing was new: the inbound callback endpoint. Naming the contact surface shrank the apparent surface area to the one boundary that carried the risk, and fixed the skeleton's first target.

A feature should usually have one. The same project had a second candidate: an outward write to an external system the team did not own. It was deferred behind an explicit go/no-go decision, because that write carried auth scope, idempotency, and failure-mode cost the pilot did not need to buy yet. More than one contact surface in a feature is a scope warning. Split the feature, or defer one surface deliberately.

The rehearsal earns its keep at exactly this boundary, because that is where the tidy diagram meets reality. On that same integration, the diagrammed sequence broke at the contact surface: a short-lived token forced a synchronous call in a codebase whose convention was fire-and-forget. The rockdrill found the divergence while it was cheap. And check the boring things while you are there: on the same system, the integration's config pointed at a dead endpoint and no route existed. If the skeleton does not stand the endpoint up for real, nothing reaches the app, and no amount of beautiful unit tests will save the feature.

One translation step also belongs to Prove. A leadership roadmap is value-ordered: the most important capability first. An engineering slice list is risk-ordered: the walking skeleton first, aimed at the contact surface. Turning one into the other is a deliberate act. Treat the roadmap as the slice list and you have quietly skipped the skeleton.

Prove exits when the highest-risk unknown has a meaningful answer. "No, this will not work" is a meaningful answer. A failed hypothesis can be a successful proof, and it costs far less in week one than in month three.

Produce

Produce begins when no load-bearing uncertainty remains untested, unbounded, or hidden. Residual uncertainty is normal. The difference is that you now understand it well enough to proceed deliberately.

Produce does not mean "rewrite the spike as production code." The spike answered a question, and its code is already done serving. Produce means building the capability as something expected to survive contact with production, users, operators, and future change. (Operability covers what that obligation includes.)

The rhythm, task by task: confirm what done looks like before you start. Build to the scoped definition, not to the better idea you had along the way. Check criteria, not feelings. Ship when done means done.

After each task, run the learning loop: what did you learn, does it change the remaining tasks, is the epic still on track? The plan is a tool, not a prison. When reality diverges from the plan, update the plan.

Things will still go wrong, and the moves are boring on purpose. Blocked: document it, work something else in parallel, name who can unblock you. Task bigger than expected: stop, split it, replan, communicate. Approach not working: check whether you skipped Prove, and do not throw good hours after bad. Scope creeping: write the new scope down as its own task, finish the current one as scoped, then decide.

Produce exits when the capability exists and the temporary proof artifacts are gone: deleted, isolated, or consciously promoted through an explicit engineering decision and a cleanup pass. Shipping with the scaffolding still up is not done.

One limit governs all three criteria: they scale with the work. A one-day task does not need ceremony designed for a multi-quarter initiative. The question each phase asks stays the same size: what must become true before continuing?

The exit criteria

Where P-Cubed sits

Levels of Work tells you what altitude you are at; P-Cubed runs an Epic. The body plan is what Prepare draws: the parts, the joints, what each part refuses to know. The walking skeleton is Prove made concrete, and it targets the contact surface. The reversibility questions decide what needs proving at all. And Operability defines what Produce must include before shipping counts as done. One cycle, with the other frames doing the real work inside it.

Common failure modes

The Forever Prepare. Discovery that never ends. Always one more question, always more terrain. The cure: timebox it, then write down what you know and what you still don't.

The Skipped Prove. "We don't have time to spike it." Then twice the time goes to fixing what the spike would have caught. The cure: prove the risky thing first. It is faster.

The Gold-Plated Produce. "While I'm in here..." The cure: write the new idea down, finish the task as scoped, then decide whether the idea earns its own task.

The Feelings Check. "Does this feel done?" is the wrong question. "Does this meet the criteria?" is the right one. The cure: write the criteria before you start, while you are still impartial.

The version of P-Cubed in this chapter is smaller than the one I first taught. It stopped claiming to replace the practices it compresses. It gained exit criteria, because a phase you cannot exit is a mood. The shrinking was the criticism working as intended.

The loop is still open. I have not yet gone back to the colleague who pushed and said: here is what survived. When I do, this chapter may shrink again. The model did not need defending. It needed testing. It still does.