CHAPTERS
- 0:00 – 2:43
Why mono-skilled PMs are becoming obsolete: product, business, and code as one stack
The episode opens with the claim that being “mono-skilled” is no longer enough, and frames the future PM as a multi-layer builder. Oji and Aakash set up the central question: how to blend product judgment and business thinking with modern AI coding harnesses like Claude Code.
- •Mono-skilled professionals are losing leverage in an AI-accelerated world
- •A tech company operates on three layers: business, product, and software/hardware
- •The episode will focus on more than code—embedding product judgment and business skills
- •Core tension introduced: what should be outsourced to LLMs vs owned by humans
- 2:43 – 3:44
The bottleneck shifts: engineers speed up, PM judgment must match
Oji explains what ProductMind sees in consulting: engineering velocity rises quickly with AI, while PM workflows lag behind. He introduces “product judgment skills” as a way for PMs to operate at engineering speed without sacrificing rigor like testing and quality.
- •AI boosts developers first; everyone else risks becoming the bottleneck
- •PMs need to accelerate orchestration and product judgment, not just documentation
- •Skills can encode frameworks to standardize and speed decision-making
- •Goal: keep code fidelity (tests, CI, quality) while moving faster
- 3:44 – 4:44
Inside the 'New Project Scaffolding' skill: an 11-step orchestrator
Oji introduces the flagship skill: New Project Scaffolding. It begins from a business problem, runs a viability gate, performs market research, produces product artifacts, and then scaffolds a working repo with architecture and CI/CD basics.
- •Scaffolding starts with a business problem, not a code prompt
- •Runs a viability gate to decide whether the project is worth doing
- •Performs market research and writes a product brief before coding
- •Makes architecture decisions, testing setup, and CI/CD part of the default flow
- 4:44 – 6:00
Demo setup: building 'Code Memo' to help vibe coders audit their code
Oji proposes a product idea: a SaaS/agent that evaluates code quality for people who generate code but don’t read it. He runs the scaffolding workflow in Claude Code to see whether the idea is viable and how it gets turned into structured artifacts.
- •Problem: code is produced faster than anyone can review or understand
- •Target users include vibe coders and non-technical builders needing safety/quality checks
- •Claude Code is used like a developer tool (not desktop chat) to run workflows
- •The workflow begins by loading an 11-step process and entering viability gating
- 6:00 – 8:42
Opening the hood: master skill + sub-skills (market research, testing, fetching skills)
Aakash asks to inspect the scaffolding file, revealing it as a multi-skill orchestrator. Oji explains it has a master skill definition and sub-skills that handle tasks like market research, generating docs, testing setup, and pulling additional skills when needed.
- •Skill architecture: master skill.md plus modular sub-skills
- •Sub-skills can do market research and fetch new skills based on project type
- •Workflow is designed to produce artifacts and repo structure automatically
- •The viability gate is the central early checkpoint to prevent wasted effort
- 8:42 – 12:09
Viability gate in action: passing the idea, then deep market research + product brief
The viability gate passes for Code Memo, and the system proceeds to market research and a product brief. Oji walks through the dimensions evaluated (revenue, feasibility, differentiation, competition, target user, urgency) and shows the generated documents.
- •Viability gate returns strengths/moderates and flags de-risking items
- •Evaluation dimensions include revenue, feasibility, differentiation, and user clarity
- •Market research doc includes trends, competitors, pricing, adjacent products
- •Product brief codifies problem, personas, value prop, and success criteria
- 12:09 – 15:43
Why scaffolding matters for PMs and vibe coders: repo bones, CI, tests, security
Oji explains the practical payoff: scaffolding creates a real repo with folder structure, prototypes, milestones, and quality rails. It helps non-engineers avoid common pitfalls like missing CI, weak testing, and secret leakage when pushing to GitHub.
- •Produces a full repo: prototypes folder, milestone structure, docs package
- •Sets up CI/testing so every commit is validated
- •Adds security hygiene (e.g., secrets handling) for GitHub pushes
- •Bridges handoff gaps: architecture, testing strategy, and build quality baked in
- 15:43 – 20:31
How the workflow is defined: steps, sharp problem test vs viability gate, and 'LLMs must say no'
They scroll through the scaffolding skill steps and clarify how it calls embedded frameworks. Oji distinguishes the viability gate from the deeper sharp problem test and emphasizes the critical feature: the system is designed to reject bad ideas.
- •Workflow stages: context gathering, project type, references, viability gate, research
- •Viability gate is a compressed sharp problem test focused on ‘is there a lane?’
- •Sharp problem test goes deeper (e.g., value magnitude and monetization realism)
- •A key design goal: unlike typical chat, the skill is allowed to tell you ‘don’t do this’
- 20:31 – 24:22
Second demo: 'Standup Zero' and the question of outsourcing PM thinking to LLMs
Oji runs scaffolding on a second idea (Slack standup digest) while Aakash asks what PM thinking should be delegated to LLMs. Oji positions these skills as a structured first draft with explicit evals—useful, but not something to accept blindly.
- •The system asks clarifying questions when inputs are insufficient
- •Skills are meant to counter the ‘LLMs always say yes’ problem
- •Outputs should be reviewed; trust requires human judgment and verification
- •Best use: fast first draft that can recommend no and highlight de-risking work
- 24:22 – 31:28
Beyond new products: 'Vet a Feature' and opportunity-cost-aware product judgment
Aakash asks whether the approach applies to features inside existing products. Oji introduces a feature-specific skill that stress-tests ideas, looks for anti-patterns, and weighs opportunity costs more explicitly than new-product scaffolding.
- •Most PM work is feature evolution, not greenfield products
- •Vet a Feature skill evaluates build-worthiness among alternatives
- •Looks for anti-patterns, confidence gaps, and sharp problem signals
- •Encourages consistent rigor rather than skipping fundamentals under time pressure
- 31:28 – 36:54
Reviewing AI artifacts like a PM: credibility checks on market research and the brief
Oji demonstrates how to apply PM judgment on top of generated documents. He outlines a practical review method: sanity-check competitor sets, freshness, differentiation maps, and ensure the brief matches the market evidence and missing personas are addressed.
- •Start review with market research + product brief; other docs may be boilerplate
- •Credibility signals: current tools, relevant competitor set, plausible positioning
- •Use a ‘PRD review room’ mindset to validate assumptions and omissions
- •Identify missing persona nuance (e.g., company size differences) and refine accordingly
- 36:54 – 39:32
The rejection case: Standup Zero gets weak/moderate scores and warns of commoditization
They inspect the Standup Zero viability scorecard, which flags weaknesses and intense competition. Oji explains how this prevents waste: many builders ship code with no customers, and a fast ‘no’ saves attention and time.
- •Standup Zero receives weak/moderate scores and ‘proceed with eyes open’ guidance
- •Issues: shallow urgency, unclear target, heavy competition, weak differentiation
- •Highlights defensibility challenges: others can build the same thing easily
- •Frames this as a cure for building-first behavior that leads to unused GitHub repos
- 39:32 – 51:59
From viable idea to product layer: interaction model decisions, prototypes, and discovery planning
With Code Memo favored, Oji moves to product execution: clarify the interaction model and generate quick prototypes, while also launching a customer discovery plan. The skills produce multiple HTML/CSS prototype directions and a structured discovery-week plan with gates.
- •Next step after viability: define interaction model and value delivery loop
- •Prototype generation is used to explore UI patterns quickly
- •Customer discovery week skill creates scripts, surveys, synthesis templates, and timeboxes
- •Discovery plan enforces a hard requirement: recruitable target users (not vague contacts)
- 51:59 – 55:31
The three-speed problem and collapsing tools into one repo: shared context as the operating system
Oji explains the “three-speed problem”: coding accelerates dramatically, but customer-bound discovery and go-to-market don’t. The answer is compressing workflows and artifacts into a shared GitHub repo (docs + code) so teams operate with one context and higher throughput.
- •Development speed is shrinking 10–20x, creating imbalance with customer-bound work
- •PM/design/business artifacts must move faster to avoid becoming the constraint
- •Collapsing Notion/Figma/document silos into a GitHub repo creates shared context
- •Skills can build feedback loops and operational rigor directly into the build workflow
- 55:31 – 1:04:41
Where to get the skills and how to roll them out safely: governance and a shared Claude.md
Oji shares where the open-source skills library lives and highlights standout skills like Vibe Memo, roadmap-from-strategy, scope cutter, and pricing. He closes with rollout pitfalls: avoid uncontrolled forks, harmonize skills to company SDLC artifacts, and maintain shared context via a centralized Claude.md.
- •Skills are accessible via productmind labs and an open-source skills library
- •Notable skills: Vibe Memo (capture the ‘why’), roadmap-from-strategy, listing machine, scope cutter
- •Harness is flexible (VS Code forks like Antigravity are optional)
- •Enterprise rollout needs governance: central Claude.md, consistent artifacts, and shared learning over forks
