Documenting Product and Pitch
Given raw product context (screens, flows, stack, goals), produce two aligned outputs from one source of truth:
- Technical doc set — architecture, data models, API assumptions, permissions, QA scenarios
- Pitch narrative — problem/solution, market, business model, roadmap, traction plan
Don't write these independently — derive both from the same module breakdown so they never contradict each other.
Progress:
- [ ] Step 1: Gather product context (purpose, users, screens, stack, decisions made)
- [ ] Step 2: Identify audiences and required outputs (dev-facing vs investor-facing)
- [ ] Step 3: Decompose product into core modules
- [ ] Step 4: For each module, define flows, data, screens, backend logic, permissions, edge cases
- [ ] Step 5: Draft technical documentation set
- [ ] Step 6: Draft pitch deck narrative from same module data
- [ ] Step 7: Cross-check consistency between both outputs
- [ ] Step 8: Refine for clarity, credibility, and audience fit
Step 1: Gather Context
Collect (ask only if genuinely missing, otherwise infer from what's given):
- Product purpose and target users
- Existing screens / current implementation state
- Technical stack (e.g., Android/Kotlin, backend, DB)
- Business assumptions already made (monetization hints, market, competitors)
Step 2: Identify Audiences
Two tracks, always:
- Developers — need specs precise enough to build/QA against
- Investors/partners — need a narrative that sells the vision without technical noise
Never mix technical jargon into pitch content or vague marketing language into specs.
Step 3: Decompose Into Modules
Standard module set for rental/marketplace/SaaS-like products (adapt names to the actual product):
- Onboarding & authentication
- User profiles & roles
- Core listing/discovery entity (e.g., properties, jobs, products)
- Application/booking/request workflow
- Payments
- Documents
- Messaging/communication
- Notifications
- Admin tools
- Analytics
Step 4: Per-Module Definition
For every module, capture in this exact shape:
| Field | Content |
|---|---|
| User flow | Step-by-step from entry point to completion |
| Data model | Entities, key fields, relationships |
| Screens | List with purpose of each |
| Backend logic | Core rules, state transitions |
| Permissions | Who can do what (role-based) |
| Edge cases | Failure states, empty states, race conditions |
| Dependencies | Other modules or external services required |
Step 5: Technical Documentation Set
Assemble into these sections, in order:
- Product overview (1 paragraph, technical framing)
- System architecture (diagram description + component list)
- Feature specifications (per module, from Step 4)
- User flows (consolidated, cross-module)
- Data models (full schema-level entity list)
- Backend/API requirements (endpoints implied by flows, auth model)
- QA scenarios (edge cases from Step 4, per module)
- Risks (technical debt, scaling concerns, security)
Step 6: Pitch Deck Narrative
Standard slide sequence — do not reorder:
- Problem
- Solution
- Product (screenshots/flow highlights, non-technical)
- Market opportunity (size, target segment)
- Business model / monetization
- Competitive positioning
- Traction / current state
- Roadmap
- Team (placeholder if not provided)
- Ask / next milestones
Same module data as Step 4, but stripped of implementation detail — express as user value, not backend logic.
Step 7: Cross-Check
Verify: roadmap in pitch deck matches technical doc's future-module notes; monetization logic matches payment module's actual data model; no feature claimed in pitch that isn't supported (even partially) in the tech spec.
Step 8: Refine
Cut redundancy, ensure consistent terminology across both documents (same module names, same entity names), tighten pitch language to be outcome-focused not feature-focused.
Example 1: Input: "Homygo has a listings screen, tenant application flow, and basic payment stub. Built in Kotlin, no backend yet."
Output:
- Module breakdown: Onboarding, Profiles (tenant/landlord roles), Listings, Applications, Payments (stubbed), Documents (not yet built — flagged as roadmap item)
- Technical doc flags payments and documents as "assumed backend, not implemented" with proposed API shape
- Pitch deck marks Payments/Documents as "Q2 roadmap" under Traction/Roadmap slides — consistent with tech doc's flagged status
Example 2: Input: "Need investor deck only, skip technical docs."
Output: Skip Steps 5, 7 (partial). Still run Steps 3–4 internally to ground the narrative in real product structure, but output only the 10-slide pitch sequence from Step 6. Note in output that module analysis was done internally to ensure claims are grounded, even though it's not shown.
- Always derive pitch content from the same module analysis as tech docs — this is the core value, not writing them separately
- Use role-based permission tables even in early-stage products; investors read this as maturity signal
- Flag unbuilt/assumed features explicitly in tech docs ("assumed," "not yet implemented") rather than presenting speculation as fact
- Keep pitch deck feature descriptions to outcomes ("tenants apply in one tap") never implementation ("Kotlin coroutine-based async form submission")
- Roadmap should appear in both documents but adapted in vocabulary — same timeline, different framing
- Writing tech docs and pitch deck as if for two unrelated products — causes contradictions investors or engineers will catch
- Letting monetization slides promise features that have no corresponding data model or backend logic in the tech spec
- Overloading pitch deck with schema/API details — kills narrative momentum
- Skipping edge cases/permissions in "early-stage" specs — these are cheap to define early and expensive to retrofit
- Treating module list as fixed — always adapt names/scope to the actual product instead of forcing a generic template