Aakash GuptaUse these skills to supercharge your claude code setup | Oji Udezue | 3x CPO
CHAPTERS
- 0:00 – 1:36
Why mono-skilled PMs are becoming obsolete in the AI era
Oji frames the core thesis: product builders can’t rely on a single discipline anymore. He sets up the need for PMs to combine product judgment, business thinking, and coding/engineering fluency to keep up with AI-accelerated teams.
- •“Mono-skilled professionals” are falling behind
- •Future product builders blend business, product, and code skills
- •LLMs change the pace and expectations of building
- •This episode will demonstrate that future live
- 1:36 – 2:43
What you’ll learn: applying product + business skills inside Claude Code
Oji explains that most “AI skills” in repos focus on coding efficiency, but winning products require three layers: business, product, and code. The goal is to use Claude Code as a harness to run repeatable PM judgment workflows—not just generate code.
- •Most public skills optimize tokens/costs at the coding layer only
- •A successful tech company operates across business, product, and engineering layers
- •PM judgment can be made “on tap” via structured skills
- •Claude Code will be used like developers use it (not desktop chat)
- 2:43 – 4:45
Why PMs became the bottleneck when engineering speeds up
Drawing from consulting work, Oji describes how AI adoption accelerates developers first while PM cadence stays the same. He introduces Product Mind’s approach: encode product judgment frameworks as reusable skills so PMs can match engineering speed.
- •AI early adopters in engineering move faster; other functions lag
- •PMs often can’t “speed up” judgment and orchestration fast enough
- •Skills encode frameworks from real product practice and their book
- •Goal: retain quality (testing, architecture, CI) while moving faster
- 4:45 – 6:00
Live demo kickoff: ‘Code Memo’ idea and the scaffolding workflow
Oji proposes a product idea for vibe coders who can’t audit their AI-generated code. He kicks off the “new project scaffolding” skill, describing its 11-step workflow and the first gate: viability assessment before any heavy build-out.
- •Problem: code is produced faster than people can read/audit it
- •Target: vibe coders and teams lacking code review bandwidth
- •Scaffolding begins from a business problem statement
- •Workflow starts with a viability gate to decide if it’s worth pursuing
- 6:00 – 8:08
Inside the scaffolding skill: multi-skill orchestrator + web research
They open the scaffolding skill files to show it’s a master orchestrator calling subskills (market research, viability gate, testing setup, etc.). Oji explains it can fetch additional skills and run web search to ground outputs in current market reality.
- •Skill structure: master skill + subskills (market research, setup, etc.)
- •Can perform web search via tools (HTTP/Chrome)
- •Runs viability gate using structured PM frameworks
- •Emphasis: artifacts created in-repo, not just chat responses
- 8:08 – 11:30
Viability gate verdict and artifact generation (market research + brief)
The first idea passes the viability gate with flagged risks, and the workflow proceeds to market research and a product brief. Oji walks through the dimensions (revenue, feasibility, differentiation, competition, user definition, urgency) and highlights the depth of the generated docs.
- •Gate outputs: pass/fail plus weak/moderate/strong scoring
- •Six evaluation dimensions guide the decision
- •Market research doc includes competitors, pricing, trends, takeaways
- •Product brief defines problem, customers, value prop, success criteria
- 11:30 – 15:34
From product thinking to code: repo scaffolding, CI, quality, and CLAUDE.md
Oji explains why scaffolding matters for PMs and vibe coders: it bridges market/product decisions into a real, working repo with structure, tests, and delivery hygiene. The skill creates folder structure, prototypes, milestones, and a tailored CLAUDE.md to keep work organized and reproducible.
- •Produces a full repo: prototypes, milestones, docs, and structure
- •Generates a project-specific CLAUDE.md optimized for the repo patterns
- •Sets up testing + CI so every commit is checked
- •Adds security hygiene (e.g., secrets handling) and quality processes
- 15:34 – 20:31
How to read the skill step-by-step (sharp problem test vs viability gate)
They scroll through the scaffolding file to understand each step and how it calls other skills. Oji distinguishes the viability gate (is there a lane?) from the sharper “sharp problem test” (is it meaningfully valuable and monetizable), and warns that LLM output must be reviewed, not treated as gospel.
- •Workflow phases: context gathering, project typing, reference projects, gate
- •Viability gate can explicitly say “no” (unlike typical LLM cheerleading)
- •Sharp problem test goes deeper on value creation and money-making potential
- •Best practice: use as a first draft, then audit outputs and assumptions
- 20:31 – 24:22
Second run: ‘Standup Zero’ idea—LLM as first-draft judgment, not authority
Oji runs the scaffolding skill on a second idea: a Slack-based standup digest. They discuss what should be outsourced to LLMs: use structured frameworks to get a rigorous first pass, then validate and refine with human judgment and additional research.
- •Skill asks clarifying questions when context is insufficient
- •LLM value is systematic evaluation vs. generic encouragement
- •Outputs include a viability document you should inspect and challenge
- •Use it to quickly identify de-risking work and unknowns
- 24:22 – 31:28
For existing products: ‘Vet a Feature’ skill for opportunity-cost decisions
Aakash asks about applying the approach beyond new products. Oji introduces “Vet a Feature,” a skill designed to pressure-test feature ideas within an existing roadmap, focusing on anti-patterns, confidence, and whether it’s worth building relative to alternatives.
- •Most PM work is feature work, not greenfield products
- •Vet a Feature evaluates opportunity cost and prioritization tradeoffs
- •Bakes in sharp problem thinking more heavily
- •Designed to “tear apart” ideas to avoid wasted build cycles
- 31:28 – 36:48
Applying PM judgment on outputs: how to review market research and the brief
They return to the Code Memo artifacts and demonstrate how a PM should evaluate credibility and completeness. Oji describes scanning for current competitors, checking differentiation maps, and doing a PRD-style critique of personas, scope choices, and consistency between research and the brief.
- •Review like a PRD meeting: credibility, completeness, and consistency
- •Check whether competitor set is current and relevant
- •Challenge persona definitions (e.g., founder size, corporate fit)
- •Use the brief to identify what’s missing and what needs validation
- 36:48 – 39:45
Standup Zero fails (or barely clears) the gate: why “don’t build” is valuable
They inspect the Standup Zero viability assessment, which flags weakness: shallow urgency, crowded competition, and weak differentiation. Oji emphasizes the benefit of being told “this is hard to win” before investing in code—protecting time and focus from building products that won’t find customers.
- •Moderate/weak scores indicate risk: convenience problem, not deep pain
- •Strong competition can be a negative signal for new entrants
- •Weak differentiation implies low defensibility
- •Early “no” saves effort versus building and languishing with no users
- 39:45 – 51:59
Prototypes + customer discovery plan: moving from ‘lane’ to real validation
With Code Memo proceeding, Oji triggers prototype generation to explore interaction models and runs a customer discovery week skill to validate assumptions with real users. The discovery plan includes scripts, a three-step interview flow, and a hard gate: you need recruitable target users, not just adjacent contacts.
- •Prototype generation explores UI patterns (dashboard, drill-down, narrative)
- •Interaction model decisions tie directly to the aha moment
- •Customer discovery week: interviews → structured questions → survey data
- •Skill blocks progress without evidence of real recruitable cohorts
- 51:59 – 55:31
The three-speed problem: code accelerates, but ‘why’ and ‘go-to-market’ lag
Oji explains the imbalance created when development speed increases 10–20x while customer discovery and distribution remain customer-bound. He argues teams should collapse shared context into a single repo so business, product, and code stay synchronized and everyone can run the same skills.
- •Historically the long pole was development; AI compresses it dramatically
- •Customer discovery and distribution still require real market contact
- •Fast shipping without adoption creates churn and redesign cycles
- •One repo can unify product docs + code + tests as shared team context
- 55:31 – 1:04:41
Where to get the skills + rollout pitfalls: shared context and governance
Oji points to Product Mind’s skills library and highlights additional favorites beyond scaffolding (Vibe Memo, roadmap from strategy, listening machine, scope cutter, pricing). He closes with an enterprise lesson: avoid uncontrolled forking—centralize and continuously refine shared CLAUDE.md and skills so one person’s learning becomes everyone’s learning.
- •Access via skills.productmind.com and an open-source skills library
- •Notable skills: Vibe Memo (capture the “why”), listening machine, scope cutter
- •Harness/tooling is flexible (Antigravity is just an interface)
- •Biggest pitfall: ungoverned AI rollout—lack of shared context and standards
