Where Engineering Fits in Launchpad Stages 1 and 2

Stage 1 is where Launchpad learns what problem is worth solving. Stage 2 is where that discovery becomes a credible path to funding, staffing, and delivery.

Engineering belongs in both stages when technical judgment changes feasibility, readiness, risk, or the delivery path. The default model is targeted participation: short reviews, clear questions, and lightweight technical artifacts before the team treats a solution as committed.

Operating Rule

Bring engineering into Launchpad when the work depends on systems, data, integrations, identity, security, hosting, vendors, procurement assumptions, delivery staffing, or long-term operations.

Do not bring engineering in just because the project feels uncertain. Uncertainty needs discovery first; technical risk needs engineering judgment.

Launchpad Stages 1 and 2

flowchart TD
    subgraph Launchpad["Launchpad work"]
        Stage1["Stage 1 baseline: user needs, core problems, success metrics, product strategy"]
        Stage2{"Stage 2 path: Alpha or implementation strategy?"}
        Ready["Launchpad approval: ready for Alpha, Prep, or 90-Day Build"]
        Stage1 -->|after oversight review| Stage2
        Stage2 -->|when complete| Ready
    end
    subgraph Engineering["Engineering needs"]
        Need1["Stage 1 need: feasibility screen and systems map"]
        Need2["Stage 2 need: architecture, integrations, staffing, reliability, and 90-day readiness"]
    end
    Stage1 -->|before product strategy hardens| Need1
    Need1 --> Stage2
    Stage2 -->|before funding baseline| Need2
    Need2 --> Ready
    style Need1 fill:#dbeafe,stroke:#2563eb,color:#172554
    style Need2 fill:#dbeafe,stroke:#2563eb,color:#172554
    style Ready fill:#dcfce7,stroke:#16a34a,color:#14532d

What to notice: Stage 1 needs engineering to test whether the product strategy is technically plausible; Stage 2 needs engineering to test whether the delivery strategy is ready to fund and start.

Checkpoints

Launchpad moment	Bring engineering in when	Output	Typical effort
Stage 1: user needs and core problems	The current service depends on applications, data, access, reporting, or manual system workarounds.	Systems map and dependency list	1-2 sessions
Stage 1: product strategy	The team is naming a platform, vendor, system, or delivery path before feasibility is clear.	Feasibility screen and open technical questions	60-90 minutes
Stage 2: technology options	The team needs to choose Alpha, build, buy, configure, reuse, or integrate.	Option tradeoffs and proof needed	1 review
Stage 2: implementation strategy	Architecture, integrations, identity, data portability, reliability, measurement, or hosting shape the plan.	Technical approach review and risk notes	1-2 reviews
Stage 2: staffing, risks, cost, vitals	The delivery plan depends on technical roles, support ownership, contractor claims, or 90-day build readiness.	Readiness caveats and next technical step	30-60 minutes

What to notice: each checkpoint has a decision or artifact. Engineering time should attach to that, not to ambient uncertainty.

Why Checkpoints Are Better Than Standing Attendance

Structured engineering checkpoints create clearer decisions than continuous engineering attendance.

When engineering is embedded in every Stage 1 conversation, the team can keep reopening the same technical questions without making a product, procurement, or governance decision. Engineering presence can become a way to defer accountability.

A checkpoint model makes engineering input explicit and time-bound:

What question did engineering review?
What assumptions are valid?
What risks remain?
What options exist?
What decision is needed next?
Who owns that decision?

After engineering provides the review, the project should either:

make a decision with the known risks;
collect the missing evidence;
escalate the decision to the right owner; or
move the issue into Stage 2, Alpha, or Prep for deeper technical work.

Engineering should not be used to keep unresolved product or governance questions open indefinitely.

Engineering checkpoints should create decision pressure. Standing engineering attendance can create decision drift.

Involvement Model

Use the lightest level that can reduce the risk.

Level	Use when	Engineering role	Output
Level 0: No engineering yet	The problem, users, current process, or decision are still vague.	Wait for better discovery signal.	No engineering assignment
Level 1: Lightweight review	Most Launchpad efforts need a quick technical read.	Review kickoff, feasibility, and readout.	2-4 hours total
Level 2: Targeted discovery	Legacy systems, data, security, IAM, integrations, or vendors are central.	Map constraints and test assumptions.	4-12 hours total
Level 3: Embedded support	MDDS is directly accountable for high-risk delivery.	Join the team intentionally.	Assigned by decision, not default

What Engineering Should Not Own

The model is lightweight by default, deeper when risk requires it, and embedded only when complexity justifies it.

Engineering should not define the user problem, run every discovery meeting, replace product or service design, validate stakeholder preferences as requirements, or turn unclear ideas into delivery commitments.

Engineering participates in Launchpad at key decision points to identify constraints, validate feasibility, surface system risks, and recommend the right level of technical support for the next phase.

Launchpad Stage 1

Appendix reference: Stage 1 is the discovery baseline. It proves the project is solving the right problem before the team asks for full MITDP designation.

Stage 1 section	What it proves	Roadmap / gate role	Engineering need
Understanding of User Needs	The team has talked directly to representative users and identified primary user groups.	Feeds Discovery and shapes the baseline Launchpad.	Notice technology needs, access barriers, system touchpoints, and data dependencies that appear in user journeys.
Core Problems & Definition of Success	The project has up to three measurable problems, success metrics, current values, targets, and stakeholder agreement.	Defines the scope MITDP funding can be spent on after approval.	Check whether metrics can actually be measured from available systems, reports, or data sources.
Product Strategy	The team has chosen a product direction based on user needs, core problems, and success measures.	Gives design and technical teams a direction to evaluate before Stage 2.	Test whether the strategy is technically plausible before it hardens into an implementation assumption.
Stage 1 review	MITDP Oversight can review, iterate, and decide whether Stage 1 is ready to move into Stage 2.	Gate before deeper Stage 2 review.	Provide caveats, technical unknowns, and the level of engineering support needed for Stage 2.

What to notice: Stage 1 does not need a full architecture plan. It needs enough technical signal to avoid choosing a product strategy that cannot be delivered.

Launchpad Stage 2

Appendix reference: Stage 2 turns the discovery baseline into a fundable delivery strategy. It proves the project can move toward Alpha, Prep, or a 90-Day Build with eyes open.

Stage 2 section	What it proves	Roadmap / gate role	Engineering need
Implementation Strategy	The team has considered technology options, architecture, data, delivery sequencing, unknowns, decision points, and the 90-Day Build.	Determines whether the project goes to optional Alpha or directly toward Prep and 90-Day Build.	Review options, integrations, identity, data portability, hosting, reliability, measurement, and the proposed 90-Day Build scope.
Stakeholder Engagement Strategy	The right people know the project, know their role, and agree to the expected engagement level.	Confirms support paths across awareness, advisory, support, and core team groups.	Ensure system owners, data owners, security, privacy, infrastructure, and technical specialists are represented.
Staffing and Leadership Strategy	The project has required leadership and core roles, including UX Lead, Technical Product Manager, and Technical Lead / Architect.	Proves the team can staff the work through Prep and the 90-Day Build.	Check whether technical leadership, engineering, QA, security, data, and support capacity match the delivery risk.
Assessment of Key Risks	The team has named major risks and how it will manage them.	Gives the approval gate a way to distinguish known risk from unmanaged risk.	Surface technical, vendor, integration, reliability, security, privacy, data, and operational risks.
Cost Estimate	The team has an initial estimate for the work, staffing, contracts, and likely delivery needs.	Establishes the first funding baseline once approved.	Validate technical assumptions that could change cost, including integrations, environments, licensing, hosting, migration, and support.
Project Vitals	The project has the basic facts needed for governance, reporting, and oversight.	Supports MITDP designation and ongoing oversight.	Confirm technical ownership, repository or vendor accountability, environments, support model, and reporting path if known.
Launchpad approval	The project can be approved as an MITDP and move to optional Alpha or directly to Prep and 90-Day Build.	Main gate after both Launchpad stages are complete.	Recommend whether the next technical step is Alpha testing, Prep readiness work, or delivery support.
Optional Alpha	The team can test technology options with real use cases before committing.	Optional phase before an updated Launchpad approval gate.	Help design prototypes, evaluation criteria, integration tests, and technical decision points.
Prep and 90-Day Build	The Definition of Ready is met and the team can demonstrate working software within 90 days.	Prep completion starts the 90-day clock; 90-Day Build approval confirms delivery capability.	Confirm Definition of Ready, demo environment, code access, quality bar, monitoring, backlog, and operational handoff path.

What to notice: Stage 2 is where engineering becomes more concrete. The need shifts from “is this plausible?” to “can this team, architecture, budget, and readiness plan survive first contact with delivery?”