A product development SOP template should keep those evidence gaps visible. The procedure below connects a proposed user problem to a hypothesis, prototype, planned test, observation record and decision. It supports iteration and a later request for release review; it does not authorize launch.
Give the procedure a bounded purpose
Confirm the actual SOP owner, version, effective date, product scope, research approval route and decision authority before use. These are organizational inputs, not universal stages supplied by this template.
Atlassian describes prototypes as versions built to learn from and testing as work that produces findings, issues and decisions about what blocks launch. We use that prototype–evidence–decision structure without adopting its numbered process as mandatory policy. Product development process
The original example is Idea I01, a small proposed tool to help volunteers identify missing submission fields. Actual problem evidence E01 is TO CONFIRM. The idea describes an intended audience and task; it does not establish that real volunteers have this problem.
Make the hypothesis observable
| Planning record | Example entry |
|---|---|
| Problem evidence E01 | TO CONFIRM; obtain the actual source of the reported need. |
| Hypothesis H01 | A user can identify the missing contact reference without a facilitator hint. |
| Proposed prototype P01 | Mock submission R01 contains a project title and description; contact reference is blank. |
| Planned test T01 | Ask the participant to identify which field is missing. |
| Expected answer | Contact reference; test-owner reference, not an actual response. |
| Actual participant observation | Blank; no participant has run this test. |
| Current hypothesis state | Unvalidated |
The phrase “without a facilitator hint” matters. If the facilitator points to the empty contact field, the resulting answer does not demonstrate independent identification. Keep all assistance in the observation record.
The prototype is bounded to this missing-field task. It does not submit a project, verify contact details, authorize participation or establish a complete product's usability.
Follow a repeatable development procedure
| Step | Required output | Decision or hold |
|---|---|---|
| 1. Capture the problem | User problem statement and source reference | If E01 is absent, keep the need unconfirmed. |
| 2. State a testable hypothesis | H01, target task and scope | Define the observation that would support or challenge it. |
| 3. Prepare the prototype | P01 version and bounded mock input R01 | Confirm the prototype matches the question being tested. |
| 4. Plan the test | T01 task wording, expected observation and assistance-recording fields | Keep expected answers separate from results. |
| 5. Confirm the research process | Approved participant/research route and actual permission references | Do not invent participants, permissions or completed sessions. |
| 6. Record actual observations | Words/actions, hints, version, context and evidence references | Preserve contrary results and incomplete observations. |
| 7. Decide using the evidence | Iterate, stop or request further review, with reason and authority | Do not call a planned test validation. |
| 8. Preserve issues and retests | Issue reference, revised version and actual retest evidence | A revision alone does not close an issue. |
Use this planned T01 script: “Look at this mock submission. Which field is missing?” Record the actual task wording if it changes. Do not quietly help the participant and then report the result as unaided.
The observation form should contain blank fields for test ID, prototype version, permitted participant reference, context, exact task wording, observed actions/words, facilitator hints, result interpretation and evidence reference. Keep actual participant identifiers and data under the organization's approved research process.
Show the iteration branch without pretending it happened
Use a separate illustrative branch O02: suppose a participant identifies the missing contact reference only after a hint. This is fictional planning evidence, not a result of T01.
That branch proposes issue B01: wording unclear. The observed need for a hint would warrant investigation; unclear wording is a proposed interpretation to test, not a proven cause. Other explanations may remain open.
Plan revised prototype P02 and retest T02. The actual revised wording and retest results are not supplied. Retain the sequence O02 → B01 → proposed P02 → planned T02 so a new screen does not erase the question that motivated it.
| Issue/retest field | Actual entry |
|---|---|
| Actual observation and evidence reference | |
| Issue and interpretation; alternatives to investigate | |
| Authorized iteration decision and reason | |
| Revised P02 version and exact change | |
| T02 plan and assistance-recording method | |
| Actual retest observations and remaining uncertainty | |
| Issue review/closure decision and evidence |
If no retest occurs, keep B01's resolution unconfirmed. If a retest includes assistance, preserve that context. Neither a new prototype nor a correct expected answer is proof that the hypothesis was validated.
Keep release review separate
A supported test decision may justify asking for further development or release review. It does not replace the organization's actual release checks. Record the requested review, required owner-defined prerequisites, open issues and authority to decide; leave actual approvals and release status blank until supplied.
This example has no actual users, test count, success metric or launch. Keep the native hypothesis, test, issue and decision records as the evidence trail.
Copy this prompt for the development SOP
Create one complete, self-contained US-English HTML companion for “I01 hypothesis and retest evidence”. Return the full HTML document, with inline CSS and any JavaScript needed for the local interactions. Use the original scenario, named records, numbers and expected cases below.
Design the page for this task: use clearly labeled input or source records, a readable result or worked example, and an adjacent explanation of the evidence. Use a restrained visual hierarchy, left-aligned text, readable tables or stacked records, and a responsive layout at 720px and 360px. Provide meaningful labeled controls for T01 · planned test; O02 · fictional branch; T02 · planned retest; Select text. Use keyboard-accessible native controls and visible focus. Keep the complete content readable without an external dependency.
The following brief supplies the substantive content and constraints. Native-format requests describe the material to represent or copy manually; this HTML must not pretend to create DOCX, XLSX, PDF, PPTX, H5P or another native file, run Python/Flask/Django/Snowflake/Power BI, connect a live service, send messages, or perform an authorized real-world action. Where the task requires a native source, actual observation or separate approval, retain that requirement and leave unsupplied evidence blank.
Prepare an original US-English product development SOP and reusable hypothesis/test/observation/issue/decision/release-review records. Do not impose a mandatory seven-stage policy or claim launch, real users or completed tests. Actual owner/version/effective date, research approval process and decision/release authorities are TO CONFIRM.
Fictional I01 is a proposed tool helping volunteers identify missing submission fields. Actual problem evidence E01 is TO CONFIRM. H01: user can identify a missing contact reference without facilitator hint. P01 mock R01 has title/description and blank contact reference. Planned T01 asks “Look at this mock submission. Which field is missing?” Expected answer: contact reference. No participant has run it; observations/results blank; H01 unvalidated.
Procedure: source problem; state falsifiable task/scope; prepare bounded prototype; plan test and expected observation; obtain approved research/participant process; record actual words/actions and all assistance; decide iterate/stop/request review using evidence; preserve issues, versions and retest references. Blank actual form fields: test/version/permitted participant/context/task wording/actions/words/hints/interpretation/evidence.
Separate fictional branch O02: answer requires a hint. Proposed B01 interpretation is wording unclear, not a proven cause. Plan revised P02 and retest T02, exact changes/results unknown. Preserve O02/B01/P02/T02 chain and alternative explanations. Revision without retest does not automatically close B01; assisted completion is not unaided evidence. Keep actual findings and decisions blank.
Include a separate release-review prerequisite record with actual organization-defined checks/authority TO CONFIRM. Prototype/test decisions do not approve release. Native evidence records remain authoritative. No fabricated counts, success metric, submission, participant data or actual approvals.
COMPLETE AUTHORED SCENARIO AND EXPECTED CASES
The following is the supplied reading/teaching/calculation record to represent in the companion. Preserve its particular content, examples, source references and unknowns. Wording about a future native implementation refers to that native task, not permission to omit this HTML companion.
# Product Development SOP Template: Trace the Idea to a Testable Decision
The prototype is ready and the test script includes the expected answer. Someone marks the idea validated, even though no participant has tried it. Another mock example shows a participant needing a hint, but the issue disappears when the team redraws the screen.
A product development SOP template should keep those evidence gaps visible. The procedure below connects a proposed user problem to a hypothesis, prototype, planned test, observation record and decision. It supports iteration and a later request for release review; it does not authorize launch.
## Give the procedure a bounded purpose
Confirm the actual SOP owner, version, effective date, product scope, research approval route and decision authority before use. These are organizational inputs, not universal stages supplied by this template.
Atlassian describes prototypes as versions built to learn from and testing as work that produces findings, issues and decisions about what blocks launch. We use that prototype–evidence–decision structure without adopting its numbered process as mandatory policy. [Product development process](https://www.atlassian.com/agile/product-management/new-product-development-process/)
The original example is **Idea I01**, a small proposed tool to help volunteers identify missing submission fields. Actual problem evidence **E01** is TO CONFIRM. The idea describes an intended audience and task; it does not establish that real volunteers have this problem.
## Make the hypothesis observable
| Planning record | Example entry |
| --- | --- |
| Problem evidence E01 | TO CONFIRM; obtain the actual source of the reported need. |
| Hypothesis H01 | A user can identify the missing contact reference without a facilitator hint. |
| Proposed prototype P01 | Mock submission R01 contains a project title and description; contact reference is blank. |
| Planned test T01 | Ask the participant to identify which field is missing. |
| Expected answer | Contact reference; test-owner reference, not an actual response. |
| Actual participant observation | Blank; no participant has run this test. |
| Current hypothesis state | Unvalidated |
The phrase “without a facilitator hint” matters. If the facilitator points to the empty contact field, the resulting answer does not demonstrate independent identification. Keep all assistance in the observation record.
The prototype is bounded to this missing-field task. It does not submit a project, verify contact details, authorize participation or establish a complete product's usability.
## Follow a repeatable development procedure
| Step | Required output | Decision or hold |
| --- | --- | --- |
| 1. Capture the problem | User problem statement and source reference | If E01 is absent, keep the need unconfirmed. |
| 2. State a testable hypothesis | H01, target task and scope | Define the observation that would support or challenge it. |
| 3. Prepare the prototype | P01 version and bounded mock input R01 | Confirm the prototype matches the question being tested. |
| 4. Plan the test | T01 task wording, expected observation and assistance-recording fields | Keep expected answers separate from results. |
| 5. Confirm the research process | Approved participant/research route and actual permission references | Do not invent participants, permissions or completed sessions. |
| 6. Record actual observations | Words/actions, hints, version, context and evidence references | Preserve contrary results and incomplete observations. |
| 7. Decide using the evidence | Iterate, stop or request further review, with reason and authority | Do not call a planned test validation. |
| 8. Preserve issues and retests | Issue reference, revised version and actual retest evidence | A revision alone does not close an issue. |
Use this planned T01 script: **“Look at this mock submission. Which field is missing?”** Record the actual task wording if it changes. Do not quietly help the participant and then report the result as unaided.
The observation form should contain blank fields for test ID, prototype version, permitted participant reference, context, exact task wording, observed actions/words, facilitator hints, result interpretation and evidence reference. Keep actual participant identifiers and data under the organization's approved research process.
## Show the iteration branch without pretending it happened
Use a separate illustrative branch **O02**: suppose a participant identifies the missing contact reference only after a hint. This is fictional planning evidence, not a result of T01.
That branch proposes issue **B01: wording unclear**. The observed need for a hint would warrant investigation; unclear wording is a proposed interpretation to test, not a proven cause. Other explanations may remain open.
Plan revised prototype **P02** and retest **T02**. The actual revised wording and retest results are not supplied. Retain the sequence `O02 → B01 → proposed P02 → planned T02` so a new screen does not erase the question that motivated it.
| Issue/retest field | Actual entry |
| --- | --- |
| Actual observation and evidence reference | |
| Issue and interpretation; alternatives to investigate | |
| Authorized iteration decision and reason | |
| Revised P02 version and exact change | |
| T02 plan and assistance-recording method | |
| Actual retest observations and remaining uncertainty | |
| Issue review/closure decision and evidence | |
If no retest occurs, keep B01's resolution unconfirmed. If a retest includes assistance, preserve that context. Neither a new prototype nor a correct expected answer is proof that the hypothesis was validated.
## Keep release review separate
A supported test decision may justify asking for further development or release review. It does not replace the organization's actual release checks. Record the requested review, required owner-defined prerequisites, open issues and authority to decide; leave actual approvals and release status blank until supplied.
This example has no actual users, test count, success metric or launch. Keep the native hypothesis, test, issue and decision records as the evidence trail.
Implement the local companion rather than returning a text-only plan. Preserve every numerical fixture and the distinction between illustrative expectations and actual evidence. Any native-runtime or classroom tests mentioned above remain tests to perform in the proper environment; do not mark them passed. Keep edits and practice responses in this open page only, without claiming persistent storage. Provide invalid/missing-input feedback and reset behavior that agree with this specific brief. Do not claim accessibility certification, learning gains, real approvals or test results that were not observed.
Review the evidence chain before the next decision
Keep the maintained research and decision records authoritative; the review does not run a participant test or approve release.
Make the next decision traceable to an observation—or keep it explicitly open when the evidence has not arrived.