FormForge User Story Map - Review
Stage 2 framework findings page for the pending user-story-map framework in the parent $journey-map loop. This page previews the non-canonical working packet and asks for approval before writing research/journey-map-user-story-map.md.
Research Scope Approved
Status: review pending
Date: 2026-07-02
Parent manifest: research/_working/journey-map-run.yaml
Selected frameworks: service-blueprint completeuser-story-map in review
Scope: flat research/ FormForge client-service intake/onboarding scope.
Output boundary: this run writes only research/_working/preliminary-user-story-map-research.md and this review page. The canonical intermediate is not written until compiled YAML approves it.
Executive Findings
Backbone
The story map centers on client-service intake: recognize need, draft, tailor, publish, collect, review, hand off, and reuse.
Confidence: high, grounded in approved ICP and code.
Walking Skeleton
The existing product surface already supports the thinnest end-to-end path from draft to public response and CSV export.
Confidence: high, observed in routes and routers.
Main Gap
The highest-value story gap is not more generic form creation. It is response readiness and handoff into service delivery.
Confidence: medium-high, research-backed but not customer-validated.
Activity Backbone
Backbone Coverage
| Activity | Coverage | Basis |
|---|---|---|
| Recognize intake need | Research high | ICP trigger events and current-state journey. |
| Draft intake form | Code high | AI route and generation service. |
| Tailor form | Code high | Editor, field palette, settings, and form router. |
| Publish and share link | Code high | Publish mutation, version snapshots, public route. |
| Complete intake | Code high | Public renderer, validation, Turnstile, submit API. |
| Review response readiness | Partial | Responses, status, stats, analytics exist; readiness scoring does not. |
| Export or hand off answers | Gap | CSV export exists; native workflow handoff is absent. |
| Reuse and improve | Partial | Duplicate/regenerate/analytics exist; intake libraries and quality metrics do not. |
| Activity | Persona | Goal | Evidence |
|---|---|---|---|
| Recognize intake need | Owner-operator, consultant, coach, small-agency operator | Realize a new client, offer, cohort, or project needs a structured intake artifact now. | research/icp.md trigger events; current-state journey. |
| Draft intake form | Buyer/user | Get from plain-language need to a usable first draft without blank-page setup. | ICP blank-page pain; README core loop; AI route and generation service. |
| Tailor form for client/service | Buyer/user, sometimes ops coordinator | Adjust fields, wording, required flags, logic, theme, settings, and publication readiness. | ICP value drivers; editor/settings UI; form router. |
| Publish and share link | Buyer/user | Send a credible intake link to the client without respondent account friction. | README core loop; publish mutation; public route; immutable snapshots. |
| Complete intake | External client/respondent | Submit required information, files, preferences, and constraints with minimal friction. | ICP respondent dynamic; submit route validation; Turnstile; renderer fields. |
| Review response readiness | Buyer/user | See what came in, triage responses, and decide whether kickoff can proceed. | Service blueprint gap analysis; response list, stats, analytics, status update. |
| Export or hand off answers | Buyer/user | Move intake answers into project docs, CRM, Notion, Sheets, kickoff notes, or service workflow. | ICP manual copy/paste pain; competitive handoff gap; CSV export. |
| Reuse and improve intake system | Buyer/user | Duplicate, regenerate, close, analyze, and adapt forms across clients or offers. | Dashboard duplicate; AI regenerate; statuses; analytics. |
Story Map
The complete story hierarchy is rendered below. Release labels are user-story-map slices for review, not a committed engineering roadmap.
Recognize Intake Need
| Task | P1 Stories | P2 Stories | P3+ Stories |
|---|---|---|---|
| Identify the intake job | Start a form for a new client or service need. | Use intake examples aligned to service type. | Separate applications, onboarding, check-ins, and testimonials. |
| Decide what good intake must capture | Describe goals, background, files, links, access, timeline, budget, and preferences in the prompt. | Use completeness prompts for commonly missed client details. | Save intake criteria by offer type. |
Draft Intake Form
| Task | P1 Stories | P2 Stories | P3+ Stories |
|---|---|---|---|
| Generate or create the first draft | Create from plain-language prompt; create manually if AI is wrong or unavailable. | AI includes sensible labels, field types, required flags, validation, options, and conditional-logic hints; generation errors guide retry. | Generation learns from saved service-type criteria. |
| Review AI quality | Preview generated fields before publishing. | Regenerate from a revision request. | Run quality checks against intake completeness. |
Tailor Form For Client/Service
| Task | P1 Stories | P2 Stories | P3+ Stories |
|---|---|---|---|
| Edit fields and logic | Add, remove, reorder, and edit fields; use common field types. | Use conditional logic, undo/redo, and preview. | Offer reusable patterns for specific service types. |
| Configure client-facing experience | Set title, description, required fields, and success message. | Configure notifications, response limits, close dates, redirect URL, GDPR consent, and themes. | Reuse themes and templates across repeated client work. |
Publish And Share Link
| Task | P1 Stories | P2 Stories | P3+ Stories |
|---|---|---|---|
| Publish a stable form | Publish only non-empty forms; tie responses to the published version. | Make draft/published/closed states clear. | Surface pre-publish completeness checks. |
| Share with a respondent | Provide a public link clients can complete without a FormForge account. | Make the shared page polished and credible. | Track whether a client has started or stalled. |
Complete Intake
| Task | P1 Stories | P2 Stories | P3+ Stories |
|---|---|---|---|
| Fill and submit the form | Respondent fills visible fields, fixes validation errors, and submits. | Only relevant fields appear; success message or redirect confirms receipt. | File and asset requests make the right materials clear. |
| Protect submission reliability | Use bot/rate-limit protection. | Use close-date and response-limit controls. | Expose submission failure or notification delivery problems. |
Review Response Readiness
| Task | P1 Stories | P2 Stories | P3+ Stories |
|---|---|---|---|
| See and triage responses | See submissions; label new/read/starred/archived. | Use response stats, recent activity, and bulk status updates. | Coordinate review across team roles. |
| Judge completeness | Open a response and read answers. | See readiness signal for missing files, unclear answers, or incomplete context. | Send follow-up requests tied to missing answers. |
Export Or Hand Off Answers
| Task | P1 Stories | P2 Stories | P3+ Stories |
|---|---|---|---|
| Export collected data | Export responses as CSV. | Preserve metadata and labels; expose truncation. | Support richer exports by destination. |
| Move answers into delivery workflow | Use at least one manual handoff path. | Use cleaner handoff to Sheets, Notion, CRM, kickoff docs, or project tools. | Use workflow-specific handoff or agent-operable access. |
Reuse And Improve Intake System
| Task | P1 Stories | P2 Stories | P3+ Stories |
|---|---|---|---|
| Reuse successful forms | Duplicate a form. | Regenerate or revise an existing form. | Use reusable intake libraries by service type. |
| Learn from usage | See basic response counts. | Use completion time and recent submission analytics. | Track intake quality and follow-up metrics. |
Release Slicing
Release 1 - Walking Skeleton
Outcome: A provider can create one intake form, publish it, collect a response, review it, and export it manually.
Stories: start form, draft/create, edit fields, publish, public submit, response review, CSV export, duplicate/count.
Release 2 - Useful Client Intake Loop
Outcome: The loop becomes credible for repeated paid-client work by improving completeness, polish, monitoring, and first handoff beyond raw collection.
Stories: completeness prompts, better AI/logic quality, themes/settings, readiness signal, export metadata, one validated handoff path.
Release 3+ - Operational Depth
Outcome: FormForge becomes an intake operating layer for repeated service workflows.
Stories: destination routing, follow-up loops, service-type libraries, teams, API/webhooks, agent-operable handoff, billing expansion.
Walking Skeleton
The thinnest deployable/testable path is: authenticated provider creates a form from a prompt or manual title; edits common fields; publishes; FormForge snapshots the published version; external client submits; provider sees the response, changes status, and exports CSV.
| Activity | Skeleton Story | Implementation Notes |
|---|---|---|
| Recognize intake need | Start one intake form for one client/service need. | Dashboard and new-form path support entry. |
| Draft intake form | Generate or manually create the first draft. | AI route and form creation route support this. |
| Tailor form | Edit/reorder common fields. | Editor palette/canvas/properties support field-level editing. |
| Publish/share | Publish a non-empty form and expose a public link. | Publish mutation snapshots fields and changes status. |
| Complete intake | Submit a public response with validation. | Public form and submit API cover this. |
| Review readiness | View response list/detail and mark status. | Response router and pages support this. |
| Export/handoff | Export responses as CSV. | CSV export builder and response page support manual handoff. |
| Reuse/improve | Duplicate or regenerate forms and see basic counts. | Duplicate, regenerate, stats, and analytics cover early reuse. |
Evidence Matrix
| Claim | Evidence Source | Evidence Type | Inference | Confidence | Decision Impact |
|---|---|---|---|---|---|
| The story map should center on client-service intake/onboarding. | research/icp.md | Approved research | The primary ICP and pains are intake-specific. | High | Approve the active backbone if the ICP still holds. |
| The current product covers a walking skeleton from draft to export. | README; AI route; form router; submit route; response router. | Observed code plus product boundary | The flow exists end to end. | High | Do not treat R1 as a greenfield requirement. |
| AI drafting helps activation but is not durable differentiation. | ICP blank-page pain; competitive analysis AI table-stakes finding. | Approved research plus inference | Useful as a start, weak as the final wedge. | High | Keep later slices focused on intake quality and handoff. |
| Editing, preview, publish, snapshots, public completion, and validation are core R1 stories. | Editor UI; publish mutation; form version schema; public form; submit route. | Observed code | These are required to prove the two-sided loop. | High | Preserve in canonical intermediate. |
| Post-submission readiness and handoff should be the main R2/R3 concern. | ICP manual copy/paste pain; competitive handoff gap; service blueprint operational gap. | Approved research plus service blueprint | The buyer's value continues after response receipt. | Medium-high | Gate for whether the next slice emphasis is right. |
| Broad integrations, API keys, billing, teams, and durable file storage should not dominate the walking skeleton. | README Fresh Start Bootstrap Note. | Product boundary | The repo explicitly defers these until core validation. | High | Keep them R3+ unless user overrides. |
| Customer-feedback confidence remains limited. | No research/customer-feedback.md; service blueprint source gaps. | Source absence | Story-map priorities are research/code-backed, not customer-proven. | High | Preserve caveats in canonical artifact. |
Evidence Coverage Gate
Is the evidence sufficient to approve this User Story Map intermediate?
Assumptions / Confidence Register
| Assumption | Status | Confidence | What Would Change It |
|---|---|---|---|
| Product-exists mode remains appropriate. | Supported by manifest selection and observed code. | High | User changes mode or scope. |
| Release labels are story-map slices, not committed engineering roadmap milestones. | Methodological assumption. | High | User requests roadmap/spec conversion. |
| CSV export is enough for the walking skeleton but not durable ICP fit. | Inferred from ICP and competitive analysis. | Medium-high | Customers show CSV/email is sufficient for repeated paid use. |
| Completeness/readiness matters before broad integrations. | Inferred from missing-details pain and service blueprint gaps. | Medium | Discovery shows buyers care primarily about destination sync. |
| Agent-operable handoff is a later candidate, not a near-term default. | Competitor MCP/API evidence and buyer-demand gap. | Medium | AI-forward agencies validate MCP/CLI immediately. |
Assumptions And Confidence Gate
Should these assumptions and confidence levels be preserved in the canonical intermediate?
Alternatives, Lower-Confidence Findings, And Source Gaps
Alternative: Feature Roadmap Emphasis
Billing, teams, API keys, and durable storage could move earlier because code exists, but the README defers them until core loop validation.
Alternative: Generic Builder Map
Templates, payments, signatures, and broad integrations could dominate a generic form-builder story map, but the approved ICP is client-service intake.
Alternative: Handoff-First R1
Adding one integration before readiness may be right later, but the current evidence does not identify the winning destination.
Source Coverage Gaps
- No direct target-buyer interviews, usage analytics, support tickets, or win/loss notes.
- No customer evidence showing which handoff destination should come first.
- No observed completion-dropoff data for external clients.
- No proof that AI-generated intake questions are ready-to-send for specific service niches.
- No evidence yet on whether agent-first access is meaningful to nontechnical owner-operators.
Proposed Canonical Artifacts & File Changes
| Path | Action Now | Action After Approval |
|---|---|---|
research/_working/preliminary-user-story-map-research.md | Written as non-canonical working packet. | Archive and remove after approved canonical write. |
alignment/user-story-map-formforge.html | Review page for approval. | Confirm page with approval record after canonical write. |
research/journey-map-user-story-map.md | Not written. | Write approved canonical intermediate. |
research/_working/journey-map-run.yaml | Read only. | Preserve; completion inferred from canonical intermediate existence. |
Artifact Destination & Proposed File Changes Gate
Approve writing the canonical User Story Map intermediate after this review?
Parent Agent Routing
agent_routing:
workflow: pattern-a-research-loop
parent_skill: journey-map
command: "$journey-map"
gate_owner: parent-orchestrator
gate_type: framework-findings
framework_slug: user-story-map
framework_mode: inline-subskill
run_manifest: research/_working/journey-map-run.yaml
next_resolution: parent-resolves-from-yaml-and-filesystemSupplemental Working Packet Source
The rendered sections above are the primary review surface. This source view is included only as a supplemental checksum against research/_working/preliminary-user-story-map-research.md.
# User Story Map
Based on: research/icp.md, research/competitive-analysis.md, research/journey-map-service-blueprint.md, README/product boundary, and observed implementation files.
Date: 2026-07-02.
Methodology: Jeff Patton User Story Mapping.
Mode: Product-Exists, grounded by code and customer-feedback-limited.
Summary: FormForge's story map backbone is the client-service intake loop: decide what information is needed, create a useful intake form, tailor it, publish a polished link, collect client responses, review readiness, and hand answers into service delivery. The walking skeleton is visible in product: create with AI or from scratch, edit fields, publish, collect a public response, review it, mark status, and export CSV. The major gap is the transition from response received to ready for kickoff or delivery work.
Canonical destination after approval: research/journey-map-user-story-map.md.Compile Responses
Answer the required gates above, then compile YAML and paste it into a session invoking the parent skill.