FORGE

Every product has a lifecycle. Most teams discover theirs by accident.

Configure yours.

Joe Nalley

The Thesis

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 proving ground are the corrections. What follows is a configurable lifecycle engine. Set your constraints, and it builds the path.

7 Non-Negotiables

Kill criteria at every gate

Written before the phase starts, falsifiable, and binding. If you can't name what would kill this product, you haven't earned the right to fund it.

The clock is the discipline

Every phase is time-boxed. The clock forces decisions that consensus never will. One extension per phase, max 3 weeks, with written justification. A second request triggers a kill review.

One person decides

Named, not titled. Not a committee. Committees distribute accountability until it disappears.

Market data over internal consensus

Buyer conversations, not alignment meetings. The market is the arbiter. Internal agreement is a comfort metric.

Dual-lane architecture

Pipeline for products with a business case. Proving Ground for ideas that don't yet have one. Both run simultaneously. Neither contaminates the other.

People problem solved by structure

Named decision authority, time-boxed disagreement, three-level escalation. Culture doesn't scale. Mechanisms do.

Fail-fast economics are explicit

The cost of running an 8-week experiment is knowable. The cost of a product that should have died in month three but ran for eighteen months is also knowable. Name both numbers.

Configuration

Build the Path

Select your product type, org structure, risk tolerance, and timeline. The framework generates a custom phase sequence with deliverables, kill criteria, and governance mapped to your context. Start with a preset or configure from scratch.

Presets

Product Type

Org Structure

Risk Tolerance

Timeline

Parallel Hub

Blueprint

Parallel Track: Proving Ground

The Full Map

How It Actually Works

The configuration console above builds you a path. This section shows you the whole territory. Every phase, every gate, every handoff, every role. If you run products, this is the reference.

Lifecycle Flow

Signal

1-2 weeks

Detect the signal. Is this worth investigating?

Gate

Thesis

4-6 weeks

Build the structural case. Name the buyer, the price, the kill conditions.

Council Gate 1

Build

8-12 weeks

Build the minimum version that generates real market data.

Gate

Prove

8-12 weeks

Put it in front of buyers. Measure what happens.

Gate

Launch

4-6 weeks

Full operational readiness. The council's second and final look.

Council Gate 2

Sustain

Continuous

Earn your place every quarter. No product has tenure.

Crucible

8-12 weeks, fixed clock

Parallel lane for ideas without a business case. Validate or kill. No extensions.

graduates to THESIS ↑

Gate Decision Mechanics

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:

Advance

Deliverables meet the bar. Next phase activates. The clock starts.

Kill

Kill criterion was met, or deliverables don't hold up. Product stops. Team redeploys. Learnings documented.

Redirect to Crucible

The idea has merit but isn't ready for the pipeline. Move it to the Crucible for an 8-12 week exploration cycle.

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 is the product owner's problem.

Roles

Who Does What

Product Owner

Owns 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 Maker

The person who approves or kills at each non-council gate. Usually the Product Owner's direct leader. Named before the phase starts.
Council

The 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).
Crucible Owner (EIR)

The person running a Crucible 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 Group

2-3 senior leaders who set Crucible priorities and approve cycle plans. Not a committee. A mandate source.

Phase Handoff Logic

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.
Crucible → Thesis The exploration output substitutes for Signal and provides evidence for the Thesis gate.

The Two-Gate Philosophy

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

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.

People Mechanisms

Structure Over Culture

Culture doesn't survive a reorg. These six mechanisms do. They solve the people problem without pretending people aren't the problem.

Named decision authority with a 5-day clock

One person is named as the decision-maker. Not a title. A person. They have 5 business days. If the clock expires without a decision, the default answer is yes and the product advances.

Time-boxed disagreement

Anyone can object. They have 10 business days to formalize the objection with evidence. If the window closes without a formal objection, the decision stands. Silence is consent.

Three-level escalation

Decision-maker decides. Objector objects with evidence. Executive resolves in 5 days. That's it. No steering committees. No monthly governance reviews. Three levels, three people, hard deadlines at each.

Cross-functional visibility without consensus

Every function sees the decision. Nobody gets a veto. Notification is not the same as approval. The product owner notifies, documents the notification, and moves. If you were notified and said nothing, you agreed. For products that directly impact a BU's P&L or client relationships, notification upgrades to consultation. The BU leader has the same 10-day objection window, but their objection triggers a mandatory conversation between the product owner and the BU leader before the decision-maker rules. The BU leader still doesn't have veto power. But they have a guaranteed seat in the room before the decision is made. Consultation means "your perspective is heard and considered." Veto means "you can stop this." The first builds alignment. The second builds paralysis.

Proving Ground as the ultimate people solution

When the real problem is political (a VP who won't let a product die, a team that can't agree on direction), move the product to the Proving Ground. Structurally separate. 8-12 weeks. Let the evidence decide. The politics can't reach it there.

Resource contention protocol

When two pipeline products compete for the same resource, the product with the earlier gate deadline gets priority. If deadlines are equal, the product with stronger kill-criterion performance in its most recent phase gets priority. If neither rule resolves it, the CPO (or designated portfolio owner) decides within 48 hours. No standing resource allocation committees. The rule resolves 90% of contention automatically. The CPO resolves the rest.

Portfolio Governance

The Layer Above

This framework manages individual products. Portfolio prioritization is the layer above it.

No more than a configurable number of products in active Build or Prove phases at any time. When the pipeline is full, new products queue at Thesis until a slot opens. The queue is ordered by market urgency: external deadline beats competitive pressure, which beats internal demand. The CPO owns the queue. One person, one list, updated weekly. No portfolio review committee. No quarterly prioritization workshops. A list, owned by a name, updated on a cadence.