IT New-Product MVP
IT New-Product MVP is a WBS template that breaks the path to a first product launch into 15 tasks across 4 phases. Dependencies run from market research to the launch Milestone, and progress weights are filled in so sibling tasks sum to 100. Scope is deliberately narrow: the goal is fast market validation.
When this template fits
- You are building the first version of a new product to validate an idea
- Pulling the launch date forward matters more than covering scope
- A small team runs research, design, build, and QA as one stream
- You decide the next scope based on how users respond after launch
When another template fits
- If the contract spells out acceptance and deliverable sign-off, SI Delivery is the better fit
- If the plan must include operations handover and user training, In-house Development is the better fit
Phase by phase
Discovery & Definition
Decide what to validate before deciding what to build. Market and competitor research and user interviews lead into a product requirements document (PRD) that locks the scope. If scope wobbles here, every later phase wobbles with it.
Design
Turn the agreed requirements into screens and structure. UX wireframes, UI design, and technical architecture run in parallel. The goal is a design you can start building from, not a perfect one.
MVP Development
The largest phase by duration. Backend API and frontend are built side by side, then joined in core feature integration. Nice-to-have features wait for post-launch decisions.
QA & Launch
Integration testing verifies the core scenarios, and the launch Milestone closes the template. Launch is not the end — it is when validation data starts arriving.
Full template structure
| WBS Code | Task Name | Type | Duration (d) | WEIGHT (%) |
|---|---|---|---|---|
| 1 | New-Product MVP | Deliverable | — | 100% |
| 1.1 | Discovery & Definition | Phase | — | 25% |
| 1.1.1 | Market & competitive research | Work Package | 5 | 35% |
| 1.1.2 | User interviews | Work Package | 4 | 30% |
| 1.1.3 | Product Requirements Document (PRD) | Work Package | 5 | 35% |
| 1.2 | Design | Phase | — | 25% |
| 1.2.1 | UX wireframes | Work Package | 5 | 30% |
| 1.2.2 | UI design | Work Package | 6 | 35% |
| 1.2.3 | Technical architecture design | Work Package | 6 | 35% |
| 1.3 | MVP Development | Phase | — | 30% |
| 1.3.1 | Backend API | Work Package | 12 | 35% |
| 1.3.2 | Frontend | Work Package | 12 | 35% |
| 1.3.3 | Core feature integration | Work Package | 8 | 30% |
| 1.4 | QA & Launch | Phase | — | 20% |
| 1.4.1 | Integration testing | Work Package | 7 | 100% |
| 1.4.2 | Official launchMilestone | Milestone | 0 | 0% |
Start with this template
FAQ
- What gets created when I apply the template?
- All 15 tasks are created in your new project with the tree structure intact. Dependencies between tasks, progress weights (WEIGHT), and a WBS Dictionary draft with each task's definition come along. After that they behave like any other task, so edit freely.
- Can I change durations and WEIGHT?
- Changing them is the point. Template durations are starting values for a typical scale; adjust them to your team's pace. When you edit WEIGHT, validation checks that sibling tasks still sum to 100.
- How is the Excel download different from applying it in the product?
- The Excel file is a static document for reviewing the structure and sharing it with your team. Applying it in the product adds dependency-driven scheduling (critical path), progress rollup, and baseline comparison. A good flow is to review in Excel, then execute in the product.
- Isn't 15 tasks too few?
- It is a deliberate size for the MVP stage. Following the 8/80 rule, each Work Package is kept from growing too large or too small. As the project grows, split tasks further or start from a larger template like In-house Development.
- How is the schedule calculated?
- Set a project start date and each task's start and finish dates are computed in working days along the dependency chain. Weekends and holidays follow the project calendar.