Product proposal
Connect a user problem and evidence to a bounded solution, expected value, a validation plan, resource estimates, and the decision required.
Use this project worksheet when a product idea is only a feature list. Start with the user task and evidence, then describe the smallest proposal that can be assessed. Help a reviewer decide whether to investigate further, test a prototype, or commit resources.
User-task evidence, intended users and scenarios, current alternatives, a proposed solution, resource estimates, and known risks. Identify missing acceptance criteria, ownership, and authority.
A reviewable product proposal that separates expected value from evidence, states exclusions, and identifies validation and approval conditions.
How to use it
- State the problem, its evidence, and the intended user task. Identify who uses the product and whether payment and decision roles are known.
- Describe a bounded solution and exclusions. Explain expected value relative to the current task or alternatives, marking untested benefits.
- Define what a prototype or pilot will observe. Agree acceptance and exit criteria before committing development; leave absent thresholds unconfirmed.
- Record resource estimates, dependencies, and risks. State the decision being requested and preserve the distinction between a request and approval.
Keep its limits in mind
This is BizThinkFrame's proposal structure, not a standard approval template. Interview interest is not a purchase or permission to build. Estimated work is not an approved schedule, and a pilot plan is not a validated result. User, payer, and decision-maker roles may differ.
Propose a controlled review link
Fictional example: Yunqiao interviews 12 design studios; 7 say clients are reluctant to register another account. The proposal is a controlled link for external review. A prototype is estimated at one week and minimum development at two weeks. A five-studio test is planned; approval and results are not supplied.
On a small screen, scroll across the diagram to read it.
Start with the unit of evidence: Seven of twelve studios reported client registration reluctance. This is not seven of twelve people and does not establish how common the problem is across the market. Lower entry friction is an expected benefit of the proposal.
Make the decision conditions visible: A one-week prototype and two-week minimum development are separate estimates; overlap and assigned resources are unknown. Five studios would test completion and permission understanding. Thresholds must be agreed, and link risks checked, before development or pilot approval is assumed.
Next step: Agree validation and exit criteria, then test the prototype with target users and check permission understanding. Ask for the bounded pilot decision with resources and risks visible.
Three reasons to return a proposal for clarification
First, return it if the problem is merely a feature request with no identifiable user task. Ask what people are trying to accomplish, what happens now, and what evidence supports the difficulty. User, payer, administrator, and reviewer may be different roles. Do not assign purchasing authority to someone just because they joined an interview.
Second, pause if the solution avoids a risk by leaving it out of the proposal. A direct link can reduce one entry step while creating forwarding or access problems. Put permission behavior, exclusions, and failure cases next to the expected value. A simpler first interaction is useful only if the product still respects the access required by the task.
Third, do not request full development on the strength of an attractive prototype estimate. Estimates need people, dependencies, and availability. Validation needs acceptance conditions and an exit decision agreed in advance. A proposal can legitimately ask for more investigation; it does not have to pretend that demand, safety, and delivery are already settled.
Choose the document that matches the investment decision
This is a site proposal structure, not a universal approval standard. Select a different method if the missing work is problem framing, a whole business model, or a comparison of already feasible choices.
| What you have | Method | Output and boundary |
|---|---|---|
| A task problem, evidence, a solution, and risks | Product proposal | A bounded request to investigate or invest; no automatic approval. |
| A broad objective with unclear exclusions | Issue definition worksheet | An agreed investigation boundary; not a product specification. |
| An offering with uncertain customers, delivery, and economics | Business Model Canvas | Connected assumptions; the canvas does not validate profitability. |
| Several feasible options with constraints and criteria | Decision matrix | Tradeoffs with reasons; no fabricated benefit scores. |
Turn the review-link idea into a conditional request
The fictional Yunqiao packet reports interviews with 12 design studios. Seven studios say clients are reluctant to register another account. The intended users are managers of 10–30-person studios and external client reviewers; the payer is unspecified. The proposed controlled link would allow direct review and bind feedback to a version. A full client portal is excluded. Estimates are one week for a prototype and two weeks for minimum development, with no staffing, cash budget, or overlap supplied.
The validation plan names five studios and two observations: task completion and understanding of permissions. The packet supplies no acceptance threshold, recruitment method, completed test, or pilot approval. Keep this five-studio plan separate from the twelve-studio interview evidence. Seven reporting studios are not seven individual reviewers, and the interviews establish neither purchase commitment nor the share of the whole market facing the problem.
Organize the request around the uncertainty that matters next. The expected value is less friction before first feedback. The product must also support authorized review, correct version identification, and the intended revocation behavior. Before implementation, agree what the prototype can represent and which technical behavior needs a separate check; a clickable screen cannot establish that server-side access controls work.
| Packet record | Proposal implication | Unresolved condition |
|---|---|---|
| 7 of 12 studios report account reluctance | Investigate direct review as one response | Client task behavior and alternative explanations. |
| Controlled link, version-bound feedback; no full portal | Keep the solution narrowly specified | Allowed audience, forwarding, expiry, and revocation behavior. |
| Plan a five-studio test | Observe completion and permission understanding | Selection, task, acceptance and exit conditions. |
| Prototype 1 week; minimum development 2 weeks | Keep both estimates visible | People, costs, dependencies, overlap, and approval. |
Review findings before expanding the commitment
The conclusion is a request to agree validation conditions and then decide on a bounded prototype or pilot. Do not add the two estimates into a promised three-week delivery date: even a sequential plan would still need a start, availability, and dependencies. The current record also does not authorize either stage. Name the decision-maker when known and record their actual response separately from the requested choice.
The proposed task review should retain each participating studio’s status, the actual reviewer role, whether the task was attempted and completed, and what permissions the person believed the link granted. Define reporting units before calculating a completion rate; multiple reviewers in one studio are not automatically independent studios. Test forwarded and revoked links against the specified access behavior, using appropriate test data. No outcomes are supplied here.
At the decision review, report usability findings, technical access checks, remaining exclusions, actual effort, and revised estimates separately. If people finish feedback but misunderstand who can view it, the value hypothesis may look promising while the access risk still blocks release. Record whether to revise, investigate, stop, or authorize a bounded next stage, together with reasons. A completed proposal remains a decision aid, not evidence that the product has been approved or validated.
Check your work
- Evidence counts retain the correct unit, such as studios rather than people.
- The solution has explicit exclusions and a task-focused rationale.
- Expected benefit and differentiation remain hypotheses unless supported by evidence.
- Estimates include prototype and development work without assuming whether they overlap.
- Validation criteria, resources, risks, and the requested decision are visible; missing details stay unconfirmed.
Framework references
References explain the framework and its scope; they do not validate the fictional example's results.
Put the framework to work
Copy the outline and add your question, evidence, and open questions.
Practice with an example
Switch denominators for the same cohort counts, distinguish the first task from later use, and leave with a bounded problem statement and evidence plan.
New users aren’t coming back. What should you check first? →