
Claude Skills by VandanaAjayDubey111
github.com/VandanaAjayDubey111Build an Opportunity Solution Tree (OST) to structure continuous product discovery — map one desired outcome to customer opportunities, candidate solutions, and validating experiments. Based on Teresa Torres' Continuous Discovery Habits. Use when structuring discovery, turning research into prioritized bets, or deciding what to build next without jumping to solutions.
Transform an output-focused roadmap into an outcome-focused one that communicates strategic intent. Rewrites initiatives as outcome statements reflecting user and business impacts. Use when shifting to outcome roadmaps, making a roadmap more strategic, or rewriting feature lists as outcomes.
Playbook for PCI-DSS scope decisions from a product perspective — SAQ-A vs SAQ-A-EP vs SAQ-D, card-data flow architecture, tokenization, SCA / PSD2 (EU), 3DS 2.x, scope-reduction patterns.
Perform a PESTLE analysis covering Political, Economic, Social, Technological, Legal, and Environmental factors. Use when assessing the macro environment, doing strategic planning, or evaluating external factors affecting your business.
Run product-led growth as an integrated system, not a tactic — where the product itself acquires, activates, retains, monetizes, and spreads. Use when the user mentions "product-led growth", "PLG", "self-serve", "free trial", "freemium", "PQL", "product-qualified lead", "bottoms-up", "free-to-paid", "self-serve funnel", "time-to-value", "TTV", or asks "should we be sales-led or product-led?". Also trigger when designing a free tier, an invite-only→open launch, an in-product upgrade path, or a...
Playbook for auditing PM-health across 15 dimensions (Discovery, Strategy, Prioritization, Roadmap, Specs, Metrics, Launch, Measure, Comms, Decisions, Pricing, Competitive, Feedback, AI-PM, Governance) and producing a structured report. The brain behind pm-auditor.
Review an engineering technical spec through a PM lens — does it cover every PRD requirement, does it preserve user/UX intent, does it quietly add or drop scope, what are the product risks, what's missing for launch. Produces a priority-tagged findings list + clarifying questions for engineering. Use after eng drafts a tech spec / design doc / architecture proposal and before code lands.
Perform Porter's Five Forces analysis — competitive rivalry, supplier power, buyer power, threat of substitutes, and threat of new entrants. Use when analyzing industry dynamics, assessing competitive forces, or evaluating market attractiveness.
Playbook for deployment-aware pull requests — the 11-section format that turns a PR into a reviewable contract; why, decision requested, change map, review order, evidence, verification, risk, rollback. Used for the Define→build handoff and any PR a great-pm-driven project opens.
Playbook for reviewing pull requests — verdict format, verification-not-trust, severity-ranked findings with concrete fixes, risk acceptance on the record. The reviewer-side counterpart of pr-authoring.
Playbook for writing build-ready PRDs — structure, user stories, acceptance criteria, scope vs non-goals, edge cases, and the anti-patterns that kill engineering velocity. Used by spec-writer (to author) and spec-reviewer (as the rubric).
Imagine the initiative has already shipped and failed publicly — work backwards from the failure to identify the most likely product / PM causes BEFORE building. Forces concrete risk identification, not vague "what could go wrong" lists. Adapted from Gary Klein's MIT Sloan research; pairs with engineering's engineering-side pre-mortem.
Playbook for choosing a pricing model, designing tiers, setting the free-vs-paid line, and estimating willingness to pay with a real method. Used by pricing-strategist.
Playbook for 12 proven prioritization methods. Helps prioritization-analyst pick the right method for the decision at hand — not the most familiar. Covers RICE, ICE, MoSCoW, Kano, Weighted Scoring, Value-vs-Effort, WSJF / Cost of Delay, Opportunity Solution Trees, Story Mapping, Impact Mapping, Buy-a-Feature, Eisenhower.
Cascade a fixed product vision into a changing roadmap through an explicit Vision → Strategy → Bets → Roadmap stack — so strategy means "which problems we''ll solve", not "a list of features". Use when the user mentions "product strategy", "strategy stack", "product vision", "strategic bets", "DHM", "delight hard-to-copy margin-enhancing", "strategy vs roadmap", "vision to roadmap", or says "our roadmap IS our strategy" / "we have a roadmap but no strategy". Also trigger when a 0-to-1 build i...
The model-capability decision tree — prompt-engineering first, then RAG for missing knowledge, then fine-tuning for missing behavior/format or cost/latency, climbing only as far as needed. Covers the cost/latency/maintenance tradeoffs of each rung and when each is the wrong choice (especially the premature-fine-tune trap). Gives the PM the framework to decide where an AI feature's knowledge and behavior should come from. Used by ai-prompt-architect and architect.
Generate user-facing release notes from tickets, PRDs, or changelogs. Creates clear, engaging summaries organized by category (new features, improvements, fixes). Use when writing release notes, creating changelogs, announcing product updates, or summarizing what shipped.
The product-side (not legal-side) safety playbook for shipping AI features — input/output filtering, confidence thresholds, hallucination grounding, escalation, disclosure, a red-team product checklist, and a PM-owned pre-ship safety gate. Grounded in the NIST AI RMF (Map/Measure/Manage), Google PAIR, and OWASP LLM guidance. Complements regulatory skills (ai-regulation, india-fintech, us-fintech) — those are legal; this is safety engineering.
Facilitate a structured sprint retrospective — what went well, what didn't, and prioritized action items with owners and deadlines. Use when running a retrospective, reflecting on a sprint, creating action items from team feedback, or learning how to run effective retros.
Reusable 3-round self-challenge + arbiter pattern for stress-testing a critical PM decision before it is finalized. Filters weak reasoning and false confidence from strategy, prioritization, spec, pricing, and gate decisions.
Plan a sprint with capacity estimation, story selection against Definition of Ready, dependency mapping, and risk identification. Produces a sprint goal + committed-scope summary with a 15-20% buffer. Use when preparing sprint planning, estimating team capacity, selecting stories, or balancing scope against velocity.
Build a stakeholder map using a power/interest grid, identify communication strategies per quadrant, and generate a communication plan. Use when managing stakeholders, preparing for a launch, aligning cross-functional teams, or planning stakeholder engagement.
Clarify brand messaging using narrative structure that positions the customer as hero. Use when the user mentions "brand message", "website copy", "elevator pitch", "one-liner", "messaging isnt resonating", "brand script", "StoryBrand framework", or "customer as hero". Also trigger when rewriting homepage copy, crafting email nurture sequences, or creating consistent messaging across sales collateral and marketing materials. Covers landing page copy, marketing collateral, and consistent commu...
Perform a detailed SWOT analysis — strengths, weaknesses, opportunities, and threats with actionable recommendations. Use when doing strategic assessment, competitive analysis, or evaluating a product or business position.
Playbook for change tickets — the format that makes a work item buildable and traceable; outcome title, why, scope, acceptance criteria, dependencies, evidence links. The upstream contract that pr-authoring's PR closes against.
Playbook for product decisions in US fintech — federal + state regulatory matrix, ECOA / Reg B adverse action, FCRA, MLA 36% APR cap, NMLS licensing, CFPB / OCC / state-DFI authority, PCI scope.
Playbook for planning and synthesizing user research — research questions, JTBD framing, interview-guide design, problem validation, and the leading-question traps to avoid. Used by user-researcher in the Discover stage.
Design a sharp value proposition using a 6-part JTBD template — Who, Why (problem/JTBD), What-before, How (solution), What-after, Alternatives. Use when articulating why a customer should choose this product over substitutes, assessing product-market fit, or producing a reusable value-prop statement for marketing/sales/onboarding.
Amazon's Working Backwards / PR-FAQ method — start from the customer problem and desired outcome, write the internal press release + FAQ BEFORE building. Use when defining a new product or major feature, evaluating competing ideas, aligning stakeholders, or forcing clarity on a vague concept before committing engineering resources.