ai-product-strategy
Skill1 starsChanged 22 days agoMITView on GitHub
Produces an Artificial Intelligence (AI) product strategy: a scored map of AI opportunities, a build-buy-partner recommendation per opportunity, a data moat assessment, trust and user experience requirements, a phased roadmap, and a risk register. Use when evaluating where AI could add value to a product; deciding whether to build, buy, or partner for an AI capability; assessing whether proprietary data creates a defensible advantage; planning an AI feature roadmap; or evaluating AI vendors and partners.
4 other projects use a version of this.
Adopted by
Most recently taken up by
- alunadev/ald-skillstheir own version, first seen Nov 8, 2026
- RefoundAI/lenny-skillstheir own version, first seen Jul 15, 2026
- impeto-ai/claude-skills-impetotheir own version, first seen May 18, 2026
- marconimarques/ai-product-strategytheir own version, first seen Mar 3, 2026
Other versions4 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 4
- RefoundAI/lenny-skills★ 1.3ksame name
- alunadev/ald-skills★ 4same name
- impeto-ai/claude-skills-impeto★ 1same name
- marconimarques/ai-product-strategy★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository41 other files it gives its agents.
- ai-activation-optimizerSkill
- ai-content-quality-gateSkill
- ai-feature-experiment-designerSkill
- ai-launch-playbookSkill
- ai-pricing-margin-modelerSkill
- ai-product-positioningSkill
- ai-search-visibility-optimizerSkill
- agent-autonomy-level-mapperSkill
- ai-failure-state-designerSkill
- ai-usability-test-plannerSkill
- ai-ux-auditSkill
- human-in-the-loop-designerSkill
- prompt-surface-designerSkill
- uncertainty-and-explainability-patternsSkill
- ai-agent-financial-analystSkill
- burn-rate-runway-plannerSkill
- capital-allocation-frameworkSkill
- dcf-valuation-builderSkill
- financial-statement-analyzerSkill
- saas-cohort-analyzerSkill
- competitive-response-modelerSkill
- mechanism-design-plannerSkill
- nash-equilibrium-solverSkill
- negotiation-strategistSkill
- repeated-game-strategistSkill
- ai-decision-engineSkill
- ai-stakeholder-translatorSkill
- customer-interview-synthesizerSkill
- jobs-to-be-done-extractorSkill
- opportunity-solution-treeSkill
- product-discovery-coachSkill
- product-roadmap-prioritizerSkill
- blue-ocean-strategy-canvasSkill
- go-to-market-strategySkill
- gtm-engineeringSkill
- market-sizingSkill
- okr-cascade-plannerSkill
- porters-five-forces-analyzerSkill
- pricing-strategy-analyzerSkill
- strategic-landscape-mapperSkill
- swot-tows-analyzerSkill
The file
We split this skill into the rules it gives an agent
5 rules. 0 are common, 5 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 4 edited versions we read keep these.
5
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 76
Test whether the data advantage is real.
- Distinctive: line 93
Progressive disclosure: - start with assistive suggestions before autonomous actions
- Distinctive: line 129
Start from a user job and pain point, not from a model capability
- Distinctive: line 131
Test the data moat against replicability, not just volume
- Distinctive: line 140
Treat responsible AI review as optional
“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
AI Product Strategy
Find the AI opportunities worth pursuing, and the ones that will still be defensible in two years.
What this skill is
A structured workflow for deciding where Artificial Intelligence (AI) belongs in a product and how to deliver it. It moves from opportunity discovery through build-buy-partner analysis, data moat assessment, and trust design to a phased roadmap with explicit risks. It draws on Marty Cagan's four product risks (value, usability, feasibility, viability), Andrew Ng's AI Transformation Playbook, Benedict Evans's writing on AI moats, and Julie Zhuo's approach to product strategy.
What it solves
- AI features chosen because competitors announced them, not because they solve a user problem
- Build decisions made without comparing the cost and speed of buying or partnering
- Strategies that assume a data advantage without testing whether the data is proprietary or replicable
- AI features that fail user trust because errors, confidence, and control were never designed
- Roadmaps that jump to differentiation before a minimum viable version has proven value
- Risk reviews that cover model accuracy but ignore viability, cost, and regulatory exposure
When to invoke
- Leadership asks "what is our AI strategy?" and the team needs a structured answer
- A team is deciding whether to build an AI capability in-house, buy a vendor solution, or partner
- A product manager needs to judge whether the company's data creates a lasting advantage
- Planning the next two to four quarters of AI features
- Evaluating AI vendors or model providers for a specific use case
Phase 1: Product and market baseline
Capture the context the strategy depends on. Ask for anything missing.
| Input | Why it matters |
| Product, users, and core jobs | AI must serve an existing job, not invent one |
| Current pain points and workarounds | The best opportunities sit where users spend effort today |
| Data assets | What data the product generates, owns, and can legally use |
| Competitive AI moves | What is becoming table stakes versus differentiating |
| Team capability | Machine learning (ML), data engineering, and evaluation skills in house |
| Constraints | Budget, latency, privacy, regulatory, and brand risk tolerance |
Phase 2: Identify AI opportunity areas
Generate candidates across six categories, then score each.
| Category | Typical pattern |
| Automation | Remove repetitive manual steps |
| Prediction | Forecast an outcome the user currently guesses |
| Personalization | Tailor content, ranking, or defaults per user |
| Content generation | Draft text, images, code, or summaries |
| Data analysis | Surface patterns users cannot see manually |
| Decision support | Recommend an action with reasoning |
Score each opportunity 1-5 on user value, frequency of the job, data availability, technical feasibility, and tolerance for error. Shortlist the top three to five.
Phase 3: Build, buy, or partner
For each shortlisted opportunity:
| Factor | Favors build | Favors buy | Favors partner |
| Strategic differentiation | Core to the product's advantage | Commodity capability | Adjacent capability |
| Proprietary data | Unique and essential | Not required | Partner holds it |
| Time to market | Can wait | Needed now | Needed soon |
| In-house capability | Strong | Weak | Mixed |
| Total cost over 3 years | Lower at scale | Lower at low volume | Shared |
| Control and lock-in risk | Full control | Vendor dependency | Contractual dependency |
Record the recommendation and the condition that would flip it.
Phase 4: Data moat assessment
Test whether the data advantage is real.
| Question | Strong moat | Weak moat |
| Is the data proprietary? | Generated only by our product | Publicly available or purchasable |
| Is there a flywheel? | Usage improves the model, which drives more usage | Model quality is static |
| How replicable is it? | Years of accumulated, labeled data | A competitor could gather it in months |
| Time to defensibility | Advantage compounds within 12-24 months | No clear compounding |
Rate the moat as strong, moderate, or weak and say what would strengthen it.
Phase 5: User experience and trust design
Specify how each AI feature earns and keeps trust:
- Transparency - show why the system produced a result and how confident it is
- User control - let users edit, override, undo, or opt out
- Graceful failure - define what happens when the model is wrong or unavailable
- Progressive disclosure - start with assistive suggestions before autonomous actions
- Trust building - expand autonomy only as measured accuracy and user acceptance rise
Phase 6: Implementation roadmap
| Stage | Goal | Exit criteria |
| Stage 1: Minimum Viable Product (MVP) | Prove user value for one opportunity | Adoption and quality targets met |
| Stage 2: Expansion | Extend to adjacent workflows and segments | Unit cost and reliability within targets |
| Stage 3: Differentiation | Build the data flywheel and proprietary capability | Measurable gap versus alternatives |
Phase 7: Risk and mitigation planning
Assess each opportunity against Cagan's four risks plus AI-specific exposure.
| Risk | Question | Mitigation example |
| Value | Will users choose to use it? | Prototype test before build |
| Usability | Can users understand and control it? | Trust patterns from Phase 5 |
| Feasibility | Can we reach the needed quality and latency? | Offline evaluation set and quality bar |
| Viability | Does it work for the business, including inference cost? | Cost per action model and pricing review |
| Responsible AI | Bias, privacy, safety, or regulatory exposure | Review gate and monitoring |
Output
- Product and market baseline
- Scored AI opportunity map with a shortlist
- Build, buy, or partner recommendation per shortlisted opportunity, with flip conditions
- Data moat rating and strengthening actions
- Trust and user experience requirements per feature
- Three-stage roadmap with exit criteria
- Risk register with mitigations and owners
Operating rules
Always
- Start from a user job and pain point, not from a model capability
- Compare build, buy, and partner explicitly for every shortlisted opportunity
- Test the data moat against replicability, not just volume
- Design failure modes and user control before launch
- Include inference cost in the viability assessment
Never
- Recommend an AI feature because a competitor shipped one
- Claim a data moat without evidence that the data is proprietary
- Skip the minimum viable stage and jump straight to differentiation
- Give an AI feature autonomy before its accuracy is measured
- Treat responsible AI review as optional
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

