Journey Map Synthesis Review - AFPS Tracker
Stage 2 parent-loop synthesis for $journey-map --synthesize research/afps-tracker. The page renders the full proposed unified research/afps-tracker/journey-map.md content, evidence, assumptions, source gaps, file changes, and approval gates. Canonical synthesis remains blocked until final compiled YAML is approved.
Research Scope Approved
State B - synthesisThe parent run manifest exists at research/afps-tracker/_working/journey-map-run.yaml and selected two frameworks: jtbd-timeline and experience-map. Both canonical intermediates exist, while research/afps-tracker/journey-map.md is absent. This invocation is therefore the synthesis review phase.
| Input | Status | Path | Use In Synthesis |
|---|---|---|---|
| Run manifest | Active | research/afps-tracker/_working/journey-map-run.yaml | Defines selected framework set and source intermediate paths. |
| JTBD Timeline | Canonical | research/afps-tracker/journey-map-jtbd-timeline.md | Switching trigger, four forces, hiring criteria, risks. |
| Experience Map | Canonical | research/afps-tracker/journey-map-experience-map.md | Emotional arc, pain/delight moments, channel transitions. |
| Canonical synthesis | Not yet written | research/afps-tracker/journey-map.md | Blocked until this review page is approved by compiled YAML. |
Executive Synthesis
pre-product hypothesizedAFPS Tracker is hired when an AFPS operator can no longer cheaply reconstruct research-portfolio state from the source artifacts alone. The user begins with trust in the AFPS workflow because the truth lives in canonical markdown, YAML, alignment pages, working packets, and task docs. The journey becomes painful when product paths and approval states multiply, especially after context compaction, session restart, handoff, or the need to explain why a branch is active, deferred, archived, promoted, or out of scope.
The unified journey is a trust-preservation problem, not a generic productivity-dashboard problem. The product wins when a passive, source-linked map shows current product paths, pipeline stages, evidence refs, and approval provenance faster than opening several files, while still letting the user verify every important claim against canonical artifacts. It loses when parser ambiguity, stale state, write-back anxiety, or manual upkeep makes it feel like another parallel board.
The clearest urgency threshold is multi-path or multi-artifact state sprawl. Single-path workflows can keep using native files and agent rereads. AFPS Tracker should therefore validate the first successful moment against real AFPS repositories where multiple product paths, working packets, alignment pages, and task records already exist.
Visual Lifecycle Overview
| Stage | User State | Evidence | Confidence |
|---|---|---|---|
| Trigger | Branch or artifact sprawl makes source state hard to hold in memory. | ICP triggers; JTBD First Thought; Experience Map artifact accumulation. | Strong |
| Discovery | User looks through AFPS usage, dogfooding, AI workflow discussions, and adjacent tools. | ICP discovery channels. | Moderate |
| Evaluation | User compares native repo navigation, generic tools, research repositories, and agent rereads. | ICP alternatives; competitive landscape; JTBD Active Looking. | Strong |
| Onboarding | First meaningful test uses a real AFPS repository with near-zero manual data entry. | ICP evaluation behavior; Experience Map first tracker read-through. | Strong |
| Aha Moment | Tracker correctly shows paths, stage, evidence refs, and approval provenance without opening several files. | ICP likely aha moment; JTBD Consuming; Experience Map delight moments. | Strong |
| Conversion | User chooses if visibility saves time and increases confidence without duplicate state. | JTBD Deciding; ICP choose/reject criteria. | Moderate |
| Retention | Repeat use depends on correct parsing across future skill runs, freshness, and no drift. | JTBD Satisfaction; Experience Map ongoing portfolio review. | Strong |
| Churn | Churn happens if state is wrong, stale, manually maintained, or write-back weakens gates. | Experience Map rejection; JTBD anxieties; ICP rejection criteria. | Strong |
| Recovery | Recovery requires source links, explicit parser limits, conservative mutation, and re-verification. | Inference from JTBD anxiety and Experience Map failure modes. | Moderate |
Proposed Canonical Journey Map
target: research/afps-tracker/journey-map.mdJourney Map
Based on: research/afps-tracker/journey-map-jtbd-timeline.md, research/afps-tracker/journey-map-experience-map.md, research/afps-tracker/icp.md, research/afps-tracker/competitive-analysis.md, research/afps-tracker/idea-brief.md, and research/.progress.yaml.
Date: 2026-06-24
Mode: Pre-Product (hypothesized)
Frameworks applied: JTBD Timeline, Experience Map
Summary
AFPS Tracker is hired when an AFPS operator can no longer cheaply reconstruct research-portfolio state from the source artifacts alone. The user begins with trust in the AFPS workflow because the truth lives in canonical markdown, YAML, alignment pages, working packets, and task docs. The journey becomes painful when product paths and approval states multiply, especially after context compaction, session restart, handoff, or the need to explain why a branch is active, deferred, archived, promoted, or out of scope.
The unified journey is a trust-preservation problem, not a generic productivity-dashboard problem. The product wins when a passive, source-linked map shows current product paths, pipeline stages, evidence refs, and approval provenance faster than opening several files, while still letting the user verify every important claim against canonical artifacts. It loses when parser ambiguity, stale state, write-back anxiety, or manual upkeep makes it feel like another parallel board.
The clearest urgency threshold is multi-path or multi-artifact state sprawl. Single-path workflows can keep using native files and agent rereads. AFPS Tracker should therefore validate the first successful moment against real AFPS repositories where multiple product paths, working packets, alignment pages, and task records already exist.
User Journeys
Primary Persona: AFPS Operator / AI Workflow Maintainer
| Element | Synthesis |
|---|---|
| Core use case | Understand and resume a research-stage AFPS product portfolio by reading canonical workflow artifacts and seeing product paths, statuses, pipeline stages, evidence refs, and approval provenance without manual duplication. |
| Entry points | Multiple product paths appear; a Codex or Claude session restarts or compacts; future self or a collaborator asks why a path is active, deferred, archived, revisit-candidate, promoted, or out of scope; an alignment page receives feedback and the operator needs to know what changed. |
| Task steps | Open source artifacts; inspect research/.progress.yaml; scan product-path research files; inspect alignment pages and task docs; reconstruct current path state; compare native reconstruction with a passive AFPS Tracker read-through; verify displayed state against source links; decide whether the tracker is trustworthy enough for repeated review. |
| Decision points | Whether the tracker maps active_paths, product_paths[], statuses, pipeline stages, evidence refs, and approval pages correctly; whether it saves reconstruction time; whether it remains subordinate to canonical files; whether any write-back is absent, optional, or approval-gated. |
| Happy path | The user sees active and parallel product paths, stage progression, approval provenance, and evidence refs in one source-linked view, then verifies each important claim back to canonical files and resumes work with less rediscovery. |
| Failure modes | Parser mismatch; stale state after new skill runs; hidden evidence; broad PM or execution-tracking scope creep; write-back that appears to corrupt or bypass approval gates; manual upkeep that creates a second source of truth. |
Adjacent Persona: AI-Native Studio Or Fractional Operator
| Element | Synthesis |
|---|---|
| Core use case | Preserve decision provenance and reduce repeated client or portfolio research reconstruction when running AFPS-like workflows across multiple concepts or engagements. |
| Entry points | Multi-client discovery, portfolio branching, handoff to collaborators or clients, and repeated need to explain evidence-backed branch decisions. |
| Task steps | Adopt or inspect AFPS-like workflow artifacts; compare source-native tracking against Notion, Linear, Jira Product Discovery, research repositories, and agent summaries; verify whether AFPS Tracker preserves client-facing provenance without extra maintenance. |
| Decision points | Whether the studio actually uses AFPS-style repo-local artifacts; whether the tracker reduces billable-time loss; whether source-linked provenance is clearer than client-facing docs or PM tools. |
| Happy path | The operator can explain branch status and evidence without reconstructing it live, while keeping canonical artifacts as the source of truth. |
| Failure modes | The workflow is not AFPS-like enough; clients expect broader collaboration, permissions, or execution tracking; WTP remains unproven without repeated client-delivery pain. |
Customer Lifecycle
| Stage | User State | Evidence | Confidence |
|---|---|---|---|
| Trigger | Branch or artifact sprawl makes source state hard to hold in memory. Common triggers are multiple product paths, session restart or compaction, handoff, feedback on a working packet, or explaining a branch decision. | ICP trigger events; JTBD First Thought; Experience Map artifact accumulation and session restart phases; current research/.progress.yaml with afps-tracker and exec-loop-tracker active. | Strong |
| Discovery | The user looks through AFPS usage, local dogfooding, Codex/Claude/Cursor workflow discussions, GitHub or repo-local tooling circles, AI builder communities, and adjacent product or research workflow tools. | ICP discovery channels and evaluation behavior. | Moderate |
| Evaluation | The user compares native repo navigation, alignment/index.html, .progress.yaml, ad hoc status docs, generic PM/workspace tools, product discovery tools, research repositories, and AI agent rereads. | ICP alternatives; competitive landscape; JTBD Active Looking. | Strong |
| Onboarding | The first meaningful test uses a real AFPS repository, not sample data. The user expects the tracker to read existing files with near-zero manual data entry. | ICP evaluation behavior; Experience Map first tracker read-through; JTBD Consuming stage. | Strong |
| Aha Moment | The tracker correctly shows active and parallel paths, pipeline stage, evidence refs, and approval provenance without requiring the user to open several files. | ICP likely aha moment; JTBD Consuming; Experience Map delight moments. | Strong |
| Conversion | The user chooses if source-linked visibility saves reconstruction time and increases confidence without creating duplicate state. Read-only or read-mostly behavior lowers early adoption risk. | JTBD Deciding; ICP choose/reject criteria; competitive positioning lessons. | Moderate |
| Transaction | Direct purchase flow is not yet evidenced. The likely early economic proof is time saved and confidence gained; adjacent categories show budget but not AFPS-specific WTP. | ICP WTP section; competitive pricing caveats; JTBD WTP risk. | Hypothesized |
| Retention | Repeat use depends on correct parsing across future skill runs, visible freshness, source-verifiable claims, and no drift from canonical artifacts. | JTBD Satisfaction; Experience Map ongoing portfolio review; competitive trust lessons. | Strong |
| Expansion | Potential expansion is from dogfooding operator to studios/fractional consultants or managed hosting for users who do not want to self-host, but packaging remains unvalidated. | ICP adjacent segments; competitive OSS-core plus managed-SaaS hypothesis. | Hypothesized |
| Advocacy | Users advocate when they can show source-linked provenance to future self, collaborators, clients, or other AI agents and look rigorous rather than merely organized. | JTBD social job; Experience Map handoff/explanation delight. | Moderate |
| Churn | Churn happens if the tracker misreads state, goes stale, requires manual upkeep, broadens into generic PM or execution tracking, or write-back weakens approval gates. | Experience Map drop-off/rejection; JTBD anxieties and journey risks; ICP rejection criteria. | Strong |
| Recovery | Recovery requires visible source links, explicit parser limitations, conservative read-only/read-mostly behavior, re-verification against canonical files, and clear separation from exec-loop-tracker. | Inference from JTBD anxiety, Experience Map failure modes, and idea-brief boundaries. | Moderate |
Critical Moments
| Moment | Why It Wins Or Loses The User | Supporting Framework(s) | Confidence |
|---|---|---|---|
| Multi-path state first becomes expensive to reconstruct | This is the first urgency threshold. Without repeated branch or artifact sprawl, native files and agent rereads may remain good enough. | JTBD Timeline; Experience Map | Strong |
| First real repo read-through | The user immediately checks whether the tracker maps active paths, pipeline stage, evidence refs, and approval state correctly. Correct mapping creates relief; wrong mapping destroys trust. | JTBD Timeline; Experience Map | Strong |
| Source verification after the first map | The map must expose why each state claim is true. Source links and evidence refs turn a summary into a trusted workflow-state view. | JTBD Timeline; Experience Map; competitive analysis | Strong |
| Write-back or state mutation consideration | Write-back can expand value later, but early mutation anxiety is high. A read-only or read-mostly path is safer until source-parsing trust is proven. | JTBD Timeline; Experience Map; ICP | Moderate |
| Handoff or explanation to future self, collaborator, client, or agent | The product becomes more valuable when it helps explain why paths exist and what evidence supports them without live reconstruction. | JTBD Timeline; Experience Map; ICP | Moderate |
Stage Detail Index
| Stage Or Topic | Deeper Artifact | What It Adds |
|---|---|---|
| Switching trigger, four forces, hiring criteria, minimum switching conditions | research/afps-tracker/journey-map-jtbd-timeline.md | Detailed Moesta/Switch timeline, push/pull/anxiety/habit forces, force imbalances, and switching risks. |
| Emotional arc, pain and delight moments, channel transitions | research/afps-tracker/journey-map-experience-map.md | Adaptive Path experience phases, doing/thinking/feeling layers, emotional intensity, and channel friction. |
| ICP, trigger events, current alternatives, WTP caveats | research/afps-tracker/icp.md | Primary and adjacent personas, evaluation behavior, pains, and willingness-to-pay caveats. |
| Substitute landscape and market gaps | research/afps-tracker/competitive-analysis.md | Native-artifact baseline, adjacent categories, market whitespace, and pricing caveats. |
| Concept boundaries and non-goals | research/afps-tracker/idea-brief.md | AFPS Tracker scope, passive v1 constraint, research-phase boundary, and exec-loop-tracker separation. |
| Product-path state | research/.progress.yaml | Active product paths, product labels, statuses, pipeline stages, evidence refs, and current parallel path context. |
Journey Gaps
| Gap | Why It Matters | Owner Or Later Validation |
|---|---|---|
| No direct AFPS user interviews or observed switching sessions | The journey is currently synthesized from approved research, dogfooding context, and repo artifacts, not observed user behavior. | Customer discovery or design-partner interviews. |
| No measured reconstruction-time baseline | The product's economic proof depends on time saved and confidence gained over manual source reconstruction. | Dogfooding logs, prototype tests, or lifecycle metrics. |
| No prototype test of the first source-linked read-through | The predicted aha moment must be verified on real AFPS artifacts. | Product design or prototype validation after positioning. |
| No parser-fidelity audit across historical artifact versions | Parser trust is decisive; failures could collapse the journey. | Technical validation before implementation planning. |
| No direct WTP evidence | Adjacent tools show budget categories but not willingness to pay for passive AFPS state visibility. | Monetization or design-partner package testing. |
| Retention instrumentation is undefined | Repeat use depends on freshness, correctness, and reduced rediscovery, but leading indicators are not yet instrumented. | Lifecycle metrics if measurement becomes a blocker before UX choices. |
Product Path Implications
The synthesis reinforces the approved AFPS Tracker boundary. exec-loop-tracker appears as a separate active concept in research/.progress.yaml, but the journey evidence says development execution tracking changes the job and should remain outside this artifact. No new product-path fork is recommended from this synthesis. The only implication is to preserve the handoff boundary: AFPS Tracker covers research-stage workflow-state visibility through branch promotion; execution tracking belongs to the separate product path.
Next Steps
Downstream routing is intentionally withheld while this synthesis is in review. After final compiled YAML approves the artifact and the canonical research/afps-tracker/journey-map.md is written, the parent journey-map orchestrator will compute the first allowed next step from the approved journey evidence and the repository's enabled skill packs.
Evidence Matrix
claims mapped to frameworks| Claim | Supporting Framework(s) | Evidence | Inference | Confidence | Decision Impact |
|---|---|---|---|---|---|
| The core journey pain is scattered AFPS workflow state, not generic project management. | JTBD Timeline; Experience Map | Both framework outputs identify state spread across .progress.yaml, markdown, alignment pages, working packets, task docs, and archives as the core pain. ICP and idea brief define the same problem. | The journey should stay source-native and AFPS-specific. | Strong | Approve a canonical journey centered on rediscovery and state reconstruction, not broad PM. |
| Multi-path complexity is the clearest trigger and urgency threshold. | JTBD Timeline; Experience Map | JTBD First Thought and force imbalances name branch sprawl; Experience Map artifact accumulation and ICP trigger ranking identify multiple product/research branches as the highest urgency trigger. | Single-path workflows may not feel enough pain to switch. | Strong | Validate first against multi-path AFPS repositories. |
| Native AFPS artifacts are the strongest substitute and the trust baseline. | JTBD Timeline; Experience Map; competitive analysis | Competitive analysis says native AFPS artifacts are the real baseline; JTBD Habit says files are free, source-faithful, and already adopted; Experience Map starts above neutral because the operator trusts the source workflow. | The tracker must beat manual reconstruction without weakening source fidelity. | Strong | Do not position as a replacement for canonical files. |
| The first successful product moment is a correct source-linked read-through over real artifacts. | JTBD Timeline; Experience Map | JTBD Consuming and Experience Map first tracker read-through both describe immediate verification against active_paths, statuses, evidence refs, and alignment pages. | Aha depends on real source state, not sample data or generic visuals. | Strong | Prototype validation should use actual AFPS repositories. |
| Parser fidelity is more important than dashboard polish at this stage. | JTBD Timeline; Experience Map | Both frameworks say mismapped source state breaks trust immediately; competitive synthesis says source fidelity is the wedge. | Incorrect state is a journey failure even if the surface is attractive. | Strong | Prioritize source-verifiable claims and error visibility in later UX. |
| Early write-back should be conservative because trust anxiety is high. | JTBD Timeline; Experience Map; ICP | JTBD anxieties and minimum switching conditions prefer absent, optional, or approval-gated write-back; Experience Map flags write-back alarm; ICP identifies write-back trust risk. | Read-only/read-mostly proof should precede state mutation. | Moderate | Keep mutation and sync decisions gated by later validation. |
| WTP and commercial urgency are still unproven. | JTBD Timeline; ICP; competitive analysis | ICP WTP section and competitive synthesis both treat adjacent spend as directional only; JTBD identifies WTP as a risk. | Journey evidence supports value risk, not pricing certainty. | Strong | Do not make pricing/package claims from this synthesis. |
exec-loop-tracker remains a separate product path and should not be folded into this journey. | JTBD Timeline; Experience Map; idea brief | Both framework scopes exclude development execution tracking; idea brief states AFPS Tracker ends where research ends and records exec-loop-tracker separately. | Execution tracking is a materially different journey. | Strong | Preserve AFPS Tracker-only scope. |
Assumptions And Confidence
review required| Assumption | Status | Confidence | What Would Change It |
|---|---|---|---|
| AFPS operators experience enough repeated rediscovery pain to switch. | Hypothesized from ICP, framework outputs, and repo artifacts. | Moderate | Dogfooding shows raw files plus agent rereads remain sufficient even in multi-path workflows. |
| Multi-path or multi-artifact complexity is the strongest urgency threshold. | Evidence-backed but not user-tested. | Moderate to strong | Single-path users report equal pain, or multi-path users remain comfortable with native files. |
| Source fidelity matters more than dashboard polish. | Evidence-backed across ICP, competitive analysis, JTBD, and Experience Map. | Strong | Users prefer broader PM/workspace features over exact AFPS parsing and source links. |
| Read-only or read-mostly first value is safer than early write-back. | Inference from trust and write-back anxiety. | Moderate | Design partners demand editing as the first useful action and accept approval-gated mutation. |
| Studios and fractional consultants may provide stronger commercial urgency if they adopt AFPS-like workflows. | Adjacent ICP hypothesis. | Moderate | Interviews show they do not use repo-local research workflows or do not value provenance enough to pay. |
| Retention depends on freshness across future skill runs. | Evidence-backed inference from satisfaction and ongoing review phases. | Moderate to strong | Users treat AFPS Tracker as a one-time audit tool rather than a repeated review surface. |
Alternatives / Lower-Confidence Findings
| Alternative Finding | Why It Is Lower Confidence Or Rejected | Residual Uncertainty |
|---|---|---|
| AFPS Tracker should lead as a generic PM or portfolio dashboard. | Rejected by idea brief, ICP, competitive analysis, and both journey frameworks. The wedge is AFPS-native source fidelity, not generic work management. | A later product path could broaden after direct AFPS evidence, but this journey should not. |
| AI agents make the tracker unnecessary. | Lower confidence. Agents can reread and summarize repo state, but they do not create persistent, reviewable, source-linked branch maps. | If agent summaries prove fast, reliable, and trusted enough in real AFPS repos, tracker demand weakens. |
| Write-back should be removed entirely. | Not selected. The approved idea includes a companion sync layer, but journey evidence says mutation should wait until read-only trust is earned. | Prototype tests may show users either need early editing or reject write-back categorically. |
| Managed hosting is part of the first journey proof. | Lower confidence. Competitive analysis preserves OSS-core plus managed-SaaS as a monetization hypothesis, not journey evidence. | Monetization research could make hosted operation central for non-technical or studio buyers. |
Source Coverage Gaps
evidence gaps preserved- No direct AFPS Tracker prototype sessions.
- No direct interviews with AFPS power users beyond dogfooding context.
- No observed behavior comparing native reconstruction, agent summaries, and a source-linked map.
- No parser-fidelity test across older or varied AFPS artifacts.
- No current willingness-to-pay test.
- No direct evidence that external AFPS users exist in meaningful volume.
- No dedicated lifecycle instrumentation plan for activation, retention, or recovery signals.
Proposed Canonical Artifacts And File Changes
blocked until approval| Path | Action | Timing |
|---|---|---|
research/afps-tracker/_working/preliminary-journey-map-research.md | Active non-canonical synthesis working packet written for review. | Written in this Stage 2 session. |
alignment/journey-map-afps-tracker.html | Active synthesis review page with gates and compiled YAML controls. | Written in this Stage 2 session. |
docs/history/archive/2026-06-24/104947/alignment/journey-map-afps-tracker.html | Archive copy of the prior confirmed Experience Map page before replacement. | Written in this Stage 2 session. |
alignment/index.html | Update central index entry for this page from confirmed Experience Map to review synthesis. | Written in this Stage 2 session. |
research/afps-tracker/journey-map.md | Create canonical unified journey-map synthesis from the approved packet, with approved edits applied first. | Only after final compiled artifact approval YAML. |
research/afps-tracker/_working/preliminary-journey-map-research.md | Archive under docs/history/archive/YYYY-MM-DD/HHMMSS/ and remove active working packet. | Only after final compiled artifact approval YAML. |
research/afps-tracker/_working/journey-map-run.yaml | Archive and remove after canonical synthesis is written. | Only after final compiled artifact approval YAML. |
research/.progress.yaml | Update AFPS Tracker pipeline_stage to journey-map. | Only after final compiled artifact approval YAML. |
alignment/journey-map-afps-tracker.html | Convert synthesis review page to confirmed, preserving approval record and written artifact paths. | Only after final compiled artifact approval YAML. |
Approval Gates
requiredAnswer every required gate and compile the response YAML at the bottom of the page to authorize final canonical synthesis. Section feedback may be compiled separately for revision requests before all gates are answered.
Gate 1: Unified Lifecycle And Persona Journeys
Approve whether the lifecycle and persona journeys correctly synthesize the approved framework outputs.
Gate 2: Critical Moments And Confidence
Approve whether the 3-5 moments and confidence labels identify where AFPS Tracker wins or loses the user.
Gate 3: Research Completeness
Approve whether the evidence matrix, gaps, assumptions, and lower-confidence findings are sufficient for a pre-product journey map.
Gate 4: Proposed File Changes
Approve the mutation boundary after final approval. Canonical journey-map.md, run-manifest cleanup, progress update, and confirmed page conversion will happen only in Stage 3.
Gate 5: Parent-Loop Finalization
Approve the parent-loop handling: no downstream command is emitted while this page is in review; after final approval writes canonical synthesis, the parent orchestrator computes the next allowed route.
Agent Routing Payload
included in compiled YAMLagent_routing: workflow: pattern-a-research-loop parent_skill: journey-map command: "$journey-map --synthesize research/afps-tracker" product_path: research/afps-tracker gate_owner: parent-orchestrator gate_type: synthesis run_manifest: research/afps-tracker/_working/journey-map-run.yaml next_resolution: parent-resolves-from-yaml-and-filesystem
Compile Responses
Compile complete approval YAML after answering every required gate. Partial YAML or section-feedback YAML can be pasted back for revisions before final approval.
No YAML compiled yet.