Twelve pillars. Eighteen modules. Everything a product decision touches.
Nothing here is theory for its own sake. The pillars are the capability map; the modules are how you work through it, and each one leaves you with an artefact that goes into your build and then your portfolio.
One programme. The complete Product Management journey.
Understand customers, problems and markets.
Turn problems into product opportunities.
Determine where and how to compete.
Create experiences people want to use.
Translate strategy into products and AI systems.
Take products to market.
Measure, experiment and scale.
Influence organisations and make strategic decisions.
One skill stack. Read it through your own job.
Twelve pillars, the same for everyone — because the product system is the same. What changes is what each pillar asks of you and what you produce.
Know what you own, and say no to work that isn't yours.
- Product Management
- Product vs Project vs Programme
- PM/PO responsibilities
- Product operating models
- Product lifecycle
A one-page definition of the outcome you own
Use AI to map an operating model and spot where decisions actually get made.
Replace 'stakeholders asked for it' with evidence from real users.
- Voice of the customer
- Customer research
- Jobs to be Done
- Personas
- Journey mapping
- Problem discovery
- Problem validation
Interview findings and a validated problem statement
Synthesise interview transcripts into themes and quote evidence in minutes.
Argue your roadmap from market reality, not internal opinion.
- Market research
- TAM/SAM/SOM
- PESTLE
- Porter's Five Forces
- Competitive strategy
- AI-powered research
A sized market and competitive map
Run market and competitor research in hours instead of weeks.
Decide where to play and what to refuse — and write it down.
- Vision
- Mission
- Strategy
- Strategic choices
- Positioning
- OKRs
- Strategic alignment
A one-page product strategy with OKRs
Pressure-test strategic choices against competitor moves and scenarios.
Turn a problem into a scoped, defensible thing to build.
- Opportunity discovery
- Prioritisation
- MVP
- Hypotheses
- PRDs
- User stories
- Acceptance criteria
A PRD and a prioritised scope
Draft PRDs, acceptance criteria and edge cases from a problem statement.
Brief and critique design work without designing it yourself.
- Design thinking
- UX
- User journeys
- Information architecture
- Prototyping
- Usability testing
User flows and a tested prototype
Generate and iterate on prototypes fast enough to test the same week.
Specify an AI feature and know when it is good enough to ship.
- AI/ML fundamentals
- LLMs
- RAG
- Agents
- Prompt engineering
- AI UX
- Evaluation
- Guardrails
- Responsible AI
An AI capability spec and evaluation plan
This pillar is the AI accelerator — how AI products are specified and judged.
Hold your own in a technical trade-off conversation.
- APIs
- Data
- Cloud concepts
- AI architecture
- Integrations
- Security
- Privacy
- Scalability
A solution architecture diagram you can explain
Use AI to explain, diagram and interrogate an architecture you didn't write.
Build the business case that gets your work funded.
- Business models
- SaaS
- Platform models
- Pricing
- Unit economics
- Business cases
- ROI
- Financial modelling
A business model canvas with real numbers
Go from assumptions to financial projections without building a spreadsheet first.
Know whether what you shipped actually worked.
- Product analytics
- North Star metrics
- Funnels
- Retention
- Experiments
- A/B testing
- Growth loops
- Network effects
A measurement plan and dashboard
Interrogate product data in plain language and surface what moved.
Land the launch instead of handing it to marketing and hoping.
- Positioning
- Messaging
- Go-to-market
- Launch strategy
- Beta
- Rollout
- Adoption
A GTM plan with channels and messaging
Draft, test and sharpen positioning and messaging against real objections.
Get a decision made when you have no authority to make it.
- Stakeholder management
- Negotiation
- Executive communication
- Decision-making
- Influence
- Product leadership
A stakeholder and influence plan
Rehearse the hard conversation and stress-test your argument before the room.
18 modules. One complete
product, built to launch.
Same eighteen modules for everyone. What changes is how deep each one runs for you and why it matters to the job you are doing.
Name the outcome you own so you can refuse work that isn't it.
Replace stakeholder opinion with evidence you can point at.
Argue the roadmap from market reality, not internal politics.
Decide where to play and write down what you refuse.
Turn a noisy backlog into a ranked set of bets.
Build the case that gets your feature funded.
Turn a problem into a scoped, defensible thing to build.
Brief and critique design work without doing it yourself.
Specify an AI feature and know when it is good enough to ship.
Hold your own in a technical trade-off conversation.
Prove the concept yourself instead of queueing for a team.
Know whether what you shipped actually worked.
Understand the margin your feature helps or hurts.
Land the launch instead of handing it over and hoping.
Sequence a rollout that doesn't burn trust.
Get decisions made when you have no authority to make them.
Run a roadmap that survives contact with the quarter.
Turn the work into the case study that gets you hired.
The same situation. A different call, depending on your job.
Short decision exercises used through the curriculum. Read one and you can feel where the tracks separate.
A clinical documentation tool has strong sign-ups and almost no second week. Clinicians say they like it.
Do you improve what exists, or accept the tool solves the wrong moment in the day?
You run five interviews and rewrite the problem statement before touching the roadmap.
Every order loses eighty pence. Growth is up thirty percent and the board is delighted.
Do you keep growing, raise prices, or cut the segment that loses the most?
You model the three options and show which one reaches break-even first.
An internal AI assistant answers confidently and is wrong roughly one time in eight.
Do you ship with a confidence warning, restrict scope, or hold until accuracy improves?
You set the evaluation threshold and define what 'good enough to ship' means.
A new onboarding flow lifts completion by twelve percent and drops ninety-day retention.
Do you keep the flow, roll it back, or split the difference?
You check whether you optimised the wrong metric and change the North Star.
A sponsor demands a fixed date for an AI feature whose accuracy is still unproven.
Do you commit, refuse, or offer something else?
You offer a date for a narrower capability and evidence for why.
A well-built product launches to silence. The team blames marketing; marketing blames positioning.
Do you relaunch, reposition, or change who you sell to?
You test the positioning against real objections before spending again.
Illustrative teaching examples built from the capstone worlds, not accounts of named clients.
Not a certificate. Evidence of capability.
The AI Product Coach
Bring an idea. The coach pushes back before you build — then evaluates your answers against the way real product decisions get made.
Let's validate it before you build it.
- → Who is the user?
- → What problem are they experiencing?
- → How frequently does it occur?
- → What are they doing today?
- → What alternatives exist?
- → Why would AI make this better?
Each framework: Learn → Example → Template → AI Assistant → Apply to your product.