OctiAI

Categories

MVP Requirements Spec Synthesizer (Work-Ops Prompt)

Convert messy stakeholder notes and user feedback into a prioritized, distribution-ready MVP requirements spec — formatted as an SOP in Markdown.

What You'll Get

How to Use

Quick setup tip

Number every pasted source line (e.g., [S1], [S2]...) and include explicit project objective, primary user segment, any hard deadlines, compliance constraints, and current technical limitations. This reduces follow-ups and produces a complete spec on the first run.

Works Best With

Works best when you can paste complete stakeholder notes, user quotes, system constraints, and a target deadline

Prompt Template


## Goal
- Produce a prioritized requirements specification (MVP scope) synthesized from stakeholder notes and user feedback: include prioritized user stories, acceptance criteria, dependencies, estimated effort bands, and top risks with mitigations. Output must be distribution-ready for product, engineering, and PM stakeholders.

## Inputs
- Paste below the raw inputs the model should use (include all available stakeholder notes, user feedback excerpts, meeting transcripts, participant list, project context, timelines, and any existing product constraints).  
- If any of the following are not provided, the prompt will ask clarifying questions before generating the spec: project objective, target user segment, hard deadlines, required compliance constraints, and current technical constraints.

Required input types (provide as part of the pasted content):
- Stakeholder notes and highlights (bullet or transcript form)
- User feedback excerpts or research summary (bullets or quotes)
- Project context and business objective
- Available resources, owners or teams (if known)
- Any deadlines or launch windows

If required data is missing, the model must explicitly request it before producing the final spec.

## Prompt
You are a product ops specialist. Using only the material pasted below as source evidence, generate a prioritized, stakeholder-ready requirements specification for an MVP. Follow these instructions exactly:

1. Start with a one-paragraph synthesis of the provided inputs, citing up to five exact excerpt lines from the source (use quotation marks and a short reference like “Source line 3”). Do not introduce facts not present in the inputs.
2. Produce the document in SOP format as specified in the Output Format section. Use the exact headings and order required there.
3. Extraction step: List all candidate requirements extracted from the inputs as numbered items. For each requirement include:
   - Source excerpts that support it (quote + source line ref).
   - A one-sentence rationale linking the requirement to the business objective.
   - Mark whether it is a “Fact” (explicit in inputs) or an “Assumption” (inferred). If an assumption, state the assumption and a clarifying question to confirm.
4. For each candidate requirement, write 1-3 user stories in the format: “As a <role>, I want <capability>, so that <benefit>.”
5. For every user story provide clear, testable acceptance criteria (given/when/then format), and minimum non-functional constraints (performance, security, compliance) if mentioned in inputs.
6. Dependencies: For each requirement/story, list dependencies (systems, teams, APIs, data, third-parties), and any blocking risks.
7. Effort estimates: Assign each user story an effort band: S (1-3 pts), M (4-8 pts), L (9-13 pts), XL (14+ pts). Also provide a confidence level (High/Medium/Low) and a one-sentence justification for the estimate.
8. Prioritization: Score each candidate requirement using this rubric and show the calculation:
   - Impact (1-5), Effort inverse (1-5), Risk (1-5 lower is better), Strategic alignment (1-5). Final priority score = (Impact + Strategic alignment + (5 − Effort)) − Risk. Present a sortable table with columns: ID, Requirement, Impact, Effort score, Risk, Strategic, Priority score, Effort band, Confidence.
9. MVP recommendation: Based on the scoring and any deadline constraints in the inputs, recommend a specific set of requirements as the MVP scope (target total effort band sum for release), and justify selection in 2-3 bullets (trade-offs considered).
10. Roadmap & owners: Provide a short implementation roadmap for the MVP with milestones (weekly or sprint-based), owners for each milestone (use provided owners; if none provided, leave owner blank and add clarifying question), and suggested due dates (only if a deadline was provided; otherwise propose realistic duration estimates).
11. Top risks & mitigations: List the top 5 risks for the MVP with a mitigation plan and a trigger/monitoring indicator for each.
12. QA checklist: Provide a short QA checklist mapping to acceptance criteria and non-functional constraints.
13. Open questions & required decisions: List any outstanding clarifying questions (explicitly call out missing inputs the model could not infer) and decisions that stakeholders must make to unblock delivery.
14. Action items: Produce a final actionable list (owner, action, due date) to move from spec to delivery-readiness. Do not invent owners or dates; if missing, leave owner or date blank and mark as “requires confirmation”.
15. Assumptions & sources: End with a list of all assumptions made (each prefixed “Assumption:”) and a consolidated list of source excerpts used (copy the quoted lines and a short identifier).

Formatting and behavior rules:
- Keep output in Markdown and use bold for section titles and important terms. Use tables where helpful (e.g., prioritization).
- Separate clearly **Facts** and **Assumptions** in each section.
- Do not invent metrics, dates, or owners. If necessary data is absent, ask explicit clarifying question(s) before producing the final spec and stop.
- Keep the final spec concise: target 1-2 pages for the MVP selection and prioritized backlog, but include appendices (detailed user stories and acceptance criteria) after the main summary.
- Mark every generated estimation with a confidence level and a one-line justification.

Now ingest the content below (do not proceed until you have it). If required inputs are missing, list exactly what is missing and ask focused clarifying questions. If inputs are complete, produce the full spec following the steps above.

-- Begin pasted inputs --
(paste stakeholder notes, user feedback, transcripts, participant list, project context, timelines, constraints here)
-- End pasted inputs --

## Output Format
Produce the requirements spec in SOP structure using these exact headings and order:

Purpose
- One-sentence statement of operational outcome and target release.

Scope
- In-scope features and explicit out-of-scope items.

Procedure
- Stepwise prioritized backlog and MVP decisions. Include:
  - Synthesis paragraph with cited source excerpts.
  - Numbered candidate requirements (with source quotes, fact/assumption).
  - User stories and acceptance criteria for each requirement.
  - Dependencies and blocking items.
  - Effort band estimates with confidence.
  - Prioritization table and final priority-sorted backlog.
  - Recommended MVP scope and rationale.

QA checks
- Test checklist mapped to acceptance criteria and non-functional constraints.

Escalation
- Who to notify for critical blockers (use provided owners or list role). For each escalation path include trigger condition and escalation cadence.

Use bold for the five top-priority items in the Procedure summary and place detailed user stories in an appendix after the QA checks.

## Guardrails
- Clearly separate **Facts** (pulled verbatim from inputs) from **Assumptions** (explicitly labeled and justified).
- If input text is ambiguous, show the original ambiguous excerpt and propose two alternative interpretations; mark which interpretation you used.
- Do not assert compliance, security, or legal claims unless the source text explicitly states them.
- All estimates must include a confidence level and a one-line reason.
- Any invented owner, date, or metric must be flagged with “Invented — confirm” and avoided unless user confirms.

## Examples
Mini excerpt showing how Decisions and Actions should appear in the delivered spec:

Decisions
- Decide MVP will include authentication and core search.

Actions (owner / action / due date)
- Product Lead / Confirm MVP feature list and priorities / requires confirmation
- Engineering Manager / Provide feasibility estimate for top 3 items / requires confirmation

Use this exact formatting style for the Decisions and Actions list in the spec.

Variables

Usage Notes

Not for

Do not include

MVP Requirements Spec Synthesizer (Work-Ops Prompt)

Turn pasted stakeholder notes, user feedback, and project context into a prioritized, auditable MVP requirements specification: user stories, acceptance criteria, dependencies, effort bands, risks & mitigations, roadmap, QA checklist, and action items — ready for product/engineering/ops distribution.

Turn this into a working asset in minutes.

Import into Workspace to auto-fill variables, adapt output style, and iterate with OctiAI's prompt editor.

What you'll get

Output format

Markdown

Best used when

Avoid when

Sign in to save, like, or rate this prompt.

Made for

What to fill in

Use the guidance below to complete each placeholder with the right level of detail.

No placeholders required for this prompt.

Rules

Canonical Examples

Input: Stakeholders: Head of Ops requests an MVP for 'QuickInvoice Capture' to extract invoice data from supplier PDFs, auto-fill a purchase system, and flag mismatches. User feedback from 8 SMB customers requests ‘fast capture, few manual fields, and CSV export’. Constraints: launch internal pilot in 6 weeks; integration only via existing REST API; no dedicated engineering resource beyond two full-time sprints. Provided excerpts include meeting notes, user quotes, and integration constraints.

Loading result...

Failed to load output.


**Purpose**
- Deliver MVP 'QuickInvoice Capture' to auto-extract key invoice fields and produce validated CSV for accounting in a 6-week pilot.

**Top prioritized backlog (bold = top-5)**
1. **Invoice OCR and field extraction**
2. **Manual correction UI for mismatches**
3. **CSV export & mapping to accounting fields**
4. **Duplicate detection**
5. **Audit log of changes**

Why it works: This example demonstrates converting messy notes and user quotes into a crisp, prioritized MVP spec with traceable source citations, clear user stories and acceptance criteria, dependency mapping, and a quantified prioritization table — all in SOP format for distribution to PM, Eng, and Ops.

Input: Stakeholders want an Employee Onboarding Portal MVP to centralize new hire tasks: document collection, equipment request, training checklist, and automatic notifications. User interviews (5 hiring managers) emphasized 'one place for compliance docs' and 'auto-remind for incomplete tasks'. Timeline: soft launch in 8 weeks; constraint: must integrate with Okta SSO and Slack notifications. Teams: People Ops owner named 'Dana (People Ops)'; Engineering available for 3 sprints.

Loading result...

Failed to load output.


**Purpose**
- Deliver an 'OnboardOne' MVP to centralize new-hire tasks, collect compliance documents, and send automated reminders via Slack, targeting a soft launch in 8 weeks.

**Top prioritized backlog (bold = top-5)**
1. **SSO + user provisioning via Okta**
2. **Task checklist & progress tracking**
3. **Document upload & storage (compliance docs)**
4. **Slack notifications for reminders**
5. **Equipment request form and approval flow**

Why it works: This example shows transforming meeting notes, user quotes, and integration constraints into a prioritized requirements spec with traceable evidence, explicit assumptions, sprint roadmap, and a prioritized backlog in SOP format.

Works Best With

Works best when you can paste complete stakeholder notes, user quotes, system constraints, and a target deadline