Career roadmap
Technical Product Manager
Decide what gets built and why, close enough to the engineering to be trusted by the people building it.
Before you start Technical PM
- Understanding of how software is built
- Clear writing
- Comfort with data and SQL basics
Discovery and problem definition
Most product failure is building the wrong thing well.
Talking to users is the input nothing else substitutes for.
- Interview technique and avoiding leading questions
- Synthesis and pattern finding
- Jobs to be done framing
- Distinguishing stated from revealed preference
A well-framed problem makes the solution obvious and the scope defensible.
- Problem statements without embedded solutions
- Opportunity sizing
- Assumption identification
- Deciding not to solve it
Technical PMs are expected to pull their own numbers.
- SQL for product questions
- Funnel and retention analysis
- Instrumentation requirements
- Reading experiment results critically
Understanding why now, and why you rather than an incumbent.
- Competitive analysis
- Positioning and differentiation
- Pricing and packaging basics
- Build versus buy versus partner
Cheap tests before expensive builds.
- Prototypes and concept testing
- Fake door and demand tests
- Pilot design
- Killing an idea early and well
BuildRun a discovery cycle on a real problem: interviews, synthesis and a written problem statement.
Technical fluency
The distinguishing half of the role: credibility with engineers.
Enough to reason about feasibility, cost and trade-offs without needing a translator.
Ch — Scalable APIs- Services, databases and queues
- Latency and scale basics
- Trade-offs engineers actually face
- Reading an architecture diagram
API products have developers as users, which changes everything about the work.
- API design principles and versioning
- Developer experience as a product metric
- Documentation as a deliverable
- Deprecation and migration policy
Advocating for work with no visible feature is a core technical PM skill.
- Framing debt in business terms
- Reliability and performance as features
- Security and compliance requirements
- Balancing investment against roadmap
Now expected: knowing what AI can reliably do and what it cannot.
Ch — LLM Fundamentals- Where probabilistic output is acceptable
- Evaluation and quality thresholds
- Cost per interaction modelling
- Setting user expectations honestly
The main artefact. Interviews frequently ask for a writing sample.
- Requirements without over-specifying design
- Edge cases and error states
- Acceptance criteria
- Keeping specs current as things change
BuildWrite a technical specification for a real feature, including API design and failure cases.
Prioritisation and delivery
Deciding what not to do, and getting the rest shipped.
Frameworks are a communication tool, not a decision oracle.
- Impact, confidence and effort scoring
- Opportunity cost reasoning
- Saying no with reasons
- Handling executive pet projects
A roadmap is a communication artefact, not a delivery commitment.
- Outcome-based roadmaps
- Communicating uncertainty in dates
- Now, next, later framing
- Roadmap for different audiences
Cutting scope without cutting value is the daily craft of the role.
- Vertical slicing of features
- Minimum viable versus minimum lovable
- Phased delivery
- Recognising scope creep
The mechanics of delivery, and the anti-patterns to avoid.
- Backlog refinement that engineers value
- Estimation and its limits
- Sprint and continuous delivery models
- Being available without micromanaging
Shipping is the start of learning, not the end of the project.
- Launch planning and rollout stages
- Success metrics defined beforehand
- Post-launch iteration
- Deciding to roll back or persevere
BuildBuild and defend a quarterly roadmap with explicit trade-offs and things you cut.
Influence and communication
PMs have no authority. Everything happens through persuasion and clarity.
The highest-leverage PM skill, and increasingly assessed directly.
- Strategy and one-page documents
- Structuring an argument
- Writing for executives
- Concise, unambiguous requirements
Alignment before decisions, not after them.
- Mapping stakeholders and interests
- Pre-alignment before meetings
- Managing conflicting priorities
- Escalating well
Choosing the metric shapes the behaviour of the whole team.
- North star and supporting metrics
- OKRs that are not vanity
- Guardrail metrics
- Reporting progress honestly
Design, sales, support and legal all have legitimate claims on the roadmap.
- Working with design
- Supporting sales without becoming sales-led
- Support and success feedback loops
- Legal and compliance constraints
Interviews probe this heavily, because it is most of the job.
- Disagreeing with engineering estimates
- Cutting a feature someone championed
- Missing a committed date
- Handling a failed launch
BuildWrite and present a strategy document to a real audience and act on the feedback.
Interview preparation
PM loops are case-heavy: product sense, technical depth, execution and behavioural.
Design a product for a given user. Structure is what is graded.
- Clarifying the problem and user
- Generating and narrowing solutions
- Prioritising with stated criteria
- Defining success metrics
The round that separates technical PMs from general PMs.
- Explaining a system at a whiteboard
- API design discussion
- Feasibility and trade-off reasoning
- Discussing failure modes
Metrics dropped. Diagnose it, with SQL if asked.
- Metric diagnosis frameworks
- SQL for product questions
- Experiment interpretation
- Choosing metrics for a feature
How you handle a slipping project or a scope conflict.
- Recovering a late project
- Prioritisation under constraint
- Managing a difficult stakeholder
- Trade-off decisions with reasoning
Written artefacts and shipped outcomes with numbers.
- A published product document
- A case study with measured impact
- A technical spec you wrote
- Evidence of a decision you reversed
BuildA portfolio of two written product documents and one case study of something you shipped.
Technical PM tools on your CV
- SQL
- Amplitude / Mixpanel
- Figma
- Jira / Linear
- Notion
- Experimentation platforms
What Technical PM employers ask to see
- A published product strategy document
- A technical specification with API design and failure cases
- A shipped feature case study with measured outcomes
- An experiment you designed and the decision it drove
Named in demand surveys alongside IT project management. Platform, API and infrastructure products specifically need PMs who can hold a technical conversation.
Content last reviewed 2026-08-31. Guidance only — no institute or paid placement is endorsed anywhere in this book.