thekb.eu — Strategy & Frameworks

Loop Engineering for Product Managers

Sun, 21 Jun 2026 00:00:00 GMT

In this long-form essay published on X, **Shubham Saboo** argues that the next decisive skill for the Product Manager in the age of agents is not **prompt engineering** but **Loop Engineering**. The end state is not a PM writing the perfect prompt every time they need something, but a PM **designing a system that improves with every run**. A loop is a repeated cycle: change what shapes the agent's behavior, run it, evaluate the output, keep the change if quality improves and revert it otherwise, then **compound the learning** so the next version starts ahead. For an engineer, this cycle starts from code. For a PM, it starts from the **artifacts** that structure product work: PRD-review skill, customer-call *summarizer*, evaluation rubric, launch checklist, research workflow, `CLAUDE.md`, prompt template, prioritization framework. Durable and reused, they encode judgment and shape the agent across dozens of runs — so they **compound in both directions**. This is where the real problem shows up: **drift**. The CLAUDE.md keeps growing, the checklist swells, eval criteria change without a trace; a month later the agent "seems worse." The model has not regressed: the artifacts have drifted unwatched, and this is precisely what Loop Engineering corrects. A useful loop has **five parts**: trigger, action, **proof**, memory, **stop condition**. The last is the most critical: many systems fail for lack of a clean exit (scope creep, a confident summary with no proof). A good loop must be able to say "stop" — nothing changed, input too thin, blocked, bar not met, human decision required. Putting one's judgment into reusable artifacts requires that **taste** now come with **proof**: **evals** become PM work, built from known examples (3 good / 3 bad PRDs, 5 understood calls, 2 past launches). The question is no longer "does the agent look smart?" but "did this artifact improve against known product judgment?" Learning needs a **memory**: **GitHub**, where the artifact, diffs, eval results, decision log, and rollback path live — *"the repo becomes product memory."* Saboo advises starting small, with **product ops**: a **weekly product signal loop** (every Friday) producing a memo that separates repeated signal from isolated noise. The loop informs a decision the PM **keeps**: *"build the loop, but stay the PM."* Generation is solved; verification and judgment remain.

How the X Algorithm Actually Works in 2026 — and What That Means for Growth

Sat, 16 May 2026 00:00:00 GMT

Internal teardown report on the open-source release **`xai-org/x-algorithm`** (May 15, 2026) — the **For You feed** algorithm of **X (formerly Twitter)** in 2026, with four audience-tuned growth recommendation tracks (personal/founder, brand/company, generalized framework, client/consulting deliverable). **Pivot thesis**: ***« The famous 2023 weight table — replies count more than likes by a big multiplier — describes a system that no longer exists in this form. »*** The 2026 algorithm is a **transformer (Phoenix, Grok-1-derived)** that learns weights from your engagement history, scored against a **19-dimension multi-action surface**, gated by an offline content-understanding service (**Grox**). **The shape of scoring now matters far more than the numbers — and the numbers themselves are not in the public release**. **4-component architecture**: (1) **Home Mixer** (Rust, request-time orchestrator, hydrate → source → filter → score → select → filter); (2) **Thunder** (Rust, Kafka-fed in-memory store of recent posts, sub-ms lookups for in-network candidates); (3) **Phoenix** (JAX ML, two-tower retrieval + ranking transformer, ~Grok-1-derived); (4) **Grox** (offline, spam/safety/PTOS/banger classifiers + multimodal v5 embedder). **The 19 actions predicted by Phoenix** (key change vs. 2023): favorite, reply, repost, photo_expand, click, profile_click, vqv (video quality view gated by min duration), share, share_via_dm, share_via_copy_link, dwell, quote, quoted_click, follow_author, not_interested, block_author, mute_author, report, dwell_time (continuous). **Final score** = `Σ (weight × P(action))` modified by **3 structural multipliers**: (a) **OON_WEIGHT_FACTOR < 1** (out-of-network penalty), (b) **author diversity decay** `(1-floor) × decay_factor^position + floor` (exponential attenuation of repeated posts from the same author within a single render), (c) **video duration gate** (vqv only contributes if `video_duration_ms > MIN_VIDEO_DURATION_MS`). **Key caveat**: **no numeric weight value** (`FAVORITE_WEIGHT`, `OON_WEIGHT_FACTOR`, `AUTHOR_DIVERSITY_DECAY`, `MIN_VIDEO_DURATION_MS`...) is in the release — everything is `crate::params::*`, managed by an internal X feature-switch service for A/B testing. ***« Anyone telling you 'replies are worth N.N× more than likes in 2026' is fabricating a number that is not derivable from the OSS release. »*** **Key differences vs. 2023**: (1) removal of every hand-engineered feature (*« We have eliminated every single hand-engineered feature and most heuristics from the system »*); (2) a single model predicting 19 actions vs. multiple single-action models; (3) Grox separates content understanding from ranking; (4) new first-class signals (continuous dwell, gated vqv, follow_author, 3 share variants); (5) two-tower OON retrieval (vs. SimClusters+heuristics) with multimodal text+image+ASR-video embeddings. **Three layers of reach** (generalized framework): Eligibility (binary, Grox+filters) → Retrieval (probabilistic, two-tower ANN) → Ranking (continuous, weighted-sum + multipliers). **Two laws of mechanical growth**: (1) In-network is multiplicative, OON is additive; (2) The model's job is to predict you, not reward you. **Deliberate honesty boundary**: released Phoenix checkpoint = mini (2 layers, 4 heads, 256-dim, 537K sports-post corpus), not the production model; Thrift integrations stubbed (`panic!("Not implemented")` in `candidate_features.rs`); brand-safety lists, topic ID mappings, language penalties, ad-blending rules absent from the public release.

La Révolution AI4* : Analyse Stratégique de l'Impact de l'IA sur le Cycle de Vie de la Production Logicielle

Sat, 01 Nov 2025 00:00:00 GMT

Strategic deep-research analysis examining the fundamental transformation of the software industry through the "AI4\*" (AI for Everything) concept: systemic overhaul of the production value chain, a shift from a labor-intensive artisanal process to an automated, intelligence-guided industrial paradigm. **6 pillars transformed by AI** **AI4Project** (Project Management): Data-driven predictive estimation (Operum, Idealink generate plans in minutes) vs. "finger-in-the-wind estimation". Paradox: estimating AI projects themselves is notoriously complex - hidden costs (data, talent at $100-200k/year, GPU) $20k basic chatbot → $500k+ advanced systems. The NIST AI RMF becomes a *central* planning component (no longer optional) - managing new risks (algorithmic bias, security flaws in generated code, black-box transparency). **AI4UX** (Human-Machine Interaction): Generative design (Uizard, Moonchild, Figma generate wireframes/UI from natural-language prompts). Adaptive interfaces with real-time personalization. "Synthetic users" (AI agent personas) test prototypes instead of recruiting human panels - early feedback. The AI Design Framework redefines the UX designer's role: from "interface creator" to "human-agent interaction architect". **AI4Dev** (Development): **Vibe Coding** (Karpathy, February 2025) - natural language to describe the goal → AI generates code → iterative experimentation. Lowers the barrier to entry (non-programmers build apps), ultra-fast prototyping. BUT the **Vibe Coding Hangover** - code accepted "without being fully understood", exponential quality/security debt, "development hell". Creates the **"Vibe Check"** economy: CodeRabbit, Qodo AI review agents "fix bugs/defects introduced by vibe coding", scanning "AI slop". New role: developer → "guiding engineer". **AI4Ops** (Operations): AIOps (Gartner, 2016) applies AI to automate IT operations. Three-level evolution: (1) Predictive Maintenance (AI alerts humans) → (2) Automated Remediation (AI triggers a pre-written solution) → (3) **Autonomous Operations/Self-Healing Systems** (ultimate goal: autonomously diagnosing/resolving new problems without human intervention). Platforms: Dynatrace (preventive operations), ServiceNow (Predictive AIOps), Splunk, New Relic, IBM, OpenText. **AI4Data** (Governance): Duality - governance as a *prerequisite* for trustworthy AI AND a *domain* benefiting from AI automation. "Governance *for* AI": ungoverned data → biased/non-compliant AI. "AI *for* Governance": automatic discovery/cataloging, automated compliance (EU AI Act, GDPR), auto-generated documentation/audit trails, continuous quality/risk analysis. Production examples from Brazil: **Cielo** (agentic AI for autonomous money-laundering detection/chargeback analysis), **Zup StackSpot** (orchestration of AI agent fleets across the development cycle). **AI4Cloud** (Infrastructure): Double FinOps dichotomy. (1) "AI for FinOps" - automates right-sizing/anomaly detection/spend forecasting. (2) **"FinOps for AI"** (critical problem) - AI workloads have volatile/unpredictable cost profiles (GenAI training/inference/GPU). New metrics (cost-per-token vs. instance/hour), new constraints (GPU scarcity), a new mental model ("cost per outcome", "frugal architecture"). 5 optimization strategies: models, GPU (NVIDIA MIG, continuous batching), infrastructure (caching), data, commercial (Savings Plans, Spot instances). **GenAI Landing Zone** - reference architecture integrating the 6 pillars on a governed foundation (Foundation Guardrails, real-time cost observability, compliant sandboxes, AWS Step Functions orchestration). **Major cross-cutting strategic trend**: Transition from **Copilots → Autonomous Agents** (agentic workforce). Agents deployed for fraud detection (Cielo), synthetic users as UX testers, code review agents, AI4Ops self-healing systems. **4 interdependent strategic conclusions**: (1) Vibe vs. Check paradox (generation speed creates quality debt requiring AI governance), (2) Rise of the agentic workforce (orchestration of agent fleets), (3) FinOps-for-AI crisis (volatile costs bottleneck scaling), (4) Governance as critical path (the pilot-to-production gap = a governance gap, GenAI Landing Zone integrates compliance/cost/security by default). **4 recommendations for CTOs/CIOs**: Invest in governance before speed (guardrails before massive GenAI rollout), resolve the FinOps-for-AI crisis now (cost as a design metric, frugal architecture), prepare the organization for agents (transform roles: developers→guides, UX→interaction strategists, Ops→autonomous-systems managers), centralize to scale (centralized governance platforms + GenAI Landing Zone vs. disparate pilots).

The Gen AI Playbook for Organizations

Sat, 01 Nov 2025 00:00:00 GMT

Bharat N. Anand (NYU Stern Dean) and Andy Wu (Harvard Business School) present in Harvard Business Review a strategic framework for IA générative deployment that moves beyond poorly framed questions about AI intelligence or CIO speed, refocusing on the creation of durable competitive advantage. **Ill-posed questions vs. the real strategic question** Executives ask the wrong questions: « When will IA générative match the intelligence of my best employees? Is it accurate enough? Is my CIO moving fast enough? What are competitors doing? » They focus on the intelligence of IA générative and its trajectory instead of the implications for corporate strategy. The real questions are: « How can the organization use IA générative effectively TODAY, despite its limitations? How can it be used to create a competitive advantage? » **4-quadrant framework** The authors position tasks along 2 dimensions: cost of errors × type of knowledge (explicit vs. tacit). **No Regrets Zone** (low error cost + explicit knowledge): resume screening, meeting transcription, customer service responses. Deploy immediately: speed + cost savings. **Creative Catalyst Zone** (low error cost + tacit knowledge): marketing taglines, design variations, presentation outlines. IA générative amplifies human creativity and broadens participation. **Human-First Zone** (high error cost + tacit knowledge): executive hiring, strategy definition, crisis management. IA générative provides supporting analysis, humans retain decision-making authority. **Quality Control Zone** (high error cost + explicit knowledge): legal drafting, financial analysis, software development. Human-in-the-loop model: IA générative handles the data-intensive work, humans verify. **3 strategic imperatives** **Access and experimentation**: remove IT bottlenecks to enable broad experimentation by employees, rather than deployment driven solely by IT. Democratize experimentation vs. centralized control. **Data as a competitive moat**: centralize proprietary data sources, capture new data flows. Give IA générative company-specific knowledge that is difficult for competitors to replicate. The only defense against the commoditization of identical tools accessible to everyone. **Organizational redesign**: rethink structures around data feedback loops, redeploy the workforce. Treat freed-up time as a strategic resource to be managed rather than assuming automatic improvement of the P&L. Freed-up time does not automatically become profit without intentional reallocation. **Access Paradox: a critical warning** Since competitors have access to the same tools, the advantage goes to those who deploy IA générative DIFFERENTLY — not to those who simply move faster. Key quote: deploy differently vs. move faster. Organizations that apply IA générative to the same tasks expose themselves to commoditization. Customers and suppliers can disintermediate traditional value chains, compressing margins as law firms experienced after the 1990s (democratized legal research tools, direct client access, intermediaries under pressure). **3 sources of strategic differentiation** « Strategic differentiation will come from three sources: (1) rapid deployment across tasks; (2) proprietary data; (3) unique people, processes, and culture. » The combination of speed + proprietary data + unique culture is the only durable protection. A tool accessible to everyone does not create an advantage — it is the way it is deployed, the exclusive data, and the organizational culture that differentiate. Classic HBR article transposing strategic management frameworks (Porter, resource-based view) to IA générative disruption, formalizing emerging best practices for executives leading the transformation.

Votre nouveau super-pouvoir : voir le jeu dans son ensemble (Wardley Mapping Expliqué)

Wed, 01 Oct 2025 00:00:00 GMT

**Conceptual Foundation: Strategy as a Dynamic Game** Educational document explaining Wardley Mapping as a **situational awareness** tool for strategic navigation. Built on the premise that strategy is not a rigid plan but the **art of making intelligent decisions in a constantly changing environment**, drawing an analogy with real-time strategy games (Fortnite, League of Legends) versus predictable checkers. References Sun Tzu (2500 years ago): a general requires 5 elements for victory, **understanding of the terrain being the most critical**. Without an accurate map of the battlefield, even a courageous general is doomed to fail. Simon Wardley created the method to **make the invisible visible** after costly strategic errors caused by a lack of mapping. **Map Architecture: Two Fundamental Axes** **Y-Axis (Vertical - Value Chain)**: represents "who needs what". Simple rule: the higher the element, the more **visible to the end user/closer to the main goal**. Pizza analogy: User (top) → Need (delicious pizza) → Components (baked dough, sauce, cheese) → Invisible dependencies (oven, electricity). **Anchor** = user need at the top of the map (always the starting point). Dependencies linked vertically, oven electricity **absolutely essential but completely invisible** to the person eating the pizza. **X-Axis (Horizontal - Evolution)**: makes the map powerful. Represents **predictable left-to-right movement** caused by supply/demand competition. **Four evolution stages**: **(1) Genesis** (Wild West) - new, chaotic, unpredictable, frequent failure, high potential reward; **(2) Custom-built** (Artisan) - built specifically, rare, competitive advantage; **(3) Product** (Mall) - purchasable "off the shelf", stable, competing versions, feature/price competition; **(4) Commodity** (Utility/Tap) - public service/utility, expected to be available, pay-per-use, noticed only when it fails. Music analogy: early MP3s (Genesis) → first iPod (Custom-built) → smartphone music apps (Product) → Spotify/Apple Music (Commodity like tap water). **System Dynamics and Anticipation** **Crucial principle**: "established things enable new things to emerge". When a component **low in the value chain becomes a commodity** (e.g. cloud storage, computing power), it **drastically reduces the cost/effort of building what depends on it**. Genesis-stage innovation higher up the chain (e.g. an AI video-editing app) is possible **only because** the underlying components have been commoditized. The map is not a snapshot but a **model of a system in motion**. Observing what becomes a commodity today → predicting tomorrow's possible innovations. The essence of strategic anticipation. **Decisive Strategic Advantages** **Energy focus**: the map clearly shows what makes something unique versus standard. **Real competitive advantage comes from the components on the left** (Genesis/Custom-built). YouTube example: Video idea + Content = the only differentiating elements. Spend 80% of time/energy there. Camera (Product), Platform (Commodity) → **never build these yourself, a monumental waste**. Decision rule: **build the unique, buy the product, use the commodity**. **Anticipating opportunities**: predictable left-to-right movement enables predictions. Example: an "AI video editing" tool appears at Genesis → anticipate that it will become a Product then a base YouTube feature (Commodity) → workflow transformation, time savings. The map helps **see the wave coming from afar, ride it instead of being submerged**. **Communication and alignment**: the map = a **single shared view of the landscape** for the whole team. End to endless debates based on opinions. Discussion focused on the map, representing a **common objective reality**. Helps different profiles (Genesis-stage creatives + Commodity-stage organizers) **understand how their respective contributions collaborate**. **Critical Thinking Lesson** Strategic power does not lie in the list of components but in **understanding position on the evolution axis**. The same action requires a completely different strategy depending on position. "Build a website" is not a strategy in itself: in 1994 (Genesis) = a pioneering act; today (Commodity, Squarespace) = often a **waste of time/money**. The map forces a shift beyond "what" to focus on "where" and "when". **The right answer always depends on context** - a fundamental critical-thinking lesson delivered visually and intuitively. **Universal Application** A tool not reserved for businesses but a **universal instrument** for anyone seeking advantage through superior situational awareness: applying to universities, growing TikTok followers, winning a robotics competition, planning a school project, building an esports team. All challenges unfold on a mappable **competitive landscape**. Final message: the map is not a diagram, it's a **way of thinking** that develops acute situational awareness to think like a master strategist.

HOW TECH COMPANIES MEASURE THE IMPACT OF AI ON SOFTWARE DEVELOPMENT

Tue, 16 Sep 2025 00:00:00 GMT

This in-depth analysis explores how **18 major tech companies**, including Google, GitHub, Microsoft, and Dropbox, measure the impact of AI on software development, amid the challenge of justifying growing investments in AI coding tools. Written by Gergely Orosz and Laura Tacho (CTO of DX), the article notes that while **85% of engineers use AI tools**, many engineering leaders struggle to assess their real value, lacking clear metrics beyond superficial measures such as lines of code (LOC). **Central message: combine metrics** Effectively measuring AI impact requires **combining existing 'core' engineering metrics with new AI-specific metrics**. Companies should not abandon traditional metrics such as Change Failure Rate, PR throughput, PR cycle time, and developer experience, since the ultimate goal of AI is precisely to improve these software delivery fundamentals. These core metrics must be tracked alongside AI adoption rates, satisfaction (CSAT) with the tools, time saved per engineer, and AI spend. **Dropbox**, for example, reached **90% AI adoption** and saw its engineers merge **20% more pull requests** with a reduced change failure rate. **Segmentation and an experimental mindset** A crucial aspect is **breaking down metrics by level of AI usage**: comparing AI users to non-AI users, and analyzing trends over time. This breakdown by role, seniority, or programming language helps identify which groups benefit most from AI or need additional training. The article emphasizes an **experimental mindset**, where data is used to answer specific questions and test predictions about AI's influence. **Quality, maintainability, developer experience** Vigilance over **code quality, maintainability, and developer experience** is paramount. The authors warn that AI-assisted development can create "the biggest pile of technical debt" if not managed carefully. It is essential to track metrics that check each other, such as speed alongside quality (PR throughput and CFR). Beyond system metrics, self-reported data on "confidence in changes," "code maintainability," and "perceived quality" are vital for capturing long-term impacts. Developer experience, often wrongly reduced to superficial perks, is critical for reducing friction across the entire development cycle. **Emerging trends and challenges** Microsoft uses **"bad developer days" (BDD)** to assess AI's impact on daily friction, while Glassdoor measures experimentation outcomes (A/B tests). The **acceptance rate** of AI suggestions, once a benchmark metric, is declining because it is too narrow: it captures neither maintainability, nor bug introduction, nor overall productivity. Cost analysis, still rarely practiced so as not to discourage usage, is expected to receive greater scrutiny as AI budgets grow. **Agent telemetry** and measurement beyond code writing are identified as areas set to evolve significantly. **AI Measurement Framework and data layers** The article introduces the **AI Measurement Framework**, a recommended set of metrics blending AI metrics with core engineering metrics, with developer experience at its center. It advocates layered data collection: quantitative system data (AI tools, GitHub, JIRA, CI/CD), periodic qualitative surveys, and in-the-moment experience sampling. **Monzo Bank**'s experience serves as a case study: objective measurement is difficult (data retention by vendors), but engineers' subjective sentiment and specific use cases such as code migrations demonstrate clear value.

Context Engineering Needs Domain Understanding

Wed, 23 Jul 2025 00:00:00 GMT

The article "Context Engineering Needs Domain Understanding" by Rod Johnson introduces **Domain-Integrated Context Engineering (DICE)** as an evolution of context engineering for building more effective and robust LLM applications. Johnson begins by acknowledging "context engineering" as a valuable advance over "prompt engineering," defining it as the art and science of filling the LLM's context window with relevant information. He argues, however, that this definition is incomplete, as it neglects two crucial aspects: the bidirectional nature of communication with LLMs (what is sent *and* what is received) and the integration of LLM applications with business understanding and existing systems. **DICE: Conceptual Extension** To address these gaps, Johnson proposes DICE, which extends context engineering by emphasizing the use of a domain model to structure context and by considering LLM outputs in addition to inputs. The central idea: although LLMs excel at natural language, **adding structure to inputs and outputs** makes them safer and more reliable. DICE allows LLMs to "converse" using a business's established terminology and concepts, fostering better integration with existing applications. In this context, domain objects are not merely data structures but define targeted behaviors that can be exposed both to manually written code AND to LLMs as tools. **Compelling Benefits of DICE** The article highlights several compelling benefits of adopting DICE. First, it allows code to be used to structure context, turning a "delicate art" into a more scientific process where context can be refined, reasoned about, and tested. This also enables precise content filtering, improving results and saving tokens. Second, DICE facilitates simpler and safer integration with existing systems, moving beyond "demo" Gen AI applications toward real-world scenarios where agents need access to existing functionality. By working with domain objects, businesses can reuse their existing domain models and capitalize on hard-won business understanding. **Additional Advantages** Other advantages include faster delivery and improved quality through the reuse of domain models across applications and agents. DICE also offers structured persistence options, enabling more precise retrieval via existing technologies such as SQL or Cypher, a potential complement to vector search. The structure and encapsulation added by the domain model strengthen testability, debugging, and tracing, since information appears in observability tools in a structured, understandable format. Finally, domain integration helps manage context in multi-step flows, preventing quality degradation and controlling token costs. **Strategic Positioning** Johnson concludes that domain integration is paramount to unlocking the full business value of generative AI, positioning existing business applications as the key adjacency for Gen AI, rather than data science or LLMs alone. **The central argument**: domain model structure moves LLM capabilities from powerful-but-chaotic to controlled-and-reliable, an essential condition for enterprise adoption. By conceptualizing domain objects as entities carrying behaviors that can be exposed as tools, DICE bridges the conceptual gap between LLM potential and enterprise reality, offering a framework for systematic, reliable, value-creating Gen AI integration into existing business workflows. This pragmatic perspective recognizes that **Gen AI's value does not lie in isolation**, but in harmonious integration with the proven systems where domain knowledge resides.

AI Workflow for Creating Wardley Maps (Video Tutorial)

Wed, 23 Apr 2025 00:00:00 GMT

**Objective and methodological context** Video tutorial demonstrating a practical workflow using AI (LLM) to bootstrap the creation of a Wardley Map. The author, a product manager in the ERP/Business Intelligence domain, seeks to explore a product space and quickly obtain a solid starting point rather than starting from a blank page. The approach acknowledges that manual Wardley Mapping is lengthy and complex, and proposes partial automation to accelerate the initial phase of strategic exploration. **Technical architecture: stack and tools** The workflow relies on **four components**: **(1) the OpenAI API** to generate capabilities and relationships via structured prompts; **(2) Obsidian** as a knowledge management tool leveraging its native relationship graph; **(3) Python with the NetworkX library** for social-graph-style clustering analysis; **(4) a custom frontend** (optional) to facilitate entering prompts and capabilities. The seamless integration allows passing the LLM's JSON outputs directly into Obsidian, then exporting them to Python for advanced analysis, then re-importing the enriched data into the Obsidian canvas. **Three structured sequential prompts** **Prompt 1 - Capability decomposition**: strict format: "I'm product manager for [product] in [space]. Frame capabilities as 'the ability to [blank]'. Break down capabilities using '... is a function of the ability to...' Return results in JSON." Concrete example: "buy lunch for team" (top-level capability) automatically broken down into sub-capabilities: planning balanced meals, sourcing quality ingredients, efficiently preparing meals, accommodating preferences/allergies. The decomposition creates **hierarchical parent → child relationships** automatically linked in the Obsidian graph. **Prompt 2 - Y-axis positioning**: Wardley Maps use a Y-axis representing customer proximity (top = visible to the customer, bottom = abstract/invisible infrastructure). The prompt categorizes capabilities according to their proximity to different roles in an operational-excellence-oriented value chain: **(level 1)** operational excellence leaders, COO, strategic program managers; **(level 2)** coaches, designers; **(level 3)** operations/IT engineers; **(level 4)** platform and data engineers; **(level 5)** infrastructure/utility layers. Crucial point: **always request the justification** along with the level assignment. This makes it possible to "get into the LLM's reasoning" and facilitates iterative tuning. The author notes that this prompt required behind-the-scenes tuning for their specific domain. **Prompt 3 - Relationships between capabilities**: "Given a list of capabilities (each with ID, name, description), identify meaningful relationships. Either functionally similar OR enabling. Be very precise. Return JSON with: pair (two related capability IDs), type (similar/enables), reason (clear explanation)." Strategy: **insert capabilities at random**, strict analysis, like scanning a table and drawing lines between similar elements. Example output: "analyze data insights" ↔ "trend analysis" = similar (both centered on data analysis); "analyze data insights" enables "actionable intelligence" (derives intelligence from data patterns). This enriches relationships beyond simple parent-child hierarchy. **NetworkX clustering and final canvas** After creating the capabilities, hierarchical relationships, similarity/enabling relationships, and Y-axis levels, the workflow uses the **Python NetworkX library** (a standard for social graph analysis) to **identify clusters within each level**. The analysis of connection density, as in a social network, assigns cluster IDs. Result: each capability has **(1) a Y-axis level** (customer proximity), **(2) a cluster ID** (logical grouping within the level), **(3) parent-child links**, **(4) similarity/enabling links with justifications**. The enriched data is imported into the **Obsidian canvas** where the capabilities are visualized. The author uses Obsidian's **grouping function** for readability. NetworkX clustering sometimes produces sensible groupings (example: "timestamped entries, audit trails of key actions, preservation of historical data" grouped together). **Value chain navigation and bootstrap philosophy** The canvas enables **value chain navigation**: example "a leader wants prioritization" (top of the map) → move down the stack level by level → identify the different elements involved in prioritization. A concrete demonstration of how a high-level need breaks down into progressively more abstract/infrastructural capabilities. **Key lesson**: the author emphasizes: "this is only the beginning, just to bootstrap it". The AI output is not the final map but an **accelerated starting point**. The intent: "then spend a lot of time learning the domain in depth". AI reduces the initial friction of the blank page and allows the product manager to immediately begin iteration and refinement with a solid base structure, rather than weeks of manual mapping. **Methodological implications** The workflow demonstrates a **pragmatic AI augmentation**: neither fully automated strategy (impossible given the nuance and context involved), nor fully manual (too slow). The hybrid approach leverages the LLM's strengths (pattern recognition, logical decomposition, relationship identification) while recognizing that human expertise remains indispensable for validation, prompt tuning (via justifications), and in-depth domain learning after the bootstrap. The systematic justifications create a **feedback loop** allowing the practitioner to understand the LLM's reasoning, iteratively adjust prompts, and improve output quality. **Transferability beyond Wardley Mapping** Although focused on Wardley Maps, the techniques are generalizable: capability decomposition, proximity categorization, relationship identification, and clustering analysis apply to other strategic frameworks requiring structured thinking about value chains, dependencies, and abstraction layers. The Obsidian + NetworkX + LLM API stack is particularly powerful for knowledge workers exploring complex domains.