Skip to content

Intake and Stage Gates

Purpose

This document describes how a new venture idea, or a new product idea within an existing venture, enters the company's pipeline, and the stage gates it must pass through as it advances. It aligns with the company product/artifact lifecycle described in ../docs/architecture/artifact-lifecycle.md — this document is the portfolio-level entry point into that lifecycle, not a replacement for it.

Intake: new venture idea

  1. Capture. Record the idea in portfolio/opportunity-backlog.md with enough detail to evaluate later — problem, rough evidence, why it might fit Devonshire Digital.
  2. Initial evaluation. Assess against portfolio/prioritization-framework.md. This does not need to be formal for an early idea, but should be explicit rather than assumed.
  3. Scaffold, don't commit. If worth exploring, a venture directory may be created from ventures/_template/ to begin strategy work. Creating the directory is not a commitment — see ventures/_template/README.md for the explicit rule that a venture is not registered in portfolio/venture-registry.json until it is ready.
  4. Registration. Once strategy work (at minimum, a completed docs/strategy/venture-brief.md) supports treating this as a real venture, register it in portfolio/venture-registry.json and reflect the venture's own venture.json accordingly.

Intake: new product idea within a venture

Per ADR-0017, this repository does not hold per-product specification scaffolding or a per-product registry — only the venture's implementation repository does.

  1. Capture. Record the idea in the relevant venture's own backlog — for a venture with an implementation repository, that backlog lives there (e.g. devonside-labs' docs/ai/product-backlog.md), not here (or in portfolio/opportunity-backlog.md if it is genuinely cross-venture in nature).
  2. Evaluation. Assess against portfolio/prioritization-framework.md (or the venture's own prioritization model, e.g. ventures/digital-products/portfolio/prioritization-model.md), informed by the venture's own strategy documents (product principles, target users).
  3. Approval for specification work. A product idea should not get active specification work in the venture's implementation repository until it has been explicitly approved to proceed — this is the company/venture-level judgment call, not an automatic outcome of having an idea. If the venture has no implementation repository yet, approval for specification work and approval to create that repository (per ADR-0014) happen together.
  4. Registration. Once approved for specification work, the product gets a product.json in the venture's implementation repository (the authoritative registry record), and that record is mirrored into this repository's portfolio/product-registry.json — a combined table of contents across ventures, not itself the source of truth.

Stage gates (aligned to the company artifact lifecycle)

See ../docs/architecture/artifact-lifecycle.md for the authoritative description of lifecycle stages and their entry/exit criteria. At a portfolio level, the gates that matter most are:

  • Idea → Approved for specification: passes intake above.
  • Specification → Build-ready: specification review passed (see ../prompts/specification-review.md for the checklist used).
  • Build-ready → Released: release readiness review passed (see ../prompts/release-readiness-review.md).

What this document does not do

It does not itself decide any specific venture's or product's fate — it describes the process by which those decisions get made and recorded.

Report an issue about this page