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.