The Product-Minded Engineering Building Impactful Software for Your Users (Drew Hoskins)（Z-Library）

Drew Hoskins Building Impactful Software for Your Users The Product-Minded Engineer

Praise for The Product-Minded Engineer Being product-minded is what separates decent software engineers from great ones at startups and Big Tech. This book is the missing guide on how to get better in this highly impactful area: how to get more “product-minded” and help your company, your team, and yourself succeed. —Gergely Orosz, author of The Pragmatic Engineer In this wonderful book, Drew Hoskins encourages software developers to adopt a product focus and teaches us the skills to do so. This material is particularly valuable to those of us who develop software artifacts that are not generally considered products, such as libraries and in-house applications. We who develop such software generally don’t have product teams to fall back on, so it’s up to us to learn these essential techniques. —Joshua Bloch, Carnegie Mellon University, author of Effective Java In an age where AI handles the syntax, engineers who master user empathy and product thinking will define the future of software. Drew Hoskins provides the definitive guide for making that transformation—blending deep technical wisdom from Microsoft, Facebook, and Stripe with practical frameworks that turn engineers into product-minded builders. This is the book that finally bridges the gap between writing code and creating impact. —David Singleton, cofounder and CEO of /dev/agents and former CTO of Stripe

The artificial split between product and engineering wastes so many hours and opportunities. When delay is expensive, avoiding a handoff is valuable. If your programmer can make good enough product decisions for now, you increase your chances of survival. This book condenses the skills necessary for good-enough-for-now decisions. —Kent Beck, creator of extreme programming and test-driven development and author of Tidy First The Product-Minded Engineer is one of those books that belongs on every software engineer’s shelf. Drew Hoskins draws on his real-world experience to unlock the secrets to creating software that users will love. —N. Scott Storkel, 35-year software engineering veteran I’d highly recommend this book for engineers looking to amplify their impact in building industry-leading experiences. This book levels up engineers at any stage of their career with an appreciation and foundation for product-focused thinking, providing a comprehensive toolkit for how to apply that thinking day-to-day with measurable results. —Kimberly Hou, engineering manager, Stripe Reading this book, I frequently found myself thinking back to past experiences where this book would have applied—both from the perspective of being a user of a product and from the perspective of being on the team producing one. The product-minded approach the book advocates is something most engineering teams can benefit from adopting—and I expect I will be recommending this book frequently to others going forward as well as returning to it myself. —Peter Schuller, Staff+ engineer, Meta For an engineer who has so far succeeded at staying in the code on their projects but finds themselves no longer able to do so, this book provides a singular reference for achieving basic literacy on product-oriented engineering decisions and the impact of product development on engineering teams. —Chelsea Troy, Mozilla, University of Chicago, chelseatroy.com

Drew Hoskins The Product-Minded Engineer Building Impactful Software for Your Users

978-1-098-17373-9 [LSI] The Product-Minded Engineer by Drew Hoskins Copyright © 2026 Drew Hoskins. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 141 Stony Circle, Suite 195, Santa Rosa, CA 95401. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://oreilly.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com. Acquisitions Editor: Louise Corrigan Development Editor: Angela Rufino Production Editor: Ashley Stussy Copyeditor: Dwight Ramsey Proofreader: Rachel Rossi Indexer: Judith McConville Cover Designer: Susan Brown Cover Illustrator: José Marzan Jr. Interior Designer: David Futato Interior Illustrator: Kate Dullea November 2025: First Edition Revision History for the First Edition 2025-11-10: First Release See http://oreilly.com/catalog/errata.csp?isbn=9781098173739 for release details. The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. The Product-Minded Engineer, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc. The views expressed in this work are those of the author and do not represent the publisher’s views. While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights.

Table of Contents Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi 1. The Foundations of Product Thinking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Case Study 2 The First Attempt, with No Scenarios 2 Meh Results 3 What Went Wrong? 4 A Second Attempt with Scenarios 4 Scenarios as Stories That Inspire 5 Scenarios That Capture User Interviews 6 Scenarios That Highlight Product Gaps 6 Scenarios That Highlight a Frictionful Experience 7 Scenarios That Validate the Feature You’re Planning to Build 7 Scenarios as Tests 8 Searching for the Key Answers 8 So, What’s the Scenario? 8 A Motivation 9 A Persona 11 A Simulation 14 How to Use Scenarios? 17 Chapter Summary 18 Exercises 18 Answers 19 v

Part I. Develop 2. Guiding Users Through Your Product. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Case Study Introduction 24 Scenarios in the User Journey 26 The Discovery Scenario 26 Product Discovery Mapping 27 Leverage Users’ Knowledge 29 Offer Multiple Routes to Discovery 30 Gracefully Reveal Complexity 32 Multipersona Design 33 Turn Unknown Unknowns into Known Unknowns 34 The Understanding Scenario 35 Picking Understandable Names 35 Classic Naming Advice Revisited 35 Giving Redundant Explanations 39 The Usage Scenario 41 Optimizing the Whole User Journey 42 The Limits of Signifiers 43 Chapter Summary 44 Exercises 44 Answers 45 3. Errors and Warnings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 The Value of Diagnostics 48 Scenarios for Diagnostics 49 Categorizing Error Scenarios 50 Categorizing Errors in Practice 51 Warning and Error Messages 53 Case Study Introduction 53 Provide Context 54 Make Error and Warning Messages Actionable 57 Raise Errors at the Interface 58 Upfront Validations 59 Repackage Errors 60 Raise Programmable Errors 61 Raise Specific Errors 61 Group Errors According to Scenario Category 62 Keep Information Around for Diagnostics 62 Diagnose Early 65 Do Static Validations 65 Validate Upfront 66 vi | Table of Contents

Let Them Test 66 Request User Confirmations 67 Chapter Summary 68 Exercises 69 Answers 70 Part II. Deliver 4. Experiencing Your Own Product. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Tests as Dogfooding 74 What Kinds of Tests Should You Write? 75 Scenario Tests 78 Functional Tests 80 End-to-End Tests 80 User Acceptance Testing 81 Documentation-Driven Development 82 Documentation Shouldn’t Be Load Bearing 83 Scenarios for Documentation Readers 83 Writing Documentation as Dogfooding 89 Friction Logging 90 Writing Friction Logs 91 Receiving Friction Logs 92 Friction Logging Culture 93 Samples 94 Chapter Summary 95 Exercises 95 Answers 96 5. Keeping Up with Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 A New Job Description—Digital Twin Caretaker 101 Designing for Change 102 Case Study Introduction 103 The Technological Underpinnings of Change 104 Getting User Feedback 108 Beta Versions Lower the Blast Radius of Failures 108 Feedback Widgets Help People Raise Their Voices 109 Champions Programs Offer Depth 109 Surveys Offer Breadth 110 The User Support Flywheel 110 Product Metrics 116 Case Study Introduction 117 Table of Contents | vii

Adoption Metrics 119 Value Metrics 121 Key Performance Indicators 123 Tactical and Strategic Metrics 124 Chapter Summary 125 Exercises 126 Answers 126 Part III. Discover 6. Understanding Your Target Audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Real Users, Not Straw Men 132 Case Study Introduction 134 Stand Back, Wield Science 134 Customer Discovery 135 Getting Interviews 135 Customer Discovery Interviews 136 Sales Calls 141 Customer Discovery Surveys 142 Networking with Interviewees 143 Customer Interviews Rules of Thumb 143 Crafting and Communicating a Target Audience 144 Choosing a Target Audience 144 Gaining Alignment with Personas 145 Audiences for the App Center 147 Nonpersonas 148 Selecting Features Based on a Target Audience 149 Keeping Your Focus 150 Multipersona Products 151 When Personas Are in Conflict 151 Understanding the Value of a Customer 153 Prioritizing Among Competing Personas 153 Chapter Summary 154 Exercises 154 Answers 155 7. Discovering Your Product Through Simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 From Vision to Requirements 157 Case Study Introduction 160 AI Assistant Product Brief 161 Finish Your Product Vision with North Star Scenarios 162 viii | Table of Contents

Scenario-Driven Discovery 162 Brainstorm Scenarios as a Team 163 Select and Refine the North Star Scenarios 164 Convert the North Star Scenarios into Requirements 167 High-Level Requirements 168 The Product Requirements Document 169 Use Case Compendium 169 Organize Your Use Case Compendium 171 Prioritize the Requirements for Your First Milestone 173 What Really Matters for Prioritization? 173 Define the Target North Star Scenarios for Your First Milestone 178 Prioritize the Use Case Compendium 178 Build Detailed User Flows for Your First Milestone 181 Validating User Flows 184 Translate User Flows into Jobs to Be Done 185 Feeding Back into the Requirements 185 Chapter Summary 186 Exercises 187 Answers 188 Part IV. Define 8. Interaction Design. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 The Role of Bias and Ideology in Software Design 193 Debate: Flexible Versus Opinionated 193 Debate: Optimism Versus Pessimism 194 Debate: Open Source Versus Proprietary 194 The Prerequisites of Good Design 195 Case Study Introduction 195 Call Attention to the Correct Usage of Your Product and Away from Incorrect Usage 197 Choose Safe, Predictable Defaults, or None at All 198 Optimize Your Path of Least Resistance 200 Give Affordances to the Right Persona in the Right Scenario 201 Perform Validations 203 Time the Affordances You Ship Wisely 204 If It’s Worth Building, It’s Worth Validating 205 Be Neither an Optimist nor a Pessimist 205 Apply the Rule of Three 206 Build It in Stages 207 If Necessary, Start with an Experimental Version 209 Table of Contents | ix

Narrow Versus Extensible Features 209 Chapter Summary 211 Exercises 212 Answers 212 9. Product Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 The Foundations of Product Architecture 216 Zoom Out and Look at the Big Picture 217 Avoid the Streetlight Effect 217 Communicate the User Impact of a Proposal 218 Use Technologies That Bridge the System-Product Gap 219 Case Study Introduction 220 Reliable User Experiences 220 Latency 221 Availability 223 Data Consistency 224 Latency, Availability, and Data Consistency Trade-Offs 227 Scalability 229 Scale Simulations 229 Communicating Nonfunctional Requirements to Users 233 Chapter Summary 235 Exercises 236 Answers 236 Wrap-Up 238 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 x | Table of Contents

Preface Northern sea otters, such as the one featured on this book’s cover, are like software engineers, except more adorable. They wield tools—mainly rocks to break open sea‐ shells. They also collaborate—they form large “rafts” of many otters, clutching one another’s paws so they can stay afloat and avoid drifting apart. Sea otters are also liminal creatures, meaning they float on the boundary between air and sea, belonging fully to neither. These marine mammals must get oxygen from the air, but their food comes from the ocean. They have paws like a land mammal, but their flippers adapt them for the sea. Engineers are liminal creatures, too, except we inhabit the space at the border between systems and users. The software, with its databases, protocols, call stacks, and containers, is like the ocean. When we dive deeper to the ocean floor, we come to rest on the hardware that supports it all. But users are our oxygen and our sunlit sky. We see farther by their light, and we must always stay afloat to do so. Why This Book Exists Thinking about software products boils down to two topics: System thinking Considers topics like algorithms and data structures, programming languages, fault tolerance in distributed systems, memory constraints of firmware, and so forth. Product thinking Comprises understanding users, their background knowledge and needs, their sequences of actions, and group dynamics—plus the design techniques and information architectures that serve them. xi

Software engineering education is mostly about system thinking. University com‐ puter science curriculum, coding bootcamps, and software engineering literature focus on algorithms, data structures, programming languages, system knowledge, and design patterns. Outside of the odd Human-Computer Interaction elective, we mostly learn about product design and our users slowly, by osmosis. Why? It’s true that system thinking is our most differentiated skill—product managers, designers, and user experience researchers can’t do it. But ask any of those people and they will tell you they wish their engineers had more product skills. They are stretched thin across many products, and communication and alignment are chal‐ lenging. We can control our product’s destiny much better by drawing on deep knowledge of our users rather than trying to interpret a PM’s hastily sketched requirements document that doesn’t talk about any edge cases. Some of us could get away without product skills when software engineering was a frontier discipline. Even the basics took unusual talent, grit, and dedication to master. So few people knew how to code effectively that the most urgent task was to train a generation of coders and software designers. The tools and languages were so difficult to use that mastering and using them was a full-time job. That’s changed. Developer technology, spearheaded by the open source ecosystem, cloud computing, and deep capital investment in developer tools companies, has improved dramatically over the last two decades. AI coding assistants and agents now do a lot of heavy lifting for us, taking care of small details so we can focus more on other topics. Topics like product thinking. This book exists to supplement the rest of your education, blending your existing engineering skills with user empathy and product skills. For example, we won’t be designing data structures or algorithms here, but we might choose one based on users’ needs. Armed with these skills, you could become better in engineering roles: • Prioritize your efforts better based on your impact. • Work more effectively with product managers and designers. • Make better-informed engineering design decisions. • Write more useful and maintainable code by treating your teammates as users of your abstractions. • Wake up most days excited to serve the people who use your product. Or you could level up in roles that require a mixture of product and engineering skills: xii | Preface

• Become a product/engineering hybrid, helping with product decisions as well as execution, simultaneously optimizing for engineering and product goals in a way that pure engineers or pure product folks cannot. • Start a company as a technical founder with product sense, better able to navigate the diverse challenges that start-ups face. • Become or improve as a tech lead, leading your teammates with sound reasoning based on user outcomes. Who This Book Is For This book is for professional software engineers of all stripes who have mastered the basics of writing and shipping code but yearn to make a bigger and more consistent impact. Topics will engage folks from a year into their careers to seasoned engineers. The user-focused skills learned here apply equally to serving coworkers, members of an open source community, and paying customers, whether the users are consumers, professionals, or other developers. I have included a wide variety of examples, from user interfaces to developer plat‐ forms to infrastructure, all of which I consider to be products. Even a modest func‐ tion is a miniature product, communicating with its users through its interface and fulfilling their needs. Yes, even infrastructure engineers build products; it’s just that their most direct target users are typically other engineers, along with the end users those engineers serve. Adding to the challenge, infrastructure engineering teams usually lack product man‐ agers and designers, counterintuitively making certain product skills such as use case awareness even more important to success. Structure of the Book Chapter 1 contains introductory material and is a prerequisite for the rest of the chapters. You can then read the remaining chapters in any order, based on your interests or timing. However, I’ve placed them in the order I recommend if you have no special preference. Those eight chapters are divided into four parts themed after phases of the “double diamond” model of software product lifecycles. Let me briefly digress about this. The Double Diamond Process Model This book isn’t primarily about software processes, and I won’t be trying to sell one to you. However, understanding the Double Diamond Process Model will help you Preface | xiii

navigate this book, and if you’re like me, it will expand your conception of what it takes to create great software. Many effective software lifecycle practices can be boiled down to these four basic phases: Discover Determine who we’re serving and the problems they need solved. This phase is about investigation, creativity, and exploration. Define Architect a product that will solve those problems. This phase is about winnow‐ ing down our options into a focused plan. Develop Choose and flesh out an implementation. In this phase, we search for the best way to implement and polish the high-level product we’ve defined. Deliver Build it, validate what you built, get it out to customers, and collect their feedback. Visualize the four combined phases as in Figure P-1. Figure P-1. The British Design Council’s depiction of the Double Diamond process model They’re represented as arrows guided along two diamonds. In the Discover and Develop phases, the arrows diverge because we explore many different threads; whereas in the Define and Deliver phases, they converge as we try to weave a tight product from those threads. Don’t take me to mean that there’s a neat progression through these phases in a soft‐ ware project. Cycles nest within cycles as you drill into subfeatures, you’ll learn new things and backtrack, and so forth. The back-and-forth between creativity and focus is enlightening. If you’re ever frus‐ trated with a colleague who seems to be defocusing things with creative ideas when you’re trying to get things shipped, maybe you’re mentally in a different phase from xiv | Preface

them. The same might be true if you feel that someone is shutting down your good ideas. Take a moment to make sure you are aligned on whether you’re, say, in Discov‐ ery or Development. This model also opens our minds to the entire product lifecycle, from the moment the problem is first posed to when it’s shipped and we’re getting feedback. Don’t jump straight to a solution, and don’t assume that you’re done when the first version of your feature ships. The seasoned product-minded engineer shapes their product’s destiny through all four phases of the lifecycle. The Parts Product thinking comes up all the time for engineers, so throughout this book, we’ll touch on all these phases and show how to use product thinking to achieve great out‐ comes in each one. Roughly, the parts of this book cover the Double Diamond phases, rotated to start halfway through the product cycle. First, we start with the Develop and Deliver pha‐ ses because these are commonly experienced by engineers of all levels. Then I will hop back to navigating the Discover and Define phases, which tend to be the domain of senior levels and above. By the time we reach Parts III and IV, Discover and Define, the decisions we’ll be making, although often made earlier in the product cycle, will be more challenging and require more context. But, if you’d rather read the parts in phase order, go for it; just know that you’re tackling more challenging material first. The Chapters • Chapter 1 introduces the core concepts of personas and scenarios that I’ll use again and again throughout the book and equips you with a touch of user psychology. Part I, “Develop” • Chapter 2, “Guiding Users Through Your Product” is about communicative, intu‐ itive product surfaces. You’ll help your users discover, understand, and use your product through effective naming and carefully revealed hierarchical design. • In Chapter 3, “Errors and Warnings”, you’ll write actionable error messages and architect your code to make errors programmable and useful. Preface | xv

Part II, “Deliver” • Chapter 4, “Experiencing Your Own Product” discusses some of the most effec‐ tive ways to dogfood your product, for example to write documentation, scenario tests, and friction logs. • Chapter 5, “Keeping Up with Users” will teach you to “design for change” and then iterate toward success based on user feedback and metrics. Part III, “Discover” • In Chapter 6, “Understanding Your Target Audience”, you’ll meet your customers and learn what they’re looking for, and share that understanding across your whole team. • Chapter 7, “Discovering Your Product Through Simulation” helps you turn user scenarios into product requirements and prioritized plans. Part IV, “Define” • In Chapter 8, “Interaction Design”, we get into the details of feature design, help‐ ing you to design products that are used only for their intended features and not for unsafe ones. • Chapter 9, “Product Architecture” applies product thinking to system concerns such as throughput, data consistency, and latency. Content Notes Here are a few notes before you start: • This book includes code listings. I’ve chosen Python because it is both commonly known and relatively straightforward to understand. I will occasionally explain syntax that might be unfamiliar. • Every chapter concludes with thought-provoking exercises and sample answers to those exercises. Please do them! Product thinking takes practice. • I have worked at Microsoft, Facebook, Stripe, and Temporal. Some examples in this book are drawn from my experiences at these companies, some from prod‐ ucts I worked on myself. I chose them not as an endorsement of these companies, but because this firsthand knowledge allows me to provide the nuanced detail a book on product thinking requires, and to do so accurately. • I’ve spent most of my career building products for developers. While I cover a much broader range of products in this work, and have sought many inputs in order to make my advice universal, there may be a bias toward techniques that are more relevant when serving technical users rather than consumers. xvi | Preface

Conventions Used in This Book The following typographical conventions are used in this book: Italic Indicates new terms, URLs, and email addresses. Constant width Used for program listings, as well as within paragraphs to refer to program ele‐ ments such as variable or function names, databases, data types, environment variables, statements, and keywords. This element signifies a tip or suggestion. This element signifies a general note. This element indicates a warning or caution. O’Reilly Online Learning For more than 40 years, O’Reilly Media has provided technol‐ ogy and business training, knowledge, and insight to help companies succeed. Our unique network of experts and innovators share their knowledge and expertise through books, articles, and our online learning platform. O’Reilly’s online learning platform gives you on-demand access to live training courses, in-depth learning paths, interactive coding environments, and a vast collection of text and video from O’Reilly and 200+ other publishers. For more information, visit https://oreilly.com. Preface | xvii

How to Contact Us Please address comments and questions concerning this book to the publisher: O’Reilly Media, Inc. 141 Stony Circle, Suite 195 Santa Rosa, CA 95401 800-889-8969 (in the United States or Canada) 707-827-7019 (international or local) 707-829-0104 (fax) support@oreilly.com https://oreilly.com/about/contact.html We have a web page for this book, where we list errata and any additional informa‐ tion. You can access this page at https://oreil.ly/the-product-minded-engineer-1e. For news and information about our books and courses, visit https://oreilly.com. Find us on LinkedIn: https://linkedin.com/company/oreilly-media Watch us on YouTube: https://youtube.com/oreillymedia Acknowledgments Here’s a wholehearted thank you to my friends and stalwart alpha readers, Carmen Krol and Peter Schuller, who subjected themselves to the entirety of the rough early draft and gave fantastic feedback. I’d also like to highlight my beta readers, Kimberly Hou, Scott Storkel, and Chelsea Troy, who plowed through the entire beta and were honest with me. Thanks to other contributors, Adam Hupp, Ben Lavender, Paul Nordstrom, Jason Rosenfeld, Jeff Schoner, Venkat Subramaniam, and Mark Wong, who all made posi‐ tive impacts on the book. Other thanks: • Anthropic for creating my research buddy, Claude. There are a lot of topics in this speedrun through product thinking, and I needed a knowledge boost on many of them. • Louise Corrigan for believing in me and suggesting that I write on this awesome topic. • My patient and knowledgeable editor, Angela Rufino. • Joshua Bloch, Don Norman, and Steven Clarke for setting me off on this product-minded journey. xviii | Preface

• Charles Zedlewski for suggesting that I give product management a try after so many years as an engineer. It would have been hard to write parts of this book well without this experience. • Gergely Orosz for his inspiring blog post, The Product-Minded Software Engineer. • Patrick Collison, for introducing me at O’Reilly, and for running a company full of product-minded engineers. • Peter Dimov, for teaching me to embrace my calling as a product-minded engineer. Preface | xix