Discovery and Business Casing

Updated 14 May 2026

Definition

Discovery and Business Casing is the capability to analyze an initiative candidate deeply enough to make a sound Gate 2 investment decision — producing a Lean Business Case as the carrier of that analysis.

The capability operates in the discovery domain of the portfolio flow, between the relevance decision at Gate 1 and the investment decision at Gate 2. It does not own the stages of the flow — those are described in Portfolio Kanban Flow. It owns the analytical disciplines that run within them.

Purpose in the system

The discovery domain exists because committing delivery capacity is expensive. A delivery system that approves initiatives without sound analysis pays the cost twice: once when delivery struggles against poorly understood scope, and again when the resulting outcomes diverge from what was expected. Discovery and Business Casing is the capability that protects the system from those costs — by ensuring that what reaches Gate 2 has been understood well enough to be framed as an investment.

This is portfolio discovery, not product discovery. The product literature — Cagan, Torres, and others — describes discovery as a continuous user-research effort within a value stream: interviews, prototyping, behavioral observation, A/B testing of features. That work is legitimate and necessary, and a mature delivery system runs it continuously inside its DVS-level work. Portfolio discovery operates one level above. It does not ask what features should this product have; it asks is this initiative a sound investment, and what would it take to deliver it? The questions overlap and inform each other, but the analytical work, the artifacts produced, and the decisions made are not the same.

The capability rests on a discipline of just enough analysis. Discovery is itself an investment of analytical capacity, which the system has in finite supply. Time spent over-analyzing one initiative is time not spent on others. The Lean Business Case is deliberately lightweight — sufficient to support a decision, not to specify a project. Uncertainty is reduced enough to commit, not eliminated. A Gate 2 approval is not a permanent commitment; it is a hypothesis that delivery will continue to test.

This stance distinguishes the capability from traditional pre-decision business casing, where extended analysis is intended to remove risk before commitment. Extended analysis produces inflated business cases, slow decisions, and a tendency to defend the original analysis rather than respond to new evidence. Lean-agile portfolio governance takes the opposite stance: decide on a hypothesis with sufficient analysis, test it through delivery, and adapt as evidence accumulates.

What the capability consists of

Discovery and Business Casing operates across two distinct kinds of work — understanding the initiative, and framing it as an investment. The two run continuously rather than as discrete phases: framing begins as understanding develops, and understanding deepens as framing surfaces new questions. Stage boundaries are described in Portfolio Kanban Flow; what follows is the analytical substance.

Understanding what the initiative affects

Sound investment decisions require an accurate view of what the initiative will touch. Not just which user need it addresses, but which business capabilities it changes, which systems it depends on, and how the new arrangement coexists with what already runs. An initiative does not exist in a vacuum — it is a change to a delivery system that already operates. The analysis must produce a current view of:

• Which business capabilities are affected — directly or indirectly
• Which systems and components are involved
• Where the boundaries lie between the new and the existing
• What the order of change must be — what depends on what

Within that view, a second question shapes the investment fundamentally: what kind of change is this? Three intervention types must be distinguished, because they carry different risk profiles and different cost implications.

Many initiatives are not purely one type. A common pattern is to add a new capability that requires updates to existing systems, or to replace a core system while preserving peripheral functionality. Identifying the mix is part of the analysis, not assumed at intake.

A capability and system map is the carrier of this understanding — the working artifact through which the analysis is held and shared. Where one already exists for the affected area, the analysis updates it. Where one does not, the analysis produces it. The map is not the deliverable; the investment decision is. But a sound decision depends on the map being current and accurate. The map directly informs two parts of the Lean Business Case: the independent operability plan (how the new and existing coexist during rollout) and the cost estimate (which is grounded in the scope of systems and capabilities affected, not in feature counts).

How a capability and system map is structured, what dimensions it captures, and which methodologies support it is method-level guidance treated separately. The capability described here is the discipline of producing or maintaining the view, not the choice of specific method.

Surfacing dependencies and risk

Initiatives at portfolio scale almost always carry dependencies — on other initiatives, on shared platforms, on external vendors, on coordinated change across value streams. Dependencies that surface during delivery are far more expensive than dependencies surfaced during analysis. Discovery and Business Casing is the first systematic point at which portfolio-level dependencies are made visible.

The disciplined work is to identify what the initiative requires from the rest of the system to succeed: which other initiatives it sequences against, which value streams must coordinate to deliver it, and which external obligations constrain when and how it can move. These findings flow into the Lean Business Case as part of the independent operability plan and inform the dependency picture maintained by Portfolio Dependency Management.

Risk surfacing follows the same logic. A material risk that the analysis identifies and acknowledges is a risk the portfolio can plan around. A material risk that the analysis misses becomes a discovery during delivery — usually at higher cost.

The Lean Business Case as carrier of the analysis

The Lean Business Case is the artifact that carries the analysis forward to Gate 2. Its full structure is described in Initiative; the capability owns the discipline of producing it well rather than the schema itself. What matters from a capability perspective is that the LBC contains, in usable form, the elements the Gate 2 decision requires: the strategic alignment, the value hypothesis, the solution direction, the independent operability plan, the MVP definition, the cost estimate, the expected outcomes, and the go/no-go criteria.

The LBC is not produced and archived. It is the living hypothesis that Continuous Initiative Validation tests during delivery. Keeping it current as understanding develops — before and after Gate 2 — is part of the Initiative Owner’s ongoing responsibility. A stale LBC is a portfolio governance problem, not a documentation problem: it means the active investment is no longer being evaluated against current understanding.

The minimum viable analysis principle

The principle that governs how much analytical work is enough is straightforward: invest enough in analysis to make a sound investment decision — not more.

In practice this means three things. First, the LBC is deliberately lightweight; it exists to support a decision, not to specify a project. Second, uncertainty is acknowledged in the analysis rather than suppressed — the work reduces uncertainty to a level where a sound decision can be made, not to a level where the decision feels safe. Third, the decision is reversible by design: if delivery produces evidence that the hypothesis is not holding, Continuous Initiative Validation re-evaluates the investment.

The principle is grounded in queue economics. Analytical capacity at portfolio level is structurally constrained — the people who produce sound portfolio analysis are few and almost always context-switching between analysis and other responsibilities. Holding an initiative in extended analysis consumes capacity that other candidates also need. The cost of being slightly under-analyzed is usually lower than the cost of being over-analyzed, given that delivery and Continuous Initiative Validation are designed to surface what the analysis missed.

How the capability expresses itself

The capability is recognizable by the character of the analysis it produces. The contrast is between an analytical discipline that supports portfolio-level investment thinking and one that does not.

The Lean Business Case is treated as a hypothesis, not a plan. Where the capability is well-developed, the LBC reads as a structured argument: this is what we believe will happen, this is what we will spend to find out, this is what would make us stop or change direction. Where it is underdeveloped, the LBC reads as a project specification — feature lists, milestone tables, scope commitments that pre-empt the delivery work the DVS will do.

Uncertainty is named. A well-developed analysis identifies what is not known and what would shift the picture if learned. An underdeveloped analysis presents conclusions without their grounding — the value hypothesis appears as a confident statement rather than as a bet that can be falsified.

The cost estimate is grounded in scope, not in feature counts. A well-developed estimate is anchored in the systems and capabilities the initiative will touch — informed by the capability and system map, by the intervention type, and by the architectural assessment. An underdeveloped estimate is a number applied to a feature list, with no traceable connection to what the change actually requires.

The independent operability plan is concrete. A well-developed plan describes how the new arrangement coexists with existing systems during rollout — the order of change, the cutover approach, the fallback if something goes wrong. An underdeveloped plan asserts independence without describing how it is achieved.

The MVP can produce signal on the hypothesis. A well-defined MVP is the smallest version of the solution that begins testing what the LBC believes will happen. An underdeveloped MVP is a phase-one scope cut — a partial delivery that does not particularly test anything because the hypothesis it is supposed to validate was not stated.

Go/no-go criteria for stop and pivot are explicit. A well-developed analysis names the conditions under which the investment should be reconsidered. An underdeveloped analysis treats Gate 2 approval as the end of the decision rather than the beginning.

The analysis is sized to the initiative. A small initiative with low coupling and clear outcomes does not warrant extended discovery; a core-system replacement does. Where the capability is well-developed, the depth of analysis is calibrated to the risk and scope of the initiative. Where it is underdeveloped, every initiative receives the same template treatment regardless of what it actually requires.

Relationship to other capabilities

Discovery and Business Casing operates within the discovery domain of the portfolio flow, with explicit upstream and downstream relationships.

Discovery and Business Casing in the discovery domain. Solid arrows show upstream-to-downstream flow through the gates; dashed lines show peer capabilities active during the analysis.

Upstream: Strategic Relevance Assessment decides at Gate 1 whether an initiative candidate warrants analytical investment in the first place. Initiatives that do not pass Gate 1 do not enter Discovery and Business Casing. Needs Capture is the further-upstream intake function that registers the candidate before Triage.

Downstream: Initiative Prioritization consumes the Lean Business Case as the basis for ranking initiatives in the Discovery Queue (during analysis) and in the Delivery Queue (after Gate 2). Continuous Initiative Validation tests the LBC hypothesis during delivery and produces the continue, pivot, or stop decisions that follow.

Peer capabilities active during the analysis:

• Portfolio Dependency Management — surfaces and manages the dependencies the analysis identifies. Discovery work feeds the portfolio dependency picture; the dependency picture in turn shapes the independent operability plan.
• Capacity and Flow Management — owns the analytical capacity within which Discovery and Business Casing operates. The minimum viable analysis principle is grounded in capacity reasoning that the capacity capability articulates.
• Environmental Scanning — supplies external signals that inform the value hypothesis and the strategic context. Analyses that ignore environmental shifts produce LBCs grounded in stale assumptions.

The capability is led by the Initiative Owner, who is accountable for the analysis, the artifacts produced, and the recommendation that goes to Gate 2. The composition of the analytical team varies per initiative — domain experts, business analysts, the Enterprise Architect, value stream representatives — and is assembled to fit the specific initiative rather than as a standing function.

Supporting documents

• Portfolio Kanban Flow — the stages of Investigate and Investment Framing, and the Gate 2 decision; the mechanics within which the capability operates
• Initiative — the Lean Business Case structure, including its required elements and the distinction between Initiative and Strategic Initiative
• Portfolio Roles — Initiative Owner accountability and Enterprise Architect participation in discovery work

Sources

• Reinertsen, D. — Principles of Product Development Flow (2009). The economic case for analytical capacity as a constrained resource and for sufficient — not exhaustive — pre-decision analysis.
• Ries, E. — The Lean Startup (2011). Investment as testable hypothesis; the discipline of stopping and pivoting based on evidence rather than original conviction.
• Gothelf, J. & Seiden, J. — Lean UX (2013). Hypothesis-driven framing of investment decisions before commitment to delivery.
• Cagan, M. — Inspired (2017). Product discovery as a continuous user-research effort within a product team — referenced as boundary marker for the distinction between product and portfolio discovery.
• Torres, T. — Continuous Discovery Habits (2021). Continuous product discovery practices at the team level — same boundary distinction applies.