Why Don’t Data Leaders Read Product Management Books?
Seven books that every data leader should read
Last week, I participated in a DAMA Norway book club session to present my book, Data as a Product Driver 🚚. The last question they asked me got me thinking afterwards.
The question was something like, “What were your sources of inspiration when writing the book?” And then I mentioned that I had read many books on data, as well as on product management, and I cited some authors: Teresa Torres, Marty Cagan, Itamar Gilad…
Afterwards, I thought that as a data professional with years of experience, I don’t think people in this field typically read many product-focused books, which is why I’ve decided to expand on the answer in this blog post.
The Wrong Books for the Real Problems
I started reading Product Management-type books because the problems killing the data teams I was managing weren’t actually architectural or data-related. They were organizational. And data books don’t teach you how to fix organizational problems.
Let’s dig a little deeper.
Data books teach you how to build things. How to model data. How to architect platforms. How to choose technologies. These skills matter—you need technical depth to be credible.
But here’s what they don’t teach you: how to decide what’s worth building. How to organize teams for impact. How to measure value instead of output. How to make product teams actually want to work with you.
That second part is what determines whether your data team succeeds or becomes an expensive ticket queue.
I’m not saying data books are useless. But once you understand data modeling and platform architecture, your biggest problems aren’t technical anymore. They’re about team structure, goal setting, and decision-making.
And the best books about those topics? They’re not in the data section.
Seven Books That Changed How I Lead Data Teams
Building on the last question I got in the book club session, here are seven product (and platform) management books that have fundamentally changed how I lead teams:
Escaping the Build Trap (2018) by Melissa Perri’s
Transformed (2024) by Marty Cagan
Evidence-Guided (2023) by Itamar Gilad
Continuous Discovery Habits (2021) by Teresa Torres
The Manager’s Path (2017) by Camille Fournier
Empowered (2020) by Marty Cagan
Team Topologies (2019) by Matthew Skelton and Manuel Pais
Here’s what each taught me that no data book did.
Outcomes Over Outputs: Escaping the Build Trap and Transformed
Two books taught me that the fundamental problem with most data teams is that we measure the wrong things and organize around the wrong boundaries.
Melissa Perri’s “Escaping the Build Trap” defines the problem clearly: “Outputs are easily quantified things that we produce. Outcomes are the things that result when we finally deliver those features, and the customer problems are solved.”
Data teams set goals on pipeline uptime, number of dashboards, and query performance, but they don’t tell you if you’re creating value.
An output is a dashboard. An outcome is faster decision-making because the right people can see the right metrics at the right time. An output is a machine learning model. An outcome is reduced fraud that saves money. I’ve written about this in depth in a previous article:
Perri also challenges how we organize: “Most data teams organize by technical layer: data engineering, analytics, data science. But value flows through customer journeys: acquisition, activation, retention, monetization. What if you organized data teams around these value streams instead?”
On the other side of the same coin, Marty Cagan’s “Transformed” goes deeper into what actually needs to change. The book frames transformation along three dimensions:
Changing how you build: Moving from projects to products. Stop creating “orphaned features” that never get iterated on because you’ve moved to the next project.
Changing how you solve problems: Give teams problems to solve, not features to build (same as Perri): “Instead of stakeholders prioritizing their perceived solutions and providing these in the form of a roadmap to a feature team, now the product team is assigned problems to solve, and the product team is empowered to discover a solution.”
Changing how you decide which problems to solve: Use an insight-driven strategy, not opinion-driven roadmaps.
Cagan also emphasizes direct access to data: Give product teams direct access to data. Build self-service tools. Your job as a data team shifts from running every query to helping teams ask better questions.
In the companies I worked with, teams reorganized from functional units (all analysts together, all engineers together) to domain-aligned teams. The growth team got its own analyst and data engineer focused only on acquisition and activation. Data people started learning the business in depth, rather than supporting 4 different areas superficially.
Discovery and Evidence: Evidence-Guided and Continuous Discovery Habits
Once you’re organized around outcomes in cross-functional product teams, how do you decide what to build? Two books taught me that.
Itamar Gilad’s “Evidence-Guided” introduced me to the GIST model (Goals, Ideas, Steps, Tasks) and changed the way I structure my work. Most data teams jump straight to tasks: “Build this dashboard.” But what’s the goal? What idea are we testing? What steps validate whether this is worth doing?
The book’s key principle is to think about Ideas to fulfill outcome-based Goals and then validate those ideas using Steps and Tasks.
The Steps part is key because before I used to jump from Idea to Tasks, but Steps help product teams gather evidence and assess its quality.
An executive’s opinion is weak evidence. Competitor behavior is slightly stronger. User interviews are stronger still. A/B test results with statistical significance are the strongest evidence.
Each of these items is a validation Step, like a data analysis or a fake door test. Success is measured differently: it’s not about producing code; it’s about learning something that informs the next decision.
And by the way, Itamar wrote the Foreword for my book, Data as a Product Driver 🚚.
Teresa Torres’ “Continuous Discovery Habits” reinforces this with structured discovery techniques for product teams. The key being product discovery isn’t a phase you do once; it’s a habit you practice continuously.
When data people are embedded in product teams using these frameworks, they run small experiments to test assumptions. They help structure discovery interviews to combine qualitative insights with quantitative data, and they do it weekly, not once per quarter.
After reading these books, I adopted ICE scoring for data product ideas. Embedded analysts and data scientists started owning discovery work alongside product managers.
Managing Empowered Teams: The Manager’s Path, Empowered, and Team Topologies
The last group of books helped me manage product teams, both teams that build customer-facing features and teams that maintain internal platforms.
Camille Fournier’s “The Manager’s Path” gave me a foundational understanding of engineering management: what it means to manage humans, how to shield teams, provide context, and foster a high-performing, psychologically safe environment.
Marty Cagan’s “Empowered” focuses specifically on managing product teams and the work of the product leaders in the team (Product, Engineering, Design, and, as I posted in previous articles, Data).
Cagan emphasizes that coaching is job #1: “If you are a manager, you should be spending most of your time and energy on coaching your team.”
Finally, “Team Topologies” by Matthew Skelton and Manuel Pais gave me a framework for structuring teams for flow.
If you want decentralized analytics, don’t centralize all your analysts. If you want product teams to own their data quality, don’t create a separate data quality team that “owns” it for them. Your org structure determines what you can build.
The book identifies four team types. Data teams map to these:
Stream-aligned teams: Embedded data people working with a specific product team or business domain. This should be your primary pattern. The analyst or data scientist on the growth team, and the data engineer supporting the payments domain. Their job is to enable the fast flow of value in their domain.
Platform teams: Your data platform team providing self-service tools and infrastructure. They reduce cognitive load by handling the complex technical foundation: data pipelines, data warehouse, experimentation platform, and analytics tools.
Enabling teams: Specialists who help other teams learn new capabilities. Maybe an experimentation specialist coaching product teams on how to run better A/B tests in big organizations. Or a machine learning engineer helping product teams understand when ML is the right solution and when it’s overkill. They work with teams temporarily to build capability, then move on.
Complicated-subsystem teams: Deep specialists in complex domains. Your ML infrastructure team if you’re doing sophisticated machine learning at scale. Your real-time streaming team if you’re processing millions of events per second with complex transformations.
If this resonates, start where your biggest pain is: (1) setting outcome-driven goals and organizing teams by value streams, (2) focusing on product discovery, or (3) team management, and start reading those books today!
Any other book you would add to the list?
Enjoyed this post? You might like my book, Data as a Product Driver 🚚.
Great post. I think another reason people don’t read product books is the translation problem - product books are very geared all around digital SaaS examples. Examples about platform products are rare let alone data platform or data more generally. So there’s a lot of questions around “Hmmm what does this mean in a data context.” I was a data analyst who became a product manager and THEN came back to data platform to blend the two and it’s hard for me. So I think it’s even harder for date leaders with no product experience. That’s why I started writing on LinkedIn a few years ago and now Substack - to write the bridge content I wish existed. Super looking forward to your book release to help sit in that gap. So much of existing data product content is very data mesh centric and not enough about product practices applied to data.