Construction

Construction is where validated opportunity becomes an actual build plan. The goal is not to recreate a full project-management suite. The goal is to decide what should be built now, what should wait, what is blocked, and how the work connects back to the proof you already gathered.

Overview

The Overview tab is the execution summary for the phase. It should tell you what is active, what is blocked, what is drifting, and whether the team is still moving toward the next meaningful release.

Key signals:

• Active sprint: The sprint currently carrying the most immediate build work.
• Scope progress: Directional view of how much of the must-have build is actually moving.
• Blocked work: Tasks that cannot move because of dependencies, missing decisions, or outside constraints.
• Overdue work: Useful for spotting where the plan and reality have started separating.
• Milestone progress: Whether the next meaningful checkpoint is still realistic.
• Release readiness: A quick view of how close the next shipping package is to being real.
• Recent decisions: Important changes that affect scope, architecture, or sequencing.

Why it matters:

• Construction gets messy quickly when founders only look at individual tasks.
• A good overview helps you answer "what matters now?" in seconds.

Tips:

• If the dashboard feels vague, the underlying tabs are probably under-defined.
• Treat blocked work as a high-priority signal, not a side note.
• Revisit Overview before starting a new sprint or changing scope.

MVP Scope

The Scope tab is where you protect the first version from becoming a disguised v2. It defines what the build must accomplish, what would be nice later, and what is explicitly out.

Key fields:

• Core problem: The main customer pain this build is meant to address.
• Success definition: What must be true for you to consider the MVP successful.
• Must-have features: Features required for the product to solve the core problem credibly.
• Nice-to-have features: Useful additions that improve the experience but are not required for the first release.
• Out of scope: Features or ideas that are intentionally excluded for now.
• Linked proof: The assumptions or evidence that justify why something belongs in scope.

Why it matters:

• Scope creep usually starts as "just one more useful thing."
• Explicitly writing what is out of scope is often more valuable than writing what is in.

Tips:

• Keep must-haves brutally short.
• If a feature does not clearly support the core problem, it probably does not belong in the MVP.
• Use out-of-scope items to reduce re-litigation, not just to park ideas.

Sprints

Sprints turn scope into short delivery windows. This is where broad product intent becomes specific build work with owners, estimates, blockers, and acceptance criteria.

Key fields:

• Sprint goal: The outcome the sprint is trying to achieve.
• Milestone: The larger checkpoint the sprint contributes to.
• Task title: A short description of the work item.
• Priority: Relative urgency or importance.
• Estimate: Rough effort sizing.
• Owner: Who is responsible for moving the task.
• Acceptance criteria: What must be true for the task to count as done.
• Notes: Extra context or implementation detail.
• Blocked by: The dependency that prevents progress.
• Linked proof / linked assumptions: The evidence that justified building this item.
• Release tag: Which release the task is intended to ship with.

Why it matters:

• Weak task definitions create hidden work, carryover, and constant interpretation.
• Linking tasks back to proof helps keep the build tied to validated need instead of personal preference.

Tips:

• If acceptance criteria are fuzzy, the task is probably still too vague.
• Use blockers explicitly instead of burying them in notes.
• Do not overload a sprint with low-priority work just because there is room on the screen.

Milestones

Milestones are the bigger checkpoints that matter to the project, such as beta readiness, onboarding launch, billing completion, or first live release.

Key fields:

• Title: The name of the checkpoint.
• Target date: When you want to hit it.
• Status: Planned, active, complete, or at risk.
• Success definition: What has to be true for the milestone to count as achieved.
• Linked sprints: The sprint windows contributing to it.
• Notes: Context, dependencies, or changes in scope.

Why it matters:

• Founders usually think in shipping moments, not just task lists.
• Milestones provide a clearer management layer between daily tasks and the whole product vision.

Tips:

• Milestones should represent outcomes, not just internal activity.
• Avoid creating too many checkpoints. A few meaningful milestones are easier to manage.
• If a milestone keeps slipping, the problem is usually scope or dependencies, not the date itself.

Releases

Releases package work into an actual ship plan. This tab is where you decide what is going live, what still needs to be ready, and what risks still threaten the launch.

Key fields:

• Release name: The label for the shipping package.
• Goal: What this release is meant to accomplish for the product or user.
• Included tasks: The concrete work that must ship with it.
• Target date: Planned release date.
• Status: Draft, active, ready, shipped, or delayed.
• Risks: Known issues that could jeopardize the release.
• Readiness checklist: The things that must be complete before shipping.
• Notes: Context on sequencing, cut items, or rollout considerations.

Why it matters:

• Releases keep the team focused on shipping outcomes instead of endless internal movement.
• They also create a more honest view of readiness than "almost done" task language.

Tips:

• A release should have a clear user-facing or business-facing purpose.
• Use the readiness checklist to make quality and launch prep visible.
• If a task is not critical to the release goal, it probably should not be included.

Decision Log

Construction creates strategic decisions constantly: what got cut, what changed technically, what was delayed, and why. The Decision Log keeps those calls visible and durable.

Key fields:

• Decision: The call that was made.
• Reason: Why the decision was necessary.
• Alternatives considered: Other options that were on the table.
• Date: When the choice was made.
• Impact: What the decision changes across scope, timeline, quality, or product direction.
• Owner: Who made or owns the decision.

Why it matters:

• Important tradeoffs are easy to forget a few weeks later.
• A decision log reduces repeated debate and makes project history easier to understand.

Tips:

• Log strategic choices, not every small preference.
• Write the reason clearly enough that future-you will still understand it.
• If a decision materially changes scope, update the other tabs too.

Technical Notes

Technical Notes capture the implementation context that sits above individual tasks: architecture, integrations, environments, deployment, instrumentation, and build risks.

Key fields:

• Architecture notes: High-level shape of the system and major design choices.
• Integrations: External tools, APIs, or services the product depends on.
• Environments: Important distinctions between local, staging, and production setup.
• Deployment notes: What is required to ship safely.
• Instrumentation: Analytics, logging, monitoring, or event tracking that should exist before launch.
• Risks: Technical unknowns or fragilities that could create delay or quality issues.

Why it matters:

• Build complexity compounds fast when implementation context lives only in people’s heads.
• This tab keeps the project legible as it grows past a few simple tasks.

Tips:

• Keep notes brief but operationally useful.
• Track deployment and instrumentation early, not as last-minute cleanup.
• If a technical risk could block shipping, surface it in releases or blockers too.

Phase Gate Checklist

The Phase Gate Checklist appears on the Construction overview and evaluates whether the project is ready to advance to Stability. Gates check whether key Construction activities have been completed - MVP scope defined, sprints planned, milestones set, releases configured, and technical notes documented.

Phase gates are advisory, not blocking. They highlight what is strong and what is still weak so you can make an informed decision about advancing. If a gate is not met but you have good reason to proceed, you can override it and the decision is recorded.

Tips:

• Review the checklist before requesting a phase change. It tells you exactly what the system considers ready vs. incomplete.
• Unmet gates are a prioritization guide - they highlight the highest-value Construction work remaining.
• A project that has shipped its first release but has incomplete technical notes might still be ready to advance if the core build is sound.

Health Scorecard

The Health Scorecard shows a composite health score for the project across five dimensions: Clarity, Proof, Construction, Stability, and Expansion. Since the project is in the Construction phase, the Construction dimension is weighted at 50% of the composite score.

The score is calculated from 26 weighted boolean items across all dimensions. Each dimension shows its own score with an expandable checklist of individual items so you can see exactly what is contributing to or dragging down the score.

Tips:

• Focus on Construction items first - they carry the most weight while the project is in this phase.
• Earlier phase scores (Clarity, Proof) should already be strong. If they are weak, it may indicate the project advanced too quickly.
• Use the expandable item checklists to find specific gaps rather than reacting to the composite number alone.