Selected system · 03

Eight stages from demand to decision and back.

This system was designed for a familiar situation: a scaled product-engineering organization with too many competing initiatives, inconsistent intake, unclear capacity, executive pressure to show progress, and rising AI and tool adoption without clear ROI measurement. It redesigns the path from raw demand to a funded, accountable decision, and back.

Type: Sanitized application
What this is: Operating-system design, documented end to end. Not a deployed software product.
Scenario: A scaled, multi-team product-engineering organization under portfolio pressure.
Design rule: Every AI placement must be bounded, observable, and reversible. Executive decision rights stay human.
Derived instrument: The readiness diagnostic maps the current responses against these eight stages and identifies the most exposed dimension.

01The system at a glance

Checkpoints sized to consequence

Heavier at data boundaries and irreversible commitments. Lighter where the work is reversible.

AI assists preparation
Human checkpoint, sized to consequence
Executive decision, no AI in the loop
Failure cascades downstream
Execution data returns to intake

Work flows left to right through eight stages. AI assists preparation at every stage except one: stage 7, the executive decision moment, is deliberately human-only. Stage 8 closes the loop, returning execution data to intake so the system learns.

02The eight stagesWhat happens · where AI helps · where judgment holds

Each stage below carries a worked thread from one illustrative application: the consolidation of three overlapping customer-onboarding workflows across Product, Engineering, Customer Success, Legal, Security, and Analytics. The full case is documented separately.

Intake

Every request for product, engineering, data, or platform work enters through one format that captures the problem, the sponsor, and the decision being asked for. Requests that arrive as solutions, escalations, or hallway asks are routed into the same shape before anything is scoped.

Where AI helps

Summarizes messy inputs into the standard shape, detects missing fields, and clusters duplicate or overlapping requests before they reach planning.

Human checkpoint

A portfolio or product-operations owner confirms the request is legitimate and names the accountable owner before it enters the queue.

Design rationale, failure mode, feedback, and worked example

Why the design choice matters

Comparable inputs are the precondition for every downstream judgment. Prioritization can only be honest when value, risk, effort, and urgency are stated the same way for every request.

What fails if designed poorly

Leaders see volume without comparability, prioritization runs on gut feel, and the loudest sponsor wins. AI applied here simply accelerates inconsistent demand.

Feedback captured

Which intake fields were missing or wrong at submission, which requests turned out to be duplicates, and how long requests sat unowned.

Worked thread · onboarding consolidation

Three separate requests to "fix onboarding" arrive from Product, Customer Success, and Engineering in three different shapes. The shared intake format exposes that they describe the same customer problem from three vantage points.

Triage

Each request is converted from a proposed solution into a stated problem, and a gate decides what proceeds, what is deferred, and what is declined. Vague or unowned outcomes are returned to the sponsor for reframing before anything enters the plan.

Where AI helps

Drafts the problem statement from the intake record and flags vague outcomes, hidden assumptions, and unstated constraints for the sponsor to resolve.

Human checkpoint

The sponsor approves the problem framing, and the triage gate is decided by a person: proceed, defer, or decline.

Design rationale, failure mode, feedback, and worked example

Why the design choice matters

Declining and deferring are decisions, not failures. A gate that can say no is what keeps the portfolio from becoming an unpriced backlog of accepted promises.

What fails if designed poorly

Solution-asks pass through unchallenged, teams optimize locally, and the organization discovers late that it solved the wrong thing well.

Feedback captured

The proceed / defer / decline ratio over time, and how often problem statements were returned for reframing, a read on demand quality at the source.

Worked thread · onboarding consolidation

The three onboarding asks are reframed into one problem statement: onboarding is fragmented across handoffs between six functions. One sponsor is named, and the other two requests are closed as duplicates in the open.

Capacity and estimation

Work that passes triage is estimated as a range with a stated confidence (best case, most likely, worst case) and checked against realistic delivery history before any commitment is made. When estimate and capacity conflict, the plan changes before the commitment is accepted.

Where AI helps

Checks estimate consistency across similar work, compares new estimates against historical delivery patterns, and highlights the drivers of variance.

Human checkpoint

Delivery and product leads validate the assumptions behind the estimate and own the stated confidence.

Design rationale, failure mode, feedback, and worked example

Why the design choice matters

Single-point estimates create false precision that can distort portfolio commitments. Ranges keep uncertainty visible where executives can account for it.

What fails if designed poorly

Overcommitment becomes the default, buffers vanish, and delivery teams absorb the gap until quality, delivery reliability, or team sustainability deteriorates.

Feedback captured

Actual effort against the original range, which assumptions failed, and where confidence was systematically over- or under-stated.

Worked thread · onboarding consolidation

Consolidation is estimated as a range with stated confidence. Delivery history for integration-heavy work argues for the wide end of the range, and the commitment is sized to that evidence.

Cross-functional risk and dependency assessment

Before work is committed, dependencies and material risks across engineering, security, legal, data, and operations are mapped and validated directly by the functions that carry them.

Where AI helps

Generates a first-pass dependency map from artifacts, prior decisions, and known patterns, so human review starts from a draft.

Human checkpoint

Engineering, security, legal, data, and operations leads validate the material risks directly and sign their names to them.

Design rationale, failure mode, feedback, and worked example

Why the design choice matters

Risks surfaced before commitment can change the decision. Risks surfaced afterward narrow the available options and often force changes to scope, sequence, or schedule.

What fails if designed poorly

Late escalations, surprise compliance and security reviews, and duplicated engineering work push delivery past its window and burn credibility with partner functions.

Feedback captured

Which risks materialized that the scan missed, and which flagged risks never materialized; both directions tune the next map.

Worked thread · onboarding consolidation

Legal and Security surface data-handling and access-review dependencies before design starts; Analytics flags that the three existing workflows measure onboarding differently, which would have corrupted any consolidated metric.

Option formulation

The work is shaped into more than one real option, each carrying its tradeoffs, its capacity impact, and the cost of deferring or doing nothing. A single option with a rubber stamp is not a decision.

Where AI helps

Drafts the option set from the framing and risk record, and surfaces contradictions between options that humans tend to smooth over.

Human checkpoint

The decision owner narrows the set and owns the tradeoffs presented.

Design rationale, failure mode, feedback, and worked example

Why the design choice matters

Executives can only exercise judgment when there is a genuine choice. Options that include "do nothing, priced" force the value case to be explicit.

What fails if designed poorly

Decision forums drift into formal confirmation, tradeoffs stay implicit, and the cost of inaction is never priced, so work proceeds by default.

Feedback captured

Which option classes get chosen over time, and whether deferred options were later reopened, a read on whether the option sets were real.

Worked thread · onboarding consolidation

Three options are priced: consolidate the three workflows fully, standardize the interfaces between them first, or defer with the cost of continued fragmentation stated. Each shows its capacity impact across the six functions.

Decision packet assembly

Everything the decision needs (recommendation, options, risks, capacity impact, and open questions) is assembled into one decision-quality packet before the forum, so the meeting can decide on arrival.

Where AI helps

Drafts the packet from the upstream record, compares options for consistency, and highlights contradictions and unresolved questions.

Human checkpoint

The decision owner approves the packet before it reaches executive review; unresolved questions are named, not papered over.

Design rationale, failure mode, feedback, and worked example

Why the design choice matters

Decision quality is set before the meeting starts. A packet that names its open questions is more trustworthy than one that performs completeness.

What fails if designed poorly

Executive forums drift into status updates, decisions shift outside the named forum, and accountability becomes unclear.

Feedback captured

Which packets were sent back for missing information, and which open questions recurred across decisions; both feed template updates.

Worked thread · onboarding consolidation

One decision packet replaces the three competing slide decks the functions had been maintaining. It recommends standardizing interfaces first, with the full-consolidation option preserved and priced.

Executive decision moment

No AI in the loop

A named forum with clear decision rights makes the call: approve, fund, defer, or decline. The rationale, including tradeoffs accepted and recommendations overridden, is recorded where the next decision can find it.

AI role at this stage

Nothing, by design. AI prepares everything upstream and touches nothing here. The decision moment has no AI in the loop.

Human checkpoint

The entire stage is the checkpoint: an accountable person decides, and the rationale is written down.

Design rationale, failure mode, feedback, and worked example

Why the design choice matters

Accountability cannot be delegated to a score. Keeping this moment fully human preserves clear responsibility for every AI-assisted input upstream: preparation is automated, and judgment stays human.

What fails if designed poorly

Decision rights blur, everything becomes a priority, and teams absorb hidden overload until delivery slips or people leave. Automated recommendations begin to substitute for accountable judgment.

Feedback captured

The decision record itself: who decided, what was accepted, what was overridden and why. This is the raw material for auditing judgment later.

Worked thread · onboarding consolidation

An accountable executive chooses the interface-standardization path first, records why full consolidation was deferred, and names the conditions under which it would be revisited.

Execution handoff and feedback loop

Committed work is handed to delivery with its assumptions attached. After delivery, actual effort, cycle time, and handoff quality are compared against the original estimate, someone owns the decision to sunset work that is no longer worth continuing, and lessons change the intake system itself.

Where AI helps

Summarizes lessons across deliveries, detects recurring patterns, and recommends template and routing updates for humans to accept or reject.

Human checkpoint

Portfolio or product operations reviews the learning and decides what changes in the intake and planning system.

Design rationale, failure mode, feedback, and worked example

Why the design choice matters

This loop is what makes the system compound. Without it, the organization repeats the same planning errors every quarter with progressively better tooling.

What fails if designed poorly

Execution data never returns to planning, nobody owns sunsetting, and the portfolio grows without pruning until capacity plans lose credibility.

Feedback captured

Estimate-versus-actual variance, handoff defects, sunset decisions taken or dodged, routed back to stage 1 as changes to the intake format and gates.

Worked thread · onboarding consolidation

After the first delivery increment, actuals are compared to the committed range and the intake template gains a field the three original requests all lacked: which existing workflow a new request overlaps.

03Dual-horizon planning in delivered practiceLong-range priorities, near-term capacity

Delivered work, sanitized

The intake and capacity mechanics above ran at portfolio scale in delivered work. Shreyas defined a dual-horizon planning process where none existed, owned the strategy and the first delivery cycle, and transferred ownership once the operating cadence was established.

Delivered work, shown in sanitized form. Names and proprietary implementation details are omitted; figures marked illustrative use synthetic values.

Human decision and goal cascade
Forecast and review feedback
Intake scoring

Two planning horizons, connected by scoring, decision forums, and forecast feedback

What the system connected

Multi-year strategic priorities and financial guardrails.
Intake scoring for strategic fit and value.
Annual and near-term funding, workforce, external-spend, and capacity plans.
Executive decision forums and a structured goal cascade, described here by function only.
Periodic forecasting and business-review feedback that refreshed priorities and allocations.
Decisions about what moved forward, what was delayed, and where capacity was redirected.

The consequential tradeoff

Each cycle forced the same decision the eight stages above are built for: which initiatives were funded now, which waited, and where existing capacity was redirected when forecasts moved.

What remains private

Internal forum names, calendar mechanics, financial targets, regional detail, and the organization’s planning terminology stay private. Forums and cadences are described by function only.

The full worked case

The onboarding consolidation is documented as a standalone case: the situation, the six functions involved, and how each stage of this system shaped the outcome path.

Read the case

Score your own model

The readiness diagnostic maps the current responses against these eight stages and identifies the most exposed dimension.

Run the diagnostic

About Shreyas Rajeev All selected systems