A practical playbook for PMs and POs worldwide. Eight modules. The complete lifecycle of product delivery — accelerated by AI at every phase.
Pre-Sales Track — Modules 1–3
1
Pre-Sales
Decode the Brief
How to extract and understand any client input using AI tools.
→
2
Pre-Sales
Know the Battlefield
Market research, competitor analysis, and feature prioritisation.
→
3
Pre-Sales
Price it Right
Build a defensible effort estimate with AI savings layered in.
→
Delivery Track — Modules 4–7
4
Delivery
Draw the Journey
UX blueprints, user flows, wireframes, and interactive prototypes.
→
5
Delivery
Make it Testable
Convert blueprints into atomic FSDs and acceptance criteria.
→
6
Delivery
Get Everyone Aligned
Cross-team validation, spec lock, and change control.
→
7
Delivery
Hand it Over Clean
Package everything into a dev-ready source of truth.
→
Post-Launch Track — Module 8
8
Post-Launch
Measure & Improve
Post-launch performance, improvement backlog, and next iteration.
→
💰
AI ROI & Savings Calculator
Answer 9 questions. Get a personalised breakdown of PM/PO savings, development savings, and rework avoided — with your ROI on AI tooling investment.
Interactive Tool
Module 1 of 8 · Decode the Brief
AI-Powered Product DeliveryModule 1 of 8Pre-Sales Track
Decode the Brief
How to extract, structure, and understand any client input using AI tools — and produce a Discovery Summary, Discovery Questionnaire, and Concept Note ready for Module 2.
Your progress0%
Part 1 of 6 — The Mindset
Before you open any AI tool, think right
Product Idea Formulation is the first phase of any engagement. A client comes with a problem, a vision, an RFP, or a rough idea. Your job is to decode what they actually need — not just what they said.
The core principle: A client says what they want. Your job is to understand what they need. These are almost never the same thing — and the gap between them is where projects fail.
Skill 1 — Listen for the real problem
Clients often describe a symptom, not the root cause. "We need a dashboard" often means "our doctors need to make faster treatment decisions without missing critical patient history."
What they say
"We need a dashboard to track our revenues."
What they mean
Our pricing decisions depend on 2 people and the knowledge dies with them. We're losing revenue daily.
Your question: "What happens today when neither of those two people is available?"
⚠️ Watch for clients who jump straight to features. When someone says "I want a mobile app with push notifications and a leaderboard" — pause. Ask: "What problem are you trying to solve for the person using this?"
Skill 2 — Feature request vs. business problem
A feature request: "I want an AI chatbot." A business problem: "Our support team is overwhelmed and response times are hurting customer retention." Features are solutions. Problems are opportunities.
→
The 5 Whys Technique
When a client names a feature, ask "why" five times in gentle succession. You'll almost always arrive at the real business problem by the third or fourth why. It feels uncomfortable at first. It works every time.
Skill 3 — Handle the client who doesn't know what they want
This is more common than you think. A client comes in excited with vague energy: "something like Uber but for laundry" or "we want to use AI somehow." Don't panic. Don't fill the silence with your own assumptions.
Don't do this
Fill the gap with your own assumptions. Nod along. Leave thinking you understood when you didn't.
Do this instead
"Help me understand — who is the person whose life gets easier when this product exists? Walk me through their typical day."
The real cost of getting this phase wrong: A requirement misunderstood here costs 1× to fix. Caught in development: 10×. Caught in production: 100×. This phase is the cheapest place to get it right.
Part 2 of 6 — The Knowledge
Two types of engagement — know which one you're in
Before gathering information, identify what type of engagement this is. The questions you ask differ significantly.
BUILD — Greenfield
Nothing exists yet. The client wants to build a new product from scratch. Focus: understanding the problem space, target users, and what success looks like from zero.
SUPPORT — Existing Product
A product already exists. The client needs evolution, new features, or AI added. Focus: what's broken, what's working, and what the constraints are.
What inputs will you receive?
In real life, you won't always get the same type of information. Here are the five input types and what to look for in each.
The 9 knowledge categories you must cover
By the end of this phase, you need answers — or documented unknowns — across all 9 categories.
1
Business Context
Why now?
What triggered this initiative — why now, not 6 months ago?
What does success look like commercially — revenue, cost saving, market share?
Is there a business event driving the timeline — launch, audit, board review?
Who internally is championing this, and who might resist it?
2
Users & Personas
Who uses it?
Who is the primary user — their job, skill level, and environment?
How often will they use this — daily, weekly, in moments of crisis?
What is their single biggest frustration today that this product will solve?
Are there accessibility or language requirements?
3
Current State
What exists today?
What tool, process, or workaround do users rely on today?
What specifically fails about the current approach?
What do users actually like about today that must be preserved?
Is there existing data, content, or IP that will migrate?
4
Product Scope
What are we building?
Is this MVP only, or a full product? What is explicitly out of scope?
What are the must-have features vs. nice-to-have?
What platforms — web, mobile, both? iOS, Android, or cross-platform?
Single-tenant or multi-tenant? Expected user scale?
5
Data & Integration
What connects to what?
What data exists today and where does it live?
What third-party systems or APIs need to integrate?
Is real-time processing required, or is batch sufficient?
Who owns the data — client, third party, or users?
6
Technical Constraints
What limits us?
Does the client have a preferred cloud platform — AWS, Azure, GCP?
Are there performance requirements — response time, uptime SLA?
Technology preferences or restrictions — languages, frameworks?
What industry regulations apply — HIPAA, GDPR, AADC, PCI-DSS, SOC2?
What regions is this product operating in?
Are there age-specific requirements — children's data?
Are there security certifications the client requires from us?
8
Team & Governance
Who decides what?
Who is the product owner on the client side — do they have budget authority?
Who is the technical decision-maker on the client side?
Are there domain experts we need access to?
How does the client make decisions — consensus, hierarchy, committee?
9
Timeline & Budget Signals
What are the real constraints?
Is there a hard deadline — and what is driving it?
Has budget been approved, or is this still exploration?
What is their decision-making timeline?
Have they spoken to other vendors — and what were they told?
You won't get answers to everything in the first conversation. What matters is knowing what you still need to find out — and going back for it before moving to Module 2.
Part 3 of 6 — The Process
From raw input to Concept Note — step by step
Here is how you work through this phase every time, regardless of the input type you receive.
1
Read the input with purpose
Don't just skim. Read looking for four specific things: the pain word (the emotional trigger), the trigger event (why now), the named solution (what they think they want), and the gap (what is conspicuously missing).
2
Map what you know and don't know
Before any client conversation, map your current knowledge against all 9 categories. Mark each: Known ✓, Partially Known ~, or Unknown ?. The unknowns drive your questionnaire.
3
Prepare your discovery questionnaire
Using your knowledge map, build a targeted questionnaire. Focus on your unknowns. Don't ask about what you already know — it wastes the client's time and signals you didn't read their brief. Business context first, technical constraints last.
4
Run the discovery conversation
The discovery call is not a Q&A session — it's a guided conversation. Ask one question, listen fully, probe one layer deeper, then move on. End with: "Is there anything you expected me to ask that I haven't?"
5
Build the Concept Note
The Concept Note is your deliverable from this phase. 1-2 pages capturing everything you now know. Clear enough for a non-technical client to validate. Detailed enough for your team to understand what comes next.
What a good Concept Note contains: Project working title · Problem statement (1-2 sentences) · Engagement type (Build or Support) · Primary users and their core need · Product type and platform · Top 5-8 MVP features · Key unknowns still to resolve · Recommended next step
Part 4 of 6 — Where AI Helps
AI accelerates execution. You still own the thinking.
Use these four prompts in sequence. Fill in the highlighted placeholders with your specific context. Always review and correct the output before using it.
Human in the loop — non-negotiable
AI processes what is written. It cannot know what the client said between the lines, what your presales colleague told you off the record, or what your experience tells you about this type of client. Every AI output here requires your review, your correction, and your sign-off. You are accountable — not the tool.
1
Input Processor — Turns any raw input into a structured Discovery Summary
I have received a [A: RFP / B: Email Brief / C: Call Transcript / D: Requirements Doc / E: One-liner]
about a potential project.
Project type: [Cloud Native / Mobile / Data+Analytics / Data+AI / AI Product]
Industry / Domain: [e.g. Healthcare, Retail, Logistics, Fintech, EdTech]
Engagement type: [BUILD — Greenfield / SUPPORT — Existing Product]
Here is the raw input:
---
[PASTE YOUR RAW INPUT HERE]
---
Extract and structure the following:
1. CORE PROBLEM — What is the client actually trying to solve? One sentence.
2. WHO IS AFFECTED — Primary user and secondary stakeholders
3. CURRENT STATE — What exists today and specifically why it fails
4. DESIRED OUTCOME — What does success look like for the client?
5. ENGAGEMENT TYPE — Confirm: Greenfield BUILD or Existing SUPPORT?
6. UNKNOWNS — List every critical piece of missing information
7. COMPLEXITY SIGNAL — Low / Medium / High / Very High, with reasoning
Format as a structured Discovery Summary.
Review Checkpoint — After Prompt 1
Does the core problem match what you actually understood? Add context the AI couldn't know — things said verbally, client history, relationships. Correct anything that feels off before moving to Prompt 2.
2
Project Lens — Surfaces risks, compliance needs, and specialist skills
Now apply a [PROJECT TYPE] lens to the Discovery Summary above.
For this type of project, identify:
1. TOP TECHNICAL RISKS — The 3 most common risks this project type signals
2. COMPLIANCE & REGULATORY FLAGS — Industry or regional requirements to raise early
3. INTEGRATION COMPLEXITY — Systems, APIs, or data sources likely needed
4. SPECIALIST SKILLS — What expertise this project demands beyond a generic team
5. REFERENCE PRODUCTS — 2-3 existing products closest to what the client wants
Be specific to [INDUSTRY / DOMAIN], not generic.
3
Discovery Questionnaire — Tailored questions for the next client call
Based on the Discovery Summary and Project Lens, generate a structured
Discovery Questionnaire for our next client conversation.
Organise questions under these 9 categories:
1. Business Context 2. Users & Personas 3. Current State 4. Product Scope
5. Data & Integration 6. Technical Constraints 7. Compliance & Security
8. Team & Governance 9. Timeline & Budget
Rules:
- Do NOT include questions already answered in the brief
- Ask 3-5 questions per category
- Phrase questions conversationally — as a PM would ask in a meeting
- Flag the top 3 most critical questions with a star (★)
These must be answered before estimation begins
Review Checkpoint — After Prompt 3
Remove questions already answered. Add questions only you know to ask based on conversations so far. Reorder by importance. You know this client — the AI does not.
4
Concept Note Generator — Your deliverable from this phase
Using everything gathered — Discovery Summary, Project Lens, and discovery
conversation notes — generate a Concept Note with:
1. PROJECT TITLE — A working name for this product
2. PROBLEM STATEMENT — 1-2 sentences, client-friendly language
3. ENGAGEMENT TYPE — BUILD or SUPPORT, with brief rationale
4. PRIMARY USERS — Who uses this and what they need
5. PRODUCT TYPE & PLATFORM — What we are building and where
6. TOP MVP FEATURES — 5-8 core features for the first version only
7. KEY UNKNOWNS REMAINING — What must be resolved before Module 2
8. RECOMMENDED NEXT STEP — What happens in the next client conversation?
Keep under 500 words.
Write so a non-technical client can read and validate it.
Write so your delivery team understands exactly what is being built or supported.
Final Checkpoint — The Concept Note is yours
Read it as the client: would you validate this description of your own problem? Read it as a developer: could you understand what you're being asked to build? Fix what doesn't pass both tests. This document is yours — not the AI's.
Part 5 of 6 — Live Examples
Two real-world prompt flows — fully anonymised
Each example shows the actual raw input, what each prompt produces, and what the final Concept Note looks like. This is exactly what you'll produce in real work.
Example 1 · Mobile Product · EdTech · UK Market
UK EdTech Startup — Gamified Maths Learning Platform
From: Presales Team — "We are talking to a prospect who wants to build an educational maths application for the UK primary school market. They want something similar to existing gamified learning platforms — avatars, coins, reward systems, and an engaging experience for children aged 6-11. Can you help understand what skills, tools, and approach would be required so we can include this in our proposal?"
Prompt 1 Output — Discovery Summary
1
Core Problem: UK primary schools need a digital maths platform that motivates children through achievement and personalised engagement — not passive content delivery
2
Primary User: Children aged 6-11 in UK primary schools. Secondary: class teachers, school administrators, parents
3
Engagement Type: BUILD — Greenfield product from scratch
4
Complexity Signal: HIGH — Specialist EdTech UX, UK National Curriculum mapping, custom avatar pipeline, real-time gamification logic, UK children's data compliance
5
Critical Unknowns: Target age range confirmed? School vs home licensing model? Budget for custom illustration assets? Who creates curriculum content?
Prompt 2 Output — Project Lens (Mobile / EdTech)
Compliance & Regulatory Flags (critical):
UK Age Appropriate Design Code (AADC / Children's Code) — mandatory for any product targeting under-18s in the UK
WCAG 2.1 accessibility — required for UK school procurement
UK GDPR for children — no behavioural advertising, parental consent flows, strict data minimisation
Specialist skills needed: EdTech-specialist UX/UI designer · 2D character illustrator with modular asset experience · UK educational consultant · QA engineer with accessibility background
Prompt 4 Output — Concept Note
Project Title: LearnQuest UK — Gamified Primary Maths Platform
Problem Statement: UK primary school children lack a motivating, curriculum-aligned digital maths platform they actually want to use. Existing tools are either too rigid or too entertainment-focused.
Platform: Web-first (school compatibility), mobile app (iOS + Android) for home use.
MVP Features: Modular avatar builder and reward economy · UK National Curriculum question bank (KS1/KS2) · Progress tracking and milestone badges · Teacher dashboard with assignment controls · Parent view · Audio hints for KS1 learners
Next Step: Schedule 60-minute discovery call with the client's product owner. The compliance awareness conversation must happen before any effort estimate is prepared.
The key lesson from Example 1
AI surfaced the UK Age Appropriate Design Code (AADC) compliance requirement — a legal obligation the PM didn't initially know to look for. Missing this in the proposal would have added weeks of unscoped work mid-project. This is where AI's domain breadth protects you.
Example 2 · AI Product · Hospitality · Enterprise
Global Hotel Group — AI-Powered Revenue Management Platform
"Their revenue management expertise is concentrated in 2-3 senior individuals. Their existing software produces unexplained recommendations the team doesn't trust and overrides manually. They want an AI system that encodes their pricing logic, explains every recommendation in plain language, and can scale across all their properties without additional headcount."
Prompt 1 Output — Discovery Summary
1
Core Problem: 30 years of revenue management expertise cannot be scaled, transferred, or systematised — and existing tools produce unexplained recommendations that the team does not trust or use
2
Engagement Type: BUILD — Greenfield AI product with deep domain knowledge encoding
3
Complexity Signal: VERY HIGH — Domain expertise encoding, ML forecasting engine, explainability layer, real-time pricing, multi-property architecture
★
Blocking unknowns: Algorithm input/output variables · Existing data infrastructure and quality · PMS/CRS/OTA integration requirements
★ Can you list the specific inputs your revenue managers use today to make pricing decisions — and the outputs they produce? This is the most important question before we can scope the algorithm.
★ How many years of clean historical booking data do you have, and is it in a structured format we can work with?
★ What forecast accuracy level would you consider acceptable for this system to replace manual decisions?
Team & Governance
Would the 2-3 senior revenue managers be available to us during Phase 1 for domain knowledge transfer sessions? Their input is essential for encoding the pricing logic correctly.
Prompt 4 Output — Concept Note
Project Title: ARIA — AI Revenue Intelligence & Automation Platform
Problem Statement: A hotel group's pricing expertise is locked inside 2-3 individuals. Their existing software produces recommendations nobody trusts — so they're overriding it manually every day, losing revenue. They need an AI system that encodes that expertise, explains every recommendation in plain English, and scales across their portfolio.
MVP Features: Demand forecasting engine (arrival-based, segment-level) · BAR and segment pricing recommendations · Plain-English AI narration for every recommendation · Competitor rate and market signal integration · Performance dashboard · Multi-property architecture (12 properties, scalable to 30)
★ Next Step: Schedule an Algorithm Scoping Session with the client's senior revenue managers and our data science lead. Effort estimation cannot be finalised until this session is complete.
The key lesson from Example 2
AI reframed the project correctly — from "build a new RMS" to "encode 30 years of human expertise into an explainable AI system." That reframe alone changes the estimation by months and hundreds of thousands in cost. The algorithm scoping session became the single critical next step. Without it, any estimate would be a guess.
Part 6 of 6 — Quality Gate
Check every box before moving to Module 2
Module 2 builds directly on what you produce here. If you can't check a box, go back and fill the gap.
Run Prompt 2 — Project Lens → Risks, compliance, skills → Add your knowledge
6
Run Prompt 3 — Discovery Questionnaire → Remove answered → Add your own
7
Run the discovery call — Open questions first · Probe deeper · Clarify before closing
8
Run Prompt 4 — Concept Note → Review as client → Review as developer → Own it
9
Check quality gate — All 10 boxes ticked? → Ready for Module 2 — Know the Battlefield
✅ Module 1 complete. You now have a Discovery Summary, a tailored questionnaire, and a Concept Note. Take these into Module 2 — Know the Battlefield, where you validate the product idea against the real market before committing to a proposal.
Module 2 of 8 · Know the Battlefield
AI-Powered Product DeliveryModule 2 of 8Pre-Sales Track
Know the Battlefield
How to use AI for market research, competitor analysis, and feature prioritisation — so you can validate the product idea before committing to a proposal.
Your progress0%
Part 1 of 7 — The Mindset
You are not doing research. You are building conviction.
You have a Discovery Summary from Module 1. A client has described their problem. Now you need to answer a harder question: should this be built at all — and if so, what should it actually do?
The output of this module is not a research report. It is a Validated PRD v0.1 — a document that says: here is the problem, here is the market reality, here are the features that will win, and here is why I believe this. Without that conviction, you will build the wrong thing or price it wrong or both.
Why this step gets skipped — and why that is a problem
In most delivery teams, structured market research before scoping is almost universally skipped. The standard flow is: receive brief → clarify scope → estimate effort → write proposal. Market validation is not part of it.
This happens for a practical reason: research takes time that no one has budgeted for, and AI was not fast enough to make it worthwhile. That equation has changed. With the right prompt sequence, a PM can run a credible competitive landscape, feature benchmark, and PRD draft in under two hours.
This module introduces a new step into standard delivery practice. It is not documenting what most teams do. It is showing what the best teams now do — and what every PM can do once AI makes it fast enough to be practical.
Three questions this phase must answer
1
Is the market real?
Someone needs to want this product enough to pay for it. Your research either confirms this or challenges it. Both are valuable.
2
Who is winning today — and why?
There is almost always a competitor — direct or indirect. Understanding what they do well and where they fall short tells you what the winning position is.
3
Which features actually matter?
Not every feature the client mentioned is worth building. Your job is to separate the features that drive adoption from the ones that sound good in a meeting.
Human skills AI cannot replace in this phase
Read between the lines of a competitor review to understand what users are really frustrated about
Decide which insight is actually important for this specific client and their specific context
Recognise when a market opportunity is structurally flawed, not just underserved
Know when to trust a data point and when to question whether the source is reliable
Translate a research finding into a feature decision that Engineering can actually build
⚠ Common trap — Confirmation bias. You come in believing the client's idea is right. Your research looks for evidence that confirms this. Every finding gets interpreted to support the answer you already expect. Fight this actively. Ask AI to argue against the idea. Look for signals that the market is already saturated or that users have tried this before and abandoned it.
When to use this module
Delivery context
How to use Module 2
New product build
Run in full — all six research areas apply
Significant new feature or capability
Run partially — competitor benchmarking and feature gap analysis. Skip market sizing.
Enhancement or iteration on live product
Use only feature gap analysis and user sentiment sections
Support or maintenance engagement
Does not apply — proceed directly to Module 3
Team augmentation
Does not apply — proceed directly to Module 3
Part 2 of 7 — What to Research
Six areas of intelligence you must cover
Gaps are fine at the start — the point is to know which areas are incomplete so you can go back and fill them before the PRD is written.
Research Area
What You Are Looking For
1 — Market Size & Growth
Is the market big enough? Is it growing or shrinking? What is the addressable segment for this client's product — not the whole industry TAM?
2 — Customer Segments & Pain Points
Who actually buys products like this? What specific pains are they describing in reviews, forums, and surveys? What language do they use to describe their problem?
3 — Competitor Landscape
Who are the direct competitors? Who are the indirect ones? What do users love about them? What do users complain about? What is each competitor's pricing model?
4 — Feature Benchmarks
What features exist across the market? Which are table stakes? Which are differentiators? Which are unmet gaps nobody has addressed?
5 — Regulatory & Technical Context
Are there compliance requirements this product must meet? What technical standards, certifications, or data handling rules apply in this domain?
6 — Industry Trends
What is changing in this market over the next 12–24 months? New entrants, AI disruption, regulatory changes, or shifts in user behaviour that will affect this product?
Not every area will be equally important for every project. A B2B compliance tool needs deep regulatory research. A consumer app needs deep user sentiment research. Use the six areas as a framework and weight your effort accordingly.
Part 3 of 7 — The Process
How to run this phase — six steps
Each step has a clear input, a clear AI action, and a clear output. Follow this sequence every time.
1
Brief the AI on context from Module 1
Do not start fresh. Feed the AI your Discovery Summary from Module 1 as the first message. This anchors all subsequent research to the right context and prevents the AI from giving you generic industry answers.
2
Run a market size and growth scan
Ask the AI to identify market research, analyst reports, and industry data for the specific domain. Prompt it to give you estimates with sources, caveats on data reliability, and the key drivers of market growth or decline. Cross-check any significant data point with a second source.
3
Map the competitor landscape
Give the AI the product description and ask it to identify direct competitors, indirect competitors, and adjacent players. For each, ask it to summarise: what they do, what users say about them, and what pricing model they use. Then do your own spot-check on 2–3 of the most important ones.
4
Synthesise user sentiment from reviews and forums
For key competitors, ask the AI to analyse publicly available user reviews (G2, Capterra, App Store, Reddit, Product Hunt) and extract the top recurring praises and complaints. Pattern these into themes — not individual comments.
5
Build a feature gap analysis
List all features mentioned in the Discovery Summary. Add competitor features from your research. Then classify each feature: Table Stakes (must-have), Differentiator (competitive advantage), or Gap (unmet by existing products). This becomes the foundation of your feature prioritisation.
6
Write the PRD v0.1
Synthesise everything into the PRD template. Use AI to help structure and articulate — but every assertion in the PRD must be one you believe and can defend. This document goes to the client. It represents your credibility.
Human in the loop: Before you finalise the PRD v0.1, do a 20-minute review with someone who knows the domain — a senior PM, a Solutions Architect, or a colleague who has worked in that industry. Ask: "What am I missing?" This is the fastest way to catch a blind spot before it becomes a proposal error.
The two outputs — and the difference between them
Validated PRD v0.1
What the product should do
Written for the client
Feature-level
Answers: is this the right product?
Scope Definition Document
What the team will build and deliver
Written for the delivery team
Deliverable-level
Answers: what exactly are we signing up for?
Part 4 of 7 — Prompt Toolkit
Seven prompts to run this entire phase
Run these in a single AI session in sequence. Prompt 1 anchors your context. Prompts 2–5 build the research. Prompt 6 assembles the PRD. Prompt 7 converts it into the Scope Definition Document.
1
Context Setter — run this first, every session
I am a Product Manager doing pre-proposal market research. I am going to
paste my Discovery Summary from my brief analysis below. Use it as the
context for all follow-up research questions in this session.
--- DISCOVERY SUMMARY (from Module 1) ---
[PASTE YOUR FULL DISCOVERY SUMMARY HERE]
--- END DISCOVERY SUMMARY ---
From this summary, confirm back to me:
1. The product in one sentence
2. The primary user and their core problem
3. The industry and geographic market
4. Any constraints or signals from the brief I should factor into research
Hold all of this as context for every question I ask next in this session.
2
Market Size & Growth
Using the context above, give me:
1. An estimate of the addressable market size for [PRODUCT CATEGORY] in [GEOGRAPHIC MARKET]
2. The current annual growth rate of this market
3. The 3 most important drivers of that growth
4. Any signals of market saturation or structural threats
5. The 2–3 most credible sources for these numbers
Be specific about data quality. Tell me if numbers are estimates, analyst
projections, or reported figures. Flag any data older than 3 years.
3
Competitor Mapping
Map the competitive landscape for [PRODUCT CATEGORY].
Give me:
— 3–5 direct competitors (products that solve the same problem)
— 2–3 indirect competitors (different approach, same user need)
— 1–2 adjacent players (not direct competitors, but entering this space)
For each include: company name, product name, target user, pricing model,
and one-line description of what makes them notable.
Format as a table.
4
User Sentiment Analysis
For the direct competitors listed above, analyse publicly available user
feedback from G2, Capterra, App Store reviews, and Reddit.
I want:
— Top 5 things users consistently praise across these products
— Top 5 things users consistently complain about across these products
— 2–3 unmet needs that appear repeatedly but no product currently addresses well
Group these into themes, not individual quotes. Be specific about which
competitor each finding comes from where relevant.
5
Feature Gap Analysis
Here are the features the client mentioned or implied during discovery:
[PASTE FEATURE LIST FROM DISCOVERY SUMMARY]
Based on the competitor research above, classify each feature as:
— TABLE STAKES: Features users expect as standard
— DIFFERENTIATOR: Features that provide genuine competitive advantage
— GAP: Unmet needs that no current competitor addresses well
Then suggest 2–3 additional features not mentioned by the client that the
market data suggests users want.
Format as a table with columns: Feature | Classification | Rationale.
6
PRD v0.1 Draft Synthesis
This is an assembly prompt. Do not generate new research.
Use only what we have established in this session.
Assemble a Validated PRD v0.1 with these seven sections:
1. Problem Statement — the real problem, for whom, and at what cost if unsolved
2. Market Context — size, growth, and key dynamics with sources cited
3. Target User Profile — primary user, secondary stakeholders, core needs
4. Competitive Position — who we compete against, what we do differently
5. MVP Feature Set — table stakes + top differentiators only, each with rationale
6. Out of Scope — what is explicitly not in v1, and why each item is deferred
7. Open Questions — what still needs to be validated before the proposal
Write in clear professional English. Do not pad.
Every line must earn its place.
7
Scope Definition Document — converts PRD v0.1 into an estimation input
I have a validated PRD v0.1. Convert it into a Scope Definition Document.
This document is internal — not shown to the client. Its purpose is to give
the estimation team a precise, unambiguous picture of what will be built.
--- PRD v0.1 ---
[PASTE YOUR PRD v0.1 HERE]
--- END PRD v0.1 ---
Produce a Scope Definition Document with exactly these seven sections:
1. DELIVERABLES LIST — concrete things the team will produce and hand over
2. IN SCOPE — explicit list of what is included
3. OUT OF SCOPE — explicit list of what is excluded, with a reason for each
4. ASSUMPTIONS — things that must be true for this estimate to hold
5. DEPENDENCIES — what must exist before work can begin
6. OPEN RISKS — unknowns that could materially change the scope or estimate
7. ESTIMATION BOUNDARY — a plain-English summary of what this estimate covers
Write precisely. Use bullet points within each section. No marketing language.
After Prompt 7
The Scope Definition Document feeds directly into Module 3 as the primary estimation input. Every assumption listed here becomes a risk if violated. Read it as the estimation team — can they start scoping without asking you any clarifying questions? If not, add more detail.
Part 5 of 7 — Live Examples
Two complete prompt flow walkthroughs
One product build scenario and one data/support scenario. Each shows the starting brief, key prompt outputs, and what the feature gap analysis looks like in practice.
Example A · Product Build · Field Service Management
HVAC Field Service Scheduling & Dispatch Platform
Mid-sized HVAC maintenance company. All dispatch managed via WhatsApp and spreadsheets. Losing approximately 30% of bookings to competitor response time. 40 field technicians, 5 office dispatchers. No existing software.
Prompt 2 Output — Market Size
The global field service management software market is estimated at $6.2B (2023) growing at 11.4% CAGR through 2028. Key growth drivers: labour shortage forcing automation, IoT-connected equipment enabling predictive dispatch, post-COVID acceleration of mobile-first operations.
PM note
The "$6.2B market" is not the client's addressable market. The PM's job is to narrow this to the relevant segment — mid-market HVAC SMBs, specific geographies. This is the judgement AI cannot make for you.
Prompt 3 Output — Competitor Map
Competitor
Key Notes
ServiceTitan
Enterprise FSM for home services. Dominant in US HVAC. Expensive ($500+/user/mo). Praised for job tracking. Criticised for steep learning curve and being overkill for small teams.
Jobber
SMB-focused. Simpler UI, cheaper pricing ($50–150/mo). Strong in landscaping and cleaning. HVAC users find it lacks technician routing intelligence.
FieldEdge
HVAC-specific. Good equipment history tracking. Limited mobile UX. Often described as "clunky but functional."
HouseCall Pro
Strong mobile-first for technicians. Good customer communication. Dispatcher dashboard is weak.
Prompt 5 Output — Feature Gap Analysis
Feature
Classification
Rationale
Job scheduling calendar
TABLE STAKES
Every FSM tool has this. Expected by default.
Technician mobile app
TABLE STAKES
Standard across all competitors.
Real-time technician location tracking
DIFFERENTIATOR
Offered by enterprise tools only. Mid-market gap.
Intelligent job routing (proximity + skill match)
DIFFERENTIATOR
Poorly executed across most competitors. Strong win area.
Customer SMS notifications (booking, ETA)
DIFFERENTIATOR
Available but not universal. High user demand in reviews.
Equipment service history per site
GAP
HVAC-specific. Most FSM tools handle this poorly. High switching cost once it exists.
WhatsApp integration for legacy transition
GAP — Additional
Not in client brief, but migration from WhatsApp is their exact pain. Reduces adoption friction significantly.
Example B · Data / Support AI · B2B SaaS
AI-Powered Tier-1 Customer Support Deflection System
B2B SaaS company selling accounting software to SMBs. Support volume grown 3× in 18 months while team grew 20%. Support team of 12 handling 4,000 tickets/month. Target: deflect 40% of tickets without adding headcount. Existing stack: Zendesk, Slack, proprietary billing system.
Prompt 2 Output — Market Context
The conversational AI and chatbot market for customer support is $1.3B (2023), growing at 23% CAGR. Differentiation now comes from quality of knowledge base integration, not NLP sophistication.
Critical PM note
ROI on support AI is highly sensitive to ticket complexity distribution. If over 60% of tickets are genuinely Tier-1, deflection targets of 40–50% are achievable. If the mix is more complex, 20–25% is more realistic. The PM must validate ticket type distribution before committing to a deflection target in the proposal.
Prompt 4 Output — User Sentiment Themes
✓
Recurring praises: Fast time-to-value when knowledge base quality is high · Customers appreciate 24/7 availability · Good analytics on deflected vs escalated tickets
✗
Recurring complaints: Hallucinations on product-specific queries when knowledge base is not maintained · Poor handoff experience — customer must repeat the whole problem · Difficult to measure true deflection vs ticket suppression · No memory between sessions
Prompt 5 Output — Feature Gap Analysis
Feature
Classification
Rationale
FAQ / knowledge base Q&A chatbot
TABLE STAKES
Every support AI tool does this.
Zendesk integration for ticket creation and escalation
TABLE STAKES
Standard integration — must-have given client stack.
Contextual escalation: conversation summary passed to human agent
DIFFERENTIATOR
Consistently missing or poorly executed in reviews. High CSAT impact.
Ticket category and deflection analytics dashboard
DIFFERENTIATOR
Strong demand in reviews. Critical for the client to justify ROI internally.
Knowledge base gap detection (questions AI couldn't answer)
DIFFERENTIATOR
Not widely implemented. High operational value.
Proactive in-app nudges based on user behaviour patterns
GAP — Additional
Not in client brief, but platform has usage data. Could reduce ticket volume upstream.
Part 6 of 7 — Quality Gate
Do not move to Module 3 until this checklist is complete
Every item must be confirmed before you treat the PRD v0.1 as ready. If you can't check an item, go back and fill the gap.
📄 Validated PRD v0.1📄 Scope Definition Document
Market Research
✓
I have an estimate of addressable market size with at least one credible source cited
✓
I know whether the market is growing, flat, or shrinking — and why
✓
I have confirmed the client's target segment is distinct enough to be viable
Competitor Intelligence
✓
I have mapped at least 4 direct competitors and 2 indirect competitors
✓
I know what users consistently complain about across the competitive set
✓
I know what 1–2 unmet needs exist that no current competitor addresses well
Feature Strategy
✓
Every feature from the Discovery Summary has been classified: table stakes, differentiator, or gap
✓
I have identified at least 1 feature not in the original brief that market data supports
✓
I have a clear out-of-scope list for v1 — and a reason for each item
PRD v0.1
✓
The PRD has all 7 sections: Problem Statement, Market Context, User Profile, Competitive Position, Feature Set, Out of Scope, Open Questions
✓
Every market data point in the PRD has a source or a stated level of confidence
✓
I have done a 20-minute peer review with someone who knows the domain
Scope Definition Document
✓
I have a deliverables list that names concrete hand-over items — not features, not capabilities, but actual things the team produces
✓
Every assumption the estimate will rest on is written down
✓
I can hand this document to the estimation team and they can begin scoping without asking me clarifying questions
✅ Module 2 complete. You have a Validated PRD v0.1 and a Scope Definition Document. Take these into Module 3 — Price it Right.
Part 7 of 7 — Quick Reference
Recommended tools and common mistakes
Tool
Best Used For
Claude / ChatGPT
Primary research synthesis, competitor summaries, PRD drafting. Use with web browsing enabled for up-to-date market data.
Perplexity AI
Market research with live citations. Reduces hallucination risk on market size data. Good for regulatory context.
Google Trends
Validate whether search interest in your product category is growing or declining. Free and fast.
G2 / Capterra
Primary source for competitor user reviews. Read the 3-star reviews — they are the most useful.
Product Hunt
Understand recent launches in the space and early user reactions. Good for spotting gaps.
LinkedIn / Reddit
User communities surface real pain points more honestly than formal review sites.
Common mistakes — and how to avoid them
Mistake
How to Avoid It
Using total industry TAM instead of the addressable segment
Narrow the market to the segment the client can realistically win. A $10B market is irrelevant if the client is targeting a $50M niche.
Treating AI competitor research as ground truth
AI can hallucinate product features and pricing. Always spot-check 2–3 competitors manually on their actual website or G2 page.
Listing features without classification
A feature list without table stakes / differentiator / gap labelling is just a wish list. It does not help with prioritisation or pricing.
Skipping the Open Questions section
What you still don't know is as important as what you do. Include it in every PRD v0.1.
Writing a PRD you cannot defend
If someone asks "why is this feature in the MVP?" you must have an answer beyond "the client asked for it."
✅ Ready for Module 3 — Price it Right, where you take the PRD v0.1 and Scope Definition Document and use them to build a defensible effort estimate covering timeline, team composition, cost, and AI savings.
Module 3 of 8 · Price it Right
AI-Powered Product DeliveryModule 3 of 8Pre-Sales Track
Price it Right
How to build a defensible effort estimate — covering workstreams, team composition, timeline phasing, AI savings, and proposal pricing — for any project type and any engagement type.
Your progress0%
Part 1 of 7 — The Mindset
The number you give is a commitment, not a guess.
A senior stakeholder asks for a ballpark. You give a number. Two weeks later that number has become the client's expectation, the internal budget, and the project success criterion — even though you had almost no information when you said it.
A defensible estimate is not the same as an accurate estimate. Accuracy is a function of information you don't yet have. Defensibility is a function of the rigour you applied to the information you do have. You are responsible for defensibility. You are not responsible for information that doesn't exist yet — as long as you named the gap as an assumption.
Three things good estimators do differently
1
They separate what they know from what they are assuming
Every estimate contains facts and assumptions. Good estimators make assumptions explicit. Bad estimators treat assumptions as facts and get surprised when they are wrong.
2
They involve the people who will do the work
The most accurate estimates come from the people who will actually do the work — not from a senior PM estimating on their behalf. Get the relevant specialists involved early, even for a few hours.
3
They think in phases, not totals
A single total number hides everything. A phased estimate — who is involved when, at what intensity — forces you to think through the work properly and gives the client a picture they can actually evaluate.
⚠ The most dangerous words in estimation: "It should be roughly similar to the last one." Analogical thinking is a valid starting point. It is not a finishing point. Use it to sanity-check, not to replace bottom-up analysis.
What you are bringing in from Module 2
Document
How it is used in Module 3
Validated PRD v0.1
Tells you what the product must do and which features are in MVP scope. Informs workstream identification.
Scope Definition Document
The primary estimation input. Every workstream, role, and hour estimate maps to a deliverable in this document.
If Module 2 was skipped (support or augmentation engagement): use your Discovery Summary from Module 1 as the input. Prompt 1 below handles both cases.
Part 2 of 7 — What to Know Before You Estimate
Project type, engagement type, and complexity drivers
Estimation requires knowledge about the work itself and the context it will be delivered in. Missing either produces an estimate that will not survive contact with reality.
Web + iOS + Android multiplies QA effort significantly. Each platform needs independent testing.
Mobile, Cloud Native
Model training data requirements
If labelled training data does not exist, creating it is a significant workstream often missed in early estimates.
Data Platform with AI, LLM
Greenfield architecture decisions
When there is no existing system, architecture decisions take longer and have more downstream impact.
New builds across all types
The three AI savings layers
Layer 1 — PM/PO Phase Savings
AI-assisted discovery, research, spec writing, and handoff (Modules 1, 2, 4, 5, 6). Saves time on the PM's hours before and during the build phase. Well-supported by McKinsey research on knowledge work acceleration.
Layer 2 — Development Phase Savings
AI-assisted coding tools (Cursor, GitHub Copilot, Claude Code) applied to eligible workstreams. GitHub and DORA research shows 18–26% productivity gains on well-structured coding tasks. Not applicable to architecture, complex state management, or integration debugging.
Layer 3 — Rework Savings
Better specs and structured handoff (Modules 5, 6, 7) reduce mid-sprint change requests. Accenture and MIT research shows structured requirements reduce rework by 40–60%. This layer grows the more rigorously the spec process is followed.
Part 3 of 7 — The Process
Eight steps from scope to priced proposal
Steps 1–5 build the raw estimate. Steps 6–8 layer in AI savings and convert the estimate into a client-facing proposal. Do not skip ahead to pricing before the raw estimate is complete.
Estimation methods — choose the right one
Method
When to use
Accuracy
Time to produce
Analogical
Early-stage, quick ballpark needed. Use a similar past project as reference and apply adjustments.
Low–Medium
1–2 hours
Bottom-up
Final proposal before SOW is signed. Break scope into deliverables, estimate each with specialists, then aggregate.
High
4–8 hours with team
Parametric
You have historical data on similar project types. Apply known productivity rates to the scope.
Medium–High
2–3 hours
1
Confirm project type and engagement type
Read your Scope Definition Document. Name both explicitly. Write them at the top of your estimation worksheet. Everything downstream flows from this.
2
Map the workstreams
Based on the project type, list every workstream this engagement requires. A workstream is a distinct body of work with its own roles and deliverables. Do not merge workstreams — each needs its own estimate.
3
Build the role and hours matrix
For each workstream, identify: which roles are needed, at what seniority level, and how many hours each role requires. Involve the relevant specialists — a senior backend engineer estimating backend hours is more accurate than a PM doing it alone.
4
Apply complexity adjustments
Review the complexity drivers from Part 2. For each one that applies, add a justified percentage uplift to the affected workstream hours. Do not apply a blanket uplift to everything — complexity is specific to specific workstreams.
5
Add buffer — with reasoning, not by habit
Well-defined enhancement: 10–15%. New build with moderate complexity: 15–25%. Greenfield with significant unknowns or integrations: 25–35%. Write down what the buffer is covering. Named risks from the Scope Definition Document belong in the buffer.
6
Phase the timeline
Convert the hours matrix into a phased timeline showing who is involved when. Architects and UX designers are front-loaded, engineers dominant in build, QA ramping up as features complete, DevOps active at start and launch. Map this as a Gantt or phase table — this is the artefact the client sees.
7
Layer in the AI savings
Identify which parts of the estimate are affected by AI tooling. Express each saving layer as a reduction in hours with a stated rationale. The calculator carries the specific percentages — your job is to tell the story clearly.
8
Build the proposal pricing document
Convert hours into cost using your rate card. Show gross estimate, AI savings, AI tool costs, net cost, and ROI on the AI investment. Every number must trace back to a line in your estimation worksheet in under 60 seconds.
Human in the loop: Before the estimate leaves the building, do a 30-minute internal review with the delivery lead or solutions architect. Ask them to challenge your workstream coverage, seniority mix, and buffer reasoning. An estimate not challenged internally will be challenged externally — at a much worse time.
Part 4 of 7 — Prompt Toolkit
Five prompts to run the estimation process end to end
Run these in a single AI session in sequence. Prompt 1 loads context from Module 2. Prompts 2–4 build the estimate progressively. Prompt 5 assembles the client-facing proposal narrative.
1
Context Setter — feeds from Module 2 outputs
I am a Product Manager building an effort estimate and proposal for a client engagement.
I am going to paste two documents from my pre-sales research. Use both as context.
--- VALIDATED PRD v0.1 ---
[PASTE YOUR VALIDATED PRD v0.1 HERE]
--- END PRD v0.1 ---
--- SCOPE DEFINITION DOCUMENT ---
[PASTE YOUR SCOPE DEFINITION DOCUMENT HERE]
--- END SCOPE DEFINITION DOCUMENT ---
Note: If Module 2 was skipped, paste the Discovery Summary from Module 1 instead.
From these documents, confirm back to me:
1. The project type (Cloud Native / Mobile / Data Platform / AI–LLM / Enterprise Integration / Platform Infra)
2. The engagement type (new build / enhancement / support / augmentation)
3. The complete deliverables list from the Scope Definition Document
4. The key assumptions and dependencies that will affect the estimate
5. Any open risks that could materially change the scope
2
Workstream and Role Matrix
Based on the context above, build me a workstream and role matrix for this engagement.
For each workstream:
— Name the workstream
— List the specific deliverables from the Scope Definition Document that belong to it
— List the roles needed to complete those deliverables
— Recommend the seniority level for each role with a one-line justification
— Flag any roles where specialist input is strongly recommended before hours are assigned
Also flag any workstreams commonly missed for this project type that should be considered.
Format as a table: Workstream | Deliverables | Roles | Seniority | Notes.
3
Hour Estimates and Complexity Adjustments
Using the workstream and role matrix above, estimate the hours for each role in each workstream.
For each role-workstream combination:
— Provide a base hour estimate (optimistic — everything goes smoothly)
— Provide a realistic hour estimate (normal variation, some rework, standard delays)
— Identify which complexity drivers apply and adjust accordingly
Complexity drivers for this project:
[LIST THE COMPLEXITY DRIVERS THAT APPLY FROM YOUR SCOPE DEFINITION DOCUMENT]
For each complexity driver that applies:
— Name the workstream(s) it affects
— Estimate the additional hours it adds
— State the assumption you are making about its impact
Then produce a summary table:
Workstream | Role | Seniority | Base Hours | Realistic Hours | Complexity Add-on | Total Hours.
4
Timeline Phasing and Gantt Structure
Using the hours matrix above, build a phased timeline for this engagement.
Total estimated hours: [TOTAL HOURS FROM PROMPT 3]
Preferred team size range: [E.G. 4–8 PEOPLE CONCURRENT]
Fixed deadlines or milestone constraints: [LIST ANY FROM SCOPE DEFINITION DOCUMENT]
For each phase:
— Name the phase and its primary objective
— List which roles are active and at what % allocation
— Estimate the phase duration in weeks
— List the key deliverables completed
— List the key milestones or decision points at the end
Then produce:
(1) A phase summary table suitable for showing to the client
(2) A text-based Gantt structure showing role involvement across phases
Flag any timeline risks — dependencies that could delay a phase if not met.
5
AI Savings Layer and Proposal Narrative
I now need to build the AI savings layer and write the proposal pricing narrative.
Raw estimate summary:
Total hours without AI: [TOTAL HOURS]
Total cost without AI (at blended rate): [GROSS COST]
AI savings inputs (from the calculator):
PM/PO phase saving: [% REDUCTION IN PM/PO HOURS]
Development phase saving: [% REDUCTION IN DEV HOURS FOR ELIGIBLE WORKSTREAMS]
Rework saving: [% REDUCTION IN REWORK ESTIMATED]
AI tool cost: [MONTHLY COST × PROJECT DURATION]
Produce:
1. THREE-LAYER SAVINGS BREAKDOWN
Layer 1 — PM/PO phase savings: what was saved and why
Layer 2 — Development savings: which workstreams, what tools, what was saved
Layer 3 — Rework savings: how better specs reduced mid-sprint changes
2. PROPOSAL PRICING SUMMARY TABLE
Gross hours | Gross cost | AI tool investment | Net saving | Net cost | ROI
3. CLIENT-FACING NARRATIVE (2–3 paragraphs)
Plain business English. No jargon. No marketing language. Every sentence must be true.
4. ANTICIPATED CLIENT PUSHBACK (3–5 questions)
Exact question + one-paragraph honest answer for each.
On the AI savings conversation
Clients will ask: "How do I know the savings are real?" Your answer must not be a percentage from a report. It must be a specific, honest explanation of what your team does differently because of AI, where that saves time, and what it does not affect. Know all three layers before you walk into the room.
Part 5 of 7 — Live Examples
Two complete estimation walkthroughs
Example A is a Cloud Native new build. Example B is a Data Platform with AI/ML project. Each shows the full flow from Scope Definition Document to priced proposal with AI savings.
Example A · Cloud Native · New Build · B2B SaaS
Multi-Tenant Construction Project Management Platform
Core features: project scheduling, document management, subcontractor coordination, mobile app for field teams. Integrations: accounting system (client API) + weather data feed. 6-city pilot before full launch.
Prompt 2 Output — Workstream & Role Matrix (condensed)
Workstream
Roles
Seniority
UX Design
UI/UX Designer
Senior — multi-user, complex info architecture
Backend API
Backend Engineers ×2, Solutions Architect
Senior Architect, Mid Engineers
Web Frontend
Frontend Engineers ×2
Mid-level — well-defined component structure
Mobile (React Native)
Mobile Developer
Senior — offline sync is complex
QA
QA Engineers ×2
Mid-level
DevOps
DevOps Engineer
Senior — multi-tenant infra requires careful design
Project Management
PM
Senior PM
Prompt 3 Output — Hours Summary
Workstream
Base
Complexity add
Total
Note
UX Design
180h
+20h
200h
Multi-tenant UX, role-based views
Backend API
480h
+80h
560h
Multi-tenancy + 2 integrations
Web Frontend
320h
+40h
360h
Admin portal scope larger than standard
Mobile
240h
+60h
300h
Offline sync adds complexity
QA
200h
+40h
240h
Cross-platform device matrix + regression
DevOps
100h
+20h
120h
Multi-tenant infra, two environments
PM
180h
—
180h
Standard PM overhead
Buffer (20%)
392h
Greenfield, 2 integrations, offline mobile
TOTAL
2,352h
Prompt 5 Output — Proposal Pricing with AI Savings
Gross hours (without AI)2,352 hours
Gross cost at blended rate ($85/hr)$199,920
Layer 1 — PM/PO phase saving−$1,700 (20h)
Layer 2 — Development saving (AI coding tools)−$18,700 (220h)
ROI on AI investment: 7.6× — $27,200 total saving on $3,600 AI tool investment. Layer 2 (development) is the largest saving. Layer 3 (rework) grows as spec discipline improves across the team.
Example B · Data Platform + AI/ML · Retail · Enterprise
Demand Forecasting Platform — 200+ Store Retail Group
Goal: reduce stockouts by 30%, reduce overstock by 20%. 3 years of historical sales data in a legacy ERP. Product master in a separate system. External signals (weather, local events) not currently used.
Prompt 3 Output — Hours Summary
Workstream
Realistic
Complexity add
Total
Note
Data Engineering
400h
+120h
520h
Legacy ERP unknown quality. Largest risk in estimate.
Feature Engineering
160h
+40h
200h
External data integration adds pipeline complexity
ML Modelling
280h
+40h
320h
Time-series with external signals — tuning intensive
High: legacy data risk, ML uncertainty, new tech stack
TOTAL
2,050h
AI savings note for Data & AI/ML projects: AI coding tool savings are lower on data engineering work (pipeline logic is bespoke and requires domain understanding) but higher on dashboard and API layer work. The most significant saving on this project type is in PM/PO phase work and rework reduction. The single largest cost risk is data quality in the legacy ERP — surfaced by better upfront requirements, not discovered after the first pipeline run.
Part 6 of 7 — Quality Gate
Do not share the estimate until this checklist is complete
Every item below must be confirmed before the estimate leaves your hands. Gaps surface during delivery — at ten times the cost.
Codebase ramp-up time, regression risk, hidden dependencies
Support and maintenance
10%
Ticket volume variance, escalation handling time
Team augmentation
N/A
Buffer is in the rate, not the hours
✅ Ready for Module 4 — Draw the Journey, where you move from proposal to delivery — building user flows, UX blueprints, and screen-level designs using AI tools.
Module 4 of 8 · Draw the Journey
AI-Powered Product DeliveryModule 4 of 8Delivery Track
Draw the Journey
How to use AI to build user flows, UX blueprints, and screen-level designs — turning a validated PRD into a design-ready artefact that engineering can actually implement.
Your progress0%
Part 1 of 7 — The Mindset
You are not making it look good. You are making it work.
Design in a delivery context is about reducing ambiguity. Every screen you produce, every flow you map, every edge case you document reduces the number of decisions engineering has to make without you.
Design that leaves interpretation to engineering is not finished design. It is deferred decision-making with a higher price tag. Every ambiguous wireframe note that says "TBD" or "as discussed" is a future sprint disruption waiting to happen.
The PM's role in this phase
→
Before design starts: you own the brief
You provide the PRD v0.1 and Scope Definition Document. You run a brief alignment session with the designer. You confirm the screen inventory and user personas before a single wireframe is opened.
→
During design: you review, not redesign
You review the UX Blueprint for completeness — are all user journeys covered, are edge cases addressed, does this match the PRD scope? You do not tell the designer how to lay out a screen. You tell them when something is functionally missing.
→
After design: you sign off before engineering sees it
No design artefact goes to engineering without PM sign-off on functional completeness. Visual polish is the designer's responsibility. Functional completeness is yours.
Human skills AI cannot replace in this phase
Knowing which user journey actually matters most to the business outcome — not just which one the client mentioned first
Recognising when a proposed flow creates friction that will hurt adoption even if it is technically correct
Reading a wireframe and seeing what is missing — the empty state, the error state, the mobile breakpoint
Deciding when a design is good enough to go to engineering versus when another review cycle is needed
Mediating between what the client wants visually and what engineering can actually build in the time available
When does this module apply?
Engagement type
Does Module 4 apply?
New product build
Always applies — full UX journey from IA through to Figma-ready designs
Significant new feature
Usually applies — new screens and changed flows need UX design work
Enhancement or iteration
Partially applies — focus on wireframe and handoff sections only
Support or maintenance
Does not apply — skip to Module 5
Team augmentation
Does not apply — client team owns design. Skip to Module 5
Part 2 of 7 — What to Know Before Design Starts
Five things a designer must know before opening Figma
Design cannot begin productively until the PM and designer share a clear, aligned picture of what is being built. The inputs exist — they came from Modules 1 through 3.
What the designer needs
Where it comes from
Who the user is
Not in general terms — specifically. Role, context, technical literacy, device environment, frequency of use. From Module 1 Discovery Summary and PRD v0.1.
What the user is trying to accomplish
The primary jobs to be done. What does a successful session look like from the user's perspective? Drives flow design and information architecture decisions.
What screens or surfaces exist
The complete list of pages, screens, views, and states in scope — not features, screens. The screen inventory comes from the Scope Definition Document deliverables list.
What is explicitly out of scope
The designer must know what not to design. Out-of-scope items create scope creep when they appear in wireframes without agreement.
What constraints exist
Technology stack (affects what interactions are possible), brand guidelines, accessibility requirements, responsive breakpoints, and any third-party component libraries in use.
The four design artefacts — know which ones are required
User Flow Diagram
A map of how a user moves through the product — screens, decisions, entry and exit points, error paths, and edge cases. Produced before wireframes. The skeleton that everything else hangs from.
Every engagement where design is in scope
UX Blueprint / Screen Outline
A structured document listing every screen by name and ID, its purpose, primary user action, key components, entry points, exit paths, and edge cases. No visual design — structure only.
Every engagement where design is in scope
Wireframes
Lo-fi visual representation of each screen — layout, hierarchy, content placement. No colour, no brand. Produced in Figma. Reviewed and approved before hi-fi design begins.
Most product builds
Interactive Prototype
Clickable Figma file or Lovable-generated prototype showing real interactions and navigation. Used for client validation, usability testing, and engineering briefing.
Client presentations, usability testing
What the UX Blueprint must contain — and must not
✓ Must contain
Executive overview in plain language
All user personas with mapped journeys
Happy path for every core user flow
Alternate flows and edge cases
Entry and exit conditions per screen
Navigation logic — what links to what and why
✗ Must not contain
Technical validations or backend logic
Field-level validation rules (those go in Module 5)
Visual or pixel design specifications
Any feature not in the PRD scope without PM agreement
Part 3 of 7 — The Process
Nine steps from PRD to engineering-ready design pack
This is the standard process a PM and designer follow from receiving the PRD to handing a design-ready artefact pack to engineering. AI accelerates several steps significantly — but none can be skipped.
1
Run the design brief alignment session
PM and designer meet for 60–90 minutes. Walk through the PRD v0.1 and Scope Definition Document together. Output: confirmed screen inventory, confirmed persona list, and a list of open design questions that need answers before work begins. Do not skip this session.
2
Build the screen inventory
Before any user flow is drawn, produce a complete list of every screen in scope. Name each one, give it a screen ID (S-01, S-02...), and write a one-sentence description of its purpose. If a screen is not on this list, it should not be designed. AI is excellent at this — Prompt 1 does it.
3
Map the user flows
For each primary user journey, map the complete flow: entry point, happy path, decision points, alternate paths, error states, empty states, and exit points. Start with the happy path — then add alternate flows, then edge cases. AI generates edge cases designers often miss under time pressure — Prompt 2 covers this.
4
Produce the UX Blueprint
For every screen, document: screen ID and name, entry points, primary user action, key UI components (structurally, not visually), exit paths, and edge cases specific to this screen. PM reviews and signs off on the Blueprint before wireframes begin. This is Gate 1.
5
Design wireframes in Figma
With the Blueprint signed off, the designer produces lo-fi wireframes for every screen. No colour, no brand at this stage — layout, hierarchy, content placement only. Wireframes reference Blueprint screen IDs so every wireframe traces back to a documented screen purpose.
6
Fill all interaction states
Every screen has multiple states: default, hover, focus, active, disabled, loading, empty, error, success. All states must be designed before the wireframe is considered complete. This is the most commonly missed step — and the most common cause of rework during engineering.
7
Build the interactive prototype (if in scope)
Two paths: (A) Figma prototype — link wireframe screens together for a clickable demo. (B) Lovable / v0 / Emergent — feed the Blueprint and wireframes into a tool that generates an interactive HTML prototype. Best for client demos before engineering begins.
8
PM review and sign-off
Before anything goes to engineering, the PM reviews against three criteria: (1) Does every screen in the screen inventory have a wireframe? (2) Does every wireframe have all required states? (3) Does the design match the PRD scope — nothing missing, nothing added? This is Gate 2. Design changes after this require change control.
9
Package and hand off to engineering
The complete design artefact pack: UX Blueprint, Figma file with all wireframes organised by screen ID, prototype link if applicable, and a design QA checklist for engineering. The designer walks the engineering lead through the Figma file. Non-obvious design decisions are annotated with rationale notes.
Human in the loop: The PM signs off at Step 4 (Blueprint) and Step 8 (wireframes). These are the two gates where scope drift is most likely — features added silently, screens out of scope quietly included. Review with the PRD and Scope Definition Document open side by side.
Part 4 of 7 — Prompt Toolkit
Six prompts to run the design phase end to end
Each prompt maps to a specific step in the process. Prompt 1 feeds directly from your PRD v0.1 and Scope Definition Document from Module 2. Carry your prior outputs forward — do not start fresh.
1
Screen Inventory Generator
I am a PM preparing a design brief for my UX designer.
I need a complete screen inventory for this product.
--- PRD v0.1 ---
[PASTE YOUR PRD v0.1 HERE]
--- END PRD ---
--- SCOPE DEFINITION DOCUMENT ---
[PASTE YOUR SCOPE DEFINITION DOCUMENT HERE]
--- END SCOPE DEFINITION DOCUMENT ---
For each screen, produce:
— Screen ID (S-01, S-02, etc.)
— Screen name (clear, functional — not marketing language)
— One-sentence description of what the user does on this screen
— User persona this screen primarily serves
— Whether this screen is in the happy path, alternate flow, or edge case
Then flag: any screens implied by the PRD not explicitly listed in scope,
and any scope items that do not obviously map to a screen.
Format as a table. Do not design anything — this is inventory only.
2
User Flow Mapper — including edge cases
Map the complete user flow for: [FLOW NAME e.g. "New user onboarding" or "Submit a service request"]
Product context: [ONE SENTENCE PRODUCT DESCRIPTION]
Primary user: [PERSONA NAME AND ROLE]
Entry point: [HOW THE USER ARRIVES AT THIS FLOW]
Goal: [WHAT SUCCESS LOOKS LIKE FOR THIS USER]
Produce the flow as a numbered sequence. For each step include:
— What the user sees
— What the user does
— What the system does in response
— Any decision point (yes/no, success/fail)
After the happy path, document:
— Two to three alternate flows (user takes a different valid path)
— Error states (what happens when something goes wrong)
— Empty states (what the user sees when there is no data)
— Permission edge cases (user without access tries to proceed)
— Assumptions I should validate before writing specs
Format as a numbered flow I can hand to a designer to replicate in Figma.
3
UX Blueprint Screen Outline Generator
I am building a UX Blueprint for: [PRODUCT NAME AND ONE-LINE DESCRIPTION]
Screen inventory: [PASTE SCREEN INVENTORY FROM PROMPT 1]
User flows: [PASTE USER FLOWS FROM PROMPT 2]
For each screen, produce a Blueprint entry with:
— Screen ID and name
— Entry points: how does a user arrive at this screen?
— Primary user action: the one thing the user most needs to do here
— Key UI components: structural elements only (e.g. data table, form, nav bar)
— Exit paths: where can the user go from here?
— Edge cases: what states does this screen need to handle?
Also produce a one-paragraph executive overview of the product at the top.
This document is for PM review and engineering reference.
No visual design language. No pixel specifications. Structure only.
Gate 1 — PM sign-off required here
Review the Blueprint against the PRD v0.1 and Scope Definition Document before wireframes begin. Every screen must trace back to an agreed deliverable. Nothing added, nothing missing.
4
AI Design Critique — before PM review
Act as a senior UX designer reviewing a wireframe for a [PRODUCT TYPE e.g. B2B SaaS / mobile app / internal dashboard].
Screen: [SCREEN NAME AND ID]
Screen purpose: [WHAT THE USER DOES ON THIS SCREEN]
Primary user: [PERSONA]
Wireframe description: [DESCRIBE THE LAYOUT, COMPONENTS, AND HIERARCHY IN PLAIN TEXT]
Review for:
1. Visual hierarchy — is the most important thing the most prominent?
2. Missing states — list any states not accounted for
3. Cognitive load — is there too much on one screen?
4. Navigation clarity — is it obvious how to proceed and go back?
5. Accessibility signals — touch targets, contrast, keyboard navigation
6. Consistency — any components that contradict standard patterns?
Score each area 1–5. Give one specific, actionable improvement for any area scoring below 4.
5
Interaction State Inventory
I am completing wireframe design for: [SCREEN NAME AND ID]
Screen purpose: [WHAT THE USER DOES HERE]
Key components on this screen: [LIST THE MAIN UI COMPONENTS]
For each state, describe what the user sees and what triggers it:
— Default state: screen as it first loads for a returning user with data
— Loading state: data is being fetched
— Empty state: user has no data yet (first-time or cleared)
— Error state: something went wrong (network, validation, permission)
— Success state: user completed an action successfully
— Disabled state: user cannot take an action (permissions, prerequisites)
— Mobile state: if this screen has a different layout on smaller screens
Flag any state that is particularly complex or likely to be misunderstood
by engineering without a design annotation.
6
Design Handoff Spec Generator
I am preparing a developer handoff spec for: [COMPONENT NAME e.g. "Data table with filters"]
Product: [PRODUCT NAME]
States: [LIST STATES]
Design decisions needing rationale: [LIST KEY DECISIONS e.g. "sticky header", "modal on mobile"]
Produce a developer handoff spec:
1. Component description: what it does and when it appears
2. States table: state | trigger | what the user sees | engineering note
3. Interaction behaviour: animations, transitions between states
4. Responsive behaviour: how this changes across 375px / 768px / 1280px
5. Accessibility requirements: ARIA labels, keyboard nav, focus management
6. Design rationale: one-paragraph explanation per decision that a developer
can use to make a judgment call if they hit a constraint during implementation
Format for a React component spec.
Flag any spec element that is technically non-trivial to implement.
Part 5 of 7 — Tools for This Phase
AI and design tools — what each one does and when to use it
No single project needs all of these. Choose based on what the engagement requires. Each tool has a specific job — using the right tool for the right step matters.
Tool
What it does
When to use it
Figma
The industry standard design tool. All wireframes, hi-fi designs, and interactive prototypes live here. Every design engagement uses Figma. Non-negotiable.
Steps 5, 6, 9 — wireframes, states, handoff
Figma AI
AI-assisted features within Figma: auto-layout suggestions, content generation for realistic mockups, design critique. Use for speed inside Figma — not a replacement for design thinking.
Step 5 — wireframe production
Claude / ChatGPT
Primary AI tool for this module. Use for all six prompts: screen inventory, user flow mapping, Blueprint generation, design critique, state inventory, handoff spec.
Steps 2, 3, 4, 5, 6, 9
Whimsical AI
Fast AI-assisted flowcharting. Generates user flow diagrams and sitemaps from text descriptions. Useful for quickly visualising flows before translating them into Figma.
Step 3 — user flow mapping
Mermaid
Text-based diagram syntax that generates flow diagrams. Good for flows that can be version-controlled and embedded in documentation. Claude can generate Mermaid diagrams directly.
Step 3 — technical teams
Lovable / v0 / Emergent
Generative prototype tools. Convert a Blueprint or wireframe description into a working interactive HTML prototype. Best for client demos and stakeholder validation before engineering begins.
Step 7 — interactive prototype
Uizard
Converts hand-drawn sketches or screenshots into editable wireframes. Useful for rapid wireframe generation from rough sketches in early alignment sessions.
Step 5 — rapid wireframing
Dovetail AI
Research synthesis tool. Analyses user interview transcripts and feedback to extract themes, pain points, and insights. Relevant if the engagement includes user research before design.
Step 1 — if user research exists
On using Lovable and generative tools: Feed your UX Blueprint and screen inventory into the tool and iterate on the generated output. Treat the output as a client communication tool, not an engineering artefact. The Figma wireframes remain the source of truth for implementation.
Part 6 of 7 — Live Examples
Three design phase walkthroughs
Example A is a Cloud Native mobile app. Example B is a data-heavy AI dashboard. Example C is a real Ideas2IT story — a PO who used AI no-code tools to build client mockups without a dedicated designer.
Example A · Cloud Native + Mobile · Field Service Management
HVAC Field Service App — Mobile + Web Dashboard
6-person team · 6-month build · 40 field technicians + 5 supervisors · iOS and Android · Offline capability required
Prompt 1 Output — Screen Inventory (condensed)
S-01
Login / Authentication
Technician or supervisor enters credentials and authenticates · Both users · Happy path
S-02
Technician Home — Job List
Technician views assigned jobs for today in priority order · Field Technician · Happy path
S-03
Job Detail View
Technician views full job details, location, client notes, history · Happy path
S-04
Job Status Update
Technician updates job status (En route / On site / Complete) · Happy path
S-05
Photo Capture & Upload
Technician captures and attaches photos to a job · Happy path
S-06
Offline Job View
Technician views job details when connectivity is lost · Edge case
S-07
Supervisor Dashboard
Supervisor views all active jobs with real-time technician status · Dispatcher · Happy path
S-08
Job Assignment
Supervisor assigns a new job to a technician · Happy path
Both users view system alerts and status change notifications · Alternate flow
Prompt 5 Output — S-03 Job Detail State Inventory
State
What the user sees
Trigger
Default
Job details fully loaded
Technician opens a job with complete data available
Loading
Skeleton screen with loading indicators
App is fetching job details from server
Offline — cached
Full details with offline banner at top
Technician offline but job was cached
Offline — uncached
Partial data with "Full details unavailable offline"
Technician offline and job was not cached
Error — load failed
"Unable to load job details. Tap to retry."
Server error or timeout on data fetch
Completed
Read-only view with completion timestamp and photos
Job has been marked complete
Reassigned
Banner: "This job has been reassigned"
Supervisor reassigned the job while technician was viewing it
Example B · Data Platform + AI/ML · Retail · Enterprise
Demand Forecasting Dashboard — Buyer-Facing UI
200+ stores · AI-generated recommendations · Design must prioritise information hierarchy, data trust signals, and clear recommended actions over visual complexity.
Key Design Principle for AI Products
When designing interfaces that display AI-generated recommendations, the design must explicitly address three things:
1
Show the recommendation clearly
The AI's recommended action must be the most prominent element on the screen — not buried in a data table.
2
Show why the AI made that recommendation (explainability)
Every recommendation links to an explanation: what signals drove it — seasonal trend, recent sales velocity, external event? This is what separates a trusted AI tool from a black box.
3
Make it easy to accept, modify, or override
S-04 must include a mandatory reason code field when overriding. This is the training signal that improves the model over time. Not a UX nicety — a functional requirement.
Prompt 1 Output — Screen Inventory
S-01
Forecast Overview Dashboard
Buyer views summary of forecast accuracy, upcoming stock risk, and top recommended actions across all stores · Happy path
S-02
Category Forecast Detail
Buyer drills into a product category to see demand forecast by week with confidence intervals · Happy path
S-03
Recommended Order View
Buyer sees AI-generated recommended purchase orders with quantity, supplier, and urgency rating · Happy path
S-04
Order Accept / Modify / Override
Buyer accepts, modifies quantities, or overrides an AI recommendation with a reason code · Alternate flow
S-05
Model Performance View
Analyst views forecast accuracy metrics over time to assess AI model reliability · Alternate flow
S-06
Alert Centre
Buyer receives alerts for high-risk stockout or overstock scenarios requiring immediate action · Edge case
Three wireframe requirements unique to AI output screens: (1) Confidence indicators on every recommendation — high/medium/low badge or percentage. (2) Override with mandatory reason code capture — this trains the model. (3) Explainability panel linked from every recommendation. These must be in scope and in the wireframes before engineering starts.
Ideas2IT — Internal Story · Real Example
How a PO built full client mockups using AI tools — with no dedicated designer
Written by Mithun Chandar V, PO at Ideas2IT. This is a live example of the Module 4 mindset applied in practice — and proof that AI no-code tools have genuinely changed what a PO can produce independently.
The situation
Mithun needed to produce UI mockups for a client engagement but did not have a dedicated designer available at that stage of the project. Rather than waiting or producing rough sketches, he used a combination of AI no-code tools to produce realistic, interactive-feeling mockups that the client could review and validate — before engineering started.
The output: client-validated screens in a fraction of the time it would have taken through a traditional design process. The approach has since been shared internally as a reusable playbook.
The mindset shift: Director, not Designer
The core insight from Mithun's playbook is the same mindset this module teaches — but applied to the tooling layer:
"Traditional design tools require you to place every element manually. AI no-code tools require you to describe what you want clearly and guide the output. You are the director — not the camera operator."
The shift matters: a PO who understands this can produce client-reviewable mockups in hours, not days. A PO who does not understand it produces generic, unusable AI output and concludes the tools do not work.
The tools Mithun used — and when
Tool
Used for
Best for
Lovable
Building realistic-looking screens with interactivity. Primary tool for screens that need to feel like a real product.
When stakeholders need to click through something that feels real
v0 by Vercel
Specific UI components — tables, cards, modals — that would be handed off to a developer. Clean React + Tailwind output.
When the output needs to be close to production-ready
Emergent Mind
Early concept exploration. Rapid generation of multiple screen concepts to identify direction before committing to one approach.
Ideation — when you have a rough idea and want to see it visualised fast
Bolt
Full app prototype with linked flows — not just individual screens but a connected user journey.
When you need to demo a working UI to stakeholders or investors
Framer AI
High-polish landing page or marketing site for a client presentation. Design quality and visual polish matter more than functionality.
When you want to publish a live URL quickly
The layering technique — how Mithun structured his prompts
Rather than writing one massive prompt, Mithun built mockups in layers — the same way the six prompts in this module are structured:
1
Define the screen type and layout structure
Start with the big picture — dashboard, form, list, onboarding. Give the tool just enough to understand the shape of the screen.
2
Add the key data and actions
What must appear on this screen? What can the user do? Feed the user story or Blueprint entry — not the full PRD.
3
Apply visual style and tone
Minimal, bold, data-heavy, friendly — give the tool a direction. Reference a known product if it helps: "similar to Stripe's dashboard" or "clean like Notion".
4
Fix specific elements that are off
Do not start fresh when something is wrong. Tell the tool exactly what to change and what to leave alone: "Keep the overall layout. Move the chart to the top. Remove the sidebar."
Pre-flight checklist before prompting — from the playbook
Mithun's playbook includes a pre-flight check before opening any tool. This maps directly to the design brief alignment session in Step 1 of this module's process:
I know who the user is and what they are trying to do
I know what type of screen this is (dashboard / form / list / onboarding)
I know if this is mobile or desktop
I have identified the 3 most important elements that must appear
I know the visual tone I want (minimal / bold / friendly / enterprise)
I have chosen the right tool for this type of screen
When is the mockup done? When stakeholders can understand the screen without your verbal explanation. When developers know what to build — even if exact styling is TBD. A mockup is a communication tool, not a finished product. Ship it when it answers the question, not when it looks perfect.
When NOT to use these tools: When you need pixel-perfect final designs for engineering handoff — use Figma. When you have zero clarity on the user or the goal — do discovery first (Module 1). When a simple whiteboard sketch would communicate the idea just as well. AI no-code tools produce the most value when you have a clear Brief and need to move fast. They produce the least value when the problem is still unclear.
Part 7 of 7 — Quality Gate
Do not hand design artefacts to engineering until this is complete
Design that goes to engineering incomplete is more expensive to fix than design that takes one more day to finish.
📄 UX Blueprint📄 Screen Inventory🎨 Figma Wireframes🔗 Prototype Link
Brief Alignment
✓
A design brief alignment session has been run between PM and designer before wireframes started
✓
The designer received the PRD v0.1 and Scope Definition Document as their primary inputs
✓
All open design questions from the alignment session have been answered
Screen Inventory
✓
Every screen in scope has been identified, named, and given a screen ID
✓
Every screen traces back to a feature or deliverable in the PRD or Scope Definition Document
✓
No screens are included that are not in the agreed scope
User Flows
✓
Every primary user journey has a complete user flow documented
✓
Each flow includes the happy path, at least two alternate flows, error states, and empty states
UX Blueprint
✓
The Blueprint has an entry for every screen in the inventory
✓
Every Blueprint entry has: entry points, primary action, key components, exit paths, and edge cases
✓
The PM has reviewed the Blueprint and signed off before wireframes began
Wireframes
✓
A wireframe exists for every screen in the screen inventory
✓
All interaction states are designed: default, loading, empty, error, success, disabled
✓
Mobile and responsive states are designed for any screen that will be used on mobile
✓
For AI/ML dashboards: confidence indicators, override capability, and explainability panels are in the wireframes
Handoff Package
✓
Figma file is organised by screen ID — no unnamed or unlabelled frames
✓
All spacing, states, and interactions are annotated in Figma
✓
An engineering walkthrough has been scheduled or completed
✅ Module 4 complete. You have a UX Blueprint, screen inventory, annotated wireframes, and a complete handoff package. Take these into Module 5 — Make it Testable.
Module 5 of 8 · Make it Testable
AI-Powered Product DeliveryModule 5 of 8Delivery Track
Make it Testable
How to convert a UX Blueprint into atomic, testable specifications and Functional Specification Documents (FSDs) that engineering can implement directly — without interpreting, assuming, or asking.
Your progress0%
Part 1 of 7 — The Mindset
A spec is not a description. It is a contract.
The most common mistake in spec writing is treating it as documentation — a record of what was discussed. A spec is a contract between the product team and the engineering team. It defines exactly what will be built, exactly how it will behave in every situation, and exactly what done looks like.
The test of a good spec is simple: can a developer who has never spoken to you about this feature implement it correctly from the document alone? If the answer is no — the spec is not finished.
Two roles, one output — who does what
PO or BA — the writer
Owns the writing of the FSD. Takes the UX Blueprint from Module 4 and converts each screen into a structured specification. Owns the accuracy of every field, rule, and behaviour described.
PM — the accountable reviewer
Does not write the FSD but is accountable for its completeness and correctness. Reviews every FSD before it is locked, confirms it matches the PRD scope, and signs off before engineering sees it.
Engineering — consulted, not driving
Reviews FSDs for technical feasibility before lock, not before they are written. The spec defines what. Engineering defines how. If engineering is writing the spec, something has gone wrong upstream.
QA — early involvement
Should receive FSDs as they are written — not at the end. Test cases are written from specs. The earlier QA reads the spec, the earlier they catch ambiguity that would surface as a bug.
What makes a spec that works vs one that does not
✓ Defines behaviour
"The email field validates on blur. If the format is invalid, an inline error appears: 'Please enter a valid email address.' The submit button remains disabled until all required fields pass validation."
✗ Describes intent
"The form validates user input."
✓ Covers the unhappy path
What happens when input is invalid, the network fails, permission is denied, or the state is empty. These fill sprint reviews with bugs when missing.
✗ Happy path only
Describes only what happens when everything works. Ignores error states, edge cases, and permission scenarios.
✓ Atomic — one behaviour per line
Each line covers one behaviour, one rule, one element. Each is independently testable. QA can write one test case per line.
✗ Compound — multiple behaviours in one paragraph
Tries to describe multiple behaviours together. Cannot be tested individually. QA cannot trace a test case to a specific line.
What AI does — and does not do — in this phase
✓ AI is excellent at
Generating complete first-draft FSD from a Blueprint entry
Identifying interaction states and edge cases the PO missed
Writing Given/When/Then acceptance criteria
Structuring spec content consistently across multiple screens
Generating a QA test case set from a completed FSD
✗ AI cannot replace
Business rules that only exist in the client's domain
Judgment on the right level of detail for this team
Knowing a rule was agreed verbally but never written down
Decisions on mobile vs desktop behaviour differences
Part 2 of 7 — FSD Structure
What a complete FSD must contain
An FSD is structured around screens, not features. One FSD section per screen, using the screen IDs from the Module 4 Blueprint. Everything inside each section follows a consistent seven-part structure.
#
Section
What it contains
1
Screen overview
Screen ID, screen name, purpose in one sentence, user persona, feature area. The orientation block — tells anyone reading the spec where they are and why this screen exists.
2
Entry conditions
What must be true for a user to arrive at this screen. Authenticated? Specific role? A prior action completed? Defines the precondition for every test case written against this screen.
3
UI component inventory
Every UI element on the screen: labels, input fields, buttons, dropdowns, data tables, navigation elements, icons. Named consistently with the wireframe and Figma file. No visual design detail.
4
Functional behaviour per component
For each interactive component: what it does, its states, what triggers each state, what happens on interaction, what validation applies. Atomic — one behaviour per line.
5
Validation rules
All field-level and form-level validation rules: which fields are required, accepted format, character limits, when validation fires, exact error message for each failure.
6
Business rules
Rules that govern the feature beyond UI behaviour. Marked as CONFIRMED, INFERRED, or ASSUMPTION. Every ASSUMPTION must be confirmed before spec lock.
7
Exit conditions and navigation
What happens after the user completes the primary action. Where do they go? What state does the system enter? Is there a confirmation? An undo? What if they navigate away mid-task?
What atomic acceptance criteria look like
Written in Given / When / Then format. Each criterion covers exactly one testable behaviour. If a QA engineer cannot write one test case directly from one criterion, it is not atomic.
✓ Good acceptance criterion
Given the user is on the login screen When they enter an email without the @ symbol Then an inline error appears: "Please enter a valid email address" And the Login button remains disabled
Specific · testable · one behaviour · exact copy specified
✗ Bad acceptance criterion
"The form should validate all fields correctly before submission."
"Correctly" is not testable · which fields? · what validation? · what happens on failure?
The five most commonly missed spec elements
Missing element
Why it matters
Empty states
What does the screen show when there is no data? Every list, table, and data view needs an empty state message and a suggested action. A blank white screen is a bug, not a design decision.
Permission states
What does a user without the required role see when they arrive at a restricted screen? An error page? A redirect? A disabled view? Almost always missing from first-draft specs.
Loading states
What does the user see while data is being fetched? How long before a timeout? What happens on timeout?
Concurrent action conflicts
What happens when two users act on the same record simultaneously? These cause the worst production bugs and are almost never in the spec.
Mobile-specific behaviour
Touch targets, collapsed navigation, swipe interactions, keyboard behaviour when a field is focused — all spec items, not design items.
Part 3 of 7 — The Process
Seven steps from Blueprint to locked spec
Steps 1–4 produce the draft FSD. Steps 5–7 validate it, fill gaps, and lock it. Do not lock a spec until all seven steps are complete.
1
Set up the FSD document structure
One FSD per product area or feature group — not one per screen (too many documents). Within each FSD, one section per screen using the screen IDs from the Module 4 Blueprint. The screen IDs become your section headings. Figma screen names must match FSD section names exactly — no synonyms, no paraphrasing.
2
Feed the Blueprint screen entry into AI — generate first draft
Paste the Blueprint entry for each screen into AI and run Prompt 1. AI generates a structured first-draft FSD section covering UI components, functional behaviour, states, and validation rules. This first draft will be approximately 60–70% complete. It will have the structure right and obvious behaviours covered. It will miss business rules and anything requiring client knowledge.
3
Fill the business rules gap
Review the AI draft and identify every place where a rule depends on business logic that only the client or domain expert knows. Make a list of every unanswered business rule question. Go back to the client or client-side PO and get explicit answers. Do not assume. Do not infer from past projects.
4
Write atomic acceptance criteria for every functional behaviour
For every functional behaviour in the spec, write one or more acceptance criteria in Given/When/Then format. Use Prompt 3 to generate a first set, then review and edit. If you cannot write a testable criterion for a behaviour, the behaviour is not specified precisely enough.
5
Engineering feasibility review
Share the draft FSD with the engineering lead before it is locked. Ask one specific question: "Is there anything in this spec that is technically impossible or significantly more complex than the estimate accounts for?" Engineering flags constraints — they do not rewrite the spec.
6
QA review — early testability check
Share the draft FSD with QA before lock. Ask QA to write one test case for each acceptance criterion. If they cannot write a test case, the criterion is not testable — which means the spec is not complete. This is the most powerful quality check in the entire process.
7
PM review and spec lock
PM reviews against three things: (1) Does every section trace back to a Blueprint screen and PRD feature? (2) Are all business rules explicitly confirmed — not assumed? (3) Does the acceptance criteria set cover all scenarios the client will use to evaluate the product? When PM signs off, the spec is locked with a version number and lock date.
Spec lock is a formal event, not a formality. Once locked, any change requires: a written change request, impact assessment on timeline and estimate, PM and client sign-off, and a version number bump on the FSD. Teams that treat spec lock casually end up with engineering building from different versions of the truth.
Part 4 of 7 — Prompt Toolkit
Five prompts — Blueprint screen to locked spec
Prompt 1 generates the FSD first draft. Prompts 2–4 fill specific gaps. Prompt 5 generates the QA test case set. Run them in sequence for each screen.
1
FSD First Draft Generator — from Blueprint screen entry
I am writing a Functional Specification Document for a software product.
You are a senior BA helping me convert a UX Blueprint screen entry
into a structured FSD section.
Blueprint entry for this screen:
--- BLUEPRINT SCREEN ENTRY ---
[PASTE THE BLUEPRINT ENTRY FOR THIS SCREEN FROM MODULE 4]
--- END BLUEPRINT ---
Wireframe description:
[DESCRIBE THE WIREFRAME LAYOUT AND COMPONENTS, OR PASTE STATE INVENTORY FROM MODULE 4 PROMPT 5]
Product type: [CLOUD NATIVE / MOBILE / DATA PLATFORM / AI-LLM / INTEGRATION]
Primary user: [PERSONA NAME AND ROLE]
Produce a complete FSD section with:
1. SCREEN OVERVIEW — Screen ID | Name | Purpose | User | Feature area
2. ENTRY CONDITIONS — What must be true for the user to arrive here?
3. UI COMPONENT INVENTORY — Every element: name | type | label | required/optional
4. FUNCTIONAL BEHAVIOUR — Per component: default state | action | response | all states
Be atomic — one behaviour per line. No compound descriptions.
5. VALIDATION RULES — Field | Required? | Format | Character limit | Trigger | Error message
6. BUSINESS RULES — List each rule. Mark: CONFIRMED / INFERRED / ASSUMPTION
7. EXIT CONDITIONS — What happens after the primary action?
Flag any section where you lack enough information to spec completely.
Do not invent business rules. Mark gaps explicitly.
2
Acceptance Criteria Generator
Convert the following functional behaviour descriptions into atomic acceptance criteria.
Use Given / When / Then format. One acceptance criterion per behaviour.
Each criterion must be independently testable by a QA engineer.
Functional behaviours to convert:
[PASTE THE FUNCTIONAL BEHAVIOUR SECTION FROM YOUR FSD DRAFT]
For each criterion:
— Given: the precondition (user state, system state, data state)
— When: the specific user action or system event
— Then: the exact expected outcome (what the user sees, what the system does)
After writing all criteria, flag:
— Any behaviour where the outcome cannot be stated precisely (write: "INCOMPLETE — requires: [what is missing]")
— Any behaviour requiring a business rule confirmation before the criterion can be completed
Do not write vague criteria.
3
Business Rules Extractor and Gap Finder
Review this FSD section and identify all business rules.
--- FSD SECTION ---
[PASTE YOUR FSD SECTION DRAFT]
--- END FSD ---
For each business rule:
1. State the rule clearly in one sentence
2. Classify as:
— CONFIRMED: explicitly stated in the PRD, Discovery Summary, or recorded client decision
— INFERRED: implied by context but not explicitly stated — needs confirmation
— ASSUMPTION: invented to fill a gap — must be confirmed before spec lock
3. For INFERRED and ASSUMPTION rules: write the exact question to ask the client
Then produce a "Business Rules Confirmation Checklist" — every question
the PO or PM must get answered before this spec can be locked.
Also flag any place where a rule is missing entirely — where behaviour
depends on a rule that has not been stated at all.
4
Edge Case and Missing State Finder
Review this FSD section and identify missing coverage.
--- FSD SECTION ---
[PASTE YOUR FSD SECTION DRAFT]
--- END FSD ---
Check for missing coverage in each category:
1. INTERACTION STATES: default, loading, empty, error, success, disabled
2. ERROR SCENARIOS: network failure, timeout, server error, invalid data, duplicate submission
3. PERMISSION EDGE CASES: user without required role, expired session, read-only access
4. CONCURRENT ACTIONS: two users acting on the same record, session expiry mid-task
5. DATA EDGE CASES: zero records, maximum records, special characters, very long strings, null values
6. MOBILE EDGE CASES (if in scope): keyboard behaviour, touch targets, offline access
For each gap found: describe the missing scenario and write a draft spec line.
Mark each: ADD TO SPEC (confirmed needed) or CONFIRM WITH CLIENT (may not be in scope).
5
QA Test Case Generator — from locked FSD
Generate a QA test case set from this locked FSD section.
--- LOCKED FSD SECTION ---
[PASTE YOUR LOCKED FSD SECTION INCLUDING ACCEPTANCE CRITERIA]
--- END FSD ---
For each acceptance criterion, produce one or more test cases:
Test Case ID: TC-[screen ID]-[number]
Acceptance Criterion: [reference the criterion]
Preconditions: [what must be set up before this test runs]
Test steps: [numbered step-by-step actions]
Expected result: [exact outcome — pass/fail must be unambiguous]
Test type: [Functional / Negative / Edge case / Permission / Performance]
After all test cases, produce:
— Coverage summary: which acceptance criteria have test cases, which do not
— List of scenarios requiring test data setup before execution
— Any test cases requiring a specific environment or integration to be available
Time saving
Prompt 5 saves one to two days of QA planning time per feature. Use it as the QA team's starting point — they review, extend, and own the final test case set. Do not hand it directly to engineering without QA review.
Part 5 of 7 — Tools for This Phase
AI and documentation tools for spec writing
The five prompts in Part 4 are the core AI layer — these tools are the environment they run in. No single project needs all of them.
Tool
How it is used in Module 5
When to use it
Claude / ChatGPT
Primary tool for all five prompts: FSD first-draft, acceptance criteria, business rules extraction, edge case finding, QA test case generation. Use with web browsing disabled when working with client data — paste only anonymised content into public AI tools.
All five prompts — throughout
Notion / Confluence
Document management for FSDs. FSD sections are living documents until lock — they need version history, comment threads, and review workflows. Notion AI can assist with reformatting and consistency checking across multiple sections.
Drafting, review, and lock management
Jira / Linear
If acceptance criteria are linked to engineering tickets, write them directly in the ticket description. Many teams paste individual acceptance criteria into the corresponding Jira story — this creates traceability between spec and implementation.
Acceptance criteria — linked to tickets
Google Sheets
Simple, effective tool for the UI component inventory and validation rules table. A shared spreadsheet where every component, its states, and validation rules are listed in rows is easier to review than a Word table. Engineering and QA can comment directly.
UI component inventory · validation rules
Zeplin / Supernova
Design-to-spec handoff tools. Connect Figma screens to spec annotations. When the FSD references a screen component, the spec can link directly to the Figma frame — showing and telling simultaneously.
Linking FSD components to Figma screens
Dovetail AI
If the engagement included user research or usability testing, Dovetail analyses session feedback and surfaces patterns that should inform spec decisions — particularly acceptance criteria around user behaviour and error recovery.
If user research is available
AI tool hygiene when writing specs: FSDs often contain client-specific business rules, proprietary workflows, and domain data. Before pasting any spec content into a public AI tool, replace client names, product names, and any identifying information with generic placeholders. Use the anonymised version for prompt input. Restore the actual content in your local document. This applies to all five prompts in this module.
Part 6 of 7 — Live Examples
Two complete spec walkthroughs
Example A specs the Job Status Update screen (S-04) from the field service app. Example B specs the Order Accept / Modify / Override screen (S-04) from the demand forecasting dashboard.
Example A · Mobile · Field Service App
S-04 — Job Status Update
Field technician updates job status through its lifecycle. States: En Route → On Site → Complete. Photo required for completion. Offline queuing required.
SCREEN OVERVIEW
Screen ID: S-04 | Screen: Job Status Update | User: Field Technician | Feature area: Job management
Purpose: Allows a field technician to update the status of an assigned job through its lifecycle from assignment to completion.
FUNCTIONAL BEHAVIOUR — selected rules
Status progression is linear: Assigned → En Route → On Site → Complete. A technician cannot skip a status or move backwards.
When the technician taps "En Route": status updates immediately in the app, a timestamp is recorded, the supervisor dashboard updates within 5 seconds via push.
When the technician taps "Complete": the system checks whether a photo has been attached. If no photo: blocking validation — "A photo is required before marking this job complete." Complete button remains disabled.
If the device has no connectivity when a status update is tapped: the action is queued locally. A banner appears: "Status update saved — will sync when connected." Status in the app reflects the queued state immediately.
BUSINESS RULES
Photo required for job completion CONFIRMED
Status updates are timestamped server-side, not device-side, to prevent manipulation CONFIRMED
A technician can only have one active job at a time ASSUMPTION — Client question: Can a technician be en route to, or on site at, multiple jobs simultaneously? Impact if confirmed: adds an "On Hold" status and job conflict prompt. Effort impact to flag to PM.
Prompt 2 Output — Acceptance Criteria
AC-S04-01
Given the technician is viewing a job with status "Assigned" When they tap "En Route" Then the job status changes to "En Route" And a timestamp is recorded And the supervisor dashboard reflects the new status within 5 seconds
AC-S04-02
Given the technician is viewing a job with status "On Site" When they tap "Complete" and no photo is attached Then the system displays: "A photo is required before marking this job complete" And the Complete button remains disabled
AC-S04-03
Given the technician has no network connectivity When they tap any status update button Then the action is queued locally And a banner displays: "Status update saved — will sync when connected" And the status in the app updates immediately to reflect the queued state
AC-S04-04
Given the technician tapped a status update while offline When connectivity is restored Then the queued status update is posted to the server automatically And the banner disappears And the technician receives a silent confirmation that sync was successful
Example B · Data Platform + AI/ML · Demand Forecasting
S-04 — Order Accept / Modify / Override
Purchasing manager accepts, modifies, or overrides an AI-generated order recommendation. Three critical spec requirements unique to AI output screens: confidence display, modification constraints, override reason capture.
FUNCTIONAL BEHAVIOUR — AI-specific requirements
Accept action: Recommended order quantity confirmed as-is. Order record created with status "Approved — AI Recommendation". AI model logs this as a positive signal. No reason capture required.
Modify action: Quantity field becomes editable. Permitted range: ASSUMPTION — is there a min/max quantity? What if user enters zero? Client confirmation required before spec lock.
Override action: Reason code dropdown appears. Reason code is mandatory before submission. Available reason codes: ASSUMPTION — list must be defined by client. Cannot be invented. Reason code and free-text note logged and fed back to ML model as a negative signal for retraining.
Confidence display: Every recommendation shows a confidence level badge: High (green) / Medium (amber) / Low (red). Read-only. Model output. Cannot be changed by user.
Explainability panel: "Why this recommendation?" expandable panel shows top 3 signals that drove the model's recommendation. Engineering to confirm API response structure includes these signals.
Prompt 4 Output — Edge Cases Found
Missing scenario
Action
User modifies quantity then navigates away without submitting — is the modification discarded? Is there an "unsaved changes" warning?
CONFIRM WITH CLIENT
User's session expires while the Override reason dropdown is open — unsaved changes discarded, redirect to login, on return land on S-03 not S-04
ADD TO SPEC
Recommendation already acted on by another user (multi-buyer scenario) — does S-04 show "This recommendation has already been processed"?
CONFIRM WITH CLIENT
Model returns no confidence value (null) — display "Confidence unavailable" in place of the badge
ADD TO SPEC
Why override reason capture is non-negotiable in AI products: The reason code is not a UX nicety — it is the training signal that improves the model over time. If the override reason is not captured, the model cannot learn from user corrections. This is a business requirement that must be in the spec and in the acceptance criteria before engineering starts.
Part 7 of 7 — Quality Gate
Do not lock the spec until this checklist is complete
A spec locked with known gaps is not a locked spec — it is a deferred problem. Every item below must be confirmed before the FSD is marked as locked and handed to engineering.
The FSD is organised by screen ID using the same IDs as the Module 4 Blueprint and Figma file
✓
Every screen in the Blueprint has a corresponding FSD section — no screens missing
✓
Screen names are consistent across Blueprint, FSD, and Figma — no synonyms or paraphrasing
Spec Completeness
✓
Every screen section has all seven required parts: overview, entry conditions, UI inventory, functional behaviour, validation rules, business rules, exit conditions
✓
Every interactive component has its functional behaviour documented to the atomic level
✓
All interaction states are covered: default, loading, empty, error, success, disabled
✓
The five commonly missed elements have been addressed: empty states, permission states, loading states, concurrent conflicts, mobile-specific behaviour
Business Rules
✓
Every business rule is marked as CONFIRMED, INFERRED, or ASSUMPTION
✓
Every INFERRED and ASSUMPTION rule has been reviewed with the client or client-side PO
✓
No ASSUMPTION-marked rule remains in the spec at lock — all have been confirmed or removed
Acceptance Criteria
✓
Every functional behaviour has at least one acceptance criterion in Given / When / Then format
✓
Every acceptance criterion is independently testable — no compound criteria
✓
No criterion contains the words "correctly", "appropriately", "properly", or any vague qualifier
Reviews Completed
✓
Engineering feasibility review completed — all technical constraints flagged and resolved
✓
QA has attempted to write test cases from the acceptance criteria — any criteria QA could not test have been rewritten
✓
PM has reviewed the complete FSD against the PRD and Scope Definition Document
✓
PM has signed off — spec is formally locked with a version number and lock date
✅ Module 5 complete. You have a locked FSD set with atomic acceptance criteria, a business rules confirmation log, and a QA test case first draft. Take these into Module 6 — Get Everyone Aligned.
Module 6 of 8 · Get Everyone Aligned
AI-Powered Product DeliveryModule 6 of 8Delivery Track
Get Everyone Aligned
How to run cross-team validation with design, engineering, QA, and compliance — lock the spec, manage change control, and produce a signed-off Spec Pack that everyone has agreed to.
Your progress0%
Part 1 of 6 — The Mindset
Alignment is not a meeting. It is a shared agreement with evidence.
Most teams think alignment means running a review meeting and asking "does everyone agree?" That is not alignment — that is a show of hands. Real alignment means every stakeholder has read the spec, raised their concerns, had those concerns resolved or documented, and signed off on a specific version.
Alignment is not consensus. You are not trying to get everyone to love the spec. You are trying to get everyone to agree that this is what we are building, that their concerns have been heard, and that they will not raise these same concerns again mid-delivery.
The cost of misalignment — when it shows up
The cost of misalignment is not discovered at the review meeting. It is discovered three sprints into development when engineering builds something the client never agreed to, or QA tests against different acceptance criteria than engineering implemented, or a compliance requirement surfaces that nobody flagged in the spec. By that point the cost of fixing it is five to ten times what it would have cost to align properly upfront.
The four stakeholder groups and what they are validating
Design
Is the spec consistent with the wireframes? Does every screen in the FSD match the Blueprint? Are there any spec decisions that conflict with design decisions already made?
Engineering
Is every specified behaviour technically feasible within the estimated effort? Are there hidden dependencies, integration constraints, or performance implications the spec does not account for?
QA
Does every acceptance criterion have a clear pass/fail condition? Are test environments and test data available for all scenarios? Are there spec behaviours that are impossible to test in the current setup?
Compliance / Legal (if applicable)
Does the product as specified meet all applicable regulatory requirements? GDPR, HIPAA, accessibility (WCAG), financial regulation, data residency — any requirement flagged in the Discovery Summary must be verified against the locked spec.
Part 2 of 6 — The Spec Pack
What the Signed-off Spec Pack must contain
The Spec Pack is not just the FSD. It is a complete, version-controlled artefact set that any team member — design, engineering, QA, or compliance — can use as their single source of truth.
📄 Locked FSD set
All FSD sections from Module 5, version-numbered, with lock date. One version for each feature group or product area in scope.
🎨 UX Blueprint
The signed-off Blueprint from Module 4. Confirms that every spec screen traces back to a designed and approved Blueprint entry.
✅ Acceptance criteria register
A consolidated view of all acceptance criteria across all screens in one document. Used by QA as their master test planning reference.
📝 Change control log
A record of every change request raised — what was requested, who raised it, what the decision was, and whether the spec was updated as a result.
🔗 Traceability matrix
A table showing every PRD feature maps to a Blueprint screen, FSD section, acceptance criteria, and QA test case. Gaps in this chain indicate coverage issues.
✍️ Sign-off record
Written confirmation from each stakeholder group. An email thread is acceptable. A signature page is better. A verbal "yes" in a meeting is not sufficient.
The traceability chain
Every deliverable in this course traces forward and backward. A broken link means something was built that was not agreed, or something was agreed that was not built.
PRD feature→Blueprint screen→FSD section→Acceptance criterion→QA test case→Engineering ticket→Implemented feature→QA pass/fail
The traceability matrix makes this chain visible. It is not bureaucracy — it is the mechanism that allows a PM to answer "was this feature tested?" or "where did this requirement come from?" in under two minutes.
Part 3 of 6 — The Process
Five steps from spec to sign-off
Steps 1 and 2 prepare for alignment. Steps 3 and 4 run the reviews. Step 5 locks and packages.
1
Prepare the alignment pack
Before any review meeting, assemble a complete draft of the Spec Pack: locked FSD sections, Blueprint, acceptance criteria register, and a traceability matrix showing coverage. Share with all reviewers at least 48 hours before the review session. Reviewers who have not read the spec before the meeting cannot contribute a meaningful review. A review session where people are reading the spec for the first time is not a review — it is a first read with an audience.
2
Run asynchronous pre-review
Before any synchronous session, ask each stakeholder group to review the spec independently and log their comments. Comments should be logged as: (A) Blocking — must be resolved before implementation, (B) Non-blocking — discuss but will not hold up the spec, or (C) Noted — acknowledged, no change needed. This pre-review step makes the synchronous session dramatically more efficient.
3
Run the alignment session
A focused working session — not a presentation. Walk through blocking comments only. For each: what is the issue, what are the options, what is the decision, who owns the update. Time-box aggressively — a medium-sized product alignment session should take 90 minutes, not a full day. If you are running over, the spec needed more work before the session.
4
Process change requests
Every blocking comment that results in a spec change is a change request. Log it: what changed, in which FSD section, from which version to which version. Update the FSD, bump the version number, and circulate the updated section to the reviewers who raised the blocking comment. Do not circulate the full spec again — only the changed sections.
5
Lock and package the Spec Pack
When all blocking comments are resolved and confirmed, the PM formally locks the spec. The lock means: no further changes without a formal change request, a new version number, and PM sign-off. Assemble the complete Spec Pack with the final version of all artefacts, the sign-off record, and the change control log.
On change control after spec lock: every post-lock change has a cost — not just the spec update, but the ripple. A spec change may require a Blueprint update, new test cases, re-review by the affected stakeholder group, and an impact assessment on the effort estimate. The PM's job is not to block change — it is to make the cost of change visible before anyone agrees to it.
Part 4 of 6 — Prompt Toolkit
Four prompts for alignment and change control
AI is most useful in this module for preparing alignment materials, synthesising review feedback, and managing change control documentation. The alignment conversation itself is human — but the before and after can be significantly accelerated.
1
Traceability Matrix Generator
Generate a traceability matrix for this product.
PRD feature list:
[PASTE FEATURE LIST FROM PRD v0.1]
FSD section list (screen ID + name):
[PASTE LIST OF FSD SECTIONS FROM MODULE 5]
Acceptance criteria register:
[PASTE CONSOLIDATED ACCEPTANCE CRITERIA LIST]
Produce a traceability matrix with columns:
— PRD feature reference
— Blueprint screen ID(s) that deliver this feature
— FSD section ID(s) that specify this feature
— Number of acceptance criteria covering this feature
— Coverage status: FULL / PARTIAL / GAP
Flag any PRD feature with no corresponding FSD section (gap in spec coverage).
Flag any FSD section with no corresponding PRD feature (scope creep risk).
2
Review Comment Synthesis
I have collected review comments from the cross-team spec review. Synthesise them.
Review comments from all stakeholders:
[PASTE ALL REVIEW COMMENTS, GROUPED BY REVIEWER OR COMMENT LOG]
Produce a structured review summary:
1. BLOCKING comments — list each with: comment summary, section affected,
who raised it, options for resolution
2. NON-BLOCKING comments — grouped by theme
3. DUPLICATE comments — merge into single items
4. CONTRADICTORY comments — flag where two reviewers have opposing views
Then produce an alignment session agenda: list only the blocking items,
in order of complexity, with estimated discussion time per item.
Total session time should not exceed 90 minutes.
3
Change Request Impact Assessment
A change request has been submitted for a locked spec. Assess the full impact.
Change request description:
[DESCRIBE THE REQUESTED CHANGE IN PLAIN TERMS]
Affected FSD sections:
[LIST THE FSD SECTIONS THIS CHANGE TOUCHES]
Assess the impact across:
1. SPEC CHANGES: Which FSD sections need updating? Which acceptance criteria change?
2. DESIGN CHANGES: Does this require a Blueprint or wireframe update?
3. EFFORT IMPACT: Does this change the hours estimate? Flag which workstreams.
4. TIMELINE IMPACT: Could this delay a milestone or phase?
5. DOWNSTREAM RISK: Does this affect any screen or feature already in development?
Produce a one-page impact summary the PM can share with the client
when presenting the change request for approval.
4
Spec Pack Assembly Checklist
I am assembling the Signed-off Spec Pack. Check my artefact list for completeness.
Current artefacts in the pack:
[LIST EVERY DOCUMENT AND FILE CURRENTLY IN YOUR SPEC PACK]
Check against the required Spec Pack contents:
— Locked FSD set (all sections, version-numbered, with lock date)
— UX Blueprint (signed-off from Module 4)
— Acceptance criteria register (all screens consolidated)
— Traceability matrix (PRD → Blueprint → FSD → AC coverage)
— Change control log (even if empty — log must exist)
— Sign-off record (written confirmation from each stakeholder group)
Flag any missing or incomplete artefact.
For each gap, state what is needed and who owns producing it.
Part 5 of 6 — Live Examples
Two alignment scenarios
Example A shows a clean alignment run with one blocking issue surfaced and resolved. Example B shows a post-lock change request arriving mid-engineering and how the PM manages it.
Example A · Field Service App · Cross-Team Alignment
Pre-review results from three stakeholder groups
Engineering raised one blocking issue. Design confirmed Blueprint alignment. QA confirmed all acceptance criteria are testable.
Prompt 2 Output — Review Comment Synthesis
BLOCKING — 1 item
Conflict resolution on offline sync not specified
Engineering cannot implement without a decision. Section affected: S-04 functional behaviour, offline queuing rules.
Options: (A) Last write wins — most recent timestamp takes precedence · (B) Server wins — supervisor update always takes precedence · (C) Conflict alert — both parties notified, manual resolution required
NON-BLOCKING — 2 items
QA requests test data specification — what job states need to exist in the test environment before offline sync tests can run.
Design notes that the offline banner copy differs between S-04 and S-06 — suggest standardising to one string.
Alignment Session Agenda
Item 1 (15 min): Offline conflict resolution — PM to present three options, team to decide. Item 2 (5 min): Offline banner copy — design to propose one string, PM to confirm. Estimated total: 20 minutes. No further items require synchronous discussion.
Resolution and Lock
Decision made in session: Server wins — the supervisor's update takes precedence. The technician's offline action is discarded if a conflict exists, and the technician receives a notification: "This job was updated while you were offline. Your action was not applied."
FSD updated with this rule. Version bumped from 1.0 to 1.1. Engineering confirmed version 1.1. Spec locked. Total alignment session: 20 minutes.
Example B · Demand Forecasting Dashboard · Post-Lock Change
Post-Lock Change Request — Bulk Accept Feature
Three weeks into engineering, the client's Head of Supply Chain requests a new feature: the ability to bulk-accept all recommendations in a category with one click.
S-03 Recommended Order View: add bulk selection UI (checkboxes, "Select All", bulk action bar). S-04 Order Accept screen: add bulk accept flow and confirmation state. Four new acceptance criteria required.
Design changes
UX Blueprint S-03 entry needs update. New wireframe state required for S-03 showing bulk selection active. Figma update and design review required before implementation.
Effort impact
Backend: bulk accept API endpoint — estimated 12–16 hours. Frontend: bulk selection UI component — estimated 8–10 hours. QA: four new test cases — estimated 4 hours. Total: 24–30 hours outside current estimate.
Timeline impact
If prioritised immediately: adds approximately 0.75 weeks to the current sprint. If deferred to next sprint: no impact on current delivery milestone.
Downstream risk
The ML model logging layer must be updated to handle bulk actions. Risk: if bulk accepts are not individually logged, model retraining quality degrades. Engineering to confirm logging behaviour before implementation.
PM Decision
Change accepted for next sprint with a formal change order signed by the client confirming the additional 24–30 hours are in scope and the delivery timeline adjusts by one week. Spec updated to v2.0. Change control log updated. Client confirmation received in writing before engineering begins.
The principle demonstrated here: The PM did not agree to the change in the meeting. The PM assessed the full impact using Prompt 3 first — then presented it to the client with the cost made explicit. The client then made an informed decision. This is what good change control looks like.
Part 6 of 6 — Quality Gate
Do not hand the Spec Pack to engineering until this is complete
Every item must be confirmed before the Spec Pack is handed to engineering. A Spec Pack with known gaps is not a Spec Pack — it is a deferred problem.
📦 Signed-off Spec Pack📝 Change Control Log🔗 Traceability Matrix
✓
The Spec Pack contains all six required artefacts: locked FSD set, Blueprint, acceptance criteria register, traceability matrix, change control log, sign-off record
✓
Every FSD section has a version number and lock date
✓
The traceability matrix shows full coverage — no PRD feature without a spec section, no spec section without a PRD feature
✓
All blocking review comments have been resolved and confirmed by the reviewer who raised them
✓
All post-lock change requests are logged with decision and outcome — even if the decision was to reject the change
✓
Written sign-off has been received from: design, engineering lead, QA lead, and any applicable compliance or legal reviewer
✓
Engineering has confirmed they have received and read the final locked version — not a draft
✓
A shared location exists where all team members can access the current Spec Pack version — no spec documents distributed only by email
✅ Module 6 complete. You have a Signed-off Spec Pack with full traceability. Take it into Module 7 — Hand it Over Clean.
Module 6 output → Module 7: Signed-off Spec Pack · Locked FSD set · Signed-off UX Blueprint · Acceptance criteria register · Traceability matrix · Change control log · Written sign-off from all stakeholder groups
Module 7 of 8 · Hand it Over Clean
AI-Powered Product DeliveryModule 7 of 8Delivery Track
Hand it Over Clean
How to package all finalised artefacts into a single, version-controlled, development-ready source of truth — so engineering can start building with zero ambiguity and zero missing context.
Your progress0%
Part 1 of 6 — The Mindset
The handoff is not the end of PM work. It is the beginning of the build.
The most damaging myth in product delivery is that the PM's job is done when the spec is signed off. If the handoff is clean, engineering starts fast, builds confidently, and produces what was specified. If the handoff is messy, the first two weeks of the build are spent reconstructing context the PM already had.
The test of a clean handoff: can a new developer who joins the team in week three of the build, having missed every conversation up to that point, get fully up to speed from the Dev-Ready Package alone in half a day? If not — the package is not complete.
What typically goes wrong — and why
Scattered artefacts across multiple locations
The spec is in Notion, the wireframes in Figma, the API docs in a Confluence page, and the architecture diagram in a Slack message from three weeks ago. Engineering spends the first sprint finding things, not building.
Multiple versions of the truth
Three different versions of the FSD exist. Nobody is sure which one is current. The wireframes in Figma do not match the spec that was signed off. Engineering builds from the wrong version and discovers the mismatch during QA.
Missing context for decisions
The spec says what to build. It does not say why a decision was made a particular way. When engineering hits a constraint and needs to deviate, they have no context to make a good judgment call. They either build it wrong or stop and wait for the PM.
Part 2 of 6 — The Dev-Ready Package
Seven artefacts. One location. One version.
The Dev-Ready Package is not a new document — it is a curated, version-controlled assembly of everything produced in Modules 1 through 6, organised for engineering consumption.
★ New document
Engineering Onboarding Brief
2–3 pages written specifically for engineers. What the product is, who the user is, the tech stack, key integrations, and the top decisions that were made and why. The context layer no other document provides.
Signed-off Spec Pack
The complete locked Spec Pack from Module 6: FSD set, Blueprint, acceptance criteria register, traceability matrix, change control log, sign-off record. Version numbers must match.
Figma design package
Final Figma file organised by screen ID matching the FSD headings exactly. All states designed. All assets exported. Prototype link included. Engineering-readable annotation layer for non-obvious UI behaviours.
API and integration specs
Endpoint list, authentication method, request/response format, error codes, and rate limits for every integration. Engineering cannot build integrations without this.
Architecture decision record
Key technical decisions: tech stack, cloud platform, database approach, auth method — and any decisions made for non-obvious reasons. These are the decisions a developer might otherwise undo without realising they were intentional.
Test environment and data guide
What test environments exist, how to access them, what test data is available, and what needs to be set up before QA begins. Without this, the first week of testing involves setting up environments instead of running tests.
Glossary of terms
Every product-specific, client-specific, or domain-specific term used in the spec, with a plain-language definition. Terms that mean different things to the client and to the engineering team are the source of more bugs than almost any other cause.
Naming convention: Every artefact named consistently — [Product]-[Artefact]-[Version]-[Date]. No files named "final", "final v2", or "use this one". One location. All team members can access it. Nothing distributed only by email.
Part 3 of 6 — The Process
Five steps from Spec Pack to engineering kickoff
1
Audit what you have
Before packaging, audit every artefact produced across Modules 1 through 6. For each: is it the final version, is it in the agreed location, does its version number match the sign-off record, and does it contain any placeholder content that was never filled. A Dev-Ready Package that contains a TBD is not ready for development. Fix every gap before packaging.
2
Write the Engineering Onboarding Brief
Write it last, once everything else is confirmed final. It references the other artefacts rather than duplicating them. Keep it to two or three pages. An engineer who reads this brief should be able to answer: what am I building, who is it for, what does done look like, where do I find the detailed spec, and what are the most important decisions I need to be aware of.
3
Organise the package
All artefacts in one location — one shared drive folder, one Notion workspace, or one Confluence space. Structure mirrors the delivery sequence: Onboarding Brief at the top, then Spec Pack, then Figma, then API specs, then Architecture decisions, then Test guide, then Glossary.
4
Run the engineering kickoff walkthrough
The PM walks the engineering lead through the Dev-Ready Package in a 60–90 minute session. Not a presentation — a walkthrough. The PM asks engineering: "What would stop you from starting tomorrow?" Any answer that is not "nothing" is a gap to fix. The walkthrough is not optional.
5
Hand over and establish the PM's ongoing role
After the walkthrough, the Dev-Ready Package is formally handed over. The PM's role shifts: from builder of artefacts to guardian of scope. During the development phase, the PM answers spec questions, manages change requests, reviews progress against the traceability matrix, and ensures that what engineering builds matches what was agreed.
Part 4 of 6 — Prompt Toolkit
Three prompts for building the Dev-Ready Package
AI is most useful for writing the Engineering Onboarding Brief and auditing the package for completeness. The organisation and walkthrough are human work.
1
Engineering Onboarding Brief Generator
Write an Engineering Onboarding Brief for a new developer joining this project.
This brief should be 2-3 pages maximum. Clear, direct, no marketing language.
PRD summary (product, user, problem, MVP scope):
[PASTE KEY SECTIONS FROM PRD v0.1]
Technology stack and architecture decisions:
[PASTE FROM SCOPE DEFINITION DOCUMENT OR ARCHITECTURE DECISION RECORD]
Key third-party integrations:
[LIST INTEGRATIONS WITH ONE-LINE DESCRIPTION OF EACH]
Top 3-5 decisions that were made and why:
[PASTE KEY DECISIONS FROM DISCOVERY, PRD, OR ALIGNMENT PROCESS]
Produce the brief with these sections:
1. What we are building (1 paragraph — product, user, problem solved)
2. MVP scope (bullet list — what is in v1 and what is explicitly deferred)
3. Technology stack and architecture (table: component | technology | reason)
4. Key integrations (table: integration | purpose | status)
5. Decisions you need to know (numbered list — decision + reason it was made that way)
6. Where to find the detailed spec (links to each artefact in the Dev-Ready Package)
7. Who to ask (PM, design, QA, client-side PO contacts)
2
Dev-Ready Package Audit
Audit my Dev-Ready Package for completeness before the engineering kickoff.
Current package contents:
[LIST EVERY FILE AND DOCUMENT WITH VERSION NUMBER AND DATE]
Check against the required Dev-Ready Package contents:
— Engineering Onboarding Brief (2-3 pages, current version)
— Signed-off Spec Pack (FSD set, Blueprint, AC register, traceability matrix, change log, sign-offs)
— Figma design package (all screens, all states, assets exported, prototype link)
— API and integration specifications
— Architecture decision record
— Test environment and data guide
— Glossary of terms
For each artefact: present (Y/N) | version confirmed (Y/N) | known gaps or placeholder content
Then flag: any artefact where the version number does not match the sign-off record,
and any artefact that contains placeholder text or unresolved TBD items.
3
Glossary Generator
Generate a glossary of terms for this product's Dev-Ready Package.
Source documents:
[PASTE KEY SECTIONS OF THE FSD, PRD, AND ENGINEERING ONBOARDING BRIEF]
For each term identified:
— Term (as used in the spec)
— Definition (plain language, 1-2 sentences)
— Context (which screen or feature does this term relate to?)
— Potential confusion flag: does this term mean something different in a general software context?
Prioritise: client-specific terms, domain-specific jargon, acronyms, and any term
used in the spec that has more than one plausible interpretation.
Part 5 of 6 — Live Examples
Engineering Onboarding Brief + Ideas2IT internal story
Example A shows the Engineering Onboarding Brief structure for the field service app. Example B is a real Ideas2IT story — how clean delivery process enabled the build of ReleasePulse, an AI tool that now runs inside the company.
Example A · Field Service App · Engineering Onboarding Brief
Field Service Management App — v1.0
This is the document an engineer reads on day one. It gives them full context without any other conversation.
WHAT WE ARE BUILDING
A mobile app for field technicians and a web dashboard for supervisors at a mid-sized HVAC maintenance company. The product replaces a WhatsApp-and-spreadsheet dispatch process. Core problem: dispatchers have no real-time visibility of job status, causing booking loss and technician idle time. MVP scope: job assignment, status updates with photo, supervisor dashboard, offline capability, iOS and Android.
TECHNOLOGY STACK
Component
Technology
Reason for choice
Mobile
React Native
iOS + Android from single codebase — client cannot afford separate native builds
Backend
Node.js + PostgreSQL on AWS
Team competency and client's existing AWS relationship
Real-time updates
WebSockets
Supervisor dashboard requires live job status without polling
Offline
SQLite local storage
Field technicians frequently work in low-connectivity environments
Auth
JWT with refresh token rotation
Stateless, mobile-friendly, standard for this stack
DECISIONS YOU NEED TO KNOW
Offline conflict resolution: Server wins. If a supervisor updates a job while a technician is offline, the supervisor's update takes precedence and the technician is notified. Do not implement "last write wins" — this was explicitly rejected in the alignment session.
Photo storage: AWS S3, not local device storage. Photos must upload before job completion is registered server-side. The app may display completion locally while the upload is pending — but the server does not record completion until the upload succeeds.
React Native was chosen over Flutter because the UI/UX designer has React experience. Any UI components not available in React Native's standard library must be flagged to the PM before a custom build is started.
These three decisions alone prevent three potential mid-sprint incidents. An engineer who reads this brief will not accidentally implement last-write-wins, store photos locally, or start building a Flutter component. This is what the Onboarding Brief is for.
Ideas2IT — Internal Story · Real Example
How clean delivery process enabled ReleasePulse — an AI tool built by Ideas2IT for Ideas2IT
ReleasePulse is a real internal product. Built by the Ideas2IT team. It runs today. This is the story of how it was conceived, built, and handed over — and why the Module 7 handoff process made it possible.
The problem it solved
Every software release at Ideas2IT required manual preparation of release communications across three platforms — Jira, Confluence, and Slack. The process was time-consuming, error-prone, and inconsistent across projects and PMs. Release notes got missed. Confluence pages were out of date. Slack announcements varied in quality and completeness.
The team identified this as a perfect candidate for AI automation: a structured, repeatable process with clear inputs (release details) and clear outputs (three types of communications across three platforms).
What they built — the architecture
ReleasePulse uses a multi-agent AI framework (Crew.ai) with three sequential agents, triggered by a single Slack command.
💬
Trigger — Slack command
PM types /trigger-release in the dedicated Release channel. A form appears collecting: version number, release highlights, and important notes. This is the single input that drives all three agents.
↓
📘
Agent 1 — Confluence Agent
Publishes formal release details into the Confluence Wiki. Creates a structured release page with version, highlights, linked Jira tickets, and release notes. Replaces the manual Confluence update that PMs previously did by hand.
↓
🎯
Agent 2 — Jira Agent
Updates release content and links in Jira. Creates a Release ticket with the description of the release and an epic ticket holding all the stories worked. Links tickets back to the Confluence page. Replaces manual Jira bookkeeping that was often skipped entirely.
↓
📢
Agent 3 — Slack Agent
Publishes a formatted release announcement to the designated Slack channel(s). Consistent format every time — version, highlights, links to Confluence and Jira. No more inconsistent announcements written differently by different PMs.
Why the Module 7 handoff process matters here
ReleasePulse was built by an internal team, not a client. But the same handoff principles applied. When the architecture was designed and the agent logic was defined, the team produced:
A clear Engineering Onboarding Brief explaining the Crew.ai framework, the three agents, and the data flow between them
An Architecture Decision Record documenting why Crew.ai was chosen over other orchestration frameworks and why the agents run sequentially rather than in parallel
A Glossary covering Crew.ai-specific terminology so that engineers who had not used the framework before could onboard without confusion
A Test environment guide specifying what sandbox Jira/Confluence/Slack environments existed and how to configure them for local testing
Without this documentation, a new engineer joining the team mid-build would have spent days reconstructing the agent logic and integration architecture from the code alone. With it — half a day. That is the test of a clean handoff.
The commands that set it up
Before triggering a release, the PM runs two setup commands in Slack:
/set-services — Choose which services are included in this release /set-leads — Assign the release leads for this release
Then /trigger-release fires all three agents sequentially. The entire release communication process — which previously took 30–60 minutes of manual work per release — now takes under 2 minutes.
What this proves: When a team follows a structured delivery process — clear spec, clean handoff, documented decisions — they can build and ship internal AI tools at the same speed and quality as client products. ReleasePulse is not a side project. It is a production system that runs on every Ideas2IT release. It was built the right way because the team handed it over clean.
Part 6 of 6 — Quality Gate
Do not start development until this is complete
📦 Dev-Ready Package📄 Engineering Onboarding Brief
✓
The Dev-Ready Package contains all seven required artefacts
✓
Every artefact has a version number and date that matches the sign-off record from Module 6
✓
No artefact contains placeholder text, TBD markers, or unresolved gaps
✓
The Engineering Onboarding Brief exists and covers all seven required sections
✓
Figma file is organised by screen ID, all states are present, all assets are exported
✓
API and integration specs are complete for every integration in scope
✓
The test environment guide confirms environments are accessible and test data is available
✓
The glossary covers all domain-specific and client-specific terms in the spec
✓
The engineering kickoff walkthrough has been completed — not just the package delivered
✓
Engineering has confirmed in writing that they have everything needed to begin
✓
A process exists for engineers to ask spec questions during the build phase — and the PM has committed to a response time
✅ Module 7 complete. Engineering has everything they need to build. Take the confirmed start into Module 8 — Measure & Improve.
Module 8 of 8 · Measure & Improve
AI-Powered Product DeliveryModule 8 of 8Post-Launch Track
Measure & Improve
How to use AI to track product performance after launch, measure against the success metrics defined in the PRD, identify what to improve, and turn a delivered project into an ongoing engagement.
Your progress0%
Part 1 of 7 — The Mindset
Delivery is not the finish line. It is the starting point for the real data.
Most PMs treat launch as the end of their job. It is not. Everything before launch was hypothesis — the PRD, the user flows, the feature decisions, the effort estimate. Launch is the moment those hypotheses meet reality.
Every delivered product contains the seeds of the next engagement. The PM's job in this module is to find those seeds, cultivate them with data, and present them in a way that makes the next phase feel like the obvious next step — not a new sale.
The commercial reality
A client whose PM disappears after launch is a client who will not return for the next phase. A client whose PM comes back with a structured performance brief, a clear view of what is working and what is not, and a credible proposal for the next iteration — that client is an account that grows.
Three outputs — and why each matters
Performance Brief
Honest comparison of PRD targets against actual post-launch data. The credibility foundation for everything that follows.
Improvement Backlog
Prioritised, evidence-backed list of improvements. Each item has evidence, user impact, business impact, and estimated effort.
Next Iteration Roadmap
Structured proposal for the next phase. The document that converts a completed delivery into a growing account relationship.
Part 2 of 7 — What to Measure
Three data sources — you need all three
Product analytics alone is not enough. User feedback alone is not enough. Technical metrics alone are not enough. The Performance Brief is built from all three.
Data source 1 — Product usage analytics
Metric
What it tells you
Feature adoption rate
What % of active users have used each feature at least once? Features below 20% adoption in the first 30 days are at risk of being considered low-value by the client.
User retention
Day 1, Day 7, Day 30 retention rates. A product that looks healthy on launch day but shows 60% drop-off by day 7 has a fundamental engagement problem.
Flow completion rates
For every primary user flow mapped in Module 4, what % of users who start it complete it? Drop-off points indicate UX or spec issues not caught in testing.
Error rates
How often are users hitting error states? High error rates indicate a spec gap, an implementation bug, or a user mental model mismatch.
Time on task
Significantly longer than the design assumption indicates friction. Significantly shorter may indicate shortcuts that bypass intended flows.
Data source 2 — User feedback
Feedback type
What it tells you
Support ticket analysis
What are users asking for help with? Ticket themes reveal where the product is unclear, where onboarding failed, and where spec assumptions were wrong about user behaviour.
NPS or CSAT scores
Overall satisfaction score and the verbatim comments attached to low scores. Low scores with no comments are data. Low scores with comments are insights.
Usability test sessions
If budget allows, 2–3 moderated usability sessions post-launch reveals behaviours analytics cannot show — confusion, workarounds, and unmet needs.
Feature request patterns
What features are users asking for that do not exist? Requests clustering around the same need are a signal for the next iteration roadmap.
Data source 3 — Technical performance
Metric
What it tells you
System uptime and reliability
Is the product available when users expect it? Downtime events and their causes.
API response times
Slow API responses create UX problems that analytics may surface as user drop-off without indicating the root cause.
Error log patterns
Error patterns that do not surface in user-facing analytics often indicate deeper reliability issues.
Infrastructure cost vs estimate
Cost overruns at this stage indicate either scope creep in the build or underestimation of usage volume.
Part 3 of 7 — The Process
Five steps from post-launch data to client-ready roadmap
1
Set the measurement baseline before launch
The success metrics in the PRD v0.1 are your baseline. Before launch, confirm with the client which metrics matter most, what the target values are, and what the measurement window is (first 30 days, first 90 days, first full quarter). Measuring without a baseline is just collecting numbers.
2
Collect data across all three sources
At the agreed measurement window, collect data from product analytics, user feedback, and technical monitoring. Use Prompt 1 to synthesise support ticket themes and user feedback at speed. Use Prompt 2 to generate a structured analysis of usage data. You are looking for patterns, not individual data points.
3
Write the Performance Brief
Compare actual metrics against the PRD baseline. For each metric: what was the target, what is the actual, what is the delta, and what does the delta tell you. Be honest — a Performance Brief that only reports metrics that look good is a document no one will trust for the next phase.
4
Build the Improvement Backlog
From the Performance Brief, identify every issue, gap, or opportunity. For each item: evidence, who is affected, estimated impact, and approximate effort. Prioritise using impact vs effort. Tier 1 = fix immediately. Tier 2 = next iteration. Tier 3 = backlog.
5
Build the Next Iteration Roadmap
From top-priority backlog items and any new features requested, build the roadmap for the next phase. Frame it as: objectives (what outcomes the next phase targets), scope (what features deliver those outcomes), and commercial case (why investing in the next phase makes business sense). This is the document that drives the next engagement.
Part 4 of 7 — Prompt Toolkit
Five prompts for the measure and improve cycle
AI is highly effective at synthesising large volumes of unstructured feedback and usage data into structured insights. The judgment about what to prioritise is human. The pattern-finding in raw data is AI.
1
User Feedback Synthesis
Synthesise user feedback from post-launch data into structured insights.
Product context: [ONE SENTENCE PRODUCT DESCRIPTION]
Primary user: [PERSONA]
Measurement window: [E.G. FIRST 30 DAYS POST-LAUNCH]
Feedback sources:
Support tickets: [PASTE OR SUMMARISE SUPPORT TICKET THEMES]
User survey responses: [PASTE OR SUMMARISE NPS/CSAT VERBATIMS]
Feature requests received: [LIST OR PASTE]
From this feedback, extract:
1. Top 5 pain points with frequency and severity (1-3 scale)
2. Top 3 things users praise consistently
3. Top 5 feature requests ranked by frequency
4. Any feedback indicating a fundamental product-market fit issue
5. The language users use to describe their problems — exact phrases where possible
Format as a structured report I can include in the Performance Brief.
2
Usage Data Analysis
Analyse product usage data and identify performance patterns.
PRD success metrics (target values): [PASTE SUCCESS METRICS FROM PRD v0.1]
Actual performance data:
Feature adoption rates: [PASTE DATA]
User retention (Day 1 / Day 7 / Day 30): [PASTE DATA]
Flow completion rates: [PASTE DATA BY FLOW]
Error rates and most common errors: [PASTE DATA]
For each metric:
1. Compare actual vs target — on track, below, or above?
2. Identify the most significant positive finding
3. Identify the most significant negative finding
4. For any flow with completion rate below 70%, identify the most likely drop-off point and a hypothesis for why
Produce a metric-by-metric analysis table and a 3-paragraph executive summary.
3
Performance Brief Generator
Write a Performance Brief for this product based on the post-launch data analysis.
Product: [PRODUCT NAME AND ONE-LINE DESCRIPTION]
Launch date: [DATE]
Measurement window: [PERIOD]
Analysis inputs:
Usage data analysis: [PASTE PROMPT 2 OUTPUT]
User feedback synthesis: [PASTE PROMPT 1 OUTPUT]
Technical performance summary: [PASTE UPTIME, RESPONSE TIMES, ERROR LOG SUMMARY]
Produce a Performance Brief with:
1. Executive summary (3 sentences: what launched, headline finding, recommended next step)
2. Success metrics scorecard (table: metric | target | actual | status)
3. What is working well (3-5 specific findings with data)
4. What needs improvement (3-5 specific findings with data and severity)
5. User sentiment summary (key themes with representative quotes)
6. Technical reliability summary
7. Recommended next steps (3 bullet points — direct, actionable)
Write for a client audience. Clear, honest, no padding. Every claim backed by data.
4
Improvement Backlog Generator
Generate a prioritised improvement backlog from this Performance Brief.
Performance Brief findings: [PASTE PROMPT 3 OUTPUT OR KEY FINDINGS]
Client-reported feature requests: [PASTE ANY DIRECT CLIENT REQUESTS]
For each improvement item, produce:
— Item name (clear, functional)
— Evidence (what data or feedback identified this)
— User impact (high / medium / low)
— Business impact (what metric does fixing this improve?)
— Estimated effort (S / M / L)
— Priority tier: Tier 1 (fix immediately), Tier 2 (next iteration), Tier 3 (backlog)
Prioritisation logic:
Tier 1 = high user impact + low effort, or critical reliability issue
Tier 2 = high business impact, medium to large effort
Tier 3 = nice to have, low urgency
Format as a table. Maximum 15 items.
5
Next Iteration Roadmap
Build a Next Iteration Roadmap based on the Performance Brief and Improvement Backlog.
Improvement backlog (Tier 1 and Tier 2 items): [PASTE PROMPT 4 OUTPUT]
Client priorities or strategic goals since launch: [PASTE ANY CLIENT DIRECTION]
Original PRD deferred features: [PASTE OUT OF SCOPE LIST FROM PRD v0.1]
Produce a Next Iteration Roadmap with:
1. OBJECTIVES: What outcomes does the next phase target? (3 max, each tied to a measurable metric)
2. SCOPE: Must-have (Tier 1 fixes + highest impact Tier 2), should-have, future backlog
3. COMMERCIAL CASE: Why is the next phase a good investment?
State: what problem it solves, what metric it moves, approximate ROI
4. SUGGESTED APPROACH: Phase structure, team composition, rough timeline
5. NEXT STEP: What the client needs to decide or confirm to proceed
Write in plain business language. This document will be presented to the client. No jargon.
Part 5 of 7 — Live Examples
Three post-launch scenarios
Example A: Field service app at 30 days. Example B: AI forecasting dashboard at 90 days with model drift. Example C: ReleasePulse — Ideas2IT's own AI tool, measured post-launch.
Example A · Field Service App · 30-Day Performance Brief
40 technicians active, 5 supervisors. Measurement window: days 1–30.
Success Metrics Scorecard
Job status update adoptionTarget: 90%87%ON TRACK
Photo capture complianceTarget: 100%76%BELOW
Daily active supervisorsTarget: 5/55/5ON TRACK
Offline sync data lossTarget: zero2 incidentsBELOW
Overall NPSTarget: 3542ABOVE
Next Iteration Roadmap — Objectives and scope
Objectives:
Reach 100% photo capture compliance (from 76%) by fixing silent upload failure on low connectivity
Reduce support ticket volume by 60% by addressing the top three ticket causes
Increase technician adoption to 95%+ through in-app onboarding nudge for non-active users
Scope — Must have:
Photo upload retry with progress indicator and failure alert Tier 1
Offline sync reliability fix Tier 1
Job history extended from 30 to 90 days Tier 2
Notification latency fix for job assignment Tier 2
Commercial case: Estimated effort: 3 weeks, 3-person team. Expected outcome: photo compliance to 95%+, support tickets from 18/month to under 7/month. Recommend proceeding immediately while team context is fresh.
Example B · Demand Forecasting Dashboard · 90-Day AI Model Issue
The forecasting model's accuracy has declined from 82% at launch to 71%. Buyers are overriding 34% of AI recommendations — against a target of under 15%.
Model drift — what it is and how to address it
What happened: The demand forecasting model was trained on 3 years of historical data. In the 90 days since launch, buying behaviour shifted due to a promotional event that was outside the training data. The model did not adapt because the retraining pipeline was configured for manual trigger only.
Metric
At launch
Now (90 days)
Target
Status
Model accuracy
82%
71%
80%
BELOW
Override rate
18%
34%
<15%
BELOW
Next Iteration Roadmap — restoring model accuracy
Objective: Restore model accuracy to 80%+ and reduce override rate below 20%.
Scope:
Automated monthly retraining pipeline Tier 1
Override reason analysis dashboard — identify which product categories are most poorly predicted Tier 2
Model monitoring alert when accuracy drops below 75% Tier 2
Commercial case: The current 34% override rate means buyers are spending significant time manually reviewing AI recommendations — the ROI promised in the proposal is not being delivered at this accuracy level. Phase 2 restores the promised saving. This is the honest conversation every PM must be prepared to have.
Ideas2IT — Internal Story · Post-Launch Measurement
ReleasePulse — post-launch performance and what it proved
ReleasePulse was built and handed over (Module 7). Now it has been running. This is the post-launch story — what was measured, what the data showed, and what it means for the next iteration.
What ReleasePulse measured post-launch
The baseline success metrics defined before launch:
Time to complete release communicationsTarget: <5 min~2 minABOVE TARGET
Consistency across channelsTarget: 100%100%ON TRACK
Consistency — same format, every release, every PM
What the performance brief would say
Executive summary: ReleasePulse launched across all active Ideas2IT projects. The headline finding is that manual release documentation time has been reduced by approximately 80%, exceeding the 70% target. The recommended next step is extending the tool to capture release metrics over time — so PMs can see trends across releases, not just per-release outputs.
What is working well: The single Slack command trigger is frictionless — adoption was immediate because the workflow required no behaviour change. Consistency across channels has eliminated the inconsistency that previously caused stakeholder confusion. The Jira Release ticket and Confluence page are now always in sync.
What needs improvement: The tool currently produces communications but does not capture them for retrospective analysis. PMs cannot look back and see how release scope has grown over time, or compare release frequency across projects. This is the gap the next iteration should address.
Next Iteration Roadmap — what was identified
Release history dashboard — track release frequency and scope growth over time Tier 1
Release metrics export — allow PMs to include release cadence data in client reporting Tier 2
Cross-project release comparison — compare release patterns across the portfolio Tier 2
MCP integration with additional tools (e.g. Notion, Teams) Tier 3
The principle this demonstrates: Every internal tool built with a proper delivery process becomes a product that can be measured, improved, and extended. ReleasePulse did not end at launch — it entered the same measure and improve cycle as any client product. That is AI-powered delivery culture in practice.
Part 6 of 7 — Quality Gate
Before presenting the Performance Brief to the client
📄 Performance Brief📋 Improvement Backlog🗺️ Next Iteration Roadmap
✓
A measurement baseline was established from the PRD success metrics before or at launch
✓
Data has been collected from all three sources: product analytics, user feedback, and technical performance
✓
The Performance Brief compares actual metrics against PRD targets — not just reports actuals
✓
The brief is honest about underperformance — no metrics omitted because they look bad
✓
Every claim in the brief is backed by a data point — no "users seem to like" without a number
✓
The Improvement Backlog contains at least one Tier 1 item (immediate action required)
✓
Every backlog item has evidence, user impact, business impact, estimated effort, and a priority tier
✓
The Next Iteration Roadmap has stated objectives tied to measurable metrics
✓
The commercial case for the next phase is explicit — not implied
✓
The roadmap includes a clear next step the client needs to take to proceed
✓
The Performance Brief has been reviewed internally before being presented to the client
✅ Module 8 complete. You have a Performance Brief, an Improvement Backlog, and a Next Iteration Roadmap. You have completed the full course.
Part 7 of 7 — Course Completion
You have completed the full course.
Eight modules. The complete lifecycle of AI-powered product delivery — from the first client conversation through to post-launch performance and the next engagement.
Module 1 — Decode the Brief
Understanding the client's real problem. Output: Discovery Summary + Concept Note
Every module produces an output that feeds the next. Every prompt builds on the documents produced in prior modules. Every quality gate checks that what you are handing forward is complete enough for the person receiving it to do their job without guessing.
This is not eight separate skills — it is one integrated system. AI accelerates every phase. Human judgment governs every decision. The combination is what produces delivery that clients trust and return to.
AI ROI & Savings Calculator
AI-Powered Product Delivery · Ideas2IT
How much could AI save your next project?
Answer 9 questions. Get a personalised ROI breakdown — across your PM/PO phase, dev phase, and rework avoided.
Estimated savings so far
$0
Complete the calculator to see your ROI
1
Project
2
AI Usage
3
Scope
4
Behaviour
Tell us about your project
Three inputs. Defaults are pre-filled — change only what applies to you.
Project type
Engagement type
Team size
2~8~1525
6 people
Project duration
1mo6mo12mo18mo
4 months
Cost basis — how would you like to estimate?
Using global average blended rate of $75/hr. You can adjust with the options above.
$
Blended hourly rate across your team
$
Total estimated project budget
Current AI usage
Be honest — this is where the savings delta is calculated. There are no wrong answers.
PM / PO side — how much AI do you use today in discovery, research, specs, and handoff?
Dev side — how much AI-assisted coding does your team use? (Cursor, Copilot, Claude Code)
Which phases are in scope?
Select all that apply to this engagement. AI saves differently across each phase.
Two more questions
These power the compounded savings calculation — the layer most calculators miss.
How often does rework happen due to unclear requirements?
Think about the last few projects — how frequently did mid-sprint changes, spec confusion, or scope disputes occur?
How structured is your current delivery process?
The less structured today, the more AI-driven process improvements will compound. Be honest.
Your estimated net saving with full AI adoption
$0
Across PM/PO phase, development, and rework avoided
Weeks saved
—
Timeline compression
AI tool cost
—
Total investment
ROI on AI
—
Return on AI investment
Where the saving comes from
🎯
Layer 1 — PM / PO phase saving
AI-assisted discovery, research, spec writing, and handoff documentation reduces PM/PO hours and produces better outputs in less time.
$0
⚡
Layer 2 — Development phase saving
AI coding tools (Cursor, Copilot, Claude Code) reduce dev hours on eligible workstreams — boilerplate, test generation, code review, and structured implementation tasks.
$0
🔁
Layer 3 — Rework avoided (compounded saving)
Better specs and structured handoff mean fewer mid-sprint changes, fewer bugs from misunderstood requirements, and less back-and-forth. This layer grows with rework frequency.
$0
Phase-by-phase breakdown
Phase
In scope
AI saving
Note
Gap analysis
You are capturing — of your total AI saving potential
Based on your current AI usage and phases in scope.
$0
Current trajectory
→
$0
Full lifecycle AI potential
Proposal pricing summary
Learn the full system
8 modules. Every phase of delivery. Free access for PMs and POs worldwide.
Talk to our team
We can show you what this saving looks like on your specific project.