Progress Md Business

PROGRESS.md — Executive Dashboard for Business Projects

This skill enforces the creation and maintenance of PROGRESS.md as the authoritative executive dashboard for any business or product project. The file is read first by stakeholders and AI agents to understand current state, next phase, and key metrics.

Core Rule

Every business or product project MUST have PROGRESS.md at the repository root. This file serves as the single source of truth for project phase, vision, milestones, and impact metrics. It is NOT a changelog, NOT a technical design document, and NOT a session handoff—it is the executive view.

What PROGRESS.md Contains

• Project phase — current state (Validation → Build → Launch → Growth → Paused → Cancelled)
• Project vision — problem statement, target customer, differentiated value, revenue model
• High-level milestones — key deliverables by phase with completion status
• Impact metrics — quantitative measures of progress (user growth, retention, revenue, engagement, etc.)
• Current blockers — what is preventing progress, with severity
• Next phase transition criteria — what must be true to move to the next phase

What PROGRESS.md Does NOT Contain

• Technical changelog → lives in CHANGELOG.md (structured, versioned)
• Architecture decisions → live in ADRs or architecture-decisions.md
• Inter-session context → lives in session-handoff.md or equivalent
• Code review state → lives in review-state.md or inline pull requests
• Implementation details → live in issue trackers, code comments, design docs

PROGRESS.md is executive summary only. It points to other documents rather than duplicating them.

Template Structure

Use this structure as a starting point. Customize sections based on project type (B2B SaaS, consumer app, marketplace, etc.):

# PROJECT_NAME — PROGRESS

## Current Phase
🔵 **Build** — ETA next phase: [DATE]

## Vision
**Problem:** [one-sentence problem statement]
**ICP:** [ideal customer profile]
**USP:** [unique value vs. alternatives]
**Revenue Model:** [how money flows]

## Milestones (Current Phase: Build)
- [✓ / ○] Milestone A — [target date]
- [✓ / ○] Milestone B — [target date]
- [✓ / ○] Milestone C — [target date]

## Key Metrics (Last Updated: [DATE])
| Metric | Value | Target | Status |
|--------|-------|--------|--------|
| [Metric A] | [current] | [goal] | [trend: ↑ / ↓ / → ] |
| [Metric B] | [current] | [goal] | [trend] |

## Blockers
🔴 **[Blocker Title]** — [description, impact]
🟡 **[Blocker Title]** — [description, impact]

## Next Phase Criteria
To transition to [Next Phase], these conditions must be met:
- Condition 1
- Condition 2
- Condition 3

## Session Updates
- **[DATE]** — [what changed; link to session handoff or PR if applicable]
- **[DATE]** — [what changed]

Maintenance Workflow

1. Session Start: Read PROGRESS.md first. Summarize current phase and blockers.
2. During Work: Continue normally. Track decisions that affect phase, metrics, or blockers.
3. Session End:
   • Update phase if changed
   • Mark milestones completed in this session
   • Revise metrics if new data
   • Add new blockers or resolve closed ones
   • Timestamp the update with a brief note

Update frequency: After every substantive work session, at phase transitions, when metrics change meaningfully, or when blockers are resolved.

Scope: What Projects Require PROGRESS.md

REQUIRED:

• Business projects (startups, side businesses, products with revenue or user acquisition targets)
• Product projects (consumer apps, SaaS, marketplaces, platforms)
• Any project with explicit phases (Validation → Build → Launch → Growth)

NOT REQUIRED:

• Infrastructure-only projects (infrastructure-as-code repos, deployment automation, tooling)
• One-off scripts or utilities
• Libraries with no business model
• Open-source projects without user growth targets

When in doubt: if the project has phases, metrics, and a decision-maker tracking status, it needs PROGRESS.md.

Example Phases and Transitions

Integration With Other Project Artifacts

PROGRESS.md owns: phase, vision, metrics, blockers, phase-transition criteria.

Peer documents it references:

• CHANGELOG.md — "What shipped and when" (technical, detailed)
• session-handoff.md — "State of work between sessions" (context for next AI agent or human)
• ADRs / architecture.md — "Why we made these technical choices"
• README.md — "How to use/deploy this project"
• Issue tracker or roadmap.md — "Detailed feature backlog"

Weekly stakeholder check-in? Open PROGRESS.md first. It answers "where are we" in 2 minutes.

Anti-Patterns (Prohibited)

❌ No PROGRESS.md in business projects — "We track it in Notion / Slack / spreadsheet" → Creates single-point-of-failure, couples project state to external tool, invisible to new team members.

❌ PROGRESS.md with only technical milestones — "UI built, API done, DB migrated" → That's a technical checklist, not an executive dashboard. Milestones should be user-facing or business-facing ("MVP beta shipped with 50 users").

❌ Metrics that don't reflect business health — "Lines of code, test coverage, CI/CD uptime" → These are technical health, not business health. Include user acquisition, retention, conversion, revenue, or engagement.

❌ PROGRESS.md updated only at end-of-project or on request → It goes stale. Update it every session. Stale = unreliable.

❌ Mixing PROGRESS.md with CHANGELOG.md — "Fixed bug X, shipped feature Y, released v2.1" → One file is technical versioning (CHANGELOG), the other is executive status (PROGRESS). Separate them.

Application

Applies to: all AI agents (Claude, Cursor, Codex, Gemini, etc.), all business and product projects.

Triggers for this skill:

• Starting a new business or product project
• MVP definition or scope review
• Phase transition decision
• Metric tracking or impact analysis
• Stakeholder status update
• New session on a business project

Coordination: Works with business-guardrails (validation before build), impact-metrics-gate (metrics definition), and adr-spec-gate (architecture decisions). PROGRESS.md answers "where are we"; guardrails ensure "should we be here at all"; metrics ensure "how do we measure success."

Example: Real Project PROGRESS.md

# TaskFlow — PROGRESS

## Current Phase
🟢 **Growth** — Stable, tracking 15% MoM user growth

## Vision
**Problem:** Teams lose context switching between task managers, calendars, and Slack
**ICP:** Remote teams <50 people, async-first cultures
**USP:** Single interface combining tasks + scheduling + comms, no extra app
**Revenue Model:** $10/user/month, free tier for <5 users

## Milestones (Current Phase: Growth)
- [✓] Free tier launched (Jun 2024)
- [✓] Slack integration MVP (Jul 2024)
- [○] Calendar sync with 3+ providers (target: Sep 2024)
- [○] Team analytics dashboard (target: Oct 2024)

## Key Metrics (Last Updated: Jun 14, 2024)
| Metric | Current | Target | Trend |
|--------|---------|--------|-------|
| Active Users | 487 | 1000 | ↑ 12% MoM |
| Free-to-Paid Conversion | 3.2% | 5% | ↑ 0.4pp |
| Monthly Churn | 2.8% | <2% | ↓ 0.5pp |
| NPS | 42 | 50+ | ↑ 3pts |
| MRR | $1,240 | $5,000 | ↑ 18% |

## Blockers
🔴 **Salesforce sync is broken** — CRM customers requesting Salesforce sync; currently API-side limitation. Blocks enterprise tier. ETA fix: 2 weeks.

🟡 **Support load unsustainable** — 2 support engineers for 500 users. Need triage automation. Blocks growth past 1000 users without hiring.

## Next Phase Criteria
To transition to "Mature," we need:
- MRR >$10k, 2000+ users
- Free-to-paid conversion >5%
- NPS >50
- Churn <2% and stable

## Session Updates
- **Jun 14** — Calendar sync spec finalized; started implementation sprint
- **Jun 10** — Onboarded first 3 enterprise customers; MRR crossed $1k
- **Jun 5** — Slack integration shipped; 40% adoption in beta cohort

Use this as your living document. Update it every session. The simplicity of PROGRESS.md compared to lengthy status reports is its greatest strength.