Ananya Iyer

Turn a One-Paragraph Feature Idea Into a Lean PRD

Expand a one-paragraph feature idea into a lean PRD with non-goals, testable acceptance criteria, edge cases, a guardrail metric and open questions.

At a glance

Best for: Product managers and founders who have a clear idea in their head and need a buildable spec by the next planning meeting.
Tested on: Claude · Opus 5.5
You fill in: ideacontextconstraints
You get: Receipt split: PRD (draft) This is one feature. Manual splitting already exists, so we're automating how the split gets filled in. Problem… (full result below)

product-management

startups

writing

Prompt

Turn this feature idea into a lean product requirements document that an engineer and a designer could start from on Monday.

Idea: {{idea}}
Product and users today: {{context}}
Constraints (team, deadline, tech): {{constraints}}

Structure:

1. Problem - who has it, how often, and what they do today. Mark anything you're inferring with (assumption).

1. Goal and non-goals - one measurable goal; at least 3 explicit non-goals.

1. User stories - max 5, "As a..., I want..., so that...", each with 2-3 acceptance criteria written as testable statements.

1. Edge cases - the 5 most likely ways this breaks or confuses users.

1. Success metric - the primary metric, a guardrail metric that must not get worse, and how we'll measure both.

1. Open questions - what must be answered before build, and who should answer each.

Keep it under 450 words. No filler sections (no "Background", no stakeholder table). If the idea is really two features, say so and write the PRD for the one that should ship first.

Fill in

{{idea}}: The feature idea in one paragraphe.g. Photograph a receipt and auto-split the transaction across budget categories
{{context}}: The product, its users, and relevant existing behavioure.g. UK budgeting app, 40k MAU, manual splits exist but only 4% of supermarket transactions are split
{{constraints}}: Team size, timeline and technical limitse.g. 2 engineers + 1 designer for 6 weeks, React Native, existing LLM API with vision

Example input

idea: Let users snap a photo of a paper receipt and have the transaction automatically split across categories (e.g. a supermarket shop that's partly groceries, partly household, partly alcohol) instead of logging the whole amount as "Groceries".
context: Moneyjar, a UK personal budgeting app with 40k monthly active users. Bank transactions arrive via open banking with a merchant name and a single category. Users can already split a transaction manually into up to 5 categories, but only 4% of supermarket transactions are ever split.
constraints: 2 engineers + 1 designer for 6 weeks; we already pay for an LLM API with vision; iOS and Android via React Native.

1.8k0

Generated Outputs (1)

3 hours ago

Claude

Opus 5.5

3 hours ago

Generated Output

Receipt split: PRD (draft)
This is one feature. Manual splitting already exists, so we're automating how the split gets filled in.

1. Problem
Supermarket transactions mix categories but land entirely in "Groceries", so users' category budgets are wrong. Only 4% get split, because splitting by hand means reading the receipt and typing each amount. Users who care probably live with the error or keep a side spreadsheet (assumption). Most users shop at a supermarket weekly (assumption).

2. Goal and non-goals
Goal: raise the share of supermarket transactions that get split from 4% to 15% within 8 weeks of launch.
Non-goals:

• Item-level price history or spending by product.

• Receipts with no matching bank transaction (cash).

• Email or app receipts in v1.

• Keeping receipt images long term.

3. User stories

1. As a user, I want to photograph a receipt from a transaction's detail screen, so that it's split without typing.

- A "Split with receipt" button opens the camera from any transaction.
- A proposed split appears within 10 seconds for a 40-line receipt (p90).

1. As a user, I want to review and change the proposed split before saving.

- Every line's category can be changed before saving.
- Save is disabled unless the split sums to the transaction amount.

1. As a user, I want to know when the receipt and bank amount don't match.

- If they differ by more than 1p, both totals are shown and I can assign the difference or retake.

1. As a user, I want my own categories used.

- Proposals only use categories from my existing list.
- Lines the model can't classify default to the transaction's original category.

4. Edge cases

1. Multi-buy and loyalty-card discounts printed as separate negative lines.

1. Long receipts photographed in two parts, or faded thermal paper.

1. Cashback or bag charges included in the bank amount.

1. Refunds and part returns.

1. Photos that capture a loyalty card number or other personal data.

5. Success metric
Primary: % of supermarket transactions split within 7 days (target 15%).
Guardrail: abandonment of the receipt flow (camera opened, split not saved) stays under 40%.
Measure: events for receipt_split_started and receipt_split_saved, plus edits per saved split as a proxy for accuracy.

6. Open questions

• Can we send receipt images to our LLM provider under our current privacy policy? (Data protection lead, before build)

• Delete images immediately after extraction, or keep them 30 days for debugging? (Product + data protection lead)

• Cost per scan if 20% of users scan weekly? (Engineering, week 1)

Why it works

"Mark anything you're inferring with (assumption)" keeps invented user research out of the problem statement. Demanding at least 3 non-goals is the cheapest scope control there is; most PRDs that overrun never said what they wouldn't do. Acceptance criteria as testable statements give QA and engineers something to check. A guardrail metric stops a team from hitting the headline number by making something else worse. The word cap and the ban on filler sections keep it a working document rather than a template to fill in.

When not to use it

Skip it for tiny changes a ticket can describe, and for research-heavy problems where you don't yet know what to build; run discovery interviews first. The model doesn't know your analytics, legal position or architecture, so every number and open question still needs an owner to confirm it before build starts.

Comments (0)

No comments yet. Be the first to share your thoughts!