Case study / Decision Intake prototype
A clearer way to make product decisions.
This prototype turns a messy request process into a workflow that is easy to review and test.
TL;DR
The Decision Intake prototype organizes requests, points out missing details, and shows how its early score was calculated. The score is only a starting point; people make the final roadmap call.
- Contribution
- Product strategy, workflow design, prototype build
- Product stage
- Testable prototype
- Primary user
- Product managers comparing requests from across a company
- Core output
- A scored request with the reason and decision history
90-second prototype test
Test one intake decision in 90 seconds
Use the sample launch-readiness request to test the workflow without entering personal or company information.
- 01
Review the sample request
Open “Executive dashboard for launch readiness” and review the problem, teams involved, wanted result, and current status.
CheckpointCan the request be understood without a meeting?
- 02
Check the early score
Review the missing details, warnings, and score breakdown. Decide which new fact could change the score.
CheckpointCan you question the suggestion by checking its inputs?
- 03
Reconsider the next step
Save a next-step decision with a written reason, then reset the sample data when you are done.
CheckpointCan another reviewer understand what changed and why?
The problem
The queue fills before the problem is clear.
Product requests often arrive as ready-made solutions across meetings, messages, and tickets. That makes the loudest ask easy to choose and the real need hard to compare.
- Requesters need a quick way to explain the need.
- Product needs enough detail to compare different requests.
- A score can make reviews more consistent without becoming the final answer.
- The decision and its reason need to be clear after the meeting.
What the prototype does
The prototype covers the full review loop.
- Different questions for bugs, improvements, and new ideas
- Required-field checks and drafts saved in the browser
- Weighted scoring with settings teams can change
- Warnings and tips for stronger requests
- Similar-request matching across title, problem, team, and request type
- Search, filters, table, and board views
- PM review with effort and confidence fields
- Status changes, comments, and decision history
- A sample-data reset for repeatable testing
Next research step / not yet run
Test whether the workflow improves the decision, not just the form.
This is the research plan for the next round of testing. No customer interviews or usability results are claimed for this portfolio prototype.
Research question
Can product managers choose and explain a next step from the request details, and can requesters provide those details without too much work?
Who to test with
- Three to five product managers who regularly review requests from other teams
- A mix of PMs working with small teams and PMs working with many groups
- At least one PM who manages intake without a Product Operations partner
- No participant needs prior knowledge of the prototype
What to watch
- How many people finish each intake step and how long it takes
- Questions that need help or are often skipped
- Whether the next-step choice changes after reviewing the full request
- Whether PMs can say which facts mattered without relying on the total score
- Whether a second reviewer can understand the written reason later
- 01
Submit the sample reporting request
Use the weekly onboarding report example to create a clear request without adding company or customer information.
Session taskPlanned
- 02
Compare two different requests
Compare the sample onboarding report and launch-readiness requests, then choose which should move ahead and explain why.
Session taskPlanned
- 03
Check the early score
Find an input or assumption that should change the launch-readiness result and describe the information needed to settle it.
Session taskPlanned
- 04
Record a decision and reset
Change a status, write the reason, find the decision history, and restore the sample starting point for the next session.
Session taskPlanned
How it works
Turn each request into a decision others can follow.
- 01
Capture the problem
Ask who is affected, what they do today, what happens if nothing changes, what result is wanted, and how success will be measured.
ProducesClear request
- 02
Check the evidence
Point out weak problem statements, missing users or results, timing conflicts, tight deadlines, and similar requests.
ProducesWarnings and similar requests
- 03
Create an early score
Score impact, company fit, urgency, and effort, then show how each part shaped the result.
ProducesScore, reason, and suggested next step
- 04
Keep the final call with a person
A PM finishes the review, changes the status with a note, adds comments, and leaves a history others can read.
ProducesDecision and history
How the score works
The score is clear by design, but it is not a fact.
Teams can change the weights. Each part uses PM input and request details such as users, results, timing, blockers, other teams, and technical readiness.
| Part | Default weight | Details used |
|---|---|---|
| Impact | 35% | Value for the business and users, people affected, cost of waiting |
| Company fit | 25% | Goal fit, wanted result, clear success measure |
| Urgency | 20% | Timing, frequency, deadline, risk of waiting |
| Effort | 20% | Work needed, blockers, other teams, technical readiness |
New requests wait for PM review. The backlog does not show a priority label until the PM fills in the review, so an early guess is less likely to be mistaken for a final call.
Sample decision comparison
The score helps sort the queue. The details decide what happens next.
This comparison uses sample requests and statuses to show how evidence shapes product choices. It does not report results from a real company.
01
Choice: AdvanceAutomate weekly onboarding reporting
Approved for discovery
The request names a weekly task, the four hours it takes today, a 30-minute goal, the teams involved, and the systems it needs. Research can now test whether the data and workflow will work.
Research takes time from operations, data, and engineering that could go to other requests.
Move past research only if the four-hour starting point is confirmed and the three systems can produce one trusted report.
02
Choice: HoldExecutive dashboard for launch readiness
Backlog
The launch problem matters, but five teams do not yet agree on what each status means or where it comes from. Building a dashboard first would only put that disagreement on a screen.
A broad dashboard would take time from product, engineering, data, operations, and sales before the status rules are settled.
Revisit when launch owners agree on milestone health, blocker levels, and one source for each update—or when one launch can be used as a smaller test.
03
Choice: Return for evidenceClean up duplicate support escalation tags
Needs more information
The daily sorting problem and 80% reduction goal are clear, but no one owns the tagging rules and the PM ratings for impact, fit, and effort are missing.
Starting without an owner could replace one set of messy tags with another and make other requests harder to compare.
Review again when support names an owner, shares how many tickets have several tags today, and completes the PM ratings.
Decisions and tradeoffs
Three choices that shaped the prototype.
01
Small steps instead of one long form
Group the form by request type, problem, result, details, and review so people can build the request one step at a time.
More steps mean more clicks, but each page is shorter and easier to understand.
02
Explain the score
Show the score breakdown, strongest and weakest details, tips, and a plain-language reason beside the suggestion.
The page includes more detail, but people can check the inputs instead of trusting a mystery number.
03
Test the workflow before connecting other tools
Use typed browser storage and sample data to test the decision flow before adding logins, a shared database, and other tool connections.
The prototype is ready to test now, but it is not a shared live product or proof that a company has adopted it.
Build details
See what was built, left out, and needed before a pilot.
This section lists what works today, what was left out on purpose, and what must be true before a real pilot.
What works
- Guided request form with draft saving and required-field checks
- Clear weighted score, warnings, and similar-request matching
- Searchable backlog with PM review, status changes, comments, and decision history
- Score settings and a repeatable sample-data reset
What it will not do
- Make roadmap decisions or replace PM judgment
- Act as a shared live system
- Connect to live Jira, CRM, analytics, or support data
- Claim that the score is proven or that the tool has business results
- 01
Draft
Save unfinished form answers in this browser and remember the current step.
Human decisionThe requester decides when the problem and details are ready to submit.
- 02
Backlog
Check required fields, calculate an early suggestion, and add the submission to decision history.
Human decisionThe PM reviews the details instead of treating the early score as approval.
- 03
PM evaluation
Update the breakdown as company fit, impact, effort, and confidence fields are completed.
Human decisionThe PM checks assumptions, reviews similar requests, and notes missing information.
- 04
Decision state
Save the status, note, comments, time, and prior status in a readable history.
Human decisionThe PM chooses research, build, backlog, more information, rejection, or another clear next step.
Less common cases checked
- A draft is saved again after a submitted request is edited
- A request is urgent but missing impact or effort details
- Two requests appear similar by title, problem, team, or request type
- Score weights change after sample requests were reviewed
- Browser storage is empty, unavailable, or reset
- A status changes more than once and the original reason must stay visible
What must work
- A requester can save an incomplete draft without creating a submitted backlog item.
- Submitting a complete form creates a backlog request and a decision-history entry.
- Every score shows how each part was calculated, the details used, and any warnings.
- A PM can finish the review without the system changing the status on its own.
- Every status change saves the old state, new state, author, time, and written note.
- Sample data can be restored so the review can be tested again.
Analytics plan
The prototype does not track behavior yet. Before a pilot, the next step is to define events, set safe data boundaries, and record baseline measures.
| Planned event | What it would test |
|---|---|
| intake_started → request_submitted | Measure where people finish or leave the form. |
| quality_warning_resolved | See whether prompts improve request details before PM review. |
| pm_evaluation_completed | Measure time from submission to a clear next step. |
| recommendation_overridden | Find where the score and the PM call disagree, then review why. |
| status_changed_with_note | Check whether decisions include a reason others can understand. |
Checks before a pilot
- Test sessions show that people can finish the form without repeated help.
- PMs can explain decisions from the request details instead of the total score alone.
- Past requests are used to check the score weights for clear mistakes before the score affects planning.
- Logins, roles, shared storage, data rules, and decision history pass security and privacy review.
- A small pilot has one owner, starting measures, a way to undo changes, and a set review date.
Where people make the call
The model organizes evidence. The PM owns the call.
- System
- Organizes details, points out gaps, calculates an early score, and saves the history.
- Product manager
- Checks assumptions, weighs tradeoffs, changes the status, and records why.
- Team
- Adds information, questions the rules, and tests whether the workflow improves real decisions.
Validation plan
The next proof is better decisions, not more features.
The prototype is ready to test for ease of use and decision quality. These are goals, not reported results.
Request quality
Fewer submissions returned for missing context
Review efficiency
Time from submission to a documented next step
Decision clarity
Reviewers can explain why one request advanced over another
Business value
Revenue gained or protected, cost saved, or hours returned after chosen work ships
System trust
PMs change inputs instead of ignoring or blindly accepting the score
Before a real pilot
A real pilot would add logins, roles, shared storage, tool connections, analytics, and a review of the score settings against past decisions before the defaults affected planning.
Explore the work
Test the workflow, then see how it was built.
Use the sample prototype to submit and review a request, or explore the source code in the repository.
Return to portfolio