ICP Research - AFPS Tracker

Executive Summary

Scope Resolution

ICP Candidates

Recommendation

Scores use 1-5, where 5 is strongest. Weighted priority uses pain intensity, WTP quality, market accessibility, and product fit. Immediate learning access is shown separately because it answers "who can we learn from fastest?", not "which buyer segment is most commercially reachable?"

Proposed ICP Deliverable

Customer Profile

Primary ICP: AI-native product studios and fractional product-engineering consultants who run AFPS or AFPS-like repo-native product discovery across multiple client or portfolio bets.

They are not generic PM teams and not generic research repositories. They are owner-operators or small teams who already use AI agents, skill workflows, structured briefs, markdown files, and repo-local state to move from idea shaping to validated product direction. Their economic job is to preserve clarity, evidence, and decision history while exploring many branches quickly.

Buyer persona: studio principal, fractional CTO, fractional CPO/CPXO, product-engineering consultant, AI-native agency lead, or senior product strategist who owns the client or portfolio discovery process. The buyer is often also the daily user in early adoption. In a small studio, the buyer may later invite researchers, product leads, engineers, or clients as viewers.

Budget: business tooling budget rather than consumer hobby budget. Adjacent spend exists in AI developer tools, coding agents, collaboration tools, product discovery tools, research repositories, and client-delivery systems. WTP is strongest when scattered state costs billable time, creates client-facing ambiguity, or weakens confidence in a promoted/deferred product branch.

Discovery channels: Codex, Claude Code, Cursor, and AI developer-tool communities; AI-native agency, fractional CTO/CPO, product studio, and build-in-public communities; GitHub/repo-native workflow discussions; AFPS skill-pack users and local dogfooding; adjacent product discovery and research repository discussions.

Geographic focus: initial focus should be English-speaking operators in the United States, Canada, United Kingdom, Europe, Australia, and similar markets because the source workflow, skill artifacts, and current research language are English.

Named Accounts

User Profile(s)

Daily users are studio principals or fractional product-engineering operators running research workflows, product strategists or researchers maintaining evidence and branch state, and technical founders or consultants using Codex/Claude/Cursor to run structured product discovery.

They are highly technical, comfortable with markdown, Git/repo structures, local files, agent sessions, and structured research workflows. Their goals are to know what each product branch is, why it exists, where it is in the skill pipeline, and what evidence backs its status; resume a research thread without re-reading scattered artifacts; explain branch decisions; and preserve status distinctions across active, deferred, archived, revisit-candidate, and promoted paths.

Trigger Events

1. Multiple branches appear in one research cycle.
2. A session restarts or compacts.
3. A client, collaborator, or future self asks why a path was promoted or deferred.
4. The operator starts using more than one coding/research agent.
5. The number of alignment pages grows.
6. Manual manifest edits become risky.
7. A branch is promoted to build and needs a clean handoff boundary.

Current State Journey

1. The operator starts with an idea brief or concept.
2. Skills generate markdown briefs, interview logs, alignment pages, and sometimes research/.progress.yaml.
3. Research creates branches: ICP candidates, problem paths, product-line ideas, competitive gaps, or deferred concepts.
4. The operator checks status by opening individual markdown files, YAML, alignment/index.html, and task files.
5. The operator asks an AI agent to continue, but the agent must re-read enough context to avoid stale assumptions.
6. If several paths exist, the operator mentally reconstructs which path is current, which was approved, which is blocked, and what evidence supports each.
7. Generic PM or notes tools can mirror this state, but that creates duplicate manual data entry.
8. The operator either narrows to one branch, parks branches, or loses confidence that the branch map reflects the actual research record.

Pain Map

Current Alternatives (User Perspective)

Market Sizing

Confidence: low-to-medium because direct AFPS adoption data is not public.

• Top-down context: GitHub reports 180 million-plus developers on GitHub in 2025. Stack Overflow reports 84% of 2025 respondents using or planning to use AI tools in development, and 51% of professional developers use AI tools daily. JetBrains reports 90% regular work usage of AI tools in January 2026. Google DORA reports 90% AI adoption among software development professionals.
• TAM: all AI-assisted technical operators and product builders who manage persistent workflow state across projects. This is large but too broad to be meaningful.
• SAM: English-speaking operators, studios, consultants, and technical founders who use repo-native AI workflows and care about research-stage branching.
• SOM: near-term design-partner pool of 10-30 operators who run multi-branch research workflows, with special attention to existing repo-local state practices.

Stated Value Drivers

• "I can see every branch without opening five files."
• "I know why this path is active, deferred, archived, or promoted."
• "I can resume work without asking the agent to rediscover the whole repo."
• "I can show a client or collaborator the evidence trail behind a decision."
• "The tracker reflects the workflow's real state instead of another manual board."
• "It helps me manage a portfolio of product bets before committing to build."

Likely aha moment: the operator sees a branch tree and pipeline-stage view that correctly reflects current repo state, including evidence references, without manual data entry.

Willingness-to-Pay Signals

Paid alternatives already exist across AI developer tools, coding agents, product discovery systems, and research repositories. The budget owner is usually a studio principal, fractional operator, founder, or consultant. Time spent reconstructing branch status, re-reading artifacts, or repairing agent context is a billable-time loss for consultants/studios. Switching tolerance is higher if AFPS Tracker reads existing files and lower for write-back until trust is earned. Solo founders are price-sensitive; studios and consultants have stronger business-budget logic; product ops and UX research have budget but expect enterprise-grade collaboration and integrations.

Customer ↔ User Dynamics

The early buyer is usually the operator who runs the workflow. Onboarding is likely self-serve and repo-based because artifacts already exist locally. Trust depends on showing that the tracker reads canonical state correctly before it writes anything back. In small studios, the lead configures the workflow, team members may need read/edit access, and clients may consume evidence views, but the product must remain subordinate to the AFPS workflow rather than become a parallel source of truth.

Discovery & Evaluation Behavior

They find solutions through AI developer-tool communities, Codex/Claude/Cursor workflow discussions, GitHub/repo-local tooling, AFPS pack usage, product studio networks, and build-in-public/fractional operator communities. They evaluate by trying it on a repo with real AFPS artifacts and comparing against manual file navigation, alignment/index.html, generic PM tools, product discovery tools, and agent-control-plane tools. They choose if it reduces repeated reconstruction without duplicate state; they reject if it requires manual upkeep, hides evidence, corrupts YAML, or feels like a generic PM layer.

Additional ICPs

Cross-ICP Analysis

Shared pains: state exists but is scattered; decision provenance matters; AI workflows increase context-management burden; reconstructing past decisions is expensive; manual repositories and boards fail when they require duplicate upkeep.

Segment conflicts: AFPS users want workflow fidelity while product ops teams expect broad integrations; solo founders want low-cost simplicity while studios can justify more process; UX research teams organize raw research data while AFPS Tracker organizes workflow state and branch decisions; agent control-plane buyers care about execution safety while AFPS Tracker's first job is research-stage portfolio clarity.

Accessibility clarification: AFPS power users have the highest immediate learning access because the concept can be tested through dogfooding and any known AFPS operators. AI-native studios and fractional consultants have stronger market accessibility because public accounts, public positioning, and niche operator communities make them externally findable even though they require outreach. The primary recommendation optimizes for commercial ICP evidence; the research sequence still starts with AFPS users because they are the fastest way to test exact workflow fidelity.

Product-line recommendation: do not create new product paths for product ops or UX research yet. Keep research/afps-tracker active as the AFPS-specific research-state tracker. Treat research/exec-loop-tracker as a separate active concept outside this ICP.

Research sequence: validate with AFPS dogfooding and any real AFPS users; interview or desk-research AI-native studios/fractional consultants; use solo technical founders as an accessibility benchmark; defer PM/product ops and UX research ops until competitive analysis.

Signals for Downstream Research

• Competitive analysis should map agent control planes, product discovery/PM tools, research repositories/customer-intelligence tools, and AI founder/MVP planning tools.
• Positioning should avoid claiming AFPS is a known public category unless adoption evidence appears.
• Monetization should treat adjacent pricing as WTP signal only, not as a pricing recommendation.
• GTM research should test which communities discuss agent context loss, repo-local workflow state, and AI-native product discovery.
• Product research should test write-back trust separately from read-only visualization.

Next Steps

Recommended: $competitive-analysis - maps the landscape your ICP operates in so positioning and GTM have competitive grounding.

Other options:

• $competitive-analysis - Map the competitive landscape for this ICP's market.
• $pack install customer-lifecycle - Needed before $journey-map; map the current-state journey to find intervention points after the pack is enabled in a new session.

Proposed Search Log

Targeted Candidate Sources

• AI-native studios / consultants: Sprinter Studio, Affiniti, Stackd Studios AI, AINative Studio, Mako Studio, Kainesis, Shape Labs, Hechura, CodePixelfy, Kaleido.
• AFPS / AI workflow context: local artifacts, Claude memory docs, Runshift.
• Solo founders / AI product discovery: MVP Copilot, LaunchChair, startupconcept.ai, Finprob, Indie Hackers AI-founder workflow discussions.
• Product ops / PM teams: Jira Product Discovery pricing, Productboard pricing, Dovetail pricing.
• UX research / research ops: Condens pricing, Dovetail pricing, UXmatters repository critique, Reddit research repository discussion.

Evidence Matrix

Assumptions & Confidence

Source Coverage Gaps

Proposed File Changes

Approval Gates

Full Working Packet

The full non-canonical packet is rendered below so the approval page is self-contained. The source path is research/afps-tracker/_working/preliminary-icp-research.md.

---
skill: icp
stage: stage-2-review
status: review
product_path: research/afps-tracker
alignment_page: alignment/icp-afps-tracker.html
canonical_outputs_gated:
  - research/afps-tracker/icp.md
  - research/afps-tracker/icp-search-log.md
created_at: 2026-06-03
updated_at: 2026-06-07
---

# Preliminary ICP Research: AFPS Tracker

This is a non-canonical working packet for `$icp`. It completes the Stage 1 research packet and feeds the Stage 2 alignment page. Do not treat it as the approved ICP deliverable until the alignment page receives final compiled approval YAML.

## Feedback Revision Notes - 2026-06-07

Revision source: feedback-only YAML from `alignment/icp-afps-tracker.html` flagged the Recommendation section as needing clarification:

> Would "AFPS power users / AI workflow operators" not be more accessible than "AI-native product studios / fractional product-engineering consultants"? I need the clarification between why accessibility is different between the two.

Clarification:

- Yes, AFPS power users are more accessible for immediate learning and dogfooding if the author can reach current AFPS pack users, known AI workflow operators, or local dogfood usage.
- No, that does not automatically make them the stronger commercial primary ICP because external market accessibility is weaker: no public AFPS category evidence, no known AFPS user list or telemetry, and no direct WTP evidence for a passive AFPS Tracker.
- AI-native studios and fractional consultants are less immediately reachable than dogfooding users, but they are more discoverable as a commercial market through public company websites, named-account research, fractional CTO/CPO communities, product studio communities, AI-native agency language, and business-budget logic.
- The revised matrix separates `Market Accessibility` from `Immediate Learning Access`. Weighted priority uses market accessibility because the primary ICP decision is a commercial ICP recommendation, not only a first-interview or dogfood sequence.
- AFPS power users remain the first learning segment. If real AFPS user volume, contactability, or paid intent appears, the candidate verdict should be revisited.

## Scope Resolution

- Active target: `research/afps-tracker`.
- Reason: `research/.progress.yaml` lists `research/afps-tracker` as an active product path, and `research/afps-tracker/idea-brief.md` is approved.
- Other active manifest path: `research/exec-loop-tracker`. This path is explicitly out of AFPS Tracker scope and has not been independently scoped. It is not included in this ICP run.
- Canonical outputs intentionally gated: `research/afps-tracker/icp.md` and `research/afps-tracker/icp-search-log.md`.
- No canonical ICP files are written in this stage.

## Local Product Context

Source artifacts:

- `research/.progress.yaml`
- `research/afps-tracker/idea-brief.md`
- `research/afps-tracker/idea-brief-interview.md`
- `alignment/idea-scope-brief-afps-tracker.html`

Working frame:

- AFPS Tracker is a companion sync layer for the alignment-first, prototype-second skills workflow.
- It reads workflow state already emitted by the skills system, especially `research/.progress.yaml`, `product_paths[]`, skill outputs, and alignment pages.
- The core pain hypothesis is scattered state across YAML, markdown, interview notes, and HTML review pages.
- The starting beneficiary hypothesis is AFPS workflow operators, with the concept author as user #1.
- The product is constrained to a passive research-phase portfolio map, not a generic project manager, active recommender, or build/execution tracker.
- Exact public demand for "AFPS" is unproven; web search did not find evidence that the named AFPS workflow is a public category.

## Marketplace Side Preflight

AFPS Tracker does not currently validate as a marketplace, platform, or B2B2C model. The concept is a companion workflow tool.

Material sides:

- Buyer/customer side: the operator or studio lead who pays for workflow tooling and owns research process quality.
- User side: the same operator in early use; in studios, additional researchers, product leads, or consultants may view or edit state.
- Stakeholder side: clients, collaborators, or future teammates may consume evidence-linked status, but they are not a separate market side in the current concept.

Side exclusions:

- No supply-side marketplace participant is required.
- No consumer/end-user side is required.
- No separate buyer/user split is forced in the first ICP because the highest-fit segments are owner-operators, studios, and consultants where buyer and daily user often overlap.

## Business Model Classification

Most likely:

- Developer-first / workflow-tooling: strongest fit. AFPS Tracker reads repo-local AFPS files and serves operators already using skill-driven workflows.
- B2C subscription or prosumer PLG: plausible if the first paying users are solo technical founders, consultants, or individual AI-workflow operators.
- B2B SaaS (PLG): plausible for small studios, AI-native agencies, and consulting teams that standardize on AFPS-like workflows.

Lower near-term fit:

- B2B SaaS (SLG): lower fit until the product supports larger teams, security review, admin controls, and integrations.
- Marketplace/platform: not supported by the concept or research.
- B2B2C, D2C, open-core, API/developer-first platform: no current evidence that these are the first model.

Evidence:

- Stack Overflow's 2025 survey reports 84% of respondents are using or planning to use AI tools in development, with 51% of professional developers using AI tools daily. Source: https://survey.stackoverflow.co/2025/ai
- JetBrains reports that in January 2026, 90% of developers regularly used at least one AI tool at work for coding/development tasks, and 74% had adopted specialized AI developer tools. Source: https://blog.jetbrains.com/research/2026/04/which-ai-coding-tools-do-developers-actually-use-at-work/
- Google DORA 2025 reports 90% AI adoption among software development professionals and a median two hours daily working with AI. Source: https://blog.google/innovation-and-ai/technology/developers-tools/dora-report-2025/
- Runshift, ClawCode, CallCode, Kagan, Lightcode, and related products position around coordinating multiple agents, shared state, file locking, session management, and trust gates. These validate adjacent workflow-control pain, but mostly in build/execution rather than research.
- Jira Product Discovery, Productboard, Dovetail, and Condens show budgeted demand for product discovery, customer intelligence, and research repositories. These validate adjacent WTP, not direct AFPS demand.

## ICP Candidate Set

### Candidate 1: AI-native AFPS workflow operators in product studios and fractional product-engineering consulting

Who they are:

- Studio leads, fractional CTO/CPO/CPXO operators, product-engineering consultants, and AI-native agency principals running discovery across multiple client or portfolio bets.
- They use or are likely to adopt Codex, Claude Code, Cursor, and repo-native workflows.
- They need evidence-backed branch decisions because client or portfolio context repeats across engagements.

Pain evidence:

- The local idea brief identifies scattered AFPS state across YAML, markdown, interview notes, and alignment pages.
- AI-agent workflow vendors position around chaos from multiple agents, shared context, file locks, session management, and trust gates.
- Product discovery and research repository vendors validate that teams pay to centralize evidence and customer/product knowledge.
- AI-native agencies and studios publicly position around compressed idea-to-product workflows and AI-assisted delivery.

Accessibility:

- Market accessibility: Medium. More concentrated than broad PM teams, but reachable through AI builder, fractional CTO/CPO, product studio, and AI-native agency communities.
- Immediate learning access: Medium. They require outreach or account research rather than pure dogfooding, but named-account research can identify small studios and consultants directly.

Value potential:

- High. Multi-branch, multi-client, and evidence-heavy research creates higher state-management pain than a single founder with one idea.
- The workflow can save billable time and reduce client-facing evidence reconstruction.

WTP signal quality:

- Medium-to-strong. This segment has business budgets and can justify tools that reduce delivery friction or make decision provenance easier to show.
- Direct AFPS-specific WTP is missing, so confidence remains medium.

Initial read:

- Best primary ICP if AFPS Tracker is meant to become more than a tool-of-one. It preserves AFPS specificity while choosing a customer with better commercial urgency than generic solo founders.

### Candidate 2: AFPS power users / AI workflow operators

Who they are:

- Individuals already using, evaluating, or willing to adopt the AFPS skills workflow.
- Likely technical product builders, Codex/Claude/Cursor users, or product/strategy operators who run research-first agent workflows in repo-local files.

Pain evidence:

- Local artifacts directly show a branching AFPS workflow with `research/.progress.yaml`, product paths, alignment pages, and working packets.
- Public adjacent evidence shows AI coding workflows suffer from fragmented context, session loss, and cross-tool handoff problems.
- Repo-local state is valuable when it is emitted by the workflow rather than manually curated.

Accessibility:

- Immediate learning access: High through dogfooding, current AFPS pack users, known AI workflow operators, or the author's own local workflow, if that reachable user base exists.
- Market accessibility: Low-to-medium until there is evidence of an external AFPS user population. Web research found no meaningful public category evidence for AFPS, and no install/usage data or reachable user list is available in this packet.

Value potential:

- Very high product fit.
- Value is clearest for operators with multiple active, deferred, and revisit branches.

WTP signal quality:

- Weak-to-medium. Adjacent tools show willingness to pay for AI workflow and repository tools, but direct evidence that AFPS users will pay for a passive tracker is absent.

Initial read:

- Best learning ICP and earliest dogfood segment. Not the strongest commercial primary unless a real AFPS user population is found.

### Candidate 3: AI-native solo technical founders / indie builders

Who they are:

- Solo founders, indie developers, and micro-SaaS builders using AI coding agents and product-discovery prompts to explore multiple ideas before committing to build.
- They may already use Notion, Linear, GitHub projects, Cursor, Claude Code, Codex, MVP planning tools, and idea-validation tools.

Pain evidence:

- AI product-discovery and MVP-planning tools explicitly sell idea validation, market research, product documentation, and build-ready planning to solo founders.
- Builder forums and tool positioning repeatedly discuss context loss, repeated rediscovery, and the need to preserve product clarity while using AI.

Accessibility:

- High through indie hacker, micro-SaaS, build-in-public, Cursor/Codex/Claude, and AI builder communities.

Value potential:

- Medium. Multi-concept portfolio tracking maps to how solo founders compare opportunities.
- Fit weakens if they do not want to adopt AFPS or repo-local research artifacts.

WTP signal quality:

- Medium. Existing founder tools sell into this audience, but solo builders can be price-sensitive and may prefer free/general-purpose tools until revenue exists.

Initial read:

- Strong reachable adjacent segment, but AFPS Tracker must prove that AFPS workflow adoption is part of the job rather than an extra process burden.

### Candidate 4: Product ops / PM teams in SaaS companies

Who they are:

- Product operations leads, product managers, and product leaders managing discovery inputs, product decisions, and roadmap evidence across products.

Pain evidence:

- Product-intelligence vendors and forum evidence show pain around customer signals scattered across calls, tickets, Slack, CRM, surveys, Jira, and feedback tools.
- Productboard, Jira Product Discovery, Dovetail, and similar tools position around shared product knowledge, customer evidence, and product decision workflows.

Accessibility:

- Medium-to-low. Budgets exist, but buyers expect collaboration, integrations, security, migration, admin, and enterprise workflows.

Value potential:

- Medium. The "portfolio map over evidence" resonates, but AFPS-specific repo files are not their native workflow.

WTP signal quality:

- Strong adjacent WTP. Jira Product Discovery lists Standard at $10/creator/month and Premium at $25/creator/month. Productboard Spark lists $15 maker/month annually or $19 monthly. Dovetail lists enterprise customer-intelligence/repository positioning with custom pricing. Condens lists paid research-repository plans from EUR 15/month and business plans from EUR 500/month.

Initial read:

- Attractive adjacent market but too broad and competitive for v1. This should remain a downstream positioning or product-line possibility, not the first ICP.

### Candidate 5: UX research / research ops teams

Who they are:

- UX researchers, research ops managers, and mixed research/product teams maintaining repositories of studies, evidence, transcripts, and insights.

Pain evidence:

- Research repository sources describe the need to centralize, search, tag, and share qualitative research.
- Forum and expert commentary warn repositories often become unused document vaults when stakeholders do not search them or when upkeep is manual.

Accessibility:

- Medium. Professional communities and known tool categories exist.

Value potential:

- Low-to-medium for AFPS Tracker as scoped. UX research teams care about study data, transcripts, participants, tags, highlight reels, and stakeholder consumption; AFPS branch-state tracking is not their primary job.

WTP signal quality:

- Strong adjacent WTP for repositories; weak direct fit.

Initial read:

- Useful cautionary segment, not the primary ICP. Their adoption failures are evidence that AFPS Tracker must avoid becoming another manually maintained repository.

## Prioritization Matrix

Scores use 1-5, where 5 is strongest. Commercial priority weights pain intensity 30%, WTP quality 30%, market accessibility 20%, and product fit 20%. Immediate learning access is shown separately and does not affect the commercial priority score.

| Candidate | Pain Intensity | WTP Quality | Market Accessibility | Immediate Learning Access | Product Fit | Weighted Priority | Interpretation |
| --- | ---: | ---: | ---: | ---: | ---: | ---: | --- |
| AI-native product studios / fractional product-engineering consultants | 4 | 4 | 3 | 3 | 4 | 3.8 | Recommended commercial primary because it balances AFPS fit, business urgency, and an externally findable buyer set. |
| AFPS power users / AI workflow operators | 5 | 2 | 2 | 5 | 5 | 3.5 | Most accessible for immediate learning and dogfooding; weaker as a repeatable commercial market until AFPS user volume and WTP are proven. |
| AI-native solo technical founders / indie builders | 4 | 3 | 5 | 3 | 3 | 3.7 | Very reachable externally and adjacent; adoption of AFPS is the gating risk. |
| Product ops / PM teams in SaaS companies | 4 | 5 | 2 | 2 | 2 | 3.5 | Strong budget evidence but too broad and integration-heavy for AFPS-specific v1. |
| UX research / research ops teams | 3 | 4 | 3 | 2 | 2 | 3.1 | Strong adjacent tooling budgets but different job/data model. |

Recommendation:

- Primary ICP: AI-native product studios and fractional product-engineering consultants who run AFPS or AFPS-like repo-native product discovery across multiple client or portfolio bets.
- Early learning segment: current AFPS power users and dogfooding operators.
- Secondary reachable segment: AI-native solo technical founders, only if they already accept structured product-discovery workflows.
- Exclusions for now: broad PM/product ops and UX research ops teams because they require a less AFPS-specific product surface and heavier collaboration/integration expectations.
- Accessibility clarification: AFPS power users are the most accessible learning audience, while studios and fractional consultants are the stronger commercial-primary hypothesis because they are externally findable and have clearer business-budget logic.

## Proposed Canonical Deliverable Preview: `research/afps-tracker/icp.md`

# AFPS Tracker ICP Research

## Customer Profile

Primary ICP: AI-native product studios and fractional product-engineering consultants who run AFPS or AFPS-like repo-native product discovery across multiple client or portfolio bets.

Plain-language definition:

- They are not generic PM teams and not generic research repositories.
- They are owner-operators or small teams who already use AI agents, skill workflows, structured briefs, markdown files, and repo-local state to move from idea shaping to validated product direction.
- Their economic job is to preserve clarity, evidence, and decision history while exploring many branches quickly.

Buyer persona:

- Studio principal, fractional CTO, fractional CPO/CPXO, product-engineering consultant, AI-native agency lead, or senior product strategist who owns the client or portfolio discovery process.
- The buyer is often also the daily user in early adoption.
- In a small studio, the buyer may later invite researchers, product leads, engineers, or clients as viewers.

Budget:

- Business tooling budget rather than consumer hobby budget.
- Adjacent spend already exists: AI developer tools, coding agents, collaboration tools, product discovery tools, research repositories, and client-delivery systems.
- WTP is strongest when scattered state costs billable time, creates client-facing ambiguity, or weakens confidence in a promoted/deferred product branch.

Discovery channels:

- Codex, Claude Code, Cursor, and AI developer-tool communities.
- AI-native agency, fractional CTO/CPO, product studio, and build-in-public communities.
- GitHub/repo-native workflow discussions.
- AFPS skill-pack users and local dogfooding.
- Adjacent product discovery and research repository discussions.

Geographic Focus:

- Initial focus should be English-speaking operators in the United States, Canada, United Kingdom, Europe, Australia, and similar markets.
- Reason: the source workflow, skill artifacts, and current research language are English; AI developer-tool adoption evidence is strongest in developer communities reachable online.
- Expansion should follow actual AFPS adoption rather than geography-first assumptions.

Named Accounts:

These are not prospects already validated for AFPS Tracker. They are real organizations that fit the broad "AI-native studio / product-engineering operator" pattern and can guide further account research.

| Account | Type | Why It Fits |
| --- | --- | --- |
| Mako Studio | AI-native web/product studio | Positions around AI-native engineering and end-to-end delivery; likely sensitive to project state across multiple builds. |
| Stackd Studios AI | AI-powered build lab / venture studio | Uses AI-assisted development language and serves founders/business owners; likely manages multiple product concepts. |
| AINative Studio | AI venture studio | Frames work around AI product strategy, design sprints, and AI-native companies. |
| Shape Labs | Venture studio for AI-powered products | Publicly offers AI MVP/product services and talks about agentic coding and deliverables. |
| Hechura | Fractional CTO and AI-native product studio | Combines fractional leadership with AI agent systems and product work. |
| CodePixelfy | Fractional CTO / AI launch consulting | Serves founders turning AI ideas into production systems. |
| Kaleido | Fractional CPXO for AI and dev-tool startups | Product/experience operator for AI and dev-tool founders. |
| Sprinter Studio | AI venture factory | Positions around building multiple products with autonomous AI agents. |
| Affiniti | Venture studio | Works with founders from idea to production-ready software. |
| Kainesis | AI venture studio | Positions around proprietary AI methodology and portfolio company building. |

Business Model & Go-to-Market Motion:

- Model type: developer-first workflow tooling, with prosumer/PLG or small-team B2B as the likely first motion.
- Buyer-user relationship: same person initially; small-team expansion if a studio standardizes the workflow.
- Primary motion to validate later: community/dogfood-led discovery, then direct founder/studio outreach. ICP research does not prescribe GTM tactics; it only identifies where evaluation behavior is likely to occur.

## User Profile(s)

Daily users:

- Studio principal or fractional product-engineering operator running research workflows.
- Product strategist or researcher responsible for maintaining evidence and branch state.
- Technical founder or consultant using Codex/Claude/Cursor to run structured product discovery.

Sophistication:

- High. They are comfortable with markdown, Git/repo structures, local files, agent sessions, and structured research workflows.
- They understand that AI agents need persistent context and that unchecked automation can corrupt decisions or files.

Goals:

- Know what each product branch is, why it exists, where it is in the skill pipeline, and what evidence backs its status.
- Resume a research thread without re-reading scattered markdown/YAML/HTML artifacts.
- Explain branch decisions to themselves, collaborators, or clients without reconstructing history from memory.
- Preserve the distinction between active, deferred, archived, revisit-candidate, and promoted paths.

Frustrations:

- State is technically present but scattered across files.
- Alignment pages are rich but hard to scan as a portfolio.
- YAML fields are authoritative but not ergonomic for repeated decision review.
- AI sessions forget, compact, or re-discover context.
- Generic PM tools require manual duplication and do not understand AFPS stage/branch semantics.

## Trigger Events

Ranked by likely urgency:

1. Multiple branches appear in one research cycle. The operator has several ICPs, product paths, market gaps, or problem candidates and cannot remember which are active, deferred, or worth revisiting.
2. A session restarts or compacts. The operator must re-ground the AI workflow against repo state and decision history.
3. A client, collaborator, or future self asks why a path was promoted or deferred. The answer exists, but it is buried across alignment pages and markdown.
4. The operator starts using more than one coding/research agent. Cross-tool context and repo state become harder to coordinate.
5. The number of alignment pages grows. The central index exists, but it is not enough to understand branch state and pipeline progress.
6. Manual manifest edits become risky. Two-way state changes need trust, provenance, and review.
7. A branch is promoted to build. AFPS Tracker must clearly stop at the research-to-build boundary and hand off without becoming an execution tracker.

## Current State Journey

1. The operator starts with an idea brief or concept.
2. Skills generate artifacts: markdown briefs, interview logs, alignment pages, and sometimes `research/.progress.yaml`.
3. Research creates branches: ICP candidates, problem paths, product-line ideas, competitive gaps, or deferred concepts.
4. The operator checks status by opening individual markdown files, YAML, `alignment/index.html`, and task files.
5. The operator asks an AI agent to continue, but the agent must re-read enough context to avoid stale assumptions.
6. If several paths exist, the operator mentally reconstructs which path is current, which was approved, which is blocked, and what evidence supports each.
7. Generic PM or notes tools can mirror this state, but that creates duplicate manual data entry.
8. Eventually the operator either narrows to one branch, parks branches, or loses confidence that the branch map reflects the actual research record.

## Pain Map

| Pain | Severity | Frequency | Evidence Basis | Why It Matters |
| --- | ---: | ---: | --- | --- |
| Scattered state across YAML, markdown, HTML, and tasks | High | High for active AFPS use | Local repo artifacts and idea brief | The core workflow state exists but is not navigable as a whole. |
| Branch sprawl | High | Medium-high when research fans out | Local product-path model and ICP workflow | Portfolio reasoning breaks when active/deferred/revisit paths multiply. |
| Context loss and repeated rediscovery | Medium-high | High for agent-heavy workflows | Stack Overflow trust data, Claude memory docs, forum evidence, agent-control-plane positioning | Operators waste time re-grounding agents and themselves. |
| Weak decision provenance under client or collaborator scrutiny | High | Medium | Product discovery/repository tooling evidence | Studios need to explain why a direction was chosen or parked. |
| Manual duplication into generic PM tools | Medium | Medium | Product management tools are workflow-agnostic | Duplicate state creates drift from the actual source files. |
| Trust risk around write-back | High | Medium | Claude docs distinguish context from enforced hooks; Runshift and similar tools emphasize gates | Two-way sync creates value only if users trust it not to corrupt canonical state. |
| Repository-adoption failure | Medium | Medium | UX research repository failure commentary | Passive maps fail if users must manually maintain them. |

## Current Alternatives (User Perspective)

Current alternatives are mostly workaround bundles rather than direct competitors.

| Alternative | What The User Gets | Why It Falls Short For This ICP |
| --- | --- | --- |
| Manual repo navigation with editor, `rg`, and markdown previews | Complete fidelity to source files | Slow repeated reconstruction; no portfolio view; no stage/branch abstraction. |
| `alignment/index.html` | A central table of contents for review pages | Page-level index, not product-path state or pipeline progression. |
| `research/.progress.yaml` | Authoritative structured state | Correct but not ergonomic for repeated human scanning. |
| Notion, Linear, Trello, Jira | Familiar manual tracking | Requires duplicate entry and does not understand AFPS fields or evidence refs. |
| Jira Product Discovery / Productboard | Budgeted product discovery workflows | Built for ideas, roadmaps, feedback, and teams, not repo-native AFPS branch state. |
| Dovetail / Condens / research repositories | Centralized research evidence and search | Built for studies/transcripts/insights, not skill-stage branch trees. |
| Runshift / ClawCode / CallCode / Kagan / Lightcode | Agent execution orchestration, shared context, file locks, sessions, trust gates | Mostly build/execution oriented; AFPS Tracker is scoped to research portfolio state. |
| Ad hoc memory files such as `PROJECT_STATE.md` or `CURRENT_STATE.md` | Lightweight session continuity | Yet another manually maintained artifact that can drift from canonical workflow outputs. |

Adjacent user language from public sources includes "context loss", "same context", "no state scattered", "source of truth", "single searchable repository", and "trust gates." AFPS Tracker should validate whether AFPS operators use similar words for research-state pain.

## Market Sizing

Confidence: low-to-medium, because direct AFPS adoption data is not public.

Top-down context:

- GitHub reports 180 million-plus developers on GitHub in 2025, with AI adoption now a structural part of developer workflows.
- Stack Overflow reports 84% of 2025 respondents using or planning to use AI tools in development; 51% of professional developers use AI tools daily.
- JetBrains reports 90% of developers regularly used at least one AI tool at work in January 2026, with 74% using specialized AI developer tools.
- Google DORA reports 90% AI adoption among software development professionals and a median two hours daily with AI.

TAM:

- Broad TAM is all AI-assisted technical operators and product builders who manage persistent workflow state across projects. This is very large but too broad to be meaningful for AFPS Tracker.

SAM:

- Real serviceable market is much narrower: English-speaking operators, studios, consultants, and technical founders who use repo-native AI workflows and care about research-stage branching.
- Public evidence supports the growth of AI developer workflows and agent orchestration, but not the number of AFPS-like workflow users.

SOM:

- Near-term obtainable market should be treated as a design-partner pool, not a numeric market: dogfooding plus a small set of AFPS users, AI-native studios, fractional CTO/CPO operators, and solo founders willing to adopt structured discovery.
- A credible first validation target would be 10-30 operators who run multi-branch research workflows, with special attention to whether they already maintain repo-local state.

Adjacent WTP evidence:

- Jira Product Discovery publishes paid creator plans at $10 and $25 per creator/month.
- Productboard Spark publishes $15 maker/month annually or $19 monthly.
- Condens publishes plans from EUR 15/month and business plans from EUR 500/month.
- Dovetail positions enterprise customer-intelligence/repository workflows with custom pricing and a free plan.
- These do not justify AFPS Tracker pricing, but they show that adjacent product discovery and research knowledge workflows can receive budget.

## Stated Value Drivers

Expected value language to validate:

- "I can see every branch without opening five files."
- "I know why this path is active, deferred, archived, or promoted."
- "I can resume work without asking the agent to rediscover the whole repo."
- "I can show a client or collaborator the evidence trail behind a decision."
- "The tracker reflects the workflow's real state instead of another manual board."
- "It helps me manage a portfolio of product bets before committing to build."

Likely aha moment:

- The operator sees a branch tree and pipeline-stage view that correctly reflects the current repo state, including evidence references, without manual data entry.

### Willingness-to-Pay Signals

Paid alternatives:

- AI developer tools and coding agents are already paid categories for this audience.
- Product discovery and research repository tools show budgeted adjacent spend.
- Studios and consultants pay for tools that improve delivery speed, reduce client ambiguity, or preserve decision quality.

Budget owner/context:

- Studio principal, fractional operator, founder, or consultant owns the budget.
- In early use, buyer and user are often the same person, reducing procurement friction.

Current spend or time-cost proxy:

- Time spent reconstructing branch status, re-reading artifacts, or repairing agent context is billable-time loss for consultants/studios.
- Repeated context re-grounding and manual status duplication create direct opportunity cost.

Switching-cost tolerance:

- Higher tolerance if AFPS Tracker reads existing files and does not require migration.
- Lower tolerance for write-back until trust is earned.

Economic urgency:

- Strongest when multiple client/product branches are active and stale decisions can create rework or client confusion.
- Weak for hobbyists or single-idea founders with no portfolio complexity.

Pricing sensitivity cues:

- Solo founders are likely price-sensitive.
- Studios and consultants have stronger business-budget logic.
- Product ops and UX research teams have budget but expect enterprise-grade collaboration and integrations.

## Customer ↔ User Dynamics

Early buyer-user relationship:

- The buyer is usually the operator who runs the workflow.
- Onboarding is likely self-serve and repo-based because the workflow artifacts already exist locally.
- Trust depends on showing that the tracker reads canonical state correctly before it writes anything back.

Small studio relationship:

- Studio lead configures the workflow and owns process quality.
- Team members may need read/edit access to branch state.
- Clients may need a read-only evidence view or exported artifact, but they are not the primary user in the first ICP.

Post-purchase dynamics:

- The tool must remain subordinate to the AFPS workflow, not become a parallel source of truth.
- Any write-back behavior must preserve provenance and be reviewable.
- If the product becomes a manual board, adoption risk increases sharply.

## Discovery & Evaluation Behavior

How they find solutions:

- Through AI developer-tool communities, Codex/Claude/Cursor workflow discussions, GitHub/repo-local tooling, AFPS pack usage, product studio networks, and build-in-public/fractional operator communities.
- They may also encounter adjacent products while looking for AI agent orchestration, project memory, product discovery, or research repository tools.

How they evaluate:

- They try it on an existing repo with real AFPS artifacts.
- They compare against manual file navigation, `alignment/index.html`, Notion/Linear/Trello, product discovery tools, and agent-control-plane tools.
- They inspect whether the tracker faithfully maps `active_paths`, `product_paths[]`, statuses, evidence refs, and alignment pages.
- They check whether it helps resume work after a session gap without stale context.

How they choose:

- They choose if it reduces repeated reconstruction without creating duplicate state.
- They reject if it requires manual upkeep, hides evidence, corrupts YAML, or feels like a generic PM layer.
- They defer if they only run one product path at a time or if AFPS itself is not yet part of their workflow.

## Additional ICPs

### AFPS power users / AI workflow operators

Customer profile:

- Individual AFPS skill-pack users, dogfooders, and agentic workflow operators managing repo-local research state.
- Buyer/user is typically the same person.

User profile:

- Highly technical, comfortable with skills, markdown, YAML, local repo state, and agent memory constraints.

Trigger events:

- More than one active product path, context compaction, restart after a long gap, or need to explain a branch decision.

Current state journey:

- Reads idea briefs, alignment pages, and `.progress.yaml` directly; asks agents to re-read context; manually reconstructs current state.

Pain map:

- Highest product-fit pain, especially around scattered state and branch sprawl.

Current alternatives:

- Manual repo reading, `rg`, `alignment/index.html`, custom memory files, and task docs.

Market sizing:

- Unknown. No public evidence that AFPS is a known workflow category.

Stated value drivers:

- Faithful map over actual AFPS state; low manual effort; clear branch provenance.

WTP:

- Weak-to-medium until AFPS user base and paid intent are validated.

Customer <-> user dynamics:

- Same person; fast feedback; low procurement; high standards for source fidelity.

Discovery & evaluation:

- Finds through AFPS, Codex, local skills workflow, and direct dogfooding.

Assessment:

- Best learning segment; insufficient commercial evidence to be the only ICP.

### AI-native solo technical founders / indie builders

Customer profile:

- Solo founders and indie builders using AI to validate and build multiple software ideas.

User profile:

- Technical or semi-technical, fast-moving, tool-curious, often price-sensitive.

Trigger events:

- Multiple ideas, repeated pivots, losing product clarity while AI makes building faster, or needing to pick one branch.

Current state journey:

- Uses AI planning tools, notes, Notion, GitHub, Cursor/Claude/Codex, and ad hoc docs.

Pain map:

- High idea sprawl and context loss; medium need for rigorous evidence provenance.

Current alternatives:

- MVP Copilot, LaunchChair, startupconcept.ai, Finprob, Notion, Linear, GitHub issues, and manual docs.

Market sizing:

- Large and reachable adjacent audience, but direct AFPS adoption unknown.

Stated value drivers:

- Stop re-evaluating old ideas; preserve why an idea was killed, parked, or selected.

WTP:

- Medium. Existing tools sell to founders, but solo builders often resist additional subscriptions.

Customer <-> user dynamics:

- Same person. Very low procurement friction, high churn risk.

Discovery & evaluation:

- Finds through indie hacker, micro-SaaS, AI builder, and vibe-coding channels.

Assessment:

- Good reach; product fit depends on willingness to adopt AFPS.

### Product ops / PM teams in SaaS companies

Customer profile:

- Product operations leads, PM teams, and product leaders managing discovery evidence and roadmap decisions.

User profile:

- PMs, product ops, design/research partners, support/sales contributors.

Trigger events:

- Feedback volume scales, roadmap decisions need evidence, customer signals spread across tools, or leadership asks for a source of truth.

Current state journey:

- Collects signals from Slack, support, CRM, sales calls, surveys, analytics, Jira, and research docs.

Pain map:

- Strong source-of-truth and evidence-traceability pain, but not AFPS-specific.

Current alternatives:

- Jira Product Discovery, Productboard, Dovetail, Canny, Aha, Airtable, Notion, spreadsheets, and customer feedback tools.

Market sizing:

- Larger and more budgeted than AFPS, but crowded and integration-heavy.

Stated value drivers:

- Connect customer evidence to product decisions and roadmaps.

WTP:

- Strong adjacent WTP, shown by paid creator/maker pricing and enterprise plans.

Customer <-> user dynamics:

- Buyer and user split is more complex; requires admin, permissions, integrations, and stakeholder workflows.

Discovery & evaluation:

- Finds via software review sites, Atlassian/Productboard ecosystems, PM communities, procurement, and vendor comparisons.

Assessment:

- Future adjacent market, not v1 ICP.

### UX research / research ops teams

Customer profile:

- UX researchers and research ops teams managing studies, transcripts, insights, and stakeholder access.

User profile:

- Researchers, research ops managers, designers, PM stakeholders, and insight consumers.

Trigger events:

- Research volume grows, stakeholders cannot find insights, duplicated research wastes time, or knowledge leaves with team members.

Current state journey:

- Stores transcripts, recordings, notes, highlight reels, and reports in repositories or shared drives.

Pain map:

- Strong evidence organization pain, but high adoption risk if stakeholders do not use repositories.

Current alternatives:

- Dovetail, Condens, EnjoyHQ, Aurelius, Airtable, Microsoft Lists, Notion, Miro, and shared drives.

Market sizing:

- Budgeted adjacent category, but not the AFPS branch-state job.

Stated value drivers:

- Searchable insights, traceability to raw data, stakeholder access, reuse of prior research.

WTP:

- Strong adjacent WTP, but weak direct fit.

Customer <-> user dynamics:

- Researchers maintain data; stakeholders consume. Adoption often fails if maintenance is manual or if stakeholders do not search.

Discovery & evaluation:

- Finds via UX research communities, repository comparisons, software review sites, and research ops networks.

Assessment:

- Cautionary evidence pool, not primary ICP.

## Cross-ICP Analysis

### Prioritization Matrix

| ICP | Value Rationale | Accessibility Rationale | WTP Rationale | Recommendation |
| --- | --- | --- | --- | --- |
| AI-native studios / fractional consultants | Multi-client and multi-branch workflows make state loss expensive. | Reachable by direct account research and niche communities. | Business budget; billable-time loss; adjacent paid tools. | Primary ICP. |
| AFPS power users | Exact product fit and best dogfood signal. | Reachable only if AFPS user base exists. | Direct WTP unproven. | Use as learning segment. |
| Solo technical founders | High idea sprawl and high AI-agent use. | Very reachable. | Medium; price-sensitive. | Secondary validation segment. |
| Product ops / PM teams | Strong evidence/source-of-truth pain. | Harder sales/evaluation path. | Strong adjacent budgets. | Defer; adjacent market. |
| UX research / research ops | Strong repository pain and adoption lessons. | Reachable communities. | Strong adjacent budgets. | Exclude for v1; use as cautionary comparator. |

Accessibility clarification:

- AFPS power users have the highest immediate learning access because the concept can be tested through dogfooding and any known AFPS operators.
- AI-native studios and fractional consultants have stronger market accessibility because public accounts, public positioning, and niche operator communities make them externally findable even though they require outreach.
- The primary recommendation optimizes for commercial ICP evidence. The research sequence still starts with AFPS users because they are the fastest way to test exact workflow fidelity.

### Shared Pains

- State exists but is scattered.
- Decision provenance matters.
- AI workflows increase speed but also increase context-management burden.
- Reconstructing past decisions is expensive.
- Manual repositories and boards fail when they require duplicate upkeep.

### Segment Conflicts

- AFPS power users want exact workflow fidelity; product ops teams expect broad integrations and collaboration.
- Solo founders want low-cost simplicity; studios can justify more process if it saves billable time.
- UX research teams organize raw research data; AFPS Tracker organizes workflow state and branch decisions.
- Agent control-plane buyers care about execution safety; AFPS Tracker's first job is research-stage portfolio clarity.

### Product-Line Recommendations

- Do not create new product paths for product ops or UX research yet. They imply materially different product surfaces and require more evidence before activation.
- Keep `research/afps-tracker` active as the AFPS-specific research-state tracker.
- Treat `research/exec-loop-tracker` as a separate active concept outside this ICP because it tracks development/execution rather than research discovery.

### Research Sequence

1. Validate with AFPS dogfooding and any real AFPS users whether scattered branch-state pain is acute.
2. Interview or desk-research AI-native studios/fractional consultants to test whether multi-client discovery creates stronger WTP.
3. Use solo technical founders as an accessibility benchmark, but do not overfit to their price sensitivity.
4. Defer PM/product ops and UX research ops until competitive analysis clarifies whether a broader category move is worth it.

### Discovery & Evaluation Comparison

- Studios/consultants evaluate through client-delivery and portfolio-management pain.
- AFPS power users evaluate by source fidelity and workflow fit.
- Solo founders evaluate by speed and clarity with minimal process overhead.
- Product ops teams evaluate through integrations, collaboration, security, and roadmap/customer-feedback workflows.
- UX research ops teams evaluate through repository adoption, search, tagging, evidence traceability, and stakeholder usage.

## Signals for Downstream Research

- Competitive analysis should map four adjacent clusters: agent control planes, product discovery/PM tools, research repositories/customer-intelligence tools, and AI founder/MVP planning tools.
- Positioning should avoid claiming AFPS is a known public category unless AFPS adoption evidence appears.
- Monetization should treat adjacent pricing as WTP signal only, not as a pricing recommendation.
- GTM research should test which communities already discuss agent context loss, repo-local workflow state, and AI-native product discovery.
- Product research should test write-back trust separately from read-only visualization.

## Next Steps

**Recommended:** `$competitive-analysis` - maps the landscape your ICP operates in so positioning and GTM have competitive grounding

Other options:

- `$competitive-analysis` - Map the competitive landscape for this ICP's market
- `$pack install customer-lifecycle` - Needed before `$journey-map`; map the current-state journey to find intervention points after the pack is enabled in a new session

## Proposed Search Log Preview: `research/afps-tracker/icp-search-log.md`

# AFPS Tracker ICP Search Log

## Query Coverage

Minimum broad-search threshold met: 12+ strategies before candidate selection. Targeted research added at least 2-3 query directions per candidate cluster.

## Broad Market Research Queries

| Strategy | Representative Queries | Findings |
| --- | --- | --- |
| AI coding-tool adoption | `Stack Overflow Developer Survey 2025 AI tools adoption ChatGPT GitHub Copilot Claude Code`; `JetBrains developer ecosystem survey AI coding tools adoption`; `Google DORA 2025 AI adoption software development professionals` | AI-assisted development is mainstream, but developers retain trust concerns and still need human oversight. |
| Developer population / top-down scale | `GitHub Octoverse 2025 number of developers GitHub global developers`; `GitHub Octoverse 2025 AI projects contributions` | GitHub reports 180M+ developers and broad AI-related growth, supporting large adjacent scale but not AFPS-specific demand. |
| Agentic workflow/context pain | `Claude Code Cursor Codex context loss workflow state management`; `AI coding agents workflow state management context continuity multiple agents` | Forum and vendor evidence repeatedly mention context loss, scattered state, session management, shared context, and trust gates. |
| Multi-agent orchestration competitors | `AI agent orchestration coding agents dashboard shared context file locking product 2026 Runshift CallCode ClawCode DevboardAI`; `multi-agent coding agents dashboard shared context file locks` | Runshift, ClawCode, CallCode, Lightcode, Kagan, and similar tools validate adjacent workflow-control pain but focus on execution/build. |
| AFPS-specific public category search | `"alignment-first" "prototype-second" AFPS workflow`; `"research/.progress.yaml" "product_paths"`; `"AFPS" "alignment-first" "skills workflow"` | No meaningful public evidence found for AFPS as a named workflow category. |
| Solo founder / AI product discovery | `AI product discovery tool solo founders idea validation MVP planning pricing`; `vibe coding solo founders AI builders product validation multiple ideas pain tracking` | MVP Copilot, LaunchChair, startupconcept.ai, Finprob, and related tools validate AI-assisted idea validation and planning demand. |
| AI-native studios / consultants | `AI native product studio software agency AI agents product development`; `fractional product engineering consultant AI coding agents product discovery studio` | Many studios/consultants now position around AI-native delivery and product strategy; likely account list is reachable. |
| Product discovery / PM tools | `Jira Product Discovery pricing`; `Productboard pricing product discovery customer feedback source of truth`; `product management customer feedback scattered across Slack Jira Zendesk CRM surveys pain` | Public pricing and positioning validate adjacent paid demand for product-discovery evidence systems. |
| UX research repositories | `Dovetail pricing research repository`; `Condens pricing UX research repository`; `research repository where insights go to die` | Repository tools validate WTP, while forum/expert commentary highlights adoption risk and manual-maintenance failure. |
| Market sizing | `product management software market size`; `AI code assistants market size`; `software development tools market size AI coding assistant` | Market reports support broad adjacent growth, but definitions vary and are too broad for direct AFPS sizing. |

## Targeted Candidate Research

### AI-native product studios / fractional consultants

Sources found:

- Sprinter Studio: https://sprinter.studio/
- Affiniti: https://affiniti.io/
- Stackd Studios AI: https://www.stackdstudiosai.com/
- AINative Studio: https://agency.ainative.studio/
- Mako Studio: https://makoai.studio/
- Kainesis: https://kainesis.com/
- Shape Labs: https://www.shape-labs.com/
- Hechura: https://www.hechura.ai/
- CodePixelfy: https://www.codepixelfy.com/
- Kaleido: https://kaleido.studio/
- Y Combinator RFS: https://www.ycombinator.com/rfs

Findings:

- AI-native studios and consultants publicly use language around AI-assisted product strategy, faster MVP/build cycles, venture studio workflows, and agent systems.
- These organizations likely handle multiple client/product branches, which matches AFPS Tracker's portfolio-state hypothesis.
- Direct evidence that they use AFPS is missing.

### AFPS power users / AI workflow operators

Sources found:

- Local repo artifacts: `research/.progress.yaml`, `research/afps-tracker/idea-brief.md`, `alignment/idea-scope-brief-afps-tracker.html`.
- AFPS public category searches produced no strong external evidence.
- Claude memory docs: https://code.claude.com/docs/en/memory
- Runshift positioning: https://runshift.ai/

Findings:

- Local evidence strongly supports the problem shape.
- Public evidence supports adjacent context/state pain.
- Public evidence does not prove AFPS user volume or direct WTP.

### AI-native solo technical founders / indie builders

Sources found:

- MVP Copilot: https://mvp-copilot.ai/
- LaunchChair: https://www.launchchair.io/
- startupconcept.ai: https://startupconcept.ai/
- Finprob: https://finprob.com/
- Indie Hackers founder workflow thread: https://www.indiehackers.com/post/ai-agent-blueprint-the-ultimate-daily-founder-workflow-solo-founders-only-211deb2d23
- Relevant Reddit/builder discussions surfaced around AI idea validation, build-in-public, and vibe coding.

Findings:

- Solo founders are reachable and experiment with AI workflow tools.
- This group may feel idea sprawl and context loss.
- WTP is weaker due price sensitivity and preference for free/general tools.

### Product ops / PM teams

Sources found:

- Jira Product Discovery pricing: https://www.atlassian.com/software/jira/product-discovery/pricing
- Productboard pricing: https://www.productboard.com/pricing/
- Dovetail pricing: https://dovetail.com/pricing/
- Scattered product feedback examples and PM forum discussions.

Findings:

- Strong adjacent WTP and source-of-truth pain.
- Fit is low for AFPS-specific repo state unless the product is reframed for broader product ops workflows.
- Buyer/user dynamics are more complex than in the proposed primary ICP.

### UX research / research ops teams

Sources found:

- Condens pricing: https://condens.io/pricing/
- Dovetail pricing: https://dovetail.com/pricing/
- UXmatters repository adoption critique: https://www.uxmatters.com/mt/archives/2022/04/why-ux-research-repos-fail-at-democratizing-insight.php
- Reddit research repository discussion: https://www.reddit.com/r/UXResearch/comments/1poyc3j/research_repository_is_where_insights_go_to_die/

Findings:

- Clear adjacent WTP and evidence-management pain.
- Strong warning that repositories fail without workflow integration and stakeholder pull.
- Direct product fit is weak because their core object is research data, not AFPS branch state.

## Evidence Matrix

| Major Claim | Evidence | Inference | Confidence | Decision Impact |
| --- | --- | --- | --- | --- |
| AI-assisted technical workflows are mainstream enough to create a large adjacent user base. | Stack Overflow 2025, JetBrains 2026, Google DORA 2025, GitHub Octoverse 2025. | AFPS Tracker can target AI-workflow operators without needing to educate the market on AI-assisted work itself. | High for adjacent adoption; low for AFPS-specific demand. | Supports staying in developer/workflow tooling rather than broad PM SaaS first. |
| Context/state management is a visible pain in agentic workflows. | Claude memory docs, Runshift positioning, ClawCode/CallCode/Lightcode/Kagan positioning, Reddit context-loss discussions. | Persistent context and shared state are recognized problems; AFPS Tracker applies this to research-stage portfolio state. | Medium. | Supports core pain hypothesis. |
| Direct AFPS category demand is unproven. | AFPS-specific web searches found no meaningful public category evidence. | AFPS Tracker should not assume a large public AFPS market; it must validate from dogfooding and direct users. | High. | Prevents overclaiming market size. |
| Studios/consultants are a better commercial ICP than individual AFPS users alone. | Studio/account research plus adjacent tooling budgets. | Multi-client/product workflows increase pain and business WTP. | Medium. | Drives primary ICP recommendation. |
| AFPS power users are the most accessible learning audience, but not yet the most accessible commercial market. | Local dogfood artifacts and AFPS workflow state are directly available; AFPS-specific web searches found no public category evidence; studio/account research found externally identifiable buyers. | Use AFPS users first for learning, but do not treat dogfood access as proof of repeatable market access or WTP. | Medium-high. | Clarifies the candidate verdict gate and prevents conflating early interviews with commercial ICP selection. |
| Product ops and UX research have adjacent WTP but lower fit. | Jira/Productboard/Dovetail/Condens pricing and positioning; repository adoption critiques. | These markets validate budget but require a broader product surface than AFPS Tracker v1. | Medium-high. | Defer as adjacent markets. |
| Passive maps risk becoming unused repositories if not workflow-emitted. | UX research repository critiques and local concept constraint that AFPS Tracker reads emitted state. | AFPS Tracker's wedge depends on near-zero manual upkeep. | Medium. | Reinforces non-goal: do not become generic manual PM/research repo. |

## Assumptions And Confidence Register

| Assumption | Status | Confidence | What Would Change It |
| --- | --- | --- | --- |
| AFPS users beyond the author exist or can be created. | Unproven | Low | Install/usage data, interviews, or repeated external adoption. |
| AFPS power users are easier to reach for learning than studios, but harder to define as a repeatable market. | Clarified from feedback | Medium-high | A known AFPS user list, install telemetry, community distribution channel, or direct paid-intent evidence. |
| Studios/consultants feel stronger pain than solo founders because they manage multiple client/product bets. | Inferred | Medium | Interviews showing solo founders have equal or greater branch-state pain, or studios do not use structured discovery. |
| Passive visualization is enough for v1. | Inherited from approved idea brief | Medium | Users expect active guidance, reminders, or recommendations during evaluation. |
| Two-way writes will be trusted if reviewable. | Unproven | Low-medium | User testing showing preference for read-only mode only. |
| Product ops/UX research should be deferred. | Evidence-backed judgment | Medium-high | Discovery showing PM/UX teams already use repo-native AFPS-like workflows. |
| Adjacent pricing signals imply WTP but not a price. | Evidence-backed | High | Direct customer pricing interviews. |

## Source Coverage Gaps

- No direct interviews with AFPS users.
- No telemetry or install count for AFPS packs.
- No list of reachable AFPS users or pack adopters that converts dogfood accessibility into commercial-market accessibility.
- No direct WTP evidence for a passive AFPS Tracker.
- Limited independent data on AI-native product studios as a software-tool buying segment.
- Market-sizing reports define categories too broadly to size AFPS Tracker directly.
- Forum evidence is directional and not representative.
- Named-account list is fit research, not proof of need or buying intent.

## Proposed Canonical File Changes After Approval

If final compiled YAML approves this alignment page:

- Write `research/afps-tracker/icp.md` from the proposed canonical deliverable preview above.
- Write `research/afps-tracker/icp-search-log.md` from the proposed search log preview above.
- Preserve `research/.progress.yaml` without adding new product paths in this approval cycle.
- Archive this active working packet to `docs/history/archive/YYYY-MM-DD/HHMMSS/research/afps-tracker/_working/preliminary-icp-research.md`.
- Remove the active working packet after archiving.
- Convert `alignment/icp-afps-tracker.html` from `review` to `confirmed` and preserve the approval record.

## Approval Questions For Alignment Page

- Is the recommended primary ICP correct, or should AFPS power users remain the primary despite weak market evidence?
- Is the commercial-primary versus first-learning-segment distinction clear enough to decide the candidate verdict?
- Is evidence coverage sufficient to write canonical ICP artifacts?
- Should product ops or UX research be parked as future product paths, or only remain as adjacent-market notes?
- Are the proposed file destinations correct?

Compile YAML