Guide
Turn a confirmed problem, requester’s role and known limits into a requirements draft. Mark assumptions separately. The team still needs to approve scope, budget, dates and success criteria.
Your worksheet stays in this page and is lost when you leave or reload. Copy it before leaving. Only guide completion is saved. Do not enter sensitive information.
Prepare a small PRD for filtered CSV export. Use the supplied fictional request, not guesses about what a team must want. It is a separate clarified example: the earlier feedback exercise did not obtain these decisions from real people. You can draft it yourself or use one approved assistant. Keep private records out. A polished PRD can ask for a decision; it cannot make one on everyone’s behalf.
Prepare a small PRD for filtered CSV export. Use the supplied fictional request, not guesses about what a team must want. It is a separate clarified example: the earlier feedback exercise did not obtain these decisions from real people. You can draft it yourself or use one approved assistant. Keep private records out. A polished PRD can ask for a decision; it cannot make one on everyone’s behalf.
Fictional request and test material. [R1] Requester: operations. Request: export only the activity-list rows that match the current filter as CSV. This refers to filter matches, not manually checked rows. [R2] Export must preserve the selected columns. [R3] Scheduled emails are outside this request. [R4] Not agreed: file-size/row limits, export permissions, delivery date, budget, outcome metrics, empty-result behavior, row ordering, encoding and handling of formula-like cell values. No approval or implementation is reported. [R5] Synthetic acceptance example, not a production dataset: rows A (label Alpha, state active), B (label Beta, state archived), C (label Gamma, state active). Filter: state = active. Selected columns: id and label. No manual row-selection step is specified. Keep R1–R5 when editing. The examples make the request testable; they do not settle the open rules in R4.
Use only the supplied request and preserve its source labels. Write a review draft with background/problem, stated behavior, non-goals, proposed acceptance cases, unresolved decisions and a next review action. Keep explicit requirements separate from assumptions. If the request is the fictional R1–R5 export example, distinguish filtered rows from manual selection and show R5’s expected CSV header and rows without claiming general CSV policy is settled. For another request, use its actual behavior and relevant examples; do not add export or CSV requirements. Keep all source unknowns open. Label acceptance cases as proposed, not approved or executed. Flag missing permissions or data-handling decisions where relevant before release. Do not invent dates, budgets, gains, access rules or extra features. Request:
PRD draft — filtered activity CSV export; for review, not approved Problem and requester [R1] Operations wants a CSV containing the activity rows that match the current filter. The request does not quantify time saved, frequency or business impact. Stated behavior [R1–R2] Export the filter-matching rows and selected columns. Do not require manual row selection: it is not part of the supplied request. This section records the request, not team approval. Non-goal [R3] Scheduled emails. No scheduling, recipients or automatic sending is proposed here. Proposed acceptance cases — not run [R1, R2, R5] AC1. Given rows A/B/C and state = active, when exporting, the file contains A and C and excludes B. Check row identities, not just a total of two rows. AC2. Given columns id and label are selected, the file has those columns and no state column. Compare both headers and each row’s values. Illustrative CSV: id,label A,Alpha C,Gamma These safe fictional values need no special quoting. This display is one possible row order, not a general ordering requirement. Do not infer handling of commas, quotes, newlines, encoding or spreadsheet formulas from this tiny example. AC3. Repeat with a different filter only after agreeing the test data and expected row set. Do not mark a test passed just because a file downloaded. Decisions still needed [R4] Access and data: who may export which rows and columns? Which permission checks must hold? The request grants no new access. Limits and failures: maximum rows/file size, empty results and how errors are shown. CSV behavior: row order, encoding, escaping and safe handling of formula-like values when opened in spreadsheet tools. Delivery and evaluation: owner, date, budget and success measures. All remain undecided. No measured improvement is supplied. Next review action — proposed, not sent Ask the requester to confirm filter semantics and selected-column behavior. Ask the responsible product/security/engineering owners to settle access, data handling and limits before release. Record accepted decisions with their owner/date and revise the draft. Do not begin a release on the assumption that open permission rules are harmless. Repair exercise Wrong: “Ship admin-only manual-row export next Friday and lift activation by 20%.” Repair: “The request is filtered-row export with selected columns [R1–R2]. Manual selection, admin-only access, next Friday and a 20% gain are not supplied. Access, delivery and outcome measures need review [R4].” Keep the source with the draft so reviewers can distinguish the request from proposed checks and undecided policy.
Use R5 to verify the CSV yourself: A and C are active, B is archived; id/label are selected and state is not. Row count alone can hide the wrong row. Compare exact row membership and values. Keep the row-order policy unresolved. Check each requirement and non-goal against R1–R4. Remove manual-selection steps, invented access rules, deadlines and percentage gains. Are proposed cases still marked not run? Are unresolved permissions/data rules visible as release decisions, rather than hidden in a footnote? Write the correction in your draft before checking below. These ticks record document review, not product acceptance or permission to ship.
Copy the reviewed PRD and unresolved decisions before leaving; edited worksheet text is not saved here. Use the roadmap-priority Task below to discuss this request against a stated objective, capacity and other work; the draft does not automatically earn a place in the roadmap. Use stakeholder update to explain proposed scope and ask for decisions, not announce an approved launch. AhaDo does not send these messages or create delivery commitments. Completion here means a review draft is ready, not that requirements are approved, tests passed or a feature shipped.
Saved for this browser session. Sign in keeps it attached to you on this device.
Editorial workflow with a synthetic example. No measured user outcome or provider performance claim.
Point out a missing step or an unsafe claim. Your note is saved in your workspace for review.
Other products from our team
DictoGo AI dictionary with offline lookup, native examples and an AI speaking coach
DictoBoard An iOS keyboard that shows bilingual definitions as you type
CS Keyboard Save frequent replies once and send them with one tap
Contrack WhatsApp attribution for TikTok Ads
Inboxto Anonymous email addresses that keep spam out of your real inbox
Phonics Joy Master English phonics in 5 minutes a day
Math Joy Fun arithmetic practice for kids
GroomGain Revenue clarity for independent pet-grooming salons
Authloom A local-first 2FA authenticator with encrypted recovery you control
Skillstore Security-audited skills for Claude, Codex and Claude Code
Flicklish Turn videos you choose into short English lessons with subtitles and an AI Coach