FORGE
Most frameworks protect the organization from bad products.
This one protects good products from the organization.
Two lanes. Pipeline ships products through six phases with two council gates -- concept and launch. Furnace explores ideas that don't have a business case yet through six modes with fixed clocks. Both run simultaneously. Neither contaminates the other.
Fifteen structural mechanisms replace culture as the governance layer. Named decision authority with 5-day clocks. Time-boxed disagreement. Blind pre-council ballots. Grief protocol for teams after correct kills. Annual zombie detection for products that stopped earning their place.
Portfolio capacity is finite and enforced. Three Full products in Build or Prove at any time. When the pipeline is full, new products queue. One person owns the queue.
The dual-lane design comes from the Pendulum -- the swing is structural, not behavioral. You can't coach your way out of it. FORGE doesn't pick a side. It builds for both positions and lets the architecture hold when the politics shift.
The framework includes a self-diagnostic that catches its own drift. Every system calcifies. This one is built to notice.
Most products don't die from bad ideas. They die because the organization starves them -- committees that won't decide, leaders who won't kill what isn't working.
Every mechanism in this framework exists because something specific broke without it. The phases, the clocks, the kill criteria -- none of it is theoretical.
Committees that distribute accountability until it disappears. Timelines without clocks. Products that nobody will kill and nobody will fund. Frameworks that pick rigor or agility and break when the organization swings the other way.
Two lanes. Pipeline ships products through six phases with two council gates. Furnace explores ideas without a business case. Both run simultaneously. Neither contaminates the other.
Time-boxed phases. Named decision authority. Kill criteria written before work begins. Fifteen structural mechanisms replace culture as the governance layer.
Select a type above, or jump straight in -- the console is pre-loaded with a Payer De Novo configuration.
Build the Path
Pick your constraints. The engine builds the path: phases, deliverables, kill criteria, governance.
Four tools built into FORGE. Configure a blueprint above, or use these directly.
What Holds It Up
FORGE has three load-bearing systems. Remove one and the others fail. The lifecycle defines what happens and when. The people mechanisms define who decides and how disagreements resolve. The portfolio layer defines how many products can run at once and what happens when the pipeline is full. Most PLMs nail the lifecycle and leave the other two to culture. Culture does not survive a reorg.
How the Lifecycle Works
The console builds a configured path. This section is the complete reference: every phase, gate, handoff, and role.
How Gates Work
Every gate follows the same protocol.
5 days before the gate: The product owner submits gate deliverables to the decision-maker. Not a deck. The actual artifacts -- the kill criterion, the market data, the prototype, whatever the phase required.
At the gate, the decision-maker reviews. The options are:
There is no "conditional advance." There is no "come back with more data." Those are kills dressed up as hope. Yes or dead.
Council gates (Thesis and Launch only) follow the same protocol but the decision-maker is the council, not the product owner's direct leader. The council sees the product twice. Everything in between belongs to the product owner.
What Happens Between Gates
A checkpoint is not a gate. Same deliverables, different reviewer. The product owner signs a 1-2 page checkpoint memo. No meeting required. No scheduling delay. No committee.
The product owner's authority is bounded by three constraints: the kill criteria (written before the phase, ratified by council), the time box (non-negotiable), and the deliverable requirements (if they're incomplete, the checkpoint can't pass).
If a phase fails at checkpoint, the product owner can restart it once at half the original time box. A third attempt requires council escalation. There is no infinite retry.
Who Does What
-
Product OwnerOwns the product through the pipeline. Responsible for all deliverables, all phase transitions, all kill decisions between council gates. One person per product. Named, not titled.
-
Decision MakerThe person who approves or kills at each non-council gate. Usually the Product Owner's direct leader. Named before the phase starts.
-
CouncilThe group that reviews at Gate 1 (Thesis) and Gate 2 (Launch). Composition varies by org. The council doesn't manage the product. It authorizes resources (Gate 1) and authorizes market entry (Gate 2).
-
Furnace LeadThe person running a Furnace cycle. Operates outside the pipeline with a mandate from leadership. One person, maybe two. Reports to a tight oversight group, not to a BU.
-
Oversight Group2-3 senior leaders who set Furnace priorities and approve cycle plans. Not a committee. A mandate source.
What Connects the Phases
Every phase produces outputs that become inputs to the next.
- Signal → Thesis The hypothesis document and competitive scan become the foundation of the business case.
- Thesis → Build The validated business case and market conversations become the build spec.
- Build → Prove The working prototype and unit economics become the pilot design.
- Prove → Launch The pilot data and refined economics become the go-to-market plan.
- Launch → Sustain The launch metrics become the quarterly health check baseline.
- Furnace → Thesis The exploration output substitutes for Signal and provides evidence for the Thesis gate.
Most PLMs have a gate at every phase transition. This one has two. The first gate (Thesis) answers: should this product exist? The second gate (Launch) answers: is this product ready for the market? Everything between those two gates is execution. The product owner bears full accountability.
Why only two? Because gate fatigue is where products go to die. When a council reviews the same product five times, by gate three they're rubber-stamping. The review becomes a meeting about a meeting. Two gates forces two real decisions. The rest is trust -- in the product owner, in the kill criteria, and in the clock.
Kill criteria are written before the phase starts, when everyone is rational. The gate is where you honor that rationality instead of succumbing to sunk cost.
The most common failure in product development isn't building the wrong thing. It's continuing to build the wrong thing after the data said stop. Kill criteria exist because organizations are bad at stopping. Named criteria, written in advance, with a named decision-maker who can't delegate the call. That's the discipline.
Structure Over Culture
Culture does not survive a reorg. These fifteen mechanisms do. People leave. These don't.
FORGE Self-Assessment
Five questions. Scored automatically. Find out whether FORGE is operating as designed or drifting toward the calcification it was built to prevent.
The Constraint Layer
How many products can run at once. Max three Full products in Build or Prove simultaneously. When the pipeline is full, new products queue at Thesis until a slot opens. One person owns the queue. The queue is ordered by market urgency, not internal politics.
Five decisions belong to the CPO. Not a committee. Not a working group. One person with the authority and the accountability to make these calls on a weekly cadence.
Concrete constraints. Not guidelines. Not recommendations. Rules that trigger specific consequences when violated.
What the CPO monitors. Not vanity metrics. Signals that the system is working or drifting.
How products move through the queue. Explicit rules that remove ambiguity about what happens next.
Why Frameworks Fail
Every framework eventually becomes the problem it was built to solve. Stage-Gate started as a discipline tool and became a compliance ritual. The swing is inevitable.
FORGE is designed with that swing in mind.
The Pipeline is the inhale: structured phases, binding kill criteria, hard clocks. The Furnace is the exhale: protected exploration, political extraction, long-range scanning.
The Pendulum thesis says organizations oscillate between rigor and agility, and the swing is structural, not behavioral. You can't coach your way out of it. You build for both positions simultaneously and let the architecture hold when the politics shift. The Pipeline holds under agility pressure. The Furnace holds under rigor pressure. Neither collapses when leadership changes.
Reading the Swing
The Pendulum tells you where the organization sits. The answer determines which lane leads.
Seven Ways to Configure FORGE
Not every product enters the pipeline the same way. The archetype determines which phases apply, which deliverables change, and how long the clock runs. Pick wrong and you waste time on governance that does not apply. Pick right and the framework fits the product instead of the other way around.
Decision Tree
Answer the questions in order. The first yes determines the archetype.
The Second Lung
Where ideas live before anyone commits build resources. Protected budget, separate owner, no obligation to ship.
The Pendulum Connection. The Pipeline creates the pressure that forces decisions. The Furnace creates the release that prevents the Pipeline from suffocating the next generation of products. Both run simultaneously.
What Each Mode Produces
The Pipeline has six phases, each with named deliverables, kill criteria, and time boxes. The Furnace needs the same discipline. Without per-mode specifications, the Furnace becomes a parking lot for ideas nobody wants to kill.
- Problem statement brief -- Names the gap, the population affected, and why existing solutions miss it. One page.
- Signal source log -- Every data point that supports the hypothesis: market reports, customer conversations, regulatory filings, claims data, competitor moves. Dated and attributed.
- Buyer landscape scan -- Who would care about this problem being solved? A list of specific buyer types with specific pain points, assembled from evidence, not intuition.
- Cycle-end recommendation -- Promote to Incubation, pivot the hypothesis, or kill. One page with evidence.
- Adjacent product impact map -- Does this problem overlap with anything already in Pipeline or Furnace?
- Regulatory landscape summary -- If the problem sits in a regulated space, the relevant compliance calendar and constraints.
- Hypothesis document -- States the gap, the buyer, and the test that determines merit. Falsifiable. One page.
- Experiment design -- Week-by-week learning plan. What evidence will be generated, how it will be measured, and what constitutes a positive or negative result.
- Buyer validation notes -- Minimum two conversations where the concept was described and the buyer's reaction documented. Not customer discovery theater.
- Kill criterion -- Written before the cycle starts. Specific conditions that would stop the experiment early.
- Final output brief -- Two to three pages. What the experiment tested, what the results were, and whether the concept should move to Extraction or die.
- Rough prototype -- If the concept benefits from something tangible, a sketch-level prototype.
- Unit economics sketch -- Early-stage cost and revenue assumptions. A napkin calculation that identifies whether the economics could ever work.
- Extraction brief -- Summarizes the Furnace evidence, names the Pipeline entry point (Thesis), and identifies what the Furnace work already answered. This replaces the Signal phase.
- Scope lock document -- Defines exactly what transfers to Pipeline and what does not. Prevents scope inflation during the handoff.
- Resource and ownership transfer plan -- Names the Pipeline product owner, team composition, and handoff timeline. The Furnace Lead does not become the Pipeline product owner. Clean break.
- Technical debt assessment -- If a prototype was built during Incubation, what needs to be rebuilt vs. what can carry forward.
- Adjacency hypothesis -- Names the existing product, the new market or population, and why the product might transfer. Cites existing product performance data.
- Gap analysis -- What is different about the adjacent market? Where does the existing product fit and where does it break?
- Buyer validation (minimum 2 conversations) -- Does the existing product's value proposition translate, or does it need to be reframed?
- Recommendation brief -- Extend the existing product, fork a new product for the adjacent market, or kill. One page with evidence.
- Cannibalization risk assessment -- Will the adjacent product compete with the existing product for the same buyers or resources?
- Quarterly horizon brief -- Covers three horizons: regulatory changes (12-24 months), market shifts (6-18 months), and technology developments (12-36 months). Names specific changes, assigns probability, and flags anything that should trigger an Exploration cycle.
- Signal escalation list -- Any horizon signal that crosses from "interesting" to "requires action." Named signals with recommended next steps.
- Prior quarter accuracy check -- What was predicted? What was missed? What was predicted and did not happen? The scanner must account for its own accuracy.
- Deep-dive memo -- When one signal warrants more investigation than a brief allows. Three to five pages.
- Kill decision review -- What triggered the kill? Was the criterion correctly constructed? Was the data accurate? Written by someone not involved in the original work or the kill decision.
- Revised hypothesis -- What was wrong with the original thesis and what evidence now suggests it may still be viable.
- Evidence test -- A targeted experiment that addresses the specific gap the original work could not close. A focused test of the exact question that killed the product.
- Final recovery recommendation -- Re-enter Pipeline at Thesis, return to Furnace archive, or confirm kill. Two pages with evidence.
- Market condition comparison -- Has something structural changed since the kill that makes the product viable now?
- Process failure analysis -- If the kill was caused by process rather than product, what broke and what would prevent it.
Who Runs the Furnace
The Furnace Lead owns the Furnace the way a Product Owner owns a Pipeline product. One person. Named, not titled. Runs all active cycles, manages the Furnace budget, decides what enters and exits. The role requires someone comfortable with ambiguity, comfortable killing their own experiments, and comfortable telling a VP that their pet idea failed a six-week test.
Not a junior role. Not a rotation assignment. A senior product leader who reports directly to the CPO and operates outside the Pipeline reporting structure. If the Furnace Lead reports to a Pipeline Product Owner or a BU leader, the Furnace becomes a feature factory for the loudest stakeholder.
- Reporting StructureFurnace Lead reports to CPO. Not to a Pipeline Product Owner, not to a BU leader, not to an innovation committee. Direct line to the person who owns the portfolio.
- Decision Rights: Furnace Lead AloneStart or kill any Exploration, Incubation, Adjacency, or Recovery cycle. Allocate Furnace budget across active cycles. Reject cycle requests that do not meet the entry bar.
- Decision Rights: Requires CPOExtraction decisions. Any single cycle consuming more than 40% of quarterly Furnace budget. Changes to overall Furnace budget allocation. Overriding a Furnace Lead kill decision.
- Escalation PathFurnace Lead vs. Pipeline Product Owner conflicts: CPO resolves within 5 business days. If the clock expires, the Furnace Lead's position holds. The Furnace is structurally protected because it is structurally weaker. Without explicit protection, the Pipeline always wins.
- Budget Allocation15-20% of total product budget, ring-fenced. Set annually, reviewed quarterly, cannot be raided for Pipeline overruns. The moment the Furnace budget becomes a Pipeline reserve fund, the Furnace is dead.
Governance Without Overhead
The Pipeline has council gates. The Furnace needs governance too, but lighter. Two cadences.
Every other PLM framework assumes the organization is the asset and the process protects it. This one starts from a different premise: most products die of oxygen deprivation, not poor decision-making. The clock, the kill, the named owner, and the Furnace are the corrections. What follows is the operating system.
This framework was built inside a top-three national health plan's product organization after 50+ interviews with product leaders, medical directors, and operations executives across health plans, health systems, and health technology companies who described the same failure modes. The phases are not theoretical. The kill criteria are not aspirational. The people mechanisms are not borrowed from a textbook. Every element exists because something specific broke without it.
The two-lane architecture came from a specific observation: organizations swing between rigor and agility, and every swing breaks whatever the last swing built. A framework that picks one side becomes a weapon for the other. FORGE has two lanes because the Pendulum is real. The Pipeline holds when leadership wants speed. The Furnace holds when leadership wants control. Neither lane exists to win. Both exist to survive the swing.
FORGE vs. Stage-Gate
Stage-Gate is the default. Most organizations run some version of it. Here is where the two frameworks diverge and why the differences matter.
| Dimension | Stage-Gate | FORGE |
|---|---|---|
| Council gates | Gate at every phase transition (typically 5) | Two council gates. Concept and launch. Everything else belongs to the product owner. |
| Time discipline | Phases end when deliverables are "ready" | Every phase is time-boxed. The clock forces the decision. |
| Kill mechanism | Gates can kill, but rarely do in practice | Kill criteria written before the phase starts. Binding. No conditional advance. |
| Decision authority | Committee-based governance | One named person decides at each non-council gate. Not a title. A person. |
| Exploration | Pre-development "Discovery" stage | Parallel Furnace with its own governance, clock, and kill criteria. |
| Configurability | One path fits all product types | Seven archetypes, each with modified phases, deliverables, and timelines. |
| People problems | Assumed to be solved by culture | Fifteen structural mechanisms. Named authority, time-boxed disagreement, escalation protocol. |
| Portfolio layer | Separate from the PLM | Built in. Capacity limits enforced. Queue owned by a name. |
10 Organizational Pathologies
One Product Through the System
A payer's specialty care team identifies a gap: high-risk maternity members are generating avoidable NICU admissions. The clinical signal is real. The cost data supports it. Nobody has built a structured intervention.
The same organization attempted the same product the previous year. Month 1: scope defined. Month 2: undocumented strategy shift by a VP who wanted to expand scope to include postpartum depression. Months 3-5: cycling iterations between product, clinical, and the BU over what "maternity" means.
Month 6: pricing model rebuilt for the third time because the expanded scope changed the economics. Month 8: compliance review flagged TCPA risk on member outreach. Month 10: compliance review completed, vendor contract expired during the delay. Month 12: new RFP required. Month 14: deprioritized by incoming leadership. Zero members served.
The product was never bad. The organization was never incompetent. The structure made speed impossible and nobody had permission to say so.
That is what FORGE prevents.
Kill Criteria Generator
Test whether your kill criterion is specific and measurable enough to be binding.
What Each Phase Actually Produces
Detailed deliverable specifications for each phase are available through the configuration console. Select a product type in Quick Start, then expand any phase card to see the full deliverable list with descriptions, quality bars, and context for why each artifact exists.
Read the full FORGE Operating Manual →Working Documents
Editable templates for every deliverable, gate review, and governance document.
Click any template to preview, edit, print, or save.
If FORGE is how you want to run your product org, I've implemented it.
joe.nalley@showyourwork.healthAvailable for advisory, implementation, and portfolio governance.