Product #94

Build Better Products · Laura Klein · 2016

It's clear why this book receives great reviews—it's a well-structured, jargon-free, practical guide to product discovery. For product managers looking to enhance their discovery skills, this is one of the better resources available. While it doesn't offer many groundbreaking revelations, it provides a solid foundation in product discovery.

Key Messages

Products fail or succeed based on how well they solve real problems and change user behaviour, not just by shipping features. Success requires a laser focus on one primary business goal, whether that's increasing revenue, user growth, or another measurable metric. Vague goals like "get more users" don't work - teams need specific, achievable targets they can influence directly.

Understanding users means going beyond basic demographics into their actual behaviours and needs. Interview users in small batches of five until you start predicting what you'll hear. Create provisional personas but validate them with real user data. Don't rely on what users say they want - observe what they actually do. When researching, match methods to specific questions: use quantitative data to understand what's happening, qualitative research to understand why.

Product development should start with observed user problems rather than assumed solutions. Many successful products like Slack and Flickr emerged from solving real problems their creators encountered. When brainstorming, only include participants familiar with recent user research, and focus on specific outcomes. Use techniques like dot voting to identify resonant ideas without requiring full consensus.

Prioritisation means saying no to most ideas while ensuring you release value quickly. Evaluate features on two axes: expected value created for users/company and effort required. Don't just chase new features - make time for technical debt, stability improvements, and iterations on existing functionality. Maintain a short-horizon roadmap plus a backlog of ideas and experiments, rather than planning years ahead.

Design should focus first on user flows and context before diving into screen layouts. Consider where and when people will use features, what interruptions might occur, and how tasks naturally sequence. Create consistent interfaces through style guides and design patterns, but only use patterns that genuinely support user needs. Get ideas out of your head through sketching and wireflows.

Features alone don't guarantee results - focus on changing user behaviour in ways that benefit both users and the business. Guide users to required tasks first, offer helpful nudges toward secondary tasks, and let them discover advanced features over time. Avoid dark patterns that trick users into unintended actions - they destroy long-term trust.

Test assumptions early to avoid wasting resources. Categorise assumptions into problem (is this needed?), solution (will this work?), and implementation (can we build it?) types. Focus first on assumptions that are both likely to fail and would have severe impact. Create falsifiable hypotheses with clear success/failure criteria.

Match validation methods to assumption types: use landing pages or pre-orders to test demand, concierge or Wizard of Oz approaches to validate solutions before building, and technical prototypes to verify implementation feasibility. Track experiments systematically, recording predictions and actual outcomes.

Build measurement into features from the start. Focus on metrics that drive decisions - if a metric changes, what action would you take? Track business outcomes (revenue, churn), user experience (speed, bugs), and product health (ensuring improvements in one area don't harm others). Avoid vanity metrics that always go up but don't inform choices.

Use appropriate measurement methods: A/B testing for comparing versions, cohort analysis for understanding retention patterns, funnel analysis for identifying drop-off points. Ensure proper data collection and stay focused on metrics that matter for your current stage.

Team structure significantly impacts product quality. Avoid common dysfunctions like siloed departments, design-by-committee, dictatorial product managers, or complete chaos. Instead, build "heist teams" where specialists unite around shared goals while leveraging their unique expertise. Product managers should provide clear vision and context while trusting team members to lead in their domains.

Success requires constant iteration across all these areas. Keep improving your understanding of users, refining solutions, testing assumptions, and measuring impact. No product is ever "done" - there's always room to make it better through continued learning and refinement.

This approach helps teams build products that genuinely improve users' lives while driving business success. It replaces guesswork and feature-chasing with validated learning and measured improvement. While the process takes discipline, it dramatically increases the odds of creating something people actually want and will pay for.

Full Book Summary · Amazon

Subscribe Button 

Quick Links

Three observations from Sam Altman · Article

We kind of suck at that right now - John Cutler · Article

Strategy Blocks: An operator’s guide to product strategy · Article

Bill Gates and Patrick Collison · Video

To Improve Yourself You Must Know Yourself · Article

Personal Dynamic Media

Alan Kay and Adele Goldberg. 1977. (View Paper → ) …we crystallized our dreams into a design idea for a personal dynamic medium the size of a notebook (the Dynabook) which could be owned by everyone and could have the power to handle virtually all of its owners information-related needs. Towards this goal we have designed and built a communications system: the Smalltalk language, implemented on small computers we refer to as "interim Dynabooks." We are exploring the use of this system as a programming and problem solving tool; as an interactive memory for the storage and manipulation of data; as a text editor; and as a medium for expression through drawing, painting, animating pictures, and composing and generating music. (Figure 26.1 is a view of this interim Dynabook.) We offer this paper as a perspective on our goals and activities during the past years. In it, we explain the Dynabook idea, and describe a variety of systems we have already written in the Smalltalk language in order to give broad images of the kinds of information-related tools that might represent the kernel of a personal computing medium.

This paper is a visionary milestone in computing. Written in 1977, it laid the groundwork for personal computing by introducing the concept of the Dynabook—a portable, interactive device that could serve as a “personal dynamic medium” for creativity, learning, and communication.

The idea of a computer for everyone was nearly unthinkable at the time. Instead of merely crunching numbers, the Dynabook was imagined as a device that would let users write, draw, animate, compose music, and even simulate complex processes. This was revolutionary because it shifted the focus from computers as specialised tools to computers as versatile extensions of human thought and expression .

Today, many of the core ideas have become the foundation of modern computing. The emphasis on a user-friendly interface, the integration of multimedia, and the empowerment of users to customise and extend their tools are evident in everything from laptops and tablets to today's app ecosystems. While the exact implementation using Smalltalk didn't become the mainstream, its object-oriented principles have deeply influenced modern programming languages and design paradigms.

An inspirational vision that took decades to realise - they were on the right path. Alan Kay is rightfully considered one of the true pioneers of computing.

Book Highlights

Once we start actively training ourselves in testing alternative hypotheses and perspective taking, it becomes clear that outcomes are rarely 100% luck or 100% skill. This means that when new information comes in, we have options beyond unquestioned confirmation or reversal. We can modify our beliefs along a spectrum because we know it is a spectrum, not a choice between opposites without middle ground Annie Duke · Thinking in Bets

Input metrics refer to the measurable and controllable factors or actions that can contribute to achieving a specific goal. They are under your influence and are considered the levers that drive success. For ChatGPT, an input metric is the number of research papers reviewed and incorporated into the language model's training data. Output metrics, on the other end, represent the actual outcomes or results that are desired or expected. These metrics are the ultimate goals that a company aims to achieve but may not be directly controlled by you directly and solely. Leading metrics are forward-looking and predictive, providing early indications of future performance (e.g., number of qualified leads per week). Lagging metrics are backward-looking and measure past outcomes (e.g., monthly revenue) Maja Voje · Go-To-Market Strategy

Ethics applies to every member of the company, but it's also true that product teams are on the leading edge where new products and services are conceived, developed, and deployed. So we have a special responsibility to consider the implications of our work. Marty Cagan · Empowered

Quotes & Tweets

Conversations are one of the best tools for breaking down big stories. Jeff Patton

Until you're 10+ in a startup, the only roles that exist are head of get shit done & chief common fucking sense officer. Jean de La Rochebrochard