The Product Books That Changed How I Work

Some product books have helped me remember a framework, while others have changed how I work through a customer or business problem. I find the second group more useful because the ideas remain relevant when the situation doesn't look like the example in the book.

Knowing a framework isn't the same as knowing when it helps. The ideas that have stayed with me connect to situations I've encountered: understanding customers, separating problems from solutions, deciding where to invest, working with engineering and design, assessing market readiness, and learning whether a release changed anything.

Six authors have had a particularly strong influence on how I think about those questions: Teresa Torres, Marty Cagan, Dan Olsen, April Dunford, Geoffrey Moore, and Melissa Perri.

I don't use their approaches as a playbook. I use the connections between them to examine customers, teams, products, markets, and outcomes from different perspectives.

Teresa Torres: Understand the experience before choosing the solution

Teresa Torres' Continuous Discovery Habits reinforced a principle that's become central to how I approach product work: customer discovery isn't primarily about asking people what they want. It's about understanding their experiences in the context of something they're trying to accomplish.

A feature request is useful information, but I want to understand the situation behind it: what the person was trying to accomplish, where they encountered friction, what they did next, how often it happens, and its effect on the outcome they care about. Those details help connect the request to opportunities and other evidence.

Torres' Opportunity Solution Tree provides a useful way to organize that thinking by connecting a desired outcome to customer opportunities, possible solutions, and the assumptions that need to be explored. I value the structure less because a team needs another diagram and more because it makes the reasoning behind a product decision visible.

Instead of moving directly from "we need to improve activation" to "let's build this feature," a team can ask what customers are experiencing that affects activation, which opportunities appear meaningful enough to pursue, what different solutions could address them, and what still needs to be learned.

Data adds another perspective. Customer conversations can help explain what someone experienced and why it mattered. Product and business data can help us understand how frequently behaviors occur and whether addressing an opportunity actually changes the outcome we care about.

The purpose is to improve our understanding of customers so we can make better investment decisions, rather than conduct discovery because a process requires it. Acting on that learning also depends on the team having room to change direction.

Marty Cagan: Product management depends on how the organization operates

Marty Cagan's Inspired helped me think more deliberately about the environment in which product management happens.

Many practices we associate with strong product work depend on more than the skills of an individual product manager. They depend on how teams are structured, how decisions are made, what teams are responsible for, and whether they're being asked to solve problems or simply deliver predefined solutions.

A team can interview customers, analyze data, and identify an opportunity while still having little ability to act on what it learns if its primary responsibility is delivering a roadmap that's already been decided elsewhere. Discovery may exist, but it risks becoming validation around decisions that have effectively already been made.

The product operating model Cagan describes presents a different relationship between the organization and the product team. Leadership provides strategic context, important customer and business problems, and outcomes that matter. Product, design, and engineering work together to understand those problems, explore solutions, manage risk, and determine how best to create the desired outcome.

The implications extend across the team. Engineers help examine the problem and possibilities before requirements are settled, designers participate in understanding the customer, and product managers connect needs, evidence, business context, and strategy.

Some of my best engineering partnerships worked that way. We developed an understanding together instead of treating my answer as complete, with technical perspectives changing what seemed possible and customer and business context helping us decide what was useful.

Continuous discovery has less value when a team can't respond to what it learns. A prescribed solution can limit the opportunity to act on an unmet need, so the operating model affects how useful the other practices become.

When the team has that context and responsibility, it still needs to choose which customer needs justify investment.

Dan Olsen: Connect unmet needs to what you build

Dan Olsen's The Lean Product Playbook helped connect customer understanding to product decisions.

Olsen's Product-Market Fit Pyramid begins with the target customer and their underserved needs. Those form the market side of the pyramid. Above them are the product decisions: the value proposition, feature set, and user experience.

That ordering helps me resist starting with a feature simply because it looks possible or appears in a competitor's product.

A new technology, request, or competitor can all provide useful information without establishing that the idea addresses an important unmet need for the customers we want to serve.

Starting with customers means understanding what they're trying to accomplish, which needs are important, and how well existing alternatives serve them. The combination of importance and dissatisfaction gives us a basis for examining an opportunity.

That understanding should inform the value the product promises and the capabilities and experience needed to deliver it.

There's an obvious connection to continuous discovery. Customer conversations can surface experiences and needs, while behavioral and business data help us understand their prevalence and relationship to outcomes. Olsen's model provides another way to connect that learning to what we choose to build.

The discipline underneath both approaches matters more to me than mechanically following either framework. Resist jumping from an observation directly to a feature. Understand who's experiencing the problem, what they're trying to accomplish, how important the unmet need is, and why the solution being considered should improve their situation.

Even a capable product can struggle when customers don't understand that value, which connects the decision to positioning.

April Dunford: Positioning changes how customers understand value

April Dunford's Obviously Awesome stands out because of how practically it approaches positioning.

Positioning can be treated as something that happens after the product work is complete, when marketing needs to determine how to describe what's already been built. Dunford makes a strong case that it's much more fundamental than that.

Customers need a frame of reference. They compare a product with something they already know, whether that's a direct competitor, another category of software, an internal process, a spreadsheet, or simply doing nothing. That comparison affects which capabilities they notice, what they believe the product is worth, and whether they think it was designed for them.

The product itself may remain largely unchanged while the context of comparison changes its perceived value.

Dunford's approach makes the problem practical: understand the alternatives customers would use if your product didn't exist, identify what distinguishes your product from those alternatives, determine why those differences matter, and understand which customers care most about that value.

This can explain situations that initially look like product problems. A capable product may struggle because customers are comparing it with the wrong alternatives or because its most valuable capabilities are being presented to people who don't particularly care about them. A different position can make existing value easier to recognize.

The reverse can happen too. A product with a clear position can lose it as new features accumulate, new segments are pursued, and its story expands to accommodate more use cases. Eventually the customers who once understood exactly why the product mattered may have a harder time recognizing what makes it different.

That's why I don't see positioning as purely a marketing responsibility. The customers we choose to serve, the alternatives we compete against, the capabilities we emphasize, and the value we promise are connected decisions.

Communicating value still leaves another question: whether the broader market is ready to adopt it.

Geoffrey Moore: Market readiness changes the product problem

Geoffrey Moore's Crossing the Chasm and Inside the Tornado pulled the lens farther outward for me.

A product doesn't move through a market evenly. Innovators may experiment because something is new. Early adopters may accept an incomplete solution because they recognize what it could enable. The early majority generally has different expectations. They're looking for something more established, with clearer evidence that it works and fewer risks associated with adoption.

Moore describes the difficult transition between early adopters and the early majority as the chasm. I find that idea useful because it challenges the assumption that early traction automatically means a product is ready for a larger market.

The customers who validate an emerging product may have different needs and expectations from those required for its next stage. That can change scope, positioning, onboarding, integrations, reliability, support, pricing, and the problems that need solving.

Inside the Tornado looks at what happens when adoption begins accelerating. The problem changes again. A company that spent its earlier life proving that a new category should exist may suddenly need to compete on execution, scale, distribution, ecosystem, and becoming a practical choice for a much larger group of customers.

These ideas changed how I think about product timing. We can understand a legitimate customer problem and build a capable solution without automatically having a market ready to adopt it at scale. Product-market fit exists for a particular group of customers at a particular point in a market's development.

This feels especially relevant whenever a new technology receives significant attention. The interesting question isn't only what we can build with it. We also need to understand who's ready for it now, which problem is important enough for them to change their behavior, and what the next group of customers will require that the current group doesn't.

Adoption also needs to be examined against the intended outcome, rather than treated as the last question.

Melissa Perri: Deployment isn't the outcome

Melissa Perri's Escaping the Build Trap reinforced a distinction I try to keep in view: building and releasing something doesn't establish that it created value.

Product teams put considerable effort into discovery, design, technical decisions, tradeoffs, coordination, testing, and release. With so much attention on delivery, deployment can feel like the finish line even though it gives us new questions to investigate.

A release tells us that we successfully built and shipped something. It doesn't tell us whether customers adopted it, whether their behavior changed, whether the original problem became easier to solve, or whether the business outcome we were trying to influence moved.

That distinction between output and outcome is one of the ideas from Perri's work that's stayed with me. Features, releases, and roadmap items are outputs. The reason for producing them should be an outcome: a meaningful change for the customer, the business, or ideally both.

After deployment, I want to understand whether people find and use the feature, whether the friction identified during discovery decreases, and whether a relevant activation, retention, revenue, efficiency, or other measure changes.

Customers may use a product as expected or in ways we didn't anticipate. Low adoption can indicate a poor solution, but it may also reflect discovery, positioning, onboarding, or another part of the experience.

A release gives us new evidence that still needs interpretation.

These ideas work together

I use these books to examine different parts of a connected problem, rather than choose one as the correct approach to product management.

Torres helps me understand what customers are experiencing and identify opportunities worth exploring. Cagan provides a model for organizing teams so they have the context and responsibility to act on what they learn. Olsen connects target customers and underserved needs to the product and value proposition. Dunford asks whether customers have the right context to understand that value. Moore pulls the lens outward to consider market readiness and adoption. Perri brings the focus back to outcomes by asking whether what we shipped actually created the change we intended.

Learning after release feeds back into the next decision. Behavior may show that a problem mattered less than expected, conversations may reveal a positioning gap, a market change may make an opportunity more relevant than it was six months earlier, and measurement may uncover a different problem.

The product operating model surrounds that loop. Teams need enough strategic context, customer access, technical participation, and decision-making responsibility to respond to what they learn rather than simply continue producing the next item on a roadmap.

The way I think about the work today is therefore less like a sequence of frameworks and more like a set of connected questions:

Do we understand the customer and what they're experiencing? Are we addressing an important unmet need? Does the team have the context and responsibility to solve it? Are we creating something meaningfully better? Can customers understand why it matters? Is the market ready to adopt it? And once we release it, did anything actually get better?

None of these books gave me a formula for success, and I'm increasingly skeptical that one exists. They gave me better ways to examine a problem, recognize what I might be missing, and decide what to learn before and after something gets built.