Strategic Directions for StoriesOnBoard Agent¶
Status: Complete — Brainstorming done, one unified direction selected Prerequisite: Complete analysis (Step 5 -
03-analysis.md) Previous version:05-directions-v1.md(mechanical gap-fill approach, replaced) Next: Step 7 deep-dive assessment →06-direction-assessment.md
Approach¶
Why redo: v1 mechanically derived directions from competitor gaps ("they don't have X → we build X"). That's backward-looking gap-filling, not strategic brainstorming. Directions should come from understanding where the world is going, not just where competitors have holes today.
Method: Process-first, forward-looking brainstorming:
- Map the SW dev process — what do our target users/personas/teams actually do today? (§1)
- Project agentic impact — how will AI change this process? What steps change, appear, disappear? How do roles shift? (§1)
- Collect pain points — what's broken/missing in current AI approaches, present and speculative future (§2)
- Collect feature/use case ideas — concrete capabilities SOB could offer (§3)
- Overlay competitive landscape — what are competitors doing, where are the real gaps (§4)
- Brainstorm directions — divergent, from the full picture above, not just gap-filling (§5)
- Evaluate & shortlist — converge on 2-3 directions with criteria-based assessment (§6)
Key aspects: - Forward-looking: where is the market going, not just where competitors have holes - Two SW dev contexts: custom development (SOB's home) vs product development (different dynamics) - Agentic shift as driver: building gets cheaper → what to build becomes the bottleneck - Pain points and ideas assessed critically: how well-founded vs speculative, potential vs hype - Competitors inform but don't drive — directions should make sense even if no gap existed - Interactive: built through discussion, not generated in one pass
Direction evaluation criteria (for §6): - Agent differentiation: why our agent, not theirs? - Domain expertise depth - Context moat potential (what data accumulates over time?) - Autonomy level (what can we safely automate?) - Workflow coverage (which end-to-end process do we own?) - Feasibility and SOB fit - Defensibility
1. SW Dev Process Model (Quick Reference)¶
Custom Software Development (better fit for SOB, not exclusive)¶
What: Customer orders software from a dev shop/team. Used by 1 customer. Includes SAP/Salesforce customization (custom dev on vendor frameworks).
Actors: Customer/Stakeholder, BA, PM/PO, Dev Team, UX, Testers
- Customer Need
- Discovery / Workshops
- Scope Definition (story mapping lives here)
- Design
- Development (sprints)
- Testing
- Delivery
- Feedback / Change Requests → back to 2 or 3
Key dynamic: Customer ↔ Dev team communication is the hard problem. Story mapping solves "do we agree on what we're building?"
Product Development (building for market)¶
What: Building a product used by many customers (Slack, Notion, Jira). No single customer to talk to.
Actors: PM, UX Researcher, Designer, Dev Team, Marketing, Sales, Support
- Market Signal
- Discovery / Research
- Vision / Strategy
- Prioritization
- Design
- Development
- Release
- Feedback Collection → back to 2 or 4
Key dynamic: No single customer voice. PM synthesizes many voices. Hard problem: "what should we build next and for whom?"
What's Common¶
Both need: understanding what to build, communicating it, building it, learning from results. The "what to build" phase is where SOB currently plays.
The Agentic Shift — How the Process Changes¶
The big change: Development (step 5) goes from weeks/months to hours/days. This compresses everything else.
How Each Step Changes¶
| Step | Current | With Agentic AI |
|---|---|---|
| 1. Customer Need | Unchanged | Unchanged — humans still have needs |
| 2. Discovery | Manual interviews, workshops, doc analysis | AI can pre-process existing docs/systems, prepare analysis. Human conversation/negotiation still needed. |
| 3. Scope Definition | Days/weeks of mapping, writing stories | AI drafts artifacts fast. Bottleneck shifts from "creating the map" to "making the decisions." |
| 4. Design | Architect proposes, team discusses | AI proposes architectures/patterns. Senior architect reviews. Routine design delegated to AI. |
| 5. Development | Weeks/months per feature | Hours/days. Coding agents handle implementation from good specs. Biggest compression. |
| 6. Testing | Manual + automated suites | AI generates and runs tests. Humans do acceptance/exploratory testing. |
| 7. Delivery | CI/CD already automated | More automated, less change here |
| 8. Feedback | Manual collection, manual processing | AI can process/categorize/summarize feedback. Decisions about what to change still human. |
How Roles Change¶
| Role | Current Focus | Agentic Shift |
|---|---|---|
| Customer/Stakeholder | Describes needs, reviews output | More empowered — may build simple things themselves (vibe coding). Expects faster delivery for complex work. |
| BA | Document requirements, write specs | Shifts to: making decisions, validating AI output, quality gate. Less writing, more thinking. |
| PM/PO | Prioritize, manage backlog, communicate | Less time on artifacts, more on decisions/prioritization. Must keep pace with faster delivery cycles. |
| Dev Team | Write code, fix bugs | Smaller teams do more. Seniors become reviewers/architects. "Coding" skill less scarce, "architecture/judgment" more valuable. |
| UX | Design interfaces, user research | AI generates UI prototypes fast. UX focuses more on research, testing, strategy. |
| Testers | Write/run test scripts | AI generates/runs tests. Testers focus on edge cases, exploratory, acceptance validation. More strategic. |
What Appears / Disappears / Changes¶
New activities: - AI output review/validation at every stage (quality gate becomes constant) - Spec quality becomes critical — agents need good specs to produce good code (garbage in, garbage out) - Prompt/instruction crafting as a skill
Shrinks significantly: - Manual documentation writing - Routine coding - Manual test script creation - Time spent on each individual sprint/cycle
Changes character: - Scope definition: could become more iterative — map → prototype → refine map → build. When building is cheap, "just try it" becomes viable for validating scope decisions. But for complex systems with many stakeholders, explicit agreement is still needed. - Planning tempo: faster delivery means faster planning cycles needed. PO/BA must keep up.
Key Implication for SOB¶
The decision-making and communication steps (2, 3, 4) become the bottleneck, not building (5). Story mapping's core value — "do we agree on what we're building?" — remains relevant but the PACE changes. Teams need to scope/decide/communicate faster because building no longer slows them down.
2. Pain Points & Market Observations¶
2.1 Observed Pain Points (from SOB users)¶
Brownfield story mapping problem: Teams almost never start from greenfield. They need to build INTO existing software, and they struggle with: - What to map vs what not to map from the existing system - They don't have extensive documentation of what exists - Even if they have docs, processing them into story maps is too much work / they don't know how (not an easy task) - Result: they either skip mapping the existing system (losing context) or spend days doing it manually
Why this matters: New stories need to blend into existing scope/flow/behavior/business rules. Without visibility into what exists, new features risk overlapping, contradicting, or ignoring existing functionality. Both the humans (BAs/POs, customers) and the AI agent need this context to plan properly.
2.2 Market-Level Observations (from CEO notes — docs/planning/preliminary-docs/)¶
Vibe coding threat: "Anyone" can now build apps with AI. SOB's "story mapping helps you get to MVP fast" value prop becomes less relevant when you can just vibe-code the MVP directly. This threatens the simpler end of SOB's market.
But for "proper" software: Quality, planning, specification become MORE important in AI-accelerated workflows. Dev time shortens → PO/BA role must speed up too → need to assess/plan/specify faster.
Two distinct market threads: 1. Traditional apps become much cheaper/faster to build 2. New category: AI agents replacing many traditional apps entirely (tasks that needed separate UIs now done by agents)
Market implications: - Market may shrink overall (cheap apps flood the market) - Huge gap between top AI adopters and the rest - Everything changes fast — don't over-plan, assume disposability
2.3 Pain Points with Current AI Approaches¶
Adoption fear / tool churn anxiety: AI tools and methods are evolving so fast that companies can't follow. They fear committing to any tool or method because a new one might appear in two months and make their investment (tool, process, training) obsolete. This creates paralysis — teams know they should adopt AI but are afraid to bet on anything.
AI trust gap — "tried it, doesn't work for me": Many users have tried AI tools and concluded they don't produce valuable results: - Output is disconnected from their context/knowledge/world - Results feel random, not grounded in their actual situation - They can only use a small percentage of what AI generates - Reviewing and refining AI output is more work than just doing it themselves - Net result: AI feels like extra work, not a shortcut
Expectation gap (flip side): Overhyped media shows vibe coding creating apps in minutes. When people then try AI for real planning/PM work and get mediocre results, the disappointment is amplified. Two failure modes: - Skeptics: "I tried it, it's useless" (undertrust) - Overbelievers: "AI can build my app in 5 minutes" → crash into reality of enterprise complexity (overtrust)
Vibe coding's hidden decision problem: Vibe coding tools can build apps fast, but they skip analysis/planning stages that exist for a reason. Circumstances, rules, edge cases need to be assessed; detailed decisions need to be made. These decisions are traditionally made deliberately by humans (customer, BA, architect). In vibe coding, the LLM invents them on its own — because the code must work one way or another, the LLM silently makes up decisions without the customer even knowing those decisions existed or were being made. - For simple/personal tools: acceptable - For anything with real business rules, compliance, multiple stakeholders: those hidden decisions are a liability - Pain point: vibe coding creates an illusion of "done" while the LLM has silently invented countless decisions the customer never made - Opportunity angle: even when building is instant, someone still needs to make and communicate decisions explicitly. Planning's job shifts from "tell devs what to build" to "make decisions visible so they don't get invented by AI without anyone knowing"
3. Feature / Use Case Ideas¶
From CEO's preliminary notes + discussion. To be critically assessed and elaborated.
3.1 Assessment / Existing System Mapping Agent¶
Scan existing artifacts (Jira backlogs, PRDs, help docs, potentially code/UI/API) → generate story map of existing system. Solves the brownfield problem (§2.1): teams can finally see what they have before planning what to add.
3.2 Well-Informed Planning Agent¶
Agent that knows related stories, their behavior, ACs, business rules. Uses that context to: - Ask the right questions during planning - Generate ACs that fit with (not contradict/overlap) existing ones - Suggest user journeys that blend into existing flows
Depends on 3.1 — needs the existing system context to be "well-informed."
3.3 Workflow-Based Operation¶
SOB supports structured workflows within its scope: assessment → requirements analysis → spec writing → planning. Not just individual AI actions, but guided multi-step processes where one step feeds the next. Moonshot: extend into development via coding tool integrations (SOB hands off spec → agent codes it).
3.4 Customizable Workflows & Templates¶
Teams can define their own workflows, templates, processes within SOB. Different teams work differently — SOB adapts to them rather than imposing a single process.
3.5 SOB as Single Source of Truth for Agents (MCP + beyond)¶
Broader than just "expose an API." SOB becomes the structured, curated database of what to build — the single source of truth that agents consume. Story maps, stories, ACs, business rules, scope decisions — all structured and maintained in SOB.
Why agents need this: Agents need accurate and complete information to work well, but ONLY for their specific task. Context window limitations and attention degradation mean too much info is as bad as too little. SOB provides exactly the right information and nothing more — structured, scoped, relevant to the task at hand.
Use cases: - Developer agent queries SOB for the specific story + ACs + related context before coding - BA/dev agent surveys application code and creates/updates story map in SOB - QA agent reads story + ACs to generate test cases - Agent-to-agent workflows (still speculative — "extreme, unforeseeable things possible")
Why this matters: If SOB isn't in the agent ecosystem, it becomes invisible. Dev tools (Cursor, Copilot, Claude Code) are where developers live. SOB needs to be accessible from there — not as a passive data store, but as the authoritative source of "what should this software do."
3.6 Methodology as Value Proposition¶
The industry has become hard to follow. SOB provides a clear, understandable, working methodology for maintaining quality while multiplying speed with AI. Not just a tool — a way of working.
3.7 Service Offering — AI Adoption Consulting¶
Help teams introduce AI into their planning/development process. Also serves as customer research channel (learn about customers' problems, projects, technical constraints).
3.8 Positioning Concepts (from preliminary notes)¶
- "Enterprise grade AI powered software development"
- "The AI Agent Orchestrator for Software development"
3.9 Vision: SOB Agent-Driven Development Workflow¶
Not decided, not set in stone — especially the concrete steps. A vague but directional vision.
- Multi-source input: Teams give SOB agent various sources — screen mockups, drawings, business process flows, diagrams, Jira tickets, even code (through an agent running in customer's environment, connected via MCP). These artifacts are stored in SOB as reference (uploaded or linked to other systems).
- Systematic assessment: SOB agent has a workflow for processing these inputs — assessing what they are, how they affect existing artifacts/story map/stories, what to do with them.
- Proposed processing steps: Agent proposes processing steps for the user. User can review/change/accept.
- Build & refine: Agent updates/builds/refines story map and stories based on inputs, proposes next steps for the changes.
- Precise story writing: Stories are written by the agent precisely, taking into account the surroundings, requirements, existing behavior, business rules. Written such that a coding agent with code and architecture knowledge can implement them well.
- Moonshot — coding agent orchestration: Coding agents running in customer's environment (in containers, with bypass permissions for autonomous operation) connected to SOB. Feature implementations initiated by SOB agent calling the coding agent. Coding agent's progress, questions monitored from SOB. Results deployed to test systems for user review/testing.
Note: This describes the internal build/refine cycle only. The full real-world process also includes customer-facing steps: gathering info from customers, processing it, negotiating/aligning with them, communication, etc. SOB could support those too — the vision above is one part of the whole, not the whole itself.
Detailed specs as part of the process: Between story writing and coding, architects/senior devs likely need to write more detailed specs (from/through SOB). A coding agent can't fully implement a feature without detailed, reviewed specifications — this is where the decisions (§2.3 vibe coding problem) get made explicitly.
3.10 Reference: SOB's Own Dev Process (orchestrator skill)¶
SOB's own development uses an 8-stage agent workflow that mirrors the vision above:
| Stage | Name | Mode | Key Activity |
|---|---|---|---|
| 1 | Requirements Planning | Interactive | Gather reqs, define ACs, assess impact |
| 2 | Concept Design | Interactive | Architecture decisions, design with user |
| 3 | Implementation Plan | Autonomous | Detailed task breakdown from spec |
| 4-5 | Plan Review Loop | Autonomous | Review + incorporate feedback |
| 6 | Implementation | Autonomous | Code from spec |
| 7-8 | Code Review Loop | Autonomous | Review + incorporate feedback |
Key pattern: Stages 1-2 are interactive (human decisions), stages 3-8 are autonomous (agent can do them). The spec file is the single source of truth — exactly the SOB-as-source-of-truth concept (§3.5).
The connection: This is essentially the product vision (§3.9) applied to SOB's own development. The product idea is: make this kind of structured, agent-driven development workflow available to SOB customers.
4. Competitive Landscape Highlights¶
Key findings from 03-analysis.md relevant to direction brainstorming:
- Story mapping methodology gap: Confirmed across all 14 active competitors — nobody has methodology-aware AI
- Feedback → journey gap: Productboard/Aha! collect feedback but output flat features, not story maps
- Cross-project learning gap: No tool learns patterns across customers' projects
- Autonomy in PM domain: PM tools stuck at L1-L2 while code tools are at L3
- Table stakes (don't differentiate here): multi-model, basic AI drafts, enterprise search, chat interface, MCP
5. Direction Brainstorming¶
5.0 Balanced Input Summary (brainstorming canvas)¶
All inputs compressed and on equal footing. Each item tagged by source.
Process & Market: - P1. Development compresses (weeks → hours); decision-making/communication become the bottleneck [§1] - P2. BA/PM roles shift from artifact creation to decision-making + AI validation; must work faster [§1] - P3. Spec quality becomes critical — agents need good specs to produce good code [§1] - P4. Vibe coding: "anyone" can build apps → SOB's "MVP fast" value prop threatened at simpler end [§2.2] - P5. "Proper"/enterprise SW: planning & QA become MORE important, not less [§2.2] - P6. AI agents as new app category — replacing some traditional apps/UIs entirely [§2.2, CEO notes] - P7. Market may shrink overall; huge gap between top AI adopters and the rest [§2.2] - P8. Scope definition may become more iterative — map → prototype → refine when building is cheap [§1]
Pain Points: - X1. Brownfield problem: teams can't story-map existing systems, abandon mapping or lose context [§2.1] - X2. Adoption fear: tools/methods change so fast, companies afraid to commit to anything [§2.3] - X3. AI trust gap: "tried it, output is random/disconnected from my world, more work to review than DIY" [§2.3] - X4. Expectation gap: overhyped demos vs disappointing reality for real work [§2.3] - X5. Vibe coding's hidden decisions: LLM silently invents business decisions customer never made [§2.3]
SOB Strengths: - S1. Story mapping methodology expertise (10+ years, unique visual approach) [01-sob-context] - S2. Mature Jira/ADO bidirectional sync [01-sob-context] - S3. Existing AI capabilities (story generation, INVEST analysis, AC generation) [01-sob-context] - S4. Enterprise-ready: ISO 27001, SOC 2, SAML SSO, unlimited free guests [01-sob-context] - S5. Visual 2D story map structure as unique context source [01-sob-context] - S6. Existing feedback collection feature [01-sob-context] - S7. Custom AI functions (user-defined prompts) already exist [01-sob-context]
Competitive Gaps: - C1. Nobody has methodology-aware story mapping AI (confirmed across 14 competitors) [§4, 03-analysis] - C2. Feedback → journey pipeline gap: Productboard/Aha! output flat features, not story maps [§4] - C3. Cross-project pattern learning: no tool learns across customers' projects [§4] - C4. PM tools stuck at L1-L2 autonomy while code tools are at L3 [§4] - C5. No tool bridges planning context (story maps) with execution context (Jira/code) deeply [03-analysis]
Feature/Use Case Ideas: - F1. Assessment agent: scan existing artifacts → generate story map of existing system [§3.1] - F2. Well-informed planning: agent knows related stories/ACs/rules, plans fitting new work [§3.2] - F3. Workflow-based operation: structured multi-step processes within SOB's scope [§3.3] - F4. Customizable workflows & templates [§3.4] - F5. SOB as single source of truth for agents — structured, scoped info for coding agents [§3.5] - F6. Methodology as value prop — clear way of working amid industry chaos [§3.6] - F7. Service offering: help teams adopt AI in planning/dev process [§3.7] - F8. Vision: multi-source input → systematic assessment → story map → precise stories → (moonshot) coding orchestration [§3.9] - F9. MCP: developer agents read specs from SOB; BA agents survey code → update story map [§3.5] - F10. Detailed specs as bridge between stories and code — where decisions get made explicitly [§3.9]
5.1 Brainstorming by Lens¶
Generate candidate directions from different angles. Overlap between lenses = strong signal.
Lens 1: Process Gaps — Which steps in the new-era process lack good tooling?¶
Looking at the agentic-era process (§1), where are the holes?
- Discovery/assessment of existing systems (step 2): No tool helps teams understand what they already have before planning new work. Coding agents have "codebase understanding" but nobody translates that into planning-level visibility. [P2, X1, F1]
- Scope definition speed (step 3): Story mapping works but is too slow for compressed dev cycles. Teams need to scope in hours, not days. Current tools (including SOB) assume a leisurely workshop pace. [P1, P2, P8]
- Spec quality for agents (between steps 3-5): Coding agents need precise, unambiguous specs. No tool focuses on producing agent-consumable specifications. PRDs and user stories weren't designed for AI readers. [P3, F10]
- Feedback → planning loop (step 8→2): Feedback tools collect and categorize, but nobody closes the loop back into story maps. Insights die in dashboards. [C2]
- Decision tracking: Which decisions were made, by whom, why, and what alternatives were considered. Vibe coding makes this worse (X5) but it's a gap in all AI-assisted development. [X5]
Lens 2: Pain Point Solutions — Which problems can SOB uniquely address?¶
For each pain point, does SOB have a structural advantage in solving it?
- X1 Brownfield → Assessment agent: SOB is THE story mapping tool. Assessment output (existing system → story map) naturally belongs here. Others would have to build story mapping first, then build assessment on top. SOB skips step 1. [F1, S1]
- X3 AI trust gap → Context-aware AI: The core complaint is "AI doesn't know my world." Story map structure IS the user's world — goals, journeys, stories, ACs, business rules. If AI draws from this, output is grounded, not random. SOB can solve the context problem that makes AI output useless. [F2, S5]
- X5 Hidden decisions → Explicit decision-making: Making decisions visible and deliberate is literally what story mapping was invented for. "Do we agree on what we're building?" is the antidote to "the LLM decided without us." [S1]
- X2 Adoption fear → Methodology over tools: If SOB positions around a method (how to plan in the AI era) rather than specific AI tech, the method survives tool churn. "The way you plan doesn't change every 2 months even if the AI underneath does." [F6]
- X4 Expectation gap → Structured, realistic approach: Counter the hype with a structured process that actually works. Not "build apps in 5 minutes" but "build the right thing, reliably, with AI acceleration." [F6, P5]
Lens 3: Strength Leverage — What can SOB do that others structurally can't?¶
- Story-map-as-context: SOB's 2D visual structure (Goals → Steps → Stories) is a unique context source for AI. Like Cursor has "codebase-as-context" and Miro has "canvas-as-context," SOB has story-map-as-context. Nobody else has this data structure. The richer the context, the better the AI output — and story maps ARE rich structured context. [S1, S5, C1]
- Planning ↔ execution bridge: Nobody else has deep bidirectional Jira/ADO sync + story map context. SOB knows which stories became which tickets, what the original intent was, what changed during implementation. This two-sided context is unique. [S2, C5]
- Cross-project pattern learning: 10+ years of story maps from many customers = unique dataset. "Teams building e-commerce typically structure checkout as..." Nobody else has this data to learn from. [S1, C3]
- Enterprise AI planning: Already enterprise-ready (S4) + methodology expertise (S1) + AI capabilities (S3). Can credibly serve "proper" software teams that need structured planning (P5), not just vibe coders. [S4, P5]
Lens 4: Market Positioning — Where does the market shift create new positions?¶
- "The quality gate for AI-era software development": As building gets cheap, the value shifts to ensuring the RIGHT thing gets built. SOB as the place where decisions are made explicitly before agents execute. Targets P1, P3, X5. [P1, P5, X5]
- "The spec engine for coding agents": Coding agents need precise input. SOB produces structured, agent-consumable specs (stories, ACs, context). SOB becomes the brain; coding tools become the hands. Targets P3, F5, F10. [P3, F5, F10]
- "Enterprise AI planning platform": Vibe coding takes the low end (P4). SOB moves up — for teams building serious software that need proper planning, quality assurance, stakeholder alignment. AI-accelerated but rigorous. [P4, P5, S4]
- "AI adoption bridge for mid-market": Huge gap between AI leaders and the rest (P7). SOB + methodology helps mid-market companies adopt AI in their planning/dev process without betting on a specific tool. [P7, X2, F6, F7]
Lens 5: Feature Composition — Which §3 ideas compose into coherent directions?¶
Cluster A — F1 (assessment) + F2 (well-informed planning) + F5 (source of truth) + F10 (detailed specs): → "Context-aware planning platform": Assess what exists, plan new work in full context, produce specs agents can execute. The story map becomes a living, AI-maintained knowledge base of the system.
Cluster B — F3 (workflows) + F4 (customizable) + F6 (methodology) + F8 (vision): → "Structured AI workflow for software planning": Guided multi-step process from discovery to spec, customizable per team. Not just a tool but an opinionated way of working.
Cluster C — F5 (source of truth) + F9 (MCP) + F10 (detailed specs): → "SOB as brain for the dev agent ecosystem": Structured source of truth that feeds coding agents exactly what they need. SOB orchestrates what gets built; coding agents handle how.
Cluster D — F6 (methodology) + F7 (service): → "Methodology-as-a-service": Beyond software — SOB provides a way of working + consulting/guidance for AI-era planning.
Cluster E — F1 (assessment) + F8 (multi-source input): → "Universal input → story map": Take anything (code, docs, mockups, Jira tickets, diagrams) and turn it into structured story maps. Solves the "starting from zero is too hard" problem.
5.2 Codex Independent Brainstorming (unbiased second opinion)¶
Codex was given §1-4 (inputs only, not our lens analysis) and asked to generate directions independently.
| # | Codex Direction | Match to Our Analysis |
|---|---|---|
| 1 | Brownfield "As-Is" Mining Agent | Strong match: our F1, X1, Lens 1+2 |
| 2 | Decision Ledger + Spec Contract | Strong match: our "quality gate" / "explicit decisions" |
| 3 | Feedback → Journey Pipeline | Strong match: our C2, Lens 1 |
| 4 | Autonomy Slider for PM/BA | Strong match: our C4 |
| 5 | Cross-Project Pattern Benchmarks | Strong match: our C3, Lens 3 |
| 6 | SOB as Agent Source of Truth | Strong match: our F5, Lens 1+3+4+5 |
| 7 | Live Workshop Copilot | New — we missed this |
Convergence: 6/7 directions match our independent analysis. Strong validation signal.
New from Codex — Live Workshop Copilot: An agent that participates in real-time discovery workshops. Captures decisions live, keeps the map coherent, flags missing questions, produces client-ready scope summary. Leverages SOB's existing collab features (unlimited guests, presenter mode). Directly targets SOB's core use case: customer ↔ dev team communication.
What Codex missed: Methodology as value proposition, enterprise positioning, AI adoption bridge, structured workflow concept.
5.3 Candidate Directions (deduplicated from all sources)¶
Collapsing 5 lenses + Codex into distinct directions. Each direction appeared in multiple independent analyses.
Direction A: Context-Aware Planning Platform¶
What: SOB knows your existing system (via assessment/import) and uses that context to help plan new work that fits — no contradictions, no overlaps, no reinventing what exists. Story-map-as-context is SOB's version of Cursor's codebase-as-context.
Key capabilities: Assessment agent (brownfield → story map), well-informed planning, context-grounded AI output
Supported by: Lens 1 (discovery gap), Lens 2 (trust gap, brownfield), Lens 3 (unique strength), Lens 5 (Cluster A), Codex #1. Pain points X1, X3. Strengths S1, S5. Features F1, F2.
Convergence strength: Very strong (4 lenses + Codex)
Direction B: Spec Engine / Source of Truth for Agent Ecosystem¶
What: SOB becomes the structured requirements backend that coding/QA agents consume. Stories + ACs + decisions + context, scoped precisely for each agent's task. SOB decides WHAT; coding agents handle HOW.
Key capabilities: MCP server, agent-consumable spec output, structured scoping per task, detailed spec writing
Supported by: Lens 1 (spec quality gap), Lens 3 (Jira bridge), Lens 4 (market position), Lens 5 (Cluster C), Codex #6. Market P3. Features F5, F9, F10.
Convergence strength: Very strong (4 lenses + Codex)
Direction C: Explicit Decision-Making / Quality Gate¶
What: SOB as the place where decisions are made visible and deliberate — the antidote to vibe coding's hidden decisions and AI-generated ambiguity. Decision tracking, spec contracts, approval flows.
Key capabilities: Decision ledger, spec review/approval, traceability (decision → story → code)
Supported by: Lens 1 (decision tracking), Lens 2 (hidden decisions), Lens 4 (quality gate position), Codex #2. Pain points X5. Strength S1.
Convergence strength: Strong (3 lenses + Codex)
Direction D: Methodology & Structured Workflow¶
What: SOB provides not just a tool but an opinionated, structured way of working for AI-era software planning. Guided workflows (assessment → planning → spec), customizable per team. The methodology survives tool churn.
Key capabilities: Workflow engine, templates, guided processes, methodology content/guidance
Supported by: Lens 2 (adoption fear), Lens 4 (AI adoption bridge), Lens 5 (Cluster B+D). Pain points X2, X4. Features F3, F4, F6, F7.
Convergence strength: Medium-strong (3 lenses, not in Codex)
Direction E: Feedback → Story Map Pipeline¶
What: Transform customer feedback into journey-structured story maps, not flat feature lists. Close the loop from feedback collection back into planning.
Key capabilities: Feedback clustering into journeys, story map proposals from feedback themes, evidence linking
Supported by: Lens 1 (feedback loop gap), Codex #3. Competitive gap C2. Strength S6.
Convergence strength: Medium (1 lens + Codex + competitive gap)
CEO ruling: OUT — Too narrow. SOB has a wider feature set/use case now; focusing on feedback pipeline would cause other capabilities to wither. Could be a feature within a larger direction, but not a direction on its own.
Direction F: Cross-Project Pattern Learning¶
What: Learn from story maps across all customers to suggest structures, patterns, benchmarks. "Teams building e-commerce typically structure checkout as..."
Key capabilities: Anonymized pattern extraction, industry/domain benchmarking, template suggestions
Supported by: Lens 3 (unique strength), Codex #5. Competitive gap C3. Strength S1.
Convergence strength: Medium (1 lens + Codex + competitive gap). Highest defensibility but lowest feasibility.
CEO ruling: OUT — Customer story maps contain very sensitive data (trade secrets, IP). Cannot share or aggregate information across customers. The privacy/consent problem isn't just hard — it's a dealbreaker.
Direction G: Live Workshop Copilot¶
What: AI agent that participates in real-time discovery workshops. Captures decisions, structures map live, flags missing questions, produces client-ready summary. Goes directly at SOB's core use case.
Key capabilities: Real-time collaboration AI, live structuring, question generation, workshop facilitation
Supported by: Codex #7 (new). Leverages S1 (methodology), S4 (unlimited guests, presenter mode). Addresses P1 (decision-making bottleneck), P2 (BA must work faster).
Convergence strength: Low (Codex only), but directly targets SOB's core value proposition.
CEO note: Good idea but too narrow as a direction. Could be a feature within a larger direction.
Direction H: Autonomy Slider for PM Work¶
What: Cursor-style graduated autonomy: L0 suggestions → L1 drafts → L2 restructuring → L3 autonomous map maintenance. Users control how much independence to give the AI.
Key capabilities: Configurable autonomy levels, approval gates, progressive trust-building
Supported by: Codex #4. Competitive gap C4. Arguably more of an implementation pattern than a strategic direction — applies to HOW any direction is delivered.
Convergence strength: Low as standalone direction. High as cross-cutting UX principle.
CEO note: Doesn't seem impactful enough as a direction. More of a UX principle to apply across whatever direction is chosen.
5.4 Synthesis¶
Directions E, F, G, H ruled out as standalone directions (see notes above). E and G could be features within a larger direction. F is a dealbreaker (IP/trade secret). H is a UX principle, not a direction.
Directions A+B+C unified into one direction (CEO confirmed). They are facets of the same idea: - A = SOB knows your system (context in) - B = SOB feeds agents the right info (structured output) - C = SOB ensures decisions are explicit (governance)
Direction D complements A+B+C — it explains HOW the unified direction is delivered: through structured methodology and guided workflows, not just features.
The Unified Direction¶
Positioning: The trustworthy, structured approach to software planning in the AI era.
In a market full of AI chaos, overpromising tools, and methods that change every month — SOB is where teams make deliberate decisions about what to build, grounded in real context, delivered through a reliable methodology. AI accelerates the work but doesn't replace human judgment. Your decisions, your process, your control.
Why this positioning works (grounded in research inputs): - X2: Adoption fear / tool churn → SOB offers a stable methodology that survives tool changes - X3: AI trust gap → SOB's context-aware AI produces grounded, relevant output — not random noise - X4: Expectation gap → SOB is honest about what AI can/can't do; structured approach, not magic promises - X5: Hidden decisions → SOB makes decisions visible; nothing happens without the team knowing - P5: "Proper" software needs more planning, not less → SOB is built for this - P1: Decision-making is the bottleneck → SOB is where decisions happen
Supported by capabilities (features that make the positioning real):
| Layer | What | Source |
|---|---|---|
| Context | SOB understands the existing system and all planning artifacts | A (context-aware planning) |
| Governance | Decisions are explicit, tracked, human-made — not hidden in AI output | C (decision-making) |
| Output | Structured, scoped specs that agents can consume and execute from | B (source of truth / spec engine) |
| Method | Structured methodology and guided workflows, not ad-hoc AI features | D (methodology & workflow) |
5.5 Result¶
The brainstorming produced one unified strategic direction with four supporting capability layers:
Positioning: The trustworthy, structured approach to software planning in the AI era.
Direction: SOB as the planning brain for AI-era software development.
| Layer | What |
|---|---|
| Context | SOB understands the existing system and all planning artifacts |
| Governance | Decisions are explicit, tracked, human-made — not hidden in AI output |
| Output | Structured, scoped specs that agents can consume and execute from |
| Method | Structured methodology and guided workflows |
Ruled-out directions (E, F, G, H) may contribute as features within this unified direction but are not standalone strategic bets.
Direction 4 (Jira Context) and Direction 5 (Autonomy Slider) from v1 are folded in as implementation aspects: Jira context enriches the Context layer; autonomy slider is a UX principle for the Method layer.
5.6 Critical Check: Would Anyone Build This From Scratch?¶
Before proceeding to assessment — does this direction actually need to exist as a product?
What someone WOULD build from scratch¶
Spec engine for agents — yes, likely. As coding agents go mainstream, there's a genuine architectural gap: agents need structured, precise input. Right now specs live in scattered Jira tickets, Confluence pages, Google Docs — none designed for agent consumption. Someone will build the structured requirements layer that feeds coding agents. This is a real infrastructure need, not invented.
Planning brain — partially. The "what to build" bottleneck is real (P1). As dev costs drop, the value shifts to deciding what to build. But would someone build a NEW tool for this? More likely: existing tools expand into it (Jira adds better AI planning, Linear improves, Notion gets smarter). The opportunity is real but competitive response risk is real too.
Story mapping methodology angle — probably not from scratch. Nobody would start a new company today around story mapping specifically. Too niche. They'd build something broader — an "AI-native planning tool" that might include story mapping as one feature among many.
Why it's needed¶
- Coding agents are exploding but planning input is stuck in the old world — this gap WILL be addressed by someone
- The hidden decisions problem (X5) is a genuine liability that will become more visible as vibe-coded software fails in production
- Enterprise teams need governance/traceability for AI-assisted development — regulatory pressure will drive this
Why it might NOT be needed as a separate product¶
- A sufficiently powerful agent with MCP access to Jira + codebase + docs might just DO this without a dedicated tool
- Bigger players (Atlassian, Linear, Notion) could add planning intelligence with more resources and larger user bases
- "Better planning" is historically hard to sell — people resist process overhead, value is abstract ("make better decisions" vs "save 2 hours/week")
Honest Assessment¶
The NEED is real. The question is whether it needs to be a standalone product or whether it gets absorbed into existing platforms. SOB's advantage: it exists, has the methodology, has the Jira integration, has 10 years of product. Building from scratch would be harder. SOB's disadvantage: scale — Jira has millions of users, SOB doesn't.
The strongest argument for SOB specifically: Depth beats breadth for specialized tasks. Cursor beat GitHub Copilot in mindshare by being deeper on code. SOB could do the same for planning — deeper on story mapping methodology than Jira's generic AI could ever be. But only if the depth is genuinely valuable, not just different.
This question should be revisited in Step 7 with concrete capability analysis: which specific capabilities in this direction create value that existing tools can't replicate by adding a feature?
6. Next: Step 7 — Direction Assessment¶
Deep-dive assessment of the unified direction in 06-direction-assessment.md:
- What does this look like concretely? (capabilities, phasing)
- Who exactly is the target? (persona, company type, use case)
- What's the competitive position?
- What are the risks?
- What's feasible short-term vs long-term?
- How does it map to SOB's existing capabilities?