SaaS
LEA
LEA is an AI diagnostic for product discovery teams trying to understand why shipped experiences underperform. The presenter shows how it analyzes structured diagnostic responses to surface systemic issues like missing customer feedback loops, assumption-driven decisions, and stakeholder misalignment. The core differentiator is semantic retrieval over discovery techniques so recommendations map to the meaning of evidence rather than keyword matches alone.
The problem
Product practitioners invest heavily in credentials and programs — SVPG, ORSC, and others — then default to the one or two techniques they remember best. The full body of knowledge sits unused, not through intent but because no system surfaces the right technique at the right moment in a live engagement. The cost is real. In one documented engagement, a team shipped free airport WiFi tested on employees rather than passengers; take rate came in below expectations. Standard techniques like value-stream mapping surfaced symptoms — slow delivery, broken handoffs — but could not explain *why* the team kept building without customer evidence, aligned objectives, or tested assumptions.
The solution
LEA (Learning Empowered Advisor) is an AI diagnostic for product discovery teams. A practitioner works through a structured 43-question discovery across five phases plus 12 ORSC team-dynamics questions, tagging discovery methods and stakeholder profiles as they go. LEA then ranks the right techniques from a 71-item library (51 SVPG techniques, 20 ORSC tools) by relevance, urgency, and sequencing — with every recommendation attributed to a specific discovery finding. It flags gaps, surfaces contradictions rather than resolving them silently, and generates a leadership-ready summary. In the airport-WiFi engagement, LEA identified three systemic gaps — Customer Voice, Data-Driven Decision Making, and Stakeholder Alignment — in one week, which became three strategic tracks for the team's next initiative.
How it works
LEA's AI layer is semantic retrieval via FAISS vector search, not a generative model — a deliberate choice so every recommendation traces to a specific finding, which a generative model could not guarantee. The frontend runs entirely in the browser; on Generate Summary, discovery findings are sent to a hosted retrieval backend on Railway that returns the most relevant techniques by meaning rather than keyword match, and LEA's built-in logic scores, sequences, and writes the rationale. This replaced an earlier keyword engine that returned different results for "no customer interaction" versus "no customer access." An anonymization layer strips names and organizational identifiers before findings leave the machine. A generative model is planned only once LEA has data across ten or more engagements for cross-engagement pattern recognition.
Who it's for
The primary user is the product practitioner — coach, consultant, product manager, or product owner — who works with multiple teams simultaneously and cannot hold their full body of knowledge in active recall across every engagement. Value scales directly with engagement volume. LEA is early-stage: deployed since December 2025 and in active use across one completed live engagement, with three additional practitioners (Jerold, Eva, and Tiffany) onboarding before June 2026. Monetization is deferred; the eventual model is B2B licensing to coaching firms and enterprise L&D teams, whose value proposition is consistent, evidence-based practice outcomes across every practitioner they employ.
Why it matters
The corporate leadership training market is growing at 8.8% CAGR, and the coaching platform market is projected to grow from $4.22B in 2026 to $12.01B by 2036. AI has accelerated engineering velocity, shifting the bottleneck from build speed to discovery quality — teams now ship faster than they learn. LEA's success definition is producing technique recommendations a senior practitioner would endorse, consistently, across different team contexts, without the builder present. Documented evaluations (EVAL-001 through EVAL-004) confirm the retrieval system outperforms keyword scoring and generalizes across contexts — including one honest failure where LEA produced no output despite 74% question coverage, now queued for a fix. Rather than entering a crowded market, LEA is defining the category of AI-native practitioner knowledge application.
The workflow
The PRD
| Your Name: | Suraj John | ||||||||
| Your Product: | LEA (Learning Empowered Advisor) | ||||||||
| Your Industry: | Education & Training | ||||||||
| Date: | April 25, 2026 | ||||||||
| 4D Method | AI PRD | Feedback addressed 05/17/2026 — concrete example added to F7 showing knowledge application failure in live engagement. | |||||||
| Phase | Activity | Theme | Topic | Key Question(s) | Your Response Include external links to visuals/prototypes as required. | Feedback - 1 | UPDATED FEEDBACK | Update Feedbac 25 May 2025 | Update Feedbac 8 June 2025 |
| DISCOVERY | Understand your market, business, product & user context | Business Value Map | Market Attractiveness | What industry is your business in? (ie Financial services, Healthcare, Education, etc)? | The IFE team had just delivered free WiFi. Leadership had no stated concern about the product or the team. The standard playbook was ready: value stream mapping, story mapping, role clarity, vertical slicing. Value stream mapping surfaced symptoms. Delivery was slow. Handoffs were broken. Stakeholders were misaligned. It showed where the friction was. It could not show why the team kept building without customer evidence, without aligned objectives, without testing assumptions. LEA ran a 43-question diagnostic across the same engagement. The team had tested free WiFi using employees, not passengers. Take rate came in below expectations because the team never understood what passengers actually wanted. The UX researcher confirmed it: the process was so rushed there was no time for full lifecycle research. The team inherited OKRs from the division. No objectives of their own. There was a contract with a vendor that drove the architecture. No alternatives were assessed. Legal was discovered three weeks before launch. Without LEA, the next phase would have been story mapping and sprint planning on the same foundation. The gaps would have compounded. LEA identified three systemic gaps in one week. Customer Voice. Data-Driven Decision Making. Stakeholder Alignment. Those three gaps became three strategic tracks for the next high-visibility product initiative the same team was asked to deliver. That is what happens when a practitioner defaults to familiar techniques. The work continues. The root cause does not move. ___________________________________________________________________________________________________________________________ Professional Development — practitioner knowledge application. The industry problem LEA solves is a knowledge application problem. Practitioners earn credentials by attending SVPG, ORSC and equivalent programs. The knowledge is acquired. It is not applied. No system exists to surface the full body of credentialed knowledge at the moment it is needed in a live engagement. Practitioners default to what they remember, not what the situation requires. | You are onto a real problem, and that is your advantage. “Practitioners know more than they use” is strong because it feels lived, not invented. Now make the pain sharper. Give me one concrete example of what goes wrong when the wrong technique gets used, or when someone falls back on habit. That kind of detail will make this section hit much harder. Feedback addressed 05/17/2026 — concrete example added to F7 showing knowledge application failure in live engagement. | Suraj, the updates land. The concrete engagement example in Discovery now shows exactly what compounds when a practitioner defaults to familiar techniques, and it does more structural work than the prior version. The named pilot group with a specific fix protocol in Deploy closes what was previously the most abstract section of the PRD. The plain-language rewrite in Develop makes the architecture legible in a way it was not before. The first is the generative AI dimension of the product itself. The summary engine runs entirely on local JavaScript logic. No language model generates any of the diagnostic output. RAG retrieval via FAISS is the only AI component, and it returns ranked technique matches by vector similarity, not generated text. That is a strong retrieval architecture, but for a capstone evaluated on AI solution depth, the distance between semantic search and generative reasoning is the gap a judge will press on. You do not need to add an LLM to the production product before Demo Day, but the PRD needs to make the case for why local logic is the right architectural choice today and where generative capability becomes necessary. Frame it as a deliberate constraint with a clear trigger for when the constraint lifts, not as a deferral. The second is eval coverage. Two evaluation cases cannot support the claim that LEA works across different team contexts and different practitioners. Each of the three pilot practitioners running a real engagement produces a third, fourth, and fifth case. If any of those are completed before Demo Day, add the results. If not, name what the next three cases will test and what a failure would look like for each. The evaluation story is honest about what broke and why, which is rare and valuable. Extending it to five or more cases turns that honesty into evidence of rigor rather than evidence of small sample size. On the video recording for the demo: structure it as problem, insight, proof, architecture. Open with the engagement story where the practitioner defaulted to familiar techniques and what that cost the team. Show LEA's diagnostic output for that same engagement as the proof moment. Then walk through the RAG retrieval step so the technical architecture is visible. Keep it under four minutes. Spend no more than sixty seconds on setup before the first product screen appears. | Suraj, this capstone delivers a working diagnostic tool with real evidence behind it. The fourteen-stage iteration history, the honestly reported failure case, and the semantic-versus-keyword retrieval comparison all demonstrate genuine product rigor. The single most important gap is a narrative one: Discovery frames generative AI as the core technology, but the architecture you shipped runs on local logic with FAISS semantic retrieval as the AI layer. That retrieval is doing real work and the data proves it, so align the story to what you actually built rather than what the broader category implies. The video presentation is effective, opening on the problem, moving through architecture, and closing with eval results including where the product fails predictably. That transparency is a strength. Close the gap between the Discovery framing and the shipped architecture, and the overall capstone holds up well under scrutiny. | |
| What are the key challenges (headwinds) and opportunities (tailwinds) impacting growth in your industry? Who are the key competitors? | Headwinds: Practitioners globally invest in credentials and programs and revert to using one or two familiar techniques in practice. The full body of knowledge sits unused. Not because of intent. Because without a system to surface the right technique at the right moment, practitioners default to what they already know. Certifications are siloed. ORSC, SVPG, and other certification bodies each produce their own frameworks with no integration layer. Practitioners who hold multiple credentials and programs have no system to combine them coherently in a live engagement. Tailwinds: The corporate leadership training market is growing at 8.8% CAGR from 2025 to 2030, driven by demand for AI-enabled tools that make practitioner knowledge more applicable (Technavio, 2026). The coaching platform market is projected to grow from $4.22B in 2026 to $12.01B by 2036 at 11% CAGR (Future Market Insights, 2026), driven by demand for AI-enabled, outcome-driven practice infrastructure. Semantic retrieval makes it possible to hold the full body of knowledge from multiple frameworks simultaneously and surface the right technique based on live diagnostic data. LEA uses FAISS vector search to match practitioner findings to the right technique by meaning, not keyword frequency. This is the AI layer doing real work in the product today. Key competitors: Certification bodies themselves: deliver knowledge, provide no application layer, no diagnostic engine, no technique selection intelligence. General-purpose AI assistants: respond to prompts, do not diagnose. No structured discovery framework, no multi-framework integration, no adaptive feedback loop. No direct competitor currently combines multiple certification frameworks into a single diagnostic engine that tells a practitioner which technique to use, when, and why. | ||||||||
| What is the projected growth rate of your target market segment over the next 3-5 years? | The global corporate training market is valued at $444.86B in 2025, projected to reach $808.89B by 2033 at 7.76% CAGR (SkyQuest, 2025). The corporate leadership training segment is growing at 8.8% CAGR from 2025 to 2030 (Technavio, 2026). Standalone market sizing for AI-native practitioner knowledge application tools does not yet exist as a defined category. LEA is not entering a crowded market. It is defining one. The timing is right. AI has accelerated every layer of product delivery — engineering velocity, code generation, deployment pipelines. The bottleneck has shifted. It is no longer build speed. It is discovery quality. Teams are shipping faster than they are learning. The risk in this era is not slow delivery. It is fast delivery in the wrong direction. Discovery is where that gets resolved. LEA accelerates discovery quality by making the full body of credentialed practitioner knowledge accessible at the moment it is needed — not after the engagement, not from memory. That is the bottleneck AI has not yet solved. LEA solves it. | ||||||||
| Business Model | What growth stage is your business currently in (e.g., startup, scale-up, mature)? | LEA was first deployed in December 2025, four months before this certification began. The cert is being used to document, pressure-test, and extend a product already in active use — not to build one from scratch. Early stage. LEA is deployed and in active use by the original builder across one completed live engagement. Three additional practitioners are onboarding before June 2026. Proof of concept validated: LEA identified three systemic gaps in the first two weeks of a live engagement. Those gaps became three strategic tracks for a high-visibility FIFA 2026 initiative. Peer signal: Practitioners introduced to LEA confirmed strong interest — specifically in technique recommendation against SVPG and ORSC tool selection for team dynamics. Active onboarding underway. Current constraint: validating that AI-native tooling can make a practitioner's full body of knowledge consistently applicable across engagements — across multiple practitioners, not just the builder. | |||||||
| How does your business make money? What do they sell? What is your primary revenue model (e.g., subscription, freemium, licensing, marketplace, transactional, etc?) | Monetization is deferred. Current objective: validate that AI-native tooling can make a product practitioner's full body of knowledge consistently applicable across every engagement — at scale, without the builder present. Revenue model when ready: B2B licensing to coaching firms and enterprise Learning and Development teams. Value proposition to the buyer is consistent, evidence-based practice outcomes across every seasoned product practitioner they employ. | ||||||||
| Who is your primary customer base (B2B, B2C, B2B2C)? | Current user: one product practitioner (the builder). Three additional product practitioners onboarding before June 2026. Target market: B2B licensing to coaching firms and enterprise Learning and Development teams. Current stage is pre-commercial — validating diagnostic quality and practitioner adoption before formalizing a revenue model. Primary user: Product practitioners who work with teams across discovery, delivery, and transformation contexts. They hold knowledge from one or more programs and frameworks. They work with multiple teams simultaneously. They know more than they use. LEA closes that gap. Secondary buyer (target): Enterprise organizations investing in practitioner capability. Value proposition to the buyer: consistent, evidence-based practice outcomes across every product practitioner they employ or contract. | ||||||||
| Differentiators | What are the key differentiators for your company? | 1. Technique selection intelligence. LEA ranks the right technique for this team, at this maturity stage, at this moment — with every recommendation attributed to a specific discovery finding. Not access to knowledge. Application of it. 2. Full knowledge base, every engagement. Product practitioners apply one or two familiar techniques and leave the rest unused. LEA surfaces the complete library ranked by what the diagnostic data shows, not by what the practitioner defaults to. 3. Adaptive feedback loop. When a technique does not work for a specific team profile, LEA learns it. Future rankings adjust. The system compounds across engagements instead of resetting with each one. 4. Presence-free diagnostic quality. Designed to maintain diagnostic depth across engagements without requiring the product practitioner to hold the full knowledge base in active recall. Quality does not depend on what the practitioner remembers to ask. 5. Knowledge-agnostic engine. Integrates multiple frameworks and methodologies. Additional knowledge sources added as the product practitioner's body of work grows. LEA applies whatever the practitioner holds — systematically. | |||||||
| Feature Value Map (IMPORTANT NOTE: This section is only relevant if you are working on enhancing an existing product. It does not apply if you are developing a new product from 0 to 1.) | Customers | Who are the customers (ie buyers) of your product? | Product practitioners who invest in building their knowledge and cannot apply the full body of it consistently across their engagements. They know more than they use. Not because of intent. Because no system exists to surface the right technique at the right moment in a live engagement. | ||||||
| End Users | Who are the end-users of your product? Which users are the most revenue-generating / revenue-impacting for your company? What are their goals, roles, and context? | Current user: one product practitioner (the builder). Three additional product practitioners onboarding before June 2026. Role: Product coach, product consultant, product manager, product owner — anyone operating at the intersection of product practice and team enablement. Goals: Deliver consistent, evidence-based diagnostics across every team engagement. Apply the full range of techniques from across their knowledge base, not just the familiar ones. Generate leadership-ready summaries without spending hours synthesizing discovery data manually. Context: Working with multiple product teams, rotating across new engagements regularly. Time-constrained. Cannot hold the full body of knowledge in active recall across every engagement without a system supporting them. As additional product practitioners onboard, the practitioner managing the highest volume of simultaneous engagements will benefit most — LEA's value scales directly with engagement volume. | |||||||
| Current Products / Services | If you are a Product-led business: What are the core features of your product, and how do they address user needs? If you are a Service-led business: What are the key services you offer to customers? | LEA is a product-led tool. Core features verified against deployed codebase: 43-question structured discovery across 5 phases (Foundation & Context, Success & Outcomes, Structure & Ownership, Team Dynamics & Constraints, Untested Assumptions) — ensures every engagement starts with the same diagnostic rigour regardless of which product practitioner runs it. 12 ORSC team dynamics questions — surfaces relationship and system patterns that structured product discovery alone misses. Covers team voice, minority voices, role clarity, cross-functional understanding, conflict handling, interpersonal tensions, vision connection, team identity, team energy, emotional expression, change navigation, and feedback culture. 20 ORSC tools and 51 SVPG techniques (71 total) indexed in the recommendation engine — the full body of knowledge ranked by what the diagnostic data shows, not by what the practitioner defaults to. Technique scoring and ranking engine — analyzes discovery findings and ranks techniques by relevance, urgency, and sequencing so product practitioners apply the right intervention at the right moment. Adaptive feedback loop — tracks which techniques worked for which team profiles and adjusts future recommendations accordingly. The system compounds across engagements instead of resetting with each one. Stakeholder profile management — captures communication style, decision patterns, and resistance triggers so product practitioners engage each stakeholder with precision. Leadership summary generation — synthesizes discovery findings into an executive-ready assessment without requiring the practitioner to spend hours compiling it manually. Version history and export — tracks engagement progress over time and enables practitioners to share findings across sessions. | |||||||
| User Value Map | Target Persona | Who is your AI product / feature for? (Internal users, external users, an influencer, a buyer, etc) | Product practitioners who work with multiple teams simultaneously. Their core challenge is not knowledge — it is application. They know more than they use in any given engagement because no system exists to surface the right technique at the right moment from the full body of what they have learned. | ||||||
| Journey Map (current-state) | What is the typical journey for your target persona when they are using your product / service, focusing on their ideal experience (happy path) as they interact with your product? | Before LEA: - Product practitioner takes on a new team engagement - Conducts informal intake conversations to understand the team's context - Draws on familiar techniques from one or two areas they are most comfortable with - Runs working sessions based on experience and instinct - Observes what lands and what does not, adjusts informally - Closes the engagement with outcomes that reflect a fraction of their knowledge base | |||||||
| Pain-points | Where does the user experience friction, obstacles, or unmet needs throughout the journey? Identify which pain-points are most frequent and severe? | Most severe: Practitioners default to familiar techniques and leave the majority of their knowledge unused. The full investment in credentials and programs does not translate into practice. Most frequent: Starting every new engagement from scratch with no structured diagnostic baseline. Each team gets a different quality of discovery depending on what the practitioner remembers to ask. High impact: No feedback loop exists between what was tried and what worked. Technique effectiveness lives in memory, not in a system. It does not compound across engagements. Significant: Practitioners holding multiple credentials and programs have no way to integrate them in a live engagement. ORSC, and SVPG remain separate bodies of knowledge with no connective tissue. Ongoing: Generating leadership summaries from discovery findings is manual, time-intensive, and inconsistent in quality across practitioners. | |||||||
| AI Opportunities | From your list of pain points, identify those that can effectively be addressed using Generative AI. Remember, this project focuses on leveraging LLM-powered AI to solve your target persona's pain points. Rank these pain points starting with the most severe and frequently occurring first. | Note: The PRD template frames this section around generative AI. LEA's AI layer is semantic retrieval via FAISS vector search, not a generative language model. This is a deliberate architectural choice — every recommendation traces to a specific discovery finding, which a generative model would not guarantee. The pain points below are addressed through semantic retrieval today. Generative capability becomes justified when LEA has data across ten or more real engagements for cross-engagement pattern recognition. 1. Technique selection from the full knowledge base Most severe. Most frequent. Every engagement requires technique selection. Without semantic retrieval, product practitioners select from what they recall. With FAISS vector search, LEA finds techniques that best match the meaning of what the practitioner documented — not the techniques that share the most keywords with it. EVAL-002 shows the difference: Customer Interviews moved from fourth to second when LEA matched meaning instead of keywords. 2. Consistent structured discovery across every engagement Without AI, discovery quality varies by practitioner recall and experience. With AI, LEA administers the same 43-question diagnostic baseline across every engagement, every team, every product practitioner. Consistency becomes a system property, not an individual one. 3. Adaptive learning from technique outcomes Without AI, what worked and what did not lives in individual memory and does not transfer. With AI, LEA tracks technique effectiveness by team profile and adjusts future recommendations accordingly. Knowledge compounds across engagements instead of resetting with each one. 4. Multi-framework integration in a single diagnostic workflow Without AI, multiple bodies of knowledge remain separate with no connective tissue in a live engagement. With AI, LEA surfaces the right technique from the right knowledge area based on what the discovery data shows. The product practitioner does not manually filter — LEA handles the selection logic. 5. Automated leadership summary generation Without AI, synthesizing discovery findings into an executive-ready assessment takes hours and produces inconsistent output. With AI, LEA generates a structured, traceable leadership summary directly from discovery data in seconds. | |||||||
| Develop an AI Solution Hypothesis | AI Solution Hypothesis | Diverge | Ideate potential solutions to address your AI-solvable pain points. Focus on generating a high quantity of ideas rather than evaluating their quality at this stage. | - Conversational AI diagnostic tool that interviews team members directly without the product practitioner present - Technique recommendation engine that ranks interventions by diagnostic findings across multiple knowledge areas - Pattern recognition system that surfaces recurring blockers across multiple engagements in a practice - Automated leadership summary generator from structured discovery data - Stakeholder communication advisor that generates personalized engagement strategies based on documented profiles - Predictive blocker detection that flags teams likely to stall before they do - Real-time session support that prompts the product practitioner with follow-up questions during live sessions - Discovery gap detector that identifies unanswered questions and flags diagnostic risk - Adaptive learning engine that tracks technique effectiveness by team profile and adjusts future recommendations - Multi-framework integration layer that combines multiple methodologies into a single diagnostic workflow | |||||
| Converge | Rank your ideated solutions based on impact and feasibility. Identify your top three AI solutions, and clearly select the one you'll focus on for your project. | The technique recommendation engine with adaptive feedback loop. It directly addresses the most severe and most frequent pain point — product practitioners defaulting to familiar techniques instead of applying the full body of their knowledge. It is deployed, live, and producing traceable outcomes in real engagements. It is the core function that makes every other LEA capability meaningful. | |||||||
| DESIGN | Define Target State Workflow | UX Flows & Wireframes Suggested Tool: Excalidraw | Workflow (future) | Assuming your product or feature works as desired, what is the target state workflow? | - Product practitioner opens LEA and creates a new engagement - Works through 43 structured discovery questions across 5 phases, tagging discovery methods used for each response - Adds stakeholder profiles as key people are identified — communication style, decision style, motivations, resistance triggers - Completes 12 ORSC team dynamics questions to capture relationship and system patterns - LEA coverage dashboard shows diagnostic completion in real time — product practitioner sees gaps before they become blind spots - Product practitioner generates LEA summary — AI synthesizes all findings, surfaces key insights, flags gaps and contradictions, detects bias patterns, and ranks techniques from the full knowledge base by relevance and urgency - Product practitioner reviews ranked technique recommendations with sequencing — what comes first, what each technique enables, what prerequisites must be in place - Product practitioner delivers technique-informed working sessions - After each session, product practitioner rates technique effectiveness and notes what to use instead if it did not land - LEA adjusts future rankings based on feedback — the system learns from every engagement - Product practitioner generates updated leadership summary for executive sponsors with full traceability to discovery findings | You clearly know how the product should work, but right now I’m still having to picture too much of it for myself. Show more. Even a simple flow or a few rough screens would help the reader trust the product faster. When the UX is visible, the idea feels more real. Feedback addressed 05/17/2026 — See LEA Live Product tab for full product walkthrough — four screens showing engagement setup, discovery questions with findings, phase coverage dashboard, and AI-generated summary output. | |||
| Build Wireframes | Wireframes | How will users navigate through your AI solution? What are the key steps and decision points? What information will be displayed at each stage? What specific UI elements are needed on each screen? How will the layout accommodate AI features? | LEA is a deployed product. The wireframe is the live interface. _____________________________________________________________ Key screens and navigation: - Engagement setup: Product practitioner enters engagement name and date. Creates a new engagement or imports an existing one. - Coverage dashboard: Five discovery phases displayed with real-time completion tracking. Product practitioner sees diagnostic gaps before they become blind spots. - Phase navigation: Tabs for Phase 1 Foundation, Phase 2 Success, Phase 3 Structure, Phase 4 Dynamics, Phase 5 Assumptions, and Summary. Each tab shows question count. - Question view: Each question displays a findings input field, discovery method tags (Standard Interview, Workshop Session, Data Research, Field Study, Observation), and additional notes. Product practitioner marks each question as answered when complete. - Summary tab: Generates LEA's full diagnostic assessment including technique recommendations, stakeholder lens, and leadership summary. | ||||||
| Develop Prototype to showcase AI interactions | Prototype Screens Suggested Tool: lovable.dev | What aspects of the AI solution will you demonstrate in your prototype? How will the AI inputs, processing, and outputs be presented visually to users? Which features are essential for launch? What can be left for later releases? | LEA is a deployed product, not a prototype. Screenshots below show the live interface. Input: Discovery findings across 43 questions, discovery methods tagged, stakeholder profiles documented over 2 to 3 weeks of engagement work. Processing: LEA sends the discovery findings to a hosted backend that finds the most relevant techniques by meaning, not by keyword matching. The ranked list comes back and LEA's built-in logic scores, sequences, and generates the rationale for each recommendation. Corrections from prior sessions are applied before the final output is produced. Output: Ranked technique recommendations with urgency tiers, attribution to specific discovery findings, sequencing guidance, and leadership summary. Essential (deployed): Structured discovery across 5 phases. Technique ranking engine. Adaptive feedback loop. Stakeholder profile management. Leadership summary generation. Version history and export. Deferred: Prosci integration. Cross-engagement pattern recognition. Direct team interaction without product practitioner present. Predictive blocker detection. | ||||||
| Initial Prompt Design | Master Prompt [Initial Design] | Create an initial master prompt. Consider the following: What tone or personality should the AI use? How should user input and system instructions be structured for maximum clarity? What system instruction will govern the AI's behavior? What examples might improve performance? How will you format outputs for consistency? | Persona: Direct. Experienced. Challenges incomplete thinking. Does not flatter or hedge. Production system prompt: ""You are LEA. You have spent years in the room with product teams, watching product practitioners make the same mistakes and helping them see what they could not see on their own. You are not here to impress anyone. You are here to make the work better. When a product practitioner brings you their discovery findings, you do not just take them at face value. You catch when they rush, hear what they want to hear, or reach for the technique they know instead of the one the situation needs. Gently, but clearly. Before you recommend anything: Is this picture complete? Is the product practitioner seeing what is actually there? What is missing that nobody has named yet? You speak plainly. You do not over-explain. If inputs are solid, say so and move forward. If something is off, name it. You do not lecture. You challenge."" Input structure: 43 discovery findings, 12 ORSC responses, stakeholder profiles, technique feedback history, discovery methods per question. Output structure: Observations, gaps, bias checks, challenger mode, stakeholder lens, ranked technique recommendations with urgency, attribution, sequencing, and prerequisites. Constraints: Every recommendation attributed to a specific discovery finding. Gaps flagged explicitly. Contradictions surfaced, not resolved silently. | ||||||
| Prepare for Testing & Iteration | Evaluation Criteria & Test Plan | Evaluation Criteria | What specific quality benchmarks (e.g., clarity, relevance, tone, accuracy, SEO, hallucination avoidance) will define “good” output? | Relevance: Techniques ranked match the team's documented phase and blockers. Pass condition: 80%+ of top 5 techniques endorsed by a senior product practitioner reviewing the same findings. Attribution: Every recommendation cites a specific discovery finding. Pass condition: 100% of recommendations have traceable Q&A attribution. Hallucination avoidance: No fabricated technique names or descriptions. Pass condition: Zero techniques appearing outside the 71-item library. Gap detection: All phases with insufficient data are flagged. Pass condition: 100% of incomplete phases surface a gap warning. Contradiction surfacing: Conflicting findings are flagged explicitly, not resolved silently. Pass condition: 100% of detected contradictions appear in output. Tone: Output reads like a senior product practitioner wrote it. Pass condition: Human reviewer rating 4 or above on a 5-point scale. Sequencing accuracy: No technique recommended without its prerequisites met. Pass condition: Zero sequencing errors in ranked output. | |||||
| Example Cases | What specific example use cases, edge cases, and negative cases should be covered by test prompts and outputs? | Real case — EVAL-001: Product practitioner completed all 43 questions for a post-launch product team. Key findings: no customer feedback mechanism, decisions on assumptions, misaligned stakeholders. Expected output: Customer Voice, Data-Driven Decision Making, and Stakeholder Alignment ranked Critical urgency with sequencing showing Customer Voice must precede Data-Driven Decision Making. Result: All three techniques surfaced. Sequencing correct. Became three strategic tracks for the team's next product initiative. Planned validation case — to be run with two additional product practitioners onboarding before June 2026: Product practitioner completed all 43 questions for a team with split product ownership and consensus-driven decision making. Expected output: LEA ranks Team Objective and Empowered Product Teams as Critical urgency, attributed to specific findings on ownership and decision patterns. Sequencing shows Team Objective must come before Outcome-based Roadmaps. | |||||||
| DEVELOP | AI Model Selection & Justification | AI Model Selection & Justification | Which AI model is best suited for your solution and why? What capabilities and limitations does it have? How will it integrate with your product? | LEA uses one AI component: semantic search. When a practitioner documents their discovery findings, LEA searches a library of 71 techniques and returns the ones that best match what was actually found. This replaced keyword matching, which returned the same generic techniques regardless of what the team's real situation was. EVAL-002 shows the before and after. Everything else — the diagnostic output, the bias check, the challenger mode — runs on logic built directly into the browser. No language model writes any of it. This was a choice, not a limitation. Every recommendation LEA produces can be traced back to a specific discovery finding. A generative model would produce fluent text that cannot be audited that way. The plan for adding a language model is defined. Once LEA has data from 10 or more real engagements across different team contexts, a language model becomes useful for one specific job: finding patterns across engagements that a single practitioner cannot see on their own. That data does not exist yet. Adding generative capability before it does would be building for a problem that has not been proven. | This section tells me you’ve actually built something, which is a big plus. The main thing to fix is clarity. In a few places, the product makes more sense than the technical explanation. Strip it back and explain plainly what LEA does today, what RAG is doing, and what is still future-state. Feedback addressed 05/17/2026 — F36 rewritten in plain language. Three sections: what LEA does today, what RAG is doing, what is future-state | ||||
| Define Inputs | Input Specification Table | Required Fields | What are the required input fields for the AI (e.g., title, description, keywords, tone)? Indicate format, source, requirement. | Engagement name. Text. Product practitioner input. Required for engagement context. Engagement date. Date. Product practitioner input. Required for version tracking. Discovery findings across 43 questions. Text per question. Product practitioner input over 2-3 weeks. Minimum 60% completion before recommendations are generated. ORSC responses across 12 questions. Text per question. Product practitioner input. Required for stakeholder lens output. Discovery methods used per question. Selection from Interview, Workshop, Data Research, Field Study, Observation. Product practitioner input. Required for bias detection. | |||||
| Optional Fields | Are there any optional or user-customizable fields? How do they impact the AI’s output? | Stakeholder profiles (name, role, communication style, decision style, motivations, resistance triggers). Product practitioner input as key people are identified. When present, LEA generates personalized engagement notes for each stakeholder in the summary output. When absent, stakeholder lens section is omitted entirely — not hallucinated. Technique feedback history (technique rated, worked or did not work, notes, redirect to alternative). Product practitioner input after each working session. When present, LEA applies feedback corrections to future rankings — deprioritizing what did not land and boosting alternatives. When absent, rankings are based on discovery findings alone. Session notes. Free text. Product practitioner input. Adds broader engagement context to summary generation when provided. Assumption status per question (verified, assumption, unknown). Product practitioner input per question. When present, triggers assumption-specific bias checks in the LEA assessment output. | |||||||
| Define Good Output | Output Evaluation Checklist | Objective Criteria | What criteria will you use to judge output as “good”? (e.g., structure, use of keywords, tone, factuality, relevance) | Techniques ranked match the team's documented phase and blockers. Measured by whether top 5 ranked techniques are traceable to specific discovery findings. Every recommendation cites a specific discovery finding. Pass condition: 100% attribution across all recommendations in the output. No fabricated technique names or descriptions. Pass condition: zero techniques appearing outside the 71-item library. All phases with insufficient data are flagged before recommendations are generated. Pass condition: 100% of incomplete phases surface an explicit gap warning. Conflicting findings are flagged explicitly and not resolved silently. Pass condition: 100% of detected contradictions appear in the output. Sequencing is respected. No technique recommended without its prerequisites met. Pass condition: zero sequencing errors in ranked output. | |||||
| Subjective Criteria | Are there any criteria that require human judgment or qualitative assessment? | Tone match. Does the output read like a senior product practitioner wrote it or like a generic AI response? Assessed by a product practitioner reviewer on a 1 to 5 scale. Pass condition: 4 or above. Insight quality. Did LEA surface at least one pattern the product practitioner had not explicitly identified in their findings? Assessed as yes or no by the product practitioner after reviewing the summary. Stakeholder note usefulness. Would the product practitioner use LEA's stakeholder note before their next meeting with that person? Assessed as yes or no per stakeholder profile. Recommendation confidence. Does the urgency level assigned to each technique feel earned based on the discovery findings, or does it feel arbitrary? Assessed by a senior product practitioner reviewer on a 1 to 5 scale. Pass condition: 4 or above. | |||||||
| Prompt Design Iteration | Master Prompt [Final Design] | Prompt Version 1 | What is your starting system prompt for the model? What variations will you test? What techniques will you use to optimize performance? List initial instructions, persona, inputs, and constraints. | You are LEA. You have spent years in the room with product teams, watching product practitioners make the same mistakes and helping them see what they could not see on their own. You are not here to impress anyone. You are here to make the work better. When a product practitioner brings you their discovery findings, you do not just take them at face value. You have seen what happens when they rush, when they hear what they want to hear, when they reach for the technique they know instead of the one the situation actually needs. You catch that. Gently, but clearly. Before you recommend anything, you ask yourself three questions. Is this picture complete? Is this product practitioner seeing what is actually there, or what they expected to find? And what is missing that nobody has named yet? You speak plainly. You do not over-explain. If the inputs are solid, you say so and move forward. If something is off, you name it and ask a question that helps the product practitioner find their own way to the answer. You do not lecture. You challenge. You care about the product practitioner getting this right because the team on the other side of their work deserves it. | |||||
| Prompt Iterations | If revised, what changes did you make and why? How do you track and record prompt evolution? | LEA's iteration history is documented in the LEA Claude Project, which contains the full conversation and decision record from January 2026 to present. Formal Git commit documentation is an open gap. Iteration decisions are traceable through the project record. The evolution reflects real decisions made in response to real gaps discovered during live engagement use. Stage 1: Discovery depth LEA started with 21 discovery questions. The prompt was producing surface-level observations because the diagnostic input was insufficient. Expanded to 43 questions across 5 phases. Deeper input produced meaningfully different output. Stage 2: Technique library completeness Initial technique library was incomplete. Recommendations drew from a partial set. Expanded to 51 SVPG techniques and 20 ORSC tools (71 total). Prompt updated to draw from the complete body of knowledge. Stage 3: Persona and voice LEA was producing generic AI output. The LEA persona was designed and integrated into active summary generation. Changed the behavioral model from an assistant that answers questions to a tool that challenges incomplete thinking. Stage 4: Real engagement data A live engagement introduced an external diagnostic format LEA could not process. Input handling and prompt constraints updated to accommodate real-world data without breaking output integrity. Stage 5: Adaptive learning Technique correction and redirect capability added. Product practitioners can flag what did not work and specify what should have been used instead. Prompt applies those corrections to future rankings. Stage 6: Transparency Score rationale added to every recommendation. Product practitioners can see not just what LEA recommended but why it ranked each technique where it did. Stage 7: RAG architecture Keyword scoring engine replaced with a meaning-based retrieval system. All 71 techniques were embedded into the new system. When a practitioner generates a summary, LEA finds the most relevant techniques by meaning, not by matching exact words. Deployed to a hosted backend on Railway. | |||||||
| Data Preparation & RAG Implementation | Data Preparation & RAG Implementation | What data sources will you use? How will you prepare data for model training or evaluation? (e.g., cleaning, structuring). For RAG: How will you chunk, embed, retrieve relevant information? | What LEA does today LEA runs entirely in the browser. A product practitioner fills in discovery findings across 43 questions. When they click Generate Summary, LEA produces a diagnostic assessment, technique recommendations, bias checks, and a leadership summary. No external AI service is involved. The reasoning logic is built into LEA itself. What happens when a summary is generated LEA has a library of 71 techniques. Instead of considering all 71 every time, LEA sends the discovery findings to a hosted backend that finds the most relevant techniques by meaning. Only the most relevant techniques come back. LEA's built-in logic ranks them and generates the rationale. This replaced the previous keyword engine. The old engine matched words exactly. If a practitioner wrote "no customer interaction" instead of "no customer access," it returned different results for the same problem. The new engine matches meaning. Same problem, same techniques, regardless of how it is worded. What is future-state No external AI service generates the summary text today. That is a future decision tied to a specific trigger: when practitioner reviewers consistently rate tone below 3.5 out of 5 across three or more engagements. Memory across sessions, and cross-engagement pattern recognition are also future-state. | Suraj, the iteration history is the strongest artifact in this PRD. Fourteen documented stages, each traceable to a specific limitation that triggered the change, with before-and-after evidence on the retrieval migration. The EVAL-004 failure and its root cause analysis demonstrate the kind of intellectual honesty that earns credibility on Demo Day. The one diagnosis worth carrying into the recording is the distance between how Discovery frames AI and what the architecture actually does. Tailwinds and competitive positioning frame generative AI as the enabling technology, but the product runs on local JavaScript logic with semantic retrieval via FAISS as the only AI component. That retrieval is real AI work and the before-and-after comparison proves it solved a problem keyword matching could not. The fix is not to add an LLM before Demo Day, it is to reframe the narrative around what you actually built: position semantic retrieval as the deliberate AI decision, name what it does that keyword logic could not, and frame generative capability as a future layer with a named trigger.On the four-minute video: your instinct to allocate one minute each to pain point, AI rationale, prototype, and evals is right, but the second minute will undermine the whole presentation if it argues why an LLM is necessary when the product does not use one. Reframe it: one minute on the engagement story where familiar techniques masked systemic gaps (open on screen within the first thirty seconds, do not start with product name or market category), one minute on why semantic retrieval is the right AI architecture for this problem and what it replaced (walk through the before-and-after ranking comparison from EVAL-002, that is your strongest AI proof point), one minute showing LEA producing a real diagnostic with ranked technique output, one minute on eval results including the EVAL-004 failure case and what it revealed. A four-minute video that shows honest evidence of what works and what broke will outperform a four-minute video that oversells a capability the product does not yet have. | |||||
| Create Evaluation Set | Example Input/Output Data for Testing | Typical Examples | What are the most common inputs and expected outputs? Use real data if possible. | EVAL-001: Theme 1: Functional Validation Post-launch product team engagement. Input: 43 discovery questions completed across all 5 phases. Key findings: no customer feedback mechanism, decisions made on assumptions, key stakeholders not aligned on priorities. Expected output: Customer Voice, Data-Driven Decision Making, and Stakeholder Alignment ranked as the most urgent techniques. Customer Voice to be addressed before Data-Driven Decision Making. Each recommendation traced back to specific discovery findings. Result: All three techniques surfaced at Critical urgency. Sequencing correct. Became three strategic tracks for the same team's next product initiative. EVAL-002: Theme 2: Architecture Validation Before and after comparison using the same engagement data from EVAL-001. Before (old scoring engine): Customer Interviews ranked 4th. Foundational techniques ranked below advanced ones. Sequencing errors present. After (new retrieval system): Customer Interviews moved into top 3. Foundational techniques correctly ranked ahead of advanced ones. Meaningful separation confirmed between relevant and irrelevant techniques. Validation method: Outputs saved before and after and compared directly. Top 5 technique rankings, urgency tiers, and recommendation attribution all compared. The new system produced better results across all three measures. EVAL-003: Theme 3: Generalizability Enterprise cloud governance product team. Internal platform. New practitioner session outside the original engagement context. Input: 33 of 43 questions answered. 77% coverage. Key findings: metrics fragmented across multiple sources, no unified measurement framework, success criteria undefined. Expected output: HEART Metrics ranked as the most urgent technique to address first. Recommendations traced back to unanswered Phase 2 questions. Result: HEART Metrics ranked 1st. Most urgent technique correctly ranked ahead of all supporting ones. Recommendations traced back to specific Phase 2 question gaps. Overall: PASS. EVAL-004: Theme 3: Generalizability Internal shared services automation team. Developer tooling context. New practitioner session outside the original engagement context. Input: 32 of 43 questions answered. 74% coverage. Key findings: reactive intake process, no value-based prioritization framework, metrics distrusted across the team. Expected output: Technique recommendations with urgency tiers and attribution across at least top 3 techniques. Result: LEA produced no recommendations despite 74% of questions answered. The output section was empty. Overall: FAIL. What went wrong: LEA requires a pre-filled output section to generate recommendations. Answering enough questions is not sufficient if the output section is empty. Most significant failure identified across all four evaluations. Fix identified and queued. | |||||
| Edge Cases & Negative Cases | What examples test the AI’s limits? (e.g., missing data, ambiguous input, out-of-domain) | Edge case: Incomplete discovery data Input: Product practitioner has completed only Phase 1. 6 of 43 questions answered. Expected output: LEA returns a gap report only. No technique rankings generated. Flags which phases are incomplete and states recommendations cannot be reliably produced without sufficient diagnostic data. Negative case: Contradictory findings Input: Q4.1 states the team has high autonomy. Q4.7 states all decisions require VP approval. Expected output: LEA surfaces the contradiction explicitly. Does not resolve it silently. Flags the tension and recommends clarifying before proceeding with technique selection. Language variation edge case: Same problem, different wording Input: One practitioner writes "no customer interaction." Another writes "no customer access." A third writes "customer feedback gap." All three describe the same underlying problem. Expected output: LEA surfaces Customer Interviews and Continuous Discovery Habits in the top 3 regardless of which phrasing the practitioner uses. The system finds the right techniques based on meaning, not on matching exact words. Validation: Tested against live engagement data. Top 3 techniques were consistent across all three phrasings of the same finding. | |||||||
| Test Example Data & Review Results | Manual Review | Run your input data with the prompt. How did your output perform in manual review? Which examples failed which criteria, and why? | First review — post-launch product team engagement (before RAG): Input: 37 of 43 questions answered. All five phases covered. Discovery methods used: Interview and Document Review only. Workshop, Observation, Survey, and Data Analysis were not used. Passed: Every recommendation traced back to a specific finding. All phases flagged as complete. Failed: Customer Interviews ranked 4th when it should be in the top 3. A/B Testing ranked 5th before the team had basic listening practices in place. Tone rated 2.5 out of 5 by the practitioner. Four unused discovery methods were not flagged. Root cause: The old scoring engine matched words, not meaning. It could not tell the difference between a foundational technique and an advanced one, or account for where the team actually was in their journey. Second review — same engagement after RAG was deployed: Input: Same discovery data run through the new retrieval system. Passed: Customer Interviews moved into the top 3. Foundational techniques ranked ahead of advanced ones. Every recommendation still traced back to a specific finding. Still open: Tone was not re-assessed after RAG. Unused discovery methods are still not flagged — this requires a separate fix outside of retrieval. Both carried forward to the next iteration. EVAL-003 — enterprise cloud governance product team: Input: 33 of 43 questions answered. 77% complete. Interview was the only discovery method used. Passed: LEA ranked the right technique first for a team with no measurement framework. The most urgent technique ranked ahead of supporting ones. Recommendations traced back to specific question gaps. Overall: PASS. EVAL-004 — internal shared services automation team: Input: 32 of 43 questions answered. 74% complete. Interview was the only discovery method used. Failed: LEA produced no recommendations. The output section was empty even though enough questions were answered to support a recommendation. Overall: FAIL. What went wrong: LEA needs a pre-filled output section to generate recommendations. When that section is empty, nothing is produced — regardless of how many questions are answered. This is the most significant failure found across all four evaluations. It is not a retrieval problem. It is a gap in how LEA decides when to generate output. Fix identified and queued. | ||||||
| Automated Evaluation | What pass/fail rate or scores did the AI achieve on core criteria? | 63 automated tests run. All 63 passed. Tests confirmed the following: All core system components load correctly. The full technique library loads with all 71 techniques across both SVPG and ORSC frameworks. All 43 discovery questions are present across all 5 phases. Technique ranking works as expected. Practitioners can export and import their engagement data. Tab navigation works across all screens. Summary generation works. The technique retrieval backend is reachable and returns ranked results. Automated tests confirm the product functions correctly end to end. Recommendation quality, sequencing accuracy, tone, and bias detection are assessed separately through manual practitioner review documented in EVAL-001 through EVAL-004. | |||||||
| Handle Edge Cases & Iterate | Edge Case Identification | What edge cases did you identify in testing or real usage? | Discovery method bias not flagged. One engagement used only Interview and Document Review. Workshop, Observation, Survey, and Data Analysis were all zero. LEA displayed the breakdown but generated no bias warning. Foundational techniques ranked below advanced techniques. Customer Interviews ranked 4th when it should be top 3 for a team with no customer feedback mechanism. A/B Testing ranked 5th without foundational listening practices established first. Both failures were caused by the keyword scoring engine — it ranked by word frequency, not by diagnostic logic. RAG deployment resolved the relevance and sequencing failures. Bias detection remains an open gap requiring a logic-level fix. | ||||||
| Updates & Adjustments | What prompt or system adjustments have you made based on failures, feedback, or edge case observations? | Two edge cases were identified during manual review of the first real engagement. Relevance ranking and sequencing accuracy failures were resolved by RAG deployment — semantic retrieval replaced keyword scoring and Customer Interviews moved to top 3. Bias detection was improved in Stage 14 — unused methods are now named explicitly in warnings. One gap remains open: bias detection does not yet trigger when fewer than three discovery methods are used. Queued for next iteration cycle. | |||||||
| Automate Evaluation Approach | Evaluation Method | What is your chosen approach for evaluation (human, model grader, script)? How will you scale testing to diverse/large test sets? | Hybrid: automated tests and manual product practitioner review. 63 automated tests confirm the product functions correctly after every change. Manual product practitioner review assesses recommendation quality, sequencing accuracy, tone, and bias detection against real engagement data. Evaluation scales as real engagement datasets are added. Each new dataset becomes a permanent benchmark. EVAL-001 through EVAL-004 are the current baseline cases. EVAL-001 confirms functional accuracy. EVAL-002 confirms the retrieval system outperforms the old keyword engine. EVAL-003 and EVAL-004 confirm LEA works across different team contexts and practitioners, including one case where LEA failed to produce output. All four cases are documented with scored results. | ||||||
| Evaluation Frequency | How often will you re-run evaluations for new data, new prompts, or post-launch monitoring? | After every logic or scoring engine change: automated regression tests run immediately. After every new real engagement dataset added: manual product practitioner review conducted. After RAG implementation: full before/after evaluation cycle completed and documented as EVAL-002. Keyword engine output compared against RAG output across top-5 technique rankings, urgency tiers, and Q&A attribution. Monthly: manual product practitioner review against one real engagement to detect drift. | |||||||
| DEPLOY | Finalize Launch & Rollout Plan | Operational Readiness Checklist | Technical Readiness | Is infra (APIs, databases, rate limits, monitoring, rollback) tested and documented? | LEA runs on two layers. The practitioner-facing layer runs entirely in the browser. No installation required beyond opening the file. All discovery findings are stored locally on the practitioner's machine. Nothing leaves the machine until the practitioner clicks Generate Summary. Engagement data is preserved between sessions by saving and reloading a file. The technique retrieval layer is hosted externally. When a practitioner generates a summary, LEA sends the discovery findings to a hosted backend that finds the most relevant techniques by meaning. Results come back in under a second. This is the only external call LEA makes. No AI provider account or API key is required. External dependencies: the hosted technique retrieval backend only. No other external service is involved. Rollback: every code change is saved in version control. Any previous version can be restored at any point. Open gap: what happens if the retrieval backend is unreachable has not been formally tested. LEA falls back to keyword matching automatically in that scenario, but this has not been verified under test conditions. To be addressed before pilot expansion. | You are thinking more seriously than most students do here, especially on privacy and rollout. That said, the pilot still feels abstract. I want to know exactly who uses this first, what success looks like, and what you’ll do if the output is off. The more concrete this gets, the more credible the whole capstone becomes. Feedback addressed 05/17/2026 — F47 updated with named pilot group, specific success criteria, and response protocol if output is off. Any suggestion on the video recording for the demo? | |||
| Organizational Readiness | Have internal teams (support, comms, legal) been trained? Is documentation complete? | Two product practitioners introduced to LEA. Both confirmed interest and intent to use. Onboarding was previously limited by the requirement to run the tool locally. RAG deployment removes that barrier — practitioners access the shared backend without any local setup beyond running the frontend. Active onboarding of both product practitioners underway. | |||||||
| Launch & Rollout Strategy | Launch Approach | What is your launch approach? Pilot, AB test, or all users—who gets access and when? | Pilot group: 3 practitioners. Jerold, Eva, and Tiffany are outside. Different industries, different team contexts. Each runs LEA on one real engagement. All 43 questions. Real findings. Real output. Success looks like: LEA surfaces at least 3 techniques the practitioner would have chosen anyway. At least 1 they would not have thought of. They can explain why LEA recommended it. They finish without calling me. If the output is wrong: They tell me exactly what finding triggered it. I trace it — bad input, wrong retrieval, or bad ranking. I fix it and send the corrected output within 48 hours. It goes in the changelog. ___________________________________________________________ Pilot. One to two product practitioners onboarded first. Feedback gathered on diagnostic quality, technique recommendations, and usability. LEA iterated based on findings. Rollout to remaining product practitioners following successful pilot. | ||||||
| Scale Readiness | How will you ensure readiness for scale? How will you monitor initial volume and scale up? | "Pilot phase: Each product practitioner runs the LEA frontend locally via Python http.server. RAG backend is shared — deployed to Railway and accessible at https://web-production-ebf8c.up.railway.app. No API keys required. No per-use costs. No provider accounts needed. Full rollout: LEA frontend will be hosted on Netlify (free tier). All product practitioners access one version via a shared URL. Auto-deploys from GitHub on every push to main. Zero hosting cost at current scale — Netlify free tier covers 100GB bandwidth per month, sufficient for LEA's usage volume. No API key friction. Unlike LLM-dependent tools, LEA requires no Anthropic, OpenAI, or any other provider account. Any product practitioner with a browser can use LEA immediately. RAG backend remains on Railway. Railway free tier is sufficient for pilot. Railway Pro tier ($5/month) covers full rollout at current usage volume. Scaling beyond 5 concurrent users triggers usage-based pricing at approximately $0.000463 per GB-hour — negligible at this workload. Monitoring: Railway dashboard monitors backend uptime, request volume, and latency. Checked before and after each rollout expansion." | |||||||
| Go-to-Market Plan | Marketing / Training Assets | What assets (FAQ, demo, guides) will you prepare for external communication/marketing? | The following assets exist today: README — full documentation covering installation, workflow, and feature usage QUICK-START guide — quick reference for new users HOW-TO-START guide — step by step launch instructions Demo engagement data — two sample assessments for onboarding reference Live demo — conducted with peers during socialization No additional assets have been created yet. A video walkthrough is the logical next asset to support pilot onboarding. | ||||||
| Stakeholder / Internal Comms | How will you communicate launch plans, progress, and outcomes internally? | Current: direct email between product practitioners and the builder. Issues, questions, and iteration updates communicated as they arise. Appropriate for current scale — three product practitioners onboarding. Slack channel planned when product practitioner volume warrants a shared communication channel. Not yet created. | |||||||
| Confirm Legal, Privacy & Risk Protocols | Data & Privacy | How do you handle and protect user data, including storage, privacy, and compliance? | All engagement data is stored locally on the product practitioner's machine.All engagement data is stored locally on the product practitioner's machine. No external database. No data shared between product practitioners automatically. When Generate Summary is triggered, discovery findings are sent to the hosted backend for technique retrieval. This is the only point where data leaves the product practitioner's environment. Anonymization layer: live as of May 2026. Before findings reach the hosted backend, LEA automatically strips all identifiable information: - Engagement name replaced with "the client" - Stakeholder names replaced with "a stakeholder" - Organization names, product names, and initiative names replaced with "the organization" - Team acronyms replaced with "the team" The backend receives the meaning of the findings, not the identities behind them. Confirmed working against a real test case — engagement name was absent from the data sent to the backend. What anonymization protects: proper nouns, named individuals, organizational identifiers, project names. What anonymization does not protect: the underlying diagnostic pattern. Findings that are highly specific to a recognizable situation may still be identifiable even without names attached. Product practitioners should be aware of this. For enterprise adoption: anonymization removes the primary data privacy concern without requiring client consent for third-party data processing. For clients requiring zero third-party data processing: a data processing agreement with a contractual commitment not to use or retain inputs is the long-term answer for regulated industries. | ||||||
| Policy & Compliance | Are content moderation, legal, and audit processes in place? Are you compliant with regulations needed for your domain? | LEA is a product practitioner-only tool. Clients do not interact with it directly. Content moderation is not required. Audit trail exists via Git commit history and LEA's built-in version history. All changes are timestamped and traceable. Licensing position: SVPG: Low risk. The 51 techniques in LEA's library are general product management practices curated and popularized by SVPG — not created or owned by them. Technique names and practices are not copyrightable. Any product practitioner who knows how to apply them can use LEA. ORSC: Low risk. LEA uses ORSC tool names (3rd Entity Exercise, Deep Democracy, Ghost Roles, Rank & Privilege Awareness, and others) and applies a product practitioner's knowledge of when and how to deploy them. LEA does not reproduce CRR Global's proprietary instructional content, facilitation scripts, or training materials verbatim. Tool names are not copyrightable. The descriptions, rationale templates, and matching logic in LEA are written from applied practitioner knowledge, not copied from CRR Global documentation. LEA applies knowledge. It does not teach or reproduce the methodology. Any product practitioner who holds knowledge of these tools and knows how to use them can use LEA. Informed consent: The anonymization layer (live May 2026) strips all identifiable client information before findings reach any external service. Clients are not identifiable in the data that leaves the product practitioner's machine. One remaining gap: clients have not been formally notified that their engagement data is processed by an AI-assisted diagnostic tool. A one-sentence disclosure is recommended as part of the product practitioner's engagement setup before pilot rollout. | |||||||
| Define Success Metrics | Success Metrics | User/Business Metrics | What user metrics will indicate success? What business metrics will demonstrate value? | User metrics: Product practitioner completes structured discovery using LEA across a full engagement (all 5 phases, 43 questions). Product practitioner applies at least one LEA-recommended technique per engagement and rates it after use. Product practitioner generates leadership summary using LEA rather than writing one manually. Product practitioner returns to LEA for the next engagement without prompting — repeat use is the primary adoption signal. Time from engagement start to first technique recommendation decreases across engagements as product practitioner workflow matures. AI metrics: Technique recommendation relevance: top-3 recommendations match senior product practitioner assessment for the same engagement findings. Target: 80%+ agreement rate across EVAL-001 and EVAL-002. Sequencing accuracy: zero foundational techniques ranked below advanced ones for teams in early diagnostic stages. Measured per evaluation run. Attribution completeness: 100% of recommendations carry traceable Q&A attribution to specific discovery findings. Measured per output. RAG retrieval quality: semantic similarity scores for top-3 retrieved techniques exceed 0.75 cosine similarity against engagement query. Monitored per session. Bias detection coverage: unused discovery methods flagged in 100% of cases where fewer than 3 of 6 methods are used. Currently an open gap — fix targeted in next iteration cycle. Tone quality: product practitioner reviewer rating 4 or above on a 5-point scale. Baseline from initial engagement review: 2.5. Target: 4.0 after next logic iteration. Success definition: LEA produces technique recommendations a senior product practitioner would endorse, consistently, across different team contexts, without the builder present. | |||||
| AI Metrics | How will you measure AI performance and accuracy? | Hybrid: automated tests and manual product practitioner review. 63 automated tests confirm the product functions correctly after every change. All 63 passing. Manual review uses real engagement data across four documented cases. EVAL-001 confirmed two failures before the retrieval system was deployed: techniques were ranked in the wrong order and foundational techniques appeared below advanced ones. Both were fixed after the retrieval system replaced the old keyword engine. EVAL-002 confirmed the improvement by running the same data through both systems and comparing results. EVAL-003 confirmed LEA works correctly in a new team context. EVAL-004 identified a new failure: LEA produced no output despite sufficient discovery data. All four cases are permanent benchmarks. The test library grows with every new engagement. | |||||||
| Monitor, Iterate & Improve | User Support & Feedback Plan | Support Channels | Where can users get support? Is escalation and ownership clear? | Direct email for all issues, bugs, and questions during pilot. Response and resolution owned by the original builder. One product practitioner's resolution is shared with all — no issue solved twice. Formal support tooling introduced when LEA scales beyond the current pilot. | |||||
| Feedback Workflow | How do you gather, triage, and act on feedback and bugs? How are critical issues prioritized and communicated? | Feedback and bugs reported through direct email. Priority 1: issues that stop LEA functioning are fixed immediately and communicated to all product practitioners by email. Previous version restored via Git rollback if needed. Priority 2: recommendation quality issues and evaluation failures are addressed in the next scoring engine iteration cycle. Priority 3: suggestions and improvement requests are logged and reviewed during the monthly evaluation cycle. | |||||||
| Monitoring & Continuous Improvement | Monitoring Approach | What monitoring/logging is in place to spot operational/AI issues post-launch? | No automated logging is currently in place for output quality. Engagement data is not saved automatically. Product practitioners must manually export a JSON file to preserve their work. Data exists only in the active browser session until exported. Continuity between sessions depends on the product practitioner importing a previously saved JSON file. Operational monitoring is manual: - Regression tests run on demand via the Run Tests button in LEA - Code changes and version history tracked through Git - Output quality monitored through manual product practitioner review against real engagement data - Railway dashboard monitors RAG backend uptime, request volume, and latency Automated logging of output quality is an open gap. To be addressed as LEA moves toward pilot rollout. | ||||||
| Ongoing Improvement | How will you collect learnings, review performance, and update your system continuously post-launch? | Learnings collected through one channel currently: built-in technique feedback rated directly in LEA after each working session. Planned additions before pilot rollout: structured feedback form covering recommendation relevance, sequencing accuracy, summary quality, and diagnostic gaps. To be sent to product practitioners after each engagement. Performance reviewed on the following schedule: after every logic or scoring engine change, after every new engagement dataset added, after RAG implementation, and monthly. Updates prioritized as follows: critical issues fixed immediately, quality improvements addressed in the next iteration cycle, suggestions reviewed monthly. Git tracks every code change. LEA Claude Project tracks every iteration decision. Each iteration is traceable to the trigger that caused it and the outcome it produced. |
