Establishing Gate Criteria and Evidence Standards

5.1 Translating Gate Decisions into Clear Approval Criteria

Approval criteria should be designed backward from the decision the gate exists to make. If a gate authorizes concept development, management needs enough evidence to determine whether the opportunity merits additional investigation. If a gate authorizes full-scale development, management needs stronger evidence that the concept is viable and sufficiently attractive to justify substantial resources. If the decision is launched, the criteria must address whether the product and organization are ready to accept the commercial, operational, regulatory, and reputational consequences of release.

The first discipline is therefore to write the gate decision as a precise management question. “Are we ready for Gate 3?” is circular. “Should we commit full development resources to this concept?” establishes the economic decision. Once that question is clear, practitioners can identify which propositions must be true for an affirmative answer to be rational.

Convert Decision Logic into Testable Criteria

For each gate, list the essential propositions supporting progression. A development-authorization gate might require management to believe that the customer problem is important, the proposed solution can meet critical requirements, the market opportunity is attractive, economics remain credible, major regulatory or operational barriers have been identified, and the project deserves the resources required for the next stage. Each proposition can then be translated into evidence expectations.

Criteria should describe outcomes or maturity rather than completed activities. “Customer interviews completed” does not establish whether customers value the concept. “Target customers demonstrate a sufficiently strong need and willingness to adopt the proposed solution” is closer to a useful criterion. Similarly, “prototype built” is an activity, whereas “prototype testing demonstrates that the critical technical assumptions are feasible within defined performance ranges” supports a decision.

Use three types of criteria where appropriate. Threshold criteria establish minimum acceptable performance, such as target margin, reliability, capital requirement, or regulatory status. Judgment criteria require informed evaluation of topics such as strategic fit, competitive differentiation, or quality of customer evidence. Must-pass criteria identify conditions whose failure should prevent progression regardless of strengths elsewhere, such as unresolved safety, regulatory, or fundamental technical feasibility issues.

Avoid creating weighted scorecards that allow strength in one category to compensate mechanically for a critical deficiency in another. An excellent commercial opportunity does not make an unsafe product acceptable. Strong technical performance does not compensate for economics that cannot support the business model. Scores may help compare projects, but gate approval should remain anchored in explicit decision logic.

Define the Required Degree of Certainty

Criteria should specify not only what needs to be known but how strong the evidence should be at that stage. Early gates often rely on directional evidence because demanding high certainty would require excessive investment before the organization has decided whether the opportunity deserves it. Later gates should expect progressively stronger validation.

For example, an early market criterion may require credible evidence that a material customer problem exists. A later gate may require quantified customer willingness to adopt, validated pricing assumptions, and a forecast supported by channel or account evidence. Technical feasibility may initially be demonstrated through simulation or laboratory testing, then through integrated prototypes, and ultimately through verification under production-representative conditions.

This progression should be designed explicitly. If standards remain vague, reviewers frequently demand late-stage certainty at early gates, slowing experimentation, or accept early-stage evidence at late gates, allowing risk to migrate toward launch. The evidence standard should increase roughly in proportion to the organization’s cumulative exposure and the difficulty of reversing the next commitment.

Clarify Exceptions and Conditions

Criteria cannot anticipate every project situation. Governance therefore needs a disciplined way to handle unmet requirements. A project should not automatically fail because a standard form of evidence is unavailable if equivalent evidence supports the same decision. Conversely, teams should not be allowed to reinterpret criteria immediately before the gate simply because results are unfavorable.

When a criterion is unmet, reviewers should determine whether the deficiency affects the fundamental decision or can reasonably be resolved during the next stage. If it affects the basis for continued investment, the appropriate outcome is generally hold, recycle, redirect, or stop. If progression remains rational, management may issue a conditional approval with a named owner, required action, due date, and explicit restriction on any commitment that depends on closure.

Approval criteria are effective when teams understand them before beginning the stage. They should guide project planning and learning priorities, not appear as a checklist during gate preparation. The team should know which questions must be answered, which evidence will be persuasive, and what management will refuse to compromise when the gate decision is made.

5.2 Technical and Product Maturity Evidence

Technical and product evidence establishes whether the proposed solution is becoming capable of doing what the business intends it to do. The required evidence varies widely across industries, but the underlying governance question is consistent: has uncertainty about feasibility, performance, integration, and product maturity been reduced enough to justify the next commitment?

Technical reviews often become difficult because teams report engineering activity rather than maturity. Completion of design work, prototype builds, test cycles, or development sprints may indicate effort, but they do not necessarily show that critical technical risks have been resolved. Gate evidence should connect work performed to the claims management needs to believe.

Start with Critical Requirements and Assumptions

Early in development, identify the technical assumptions whose failure would materially weaken or invalidate the project. These may concern achievable performance, architecture, materials, manufacturability, scalability, reliability, interoperability, algorithm performance, thermal limits, battery life, formulation stability, data availability, or another technology-specific constraint.

The evidence plan should prioritize these uncertainties. Teams can easily generate visible progress on lower-risk elements while postponing difficult experiments. Governance should instead encourage early tests of the assumptions with the highest consequence. A project that cannot demonstrate feasibility of its core technology should not receive substantial development funding because peripheral design work is progressing well.

Gate packs should distinguish requirements from targets. Requirements are conditions the solution must satisfy to succeed or comply. Targets represent desired performance that may involve trade-offs. If every aspiration is labeled mandatory, teams lose flexibility. If critical requirements are treated as negotiable targets, programs can progress without confronting fundamental deficiencies.

Use a Maturity Progression

Technical evidence should become progressively more representative of the final product and its expected operating environment. Early feasibility may rely on models, simulations, breadboards, laboratory tests, proof-of-concept software, benchtop experiments, or individual subsystem demonstrations. These forms of evidence can be entirely appropriate when the decision is whether to continue exploring.

As development proceeds, evidence should address integration. Components that work independently may fail when combined because of interfaces, tolerance interactions, software dependencies, thermal behavior, data integration, manufacturing variation, or operating conditions. Later gates should therefore require evidence from integrated systems rather than simply aggregating successful subsystem results.

Before final release, tests should increasingly represent actual use and production conditions. The precise sequence varies by industry, but management should understand whether evidence came from a controlled laboratory prototype, an engineering build, a pilot process, production-intent hardware, released software, validated manufacturing equipment, or another maturity level. Reviewers should not treat these forms of evidence as equivalent.

Make Residual Technical Risk Visible

A gate review should not present technical readiness as a binary statement unless it genuinely is one. Teams should identify unresolved technical risks, their probability and consequence where estimable, mitigation plans, and the stage at which they must be resolved. High-quality evidence packs distinguish a requirement that has been demonstrated from one believed achievable based on analysis.

When testing produces mixed results, show the distribution rather than only the favorable outcome. Reliability, performance, yield, response time, stability, or defect results often contain variation that matters more than an average. Management needs to know whether demonstrated performance has adequate margin against requirements and whether the results are repeatable.

Technical waivers and deviations should also be visible. A program can appear mature while relying on temporary workarounds, manually adjusted prototypes, nonproduction components, or unresolved software defects. Some are acceptable at intermediate stages, but reviewers must understand what remains before the product can operate at scale.

Assess Product Maturity Beyond Core Technology

A technically feasible invention is not necessarily a mature product. Product evidence should address whether the complete offering can meet its intended use, user requirements, interface needs, service expectations, and lifecycle obligations. Depending on the product, this may include usability, installation, maintainability, cybersecurity, documentation, packaging, compatibility, field support, data management, or end-of-life requirements.

Evidence should also reflect configuration control. Gate reviewers need confidence that the design being evaluated is the design the organization intends to build or release. When requirements, drawings, code, bills of material, specifications, or configurations remain unstable, a nominally successful test may not provide evidence about the final product.

The purpose of technical and product evidence is not to demonstrate perfection. It is to establish what has been proven, what remains uncertain, and whether the residual uncertainty is appropriate for the commitment being requested. That distinction allows development to proceed under uncertainty without allowing optimism to substitute for demonstrated maturity.

5.3 Commercial, Financial, and Strategic Evidence

Development governance should test not only whether the organization can build the product but whether it should. Commercial, financial, and strategic evidence provides the business rationale for continued investment. Weak governance often gives technical evidence substantial scrutiny while allowing demand forecasts, pricing assumptions, or strategic claims to remain largely unchallenged.

The objective is not to produce a highly precise business case at the earliest stages. It is to improve the quality of commercial and economic evidence as the project approaches commitments that depend on that evidence. Early assumptions should become tested hypotheses, and tested hypotheses should become progressively more reliable forecasts.

Validate the Customer and Market Case

Commercial evidence should begin with the customer problem. Who experiences the need, how important is it, what alternatives exist today, and why would the proposed solution create materially greater value? Early evidence may come from interviews, observations, concept tests, existing customer requests, analogue products, or market research. Management should assess the quality of the evidence rather than simply the number of customer interactions.

Later stages should test adoption assumptions more directly. Depending on the business, this may include pricing research, willingness-to-pay evidence, pilots, beta programs, letters of intent, channel feedback, customer commitments, retailer interest, usage behavior, or sales-pipeline validation. Forecasts should distinguish evidence-based demand from management aspiration.

Market size estimates require particular care. A large addressable market does not demonstrate that the project can capture an economically attractive share. Gate evidence should progress from total market opportunity toward the segments the product can realistically serve, the customers accessible through the intended route to market, and the expected adoption profile. Competitive response and substitution should be incorporated rather than treated as footnotes.

Build the Financial Case Around Decision-Relevant Economics

The financial case should show the economic consequences of continued investment. Relevant measures may include revenue, gross margin, contribution margin, development cost, capital expenditure, working capital, cash flow, net present value, internal rate of return, payback, or expected value. The appropriate measures depend on the business and project type.

Gate reviewers should focus particularly on assumptions that drive the result. A sophisticated valuation model adds little if most of the value depends on an untested adoption rate or unrealistic manufacturing yield. Sensitivity analysis should identify which variables materially affect the investment case and whether management has sufficient evidence on them.

Sunk cost should be excluded from the logic of continued investment. At every gate, management should compare the expected benefits of proceeding with the remaining costs, risks, and alternative uses of resources. Prior expenditure may explain why stopping is organizationally difficult, but it should not provide an economic justification for continuing.

Financial evidence should also reflect downside exposure. Rather than presenting only a base case, teams should show credible ranges or scenarios for uncertain variables. Major investments may warrant explicit downside cases covering schedule delay, lower demand, higher capital, reduced price, lower yield, regulatory delay, or another project-specific risk. The question is not whether the downside can be forecast perfectly, but whether management understands the exposure it is authorizing.

Demonstrate Strategic Fit

Strategic rationale should be more specific than stating that a project supports growth, innovation, customer focus, or another broad objective. The team should identify which strategic priority the initiative advances and how. A project might strengthen a priority platform, deepen an important customer relationship, create access to a new market, defend a strategic position, develop a differentiating capability, or provide an option on an emerging technology.

Strategic importance can justify accepting economics or uncertainty that would be inappropriate for a routine project, but the trade-off should be explicit. Management should know what strategic value it believes compensates for a lower financial return or higher risk. Otherwise, the phrase “strategic project” can become a mechanism for avoiding economic discipline.

The gate should also consider whether the strategic rationale remains current. Development cycles can span years, during which market conditions, corporate priorities, competitive positions, regulations, technologies, or partner relationships change. A project should not continue receiving privileged status simply because it was strategically important when approved initially.

Commercial, financial, and strategic evidence should ultimately form one coherent investment case. Customer demand drives revenue assumptions; product differentiation influences price and adoption; technical choices affect cost and timing; capital requirements affect returns; and strategic importance affects the organization’s willingness to accept uncertainty. Gate reviewers should challenge inconsistencies among these elements rather than evaluating each evidence package independently.

5.4 Operational, Quality, Regulatory, and Supply Readiness Evidence

Many development programs encounter their most damaging surprises after the core product appears nearly complete. Manufacturing proves more difficult than expected, suppliers cannot meet specifications at scale, quality systems are not ready, regulatory evidence is incomplete, service processes lag the launch, or production economics differ materially from prototype assumptions. Gate criteria should force these issues into view before the organization commits to launch.

The key design principle is progressive readiness. Operations, quality, regulatory, and supply evidence should begin well before the final gate, but the expected level of maturity should rise as launch approaches. Waiting until development is effectively finished turns these functions into late-stage inspectors rather than contributors to successful product design.

Operational Readiness

Operational evidence should demonstrate that the organization can produce, deploy, deliver, install, or support the offering at the required scale, cost, quality, and timing. For physical products, evidence may cover manufacturing process design, tooling, equipment, capacity, labor, process capability, pilot builds, production documentation, maintenance, packaging, logistics, and ramp plans. For software or service products, the analogous issues may include hosting capacity, deployment processes, customer support, monitoring, incident management, data operations, and service staffing.

Early gates should identify fundamental operating constraints. Can the proposed design be manufactured using available processes? Does it require equipment with unusually long lead times? Is the required service model economically viable? Are specialized skills available? Later gates should require progressively stronger demonstration through pilot production, scale testing, operational simulations, deployment rehearsals, or other representative evidence.

Capacity assumptions should include both normal demand and ramp uncertainty. A process capable of producing the expected steady-state volume may still fail if yield is initially low or demand ramps faster than expected. Conversely, excessive capacity built around an optimistic forecast can destroy project economics. Gate evidence should connect operational capacity with the commercial scenarios used in the business case.

Quality Readiness

Quality evidence should show that critical requirements have been defined, verified, controlled, and translated into repeatable processes. Relevant evidence may include design verification, validation, risk analyses, control plans, process capability, inspection methods, defect performance, reliability results, traceability, corrective-action status, documentation, and readiness of the quality management system.

Quality criteria should distinguish between open items that can reasonably be closed after a gate and deficiencies that undermine the requested decision. A small documentation issue may not prevent progression. An unresolved failure affecting safety, regulatory compliance, or a critical performance requirement may. The gate standard should define this distinction in advance where possible.

Gate reviewers should also examine whether quality evidence reflects representative production conditions. A product assembled by expert engineers under controlled prototype conditions may perform differently when produced at normal line speed, by standard operators, with normal supplier variation. Later-stage evidence should increasingly incorporate those realities.

Regulatory and Compliance Readiness

For regulated products, the regulatory pathway can determine development architecture, evidence requirements, timing, cost, and commercial feasibility. Governance should therefore establish the pathway early enough to influence the development plan. Required evidence may include classification, regulator interactions, submission strategy, clinical or performance data, labeling, cybersecurity documentation, environmental requirements, certifications, and jurisdiction-specific approvals.

Regulatory status should be described precisely. “Regulatory on track” is not sufficient. Gate reviewers should know which approvals are required, which evidence has been generated, what has been submitted, what feedback has been received, which assumptions remain, and what activities depend on a favorable regulatory outcome.

Where different markets have different requirements, the launch decision may need to be segmented by geography. A project should not be represented as globally ready when approvals or compliance evidence exist only for selected jurisdictions.

Supply and Supplier Readiness

Supply evidence should cover availability, qualification, capacity, cost, lead times, quality, resilience, and contractual status for critical materials, components, external services, or manufacturing partners. Early development may rely on prototype suppliers or nonproduction components, but later gates should demonstrate that the intended supply chain can support commercial requirements.

Identify single-source items, long-lead components, immature suppliers, constrained commodities, geographic concentrations, and dependencies on unproven processes. Each should have a clear mitigation or acceptance decision. Supplier nomination alone is not evidence of readiness if capacity, quality, tooling, or commercial terms remain unresolved.

Operational, quality, regulatory, and supply evidence should be integrated. A supplier problem may alter manufacturing yield, which affects unit economics, which changes the business case. A regulatory requirement may force a product change that invalidates previously completed verification. Gate reviews should therefore examine cross-functional dependencies rather than treating readiness as a collection of independent green status indicators.

5.5 Gate Review Checklist, Evidence Pack, and Readiness Templates

Templates should make gate decisions easier, not make gate preparation larger. The objective of a standardized evidence pack is to present the information decision makers need in a consistent structure, highlight material changes and unresolved uncertainties, and create an auditable record of why the project was authorized to proceed. It should not become a repository for every analysis the project team has completed.

Gate Review Checklist

A practical pre-review checklist should confirm that the meeting is ready to make a decision:

• Decision: Is the specific decision being requested stated clearly?
• Criteria: Has the project addressed every applicable approval criterion?
• Evidence: Is supporting evidence appropriate to the maturity and commitment of the gate?
• Exceptions: Are unmet criteria, waivers, and proposed conditions explicitly identified?
• Risks: Are major unresolved technical, commercial, operational, regulatory, supply, and financial risks visible?
• Business case: Have major economic assumptions and changes since the prior gate been highlighted?
• Resources: Is the funding and constrained capacity required for the next stage clear?
• Authority: Will the required decision makers and functional approvers participate?
• Recommendation: Has the project team made an explicit go, hold, recycle, redirect, or stop recommendation?

Structure the Evidence Pack Around the Decision

The core gate pack should generally begin with a concise executive summary showing the requested decision, project status, changes since the prior gate, major evidence, unresolved issues, required resources, and recommendation. Subsequent sections should provide the technical, commercial, financial, strategic, operational, quality, regulatory, and supply evidence applicable to that gate.

Use appendices for detailed analyses rather than forcing every reviewer through them. Gate members should be able to understand the decision case from the core material while having access to deeper evidence when necessary. This approach also reduces the incentive to measure gate quality by presentation length.

Templates should visibly distinguish completed evidence from projections and open items. A readiness table can use fields such as criterion, required standard, evidence available, status, residual risk, accountable owner, and decision implication. Avoid relying solely on red-yellow-green status because colors often conceal the reason an item is considered acceptable.

Document the Decision and Conditions

The gate record should capture the decision, authorized scope, funding or resources released, conditions, unresolved exceptions, named owners, deadlines, and any restrictions on commitments before conditions are closed. It should also record significant changes to the business case or project scope accepted by the decision makers.

Templates should remain proportionate to project type. Streamlined projects can use shorter evidence packs and combined readiness checklists, while major or high-risk programs may require deeper functional evidence. What should remain common is the decision logic: the project states what authorization it seeks, demonstrates why the criteria are satisfied, identifies what remains uncertain, and receives an explicit decision with operational consequences.

Used well, checklists and templates create consistency without substituting documentation for judgment. Teams know what evidence they must develop, reviewers can focus on material uncertainties rather than searching for information, and gate outcomes become easier to compare across the portfolio. The standard is not whether the paperwork is complete; it is whether management has sufficient, credible evidence to make the next commitment deliberately.