Books › Product Engineer roadmap

Best books for Product Engineers

This list is for building a product, not just a feature. It starts with how good teams decide what to build and how to talk to customers before writing code. The middle books cover measurement and experiments, so you can say whether a change worked. The lead books are about influence and systems thinking once you own a product area across several teams.

10 books in 3 stages, about 2,160 pages (at least 54 hours of reading). The notes are ours, with no ratings or sales claims.

See the full Product Engineer roadmap →Best courses for Product Engineers →

How to choose your books

A short method, so you read the right book for where you are instead of the longest list.

Find your stage

  • Getting started · 3 books

    Product thinking and customer evidence: how teams decide what to build, and how to test an idea before committing engineering time.

    Jump to this stage ↓
  • Doing the job · 5 books

    Measuring and shipping: experiments, metrics, validating ideas with users and the data trade-offs behind the product.

    Jump to this stage ↓
  • Senior and leading · 2 books

    Owning outcomes across teams: the senior technical track, and the systems view that explains why a product behaves the way it does over time.

    Jump to this stage ↓

If you are unsure, start one stage lower than you think. Books in a later stage assume the working knowledge the earlier ones give you.

Begin with one book

Our starting pick

Inspired

by Marty Cagan · 2017

It sets out what product teams are for: solving customer problems with technology, and how to tell good product decisions from busy ones. Read it before anything else on the list.

See the book ↓

Then pick by your situation

Choose the next book by the problem in front of you, not by its place in the list.

Set a time budget

StageBooksPagesReadingAt 3 hrs a week
Getting started375019 hrs6 wks
Doing the job5≥ 1,410≥ 35 hrs≥ 12 wks
Senior and leading2n/an/an/a
All 3 stages10≥ 2,160≥ 54 hrs≥ 18 wks

Treat this as a ceiling, not a target. Read one book at a time, apply it, then move on; read reference-style books in sections. Totals are approximate.

Judge any book before you buy it

  • Age

    This list runs from 2008 (Thinking in Systems) to 2021 (Continuous Discovery Habits). Older books earn their place by teaching principles that do not change. For tools and platforms, buy the latest edition.

  • Level

    Check the stage before the title. A book from a later stage will make sense only once you have faced the problems it solves.

  • Format

    The longest book here, Designing Data-Intensive Applications, runs about 620 pages. Read very long books as references: pick the chapter that matches the problem you have.

  • Fit

    Ask what you will do differently the week after you finish. If you cannot answer, the book is for a different moment. Come back to it when the situation arrives.

Getting started

Product thinking and customer evidence: how teams decide what to build, and how to test an idea before committing engineering time.

  • Cover of Inspired
    Start here

    Inspired

    by Marty Cagan · 2017

    ~370 pages~9 hrs to read

    How good product teams pick what to build and test assumptions before committing engineering time. Read it early so you can take part in those decisions instead of receiving tickets.

    View book →
  • Cover of Continuous Discovery Habits

    Continuous Discovery Habits

    by Teresa Torres · 2021

    ~240 pages~6 hrs to read

    A weekly routine for talking to customers and testing ideas in small steps. It shows how a product engineer can keep learning from users while the sprint keeps moving.

    View book →
  • Cover of The Mom Test

    The Mom Test

    by Rob Fitzpatrick · 2014

    ~140 pages~4 hrs to read

    How to ask customers questions that produce honest answers. Short and practical, and the habit it teaches is useful for any feature you propose.

    View book →

Doing the job

Measuring and shipping: experiments, metrics, validating ideas with users and the data trade-offs behind the product.

  • Cover of Escaping the Build Trap

    Escaping the Build Trap

    by Melissa Perri · 2018

    ~180 pages~5 hrs to read

    Why teams ship a lot of output without outcomes, and how to tie work to the customer and business results it should move. Useful once you own a product area.

    View book →
  • Cover of Lean Analytics

    Lean Analytics

    by Alistair Croll, Benjamin Yoskovitz · 2013

    ~410 pages~10 hrs to read

    Choosing the one metric that matters at each stage of a product and building the measurement around it. A practical companion for experiments and dashboards.

    View book →
  • Trustworthy Online Controlled Experiments

    by Ron Kohavi, Diane Tang, Ya Xu · 2020

    ~200 pages~5 hrs to read

    A practitioner's guide to A/B testing: how to design experiments, avoid misleading results and trust the numbers that come out of them.

    View book →
  • Cover of Designing Data-Intensive Applications

    Designing Data-Intensive Applications

    by Martin Kleppmann · 2017

    ~620 pages~16 hrs to read

    The trade-offs behind databases, replication and streaming systems. Product engineers who make data decisions need this vocabulary to explain costs to their team.

    View book →
  • Sprint

    by Jake Knapp, John Zeratsky, Braden Kowitz · 2016

    A five-day process for testing a product idea with real users before building it. It is a clear model for the validate-then-build loop this role depends on.

    View book →

Senior and leading

Owning outcomes across teams: the senior technical track, and the systems view that explains why a product behaves the way it does over time.

  • Staff Engineer

    by Will Larson, Tanya Reilly · 2021

    What the senior technical track asks for: scope, influence and judgment rather than more code. Useful once you are responsible for a product area across several teams.

    View book →
  • Thinking in Systems

    by Donella H. Meadows, Diana Wright · 2008

    How feedback loops, delays and incentives shape what a product does over time. It helps leads reason about the second-order effects of the features they approve.

    View book →

Book links go to Amazon and are affiliate links. As an Amazon Associate I earn from qualifying purchases.

Frequently asked questions

Which book should a Product Engineer read first?

Inspired by Marty Cagan. It sets out what product teams are for: solving customer problems with technology, and how to tell good product decisions from busy ones. Read it before anything else on the list.

Do I need to read all 10 books?

No. The list is a menu, not a syllabus. Find your stage (getting started: 3, doing the job: 5, senior and leading: 2), begin with one book (we suggest Inspired), then pick the next book by the problem you are facing at work. Come back to the others when the situation they cover arrives.

How long does it take to read these books?

The 7 books with a known page count add up to about 2,160 pages, roughly 54 hours at 1.5 minutes a page. At three hours a week that is about 18 weeks; at six hours a week, about 9. The list is meant to be read over time, one book at a time, not in one run.

Are these books up to date?

They range from 2008 (Thinking in Systems) to 2021 (Continuous Discovery Habits). Older titles are included because they teach principles that have not changed; for tools and platforms, we favor recent editions. Check the edition before you buy.

Some links are affiliate links: we earn a small commission if you buy, at no cost to you. It does not change what we list.