Sketch the user journey and review systems - product-minded engineering with Drew Hoskins

Drew Hoskins introduces himself as the author of The Product-Minded Engineer, published by O’Reilly, and describes a career that began with compiler engineering at Microsoft. He was initially drawn to algorithms, deep technical work, and what he called “hardcore” engineering. He then moved through Facebook, Oculus, and Stripe, gradually becoming what he describes as a product-engineering hybrid. The important before-and-after in his story is that he once felt he was “spinning his wheels,” but after developing product skills, his career accelerated. Writing the book was his attempt to explain that transition to other engineers. Kent asks whether product engineering changes depending on the audience. Drew says developers have been his customers throughout his career, including at Facebook and Oculus. He did some of his best work on Facebook’s internal developer-productivity team, where the company funded and valued tools for its own engineers. He felt external developer platforms at Facebook and Oculus received less consistent attention, which helped motivate his move to Stripe. Stripe’s model—where the company could be paid on every API call—created a stronger incentive to care about external developers. Drew says he felt he had found “my people” there.

Kent describes Stripe as the long-standing contrast to PayPal’s reputation for poor documentation and developer experience, then asks what produced Stripe’s level of customer care. Drew attributes it first to the founders’ “users first” orientation and to cultural principles such as “build with craft and beauty.” In his explanation, craft means thinking carefully about edge cases, interoperability, and how an API will behave in real usage—not merely making the happy path work. Drew gives API Review as a concrete mechanism. For roughly two years, he participated in a centralized review process in which someone from API Review became a partner for an engineer trying to ship an API. That reviewer brought organizational context, taught API-design practices, helped the engineer think through user scenarios, and shepherded the change through the organization. This distributed knowledge about good API design instead of leaving every team to rediscover it. Drew says Stripe’s developer focus came from the combination of leadership, cultural practices such as API Review, and interview loops that reinforced those expectations. Kent agrees that individual engineers can make progress without company-wide alignment, but a culture that actively rewards user care makes the work substantially easier.

Drew explains that his transition began in the C++ community, where he helped build a compiler framework with an API that was not especially usable. He noticed that the C# community was doing forward-looking work on scenario-driven design, design patterns, and usability—partly because it wanted to be more usable than Java—and brought those ideas into his own work. He became increasingly interested in API design because it required user empathy and careful thought about how people would actually use an interface. At first, Drew developed product skills narrowly: he designed better interfaces but did not apply the same thinking to prioritization or broader product decisions. He began analyzing a user journey as discovery, understanding, and usage: can the user find the feature, interpret what it does, and use it safely without causing an unintended result? As he practiced this structured way of thinking, he started applying it to deciding what to build and aligning his motivations with those of his manager and company. At Facebook, Kent Beck and others described five staff-engineer archetypes—coding machine, generalist, specialist, product hybrid, and fixer. Drew’s manager identified him as a product hybrid because he was good at figuring out what to do and why. Drew chose to deepen that path rather than become a manager, and he says this was when his career “hockey sticked.”

Drew defines a scenario as a narrative sequence such as “the user does X, the software responds, and then the user does Y.” He says discovery, understanding, and usage—including safe usage—are a mental shortcut for checking whether a product can actually work. If a feature cannot be discovered, interpreted, or used without unintended consequences, the product is incomplete. Kent connects this to jobs theory, while Drew emphasizes that scenarios expose the concrete circumstances in which a feature must operate. Drew distinguishes two ways engineers should represent the world. The familiar engineering index is the system diagram: modules, interfaces, databases, and the relationships between them. The other index is based on time and people: what one user does, what the software does next, and what many users may be doing simultaneously. Engineers need both representations. Scenarios draw attention to requirements—for example, a commuter ordering coffee from a car raises questions about voice commands, authorization, fulfillment, payment, and workflow—but scenarios must then be generalized into components and edge cases. Drew uses the rule of three: if he can identify three distinct, high-priority use cases for an abstraction, he assumes there are probably more and builds a general solution. If one use case represents roughly 90% of the work, he avoids unnecessary generalization.

Drew illustrates the career impact of product-minded engineering through a framework he built at Facebook, which he calls “EnSchema” in the conversation. Facebook engineers created many graph models—users, events, groups, and News Feed posts—and each model required repetitive work: an object wrapper around the database, database deployment configuration, mutation wrappers, documentation, and other boilerplate. Drew and his team combined those requirements into a single schema from which the other pieces could be generated. The framework later became a general-purpose platform for reflecting on the graph and supported data migrations and other capabilities. He says the framework’s success depended on six or seven product decisions that were also technical decisions. One controversial area was code generation: engineers debated whether generation should happen at build time, development time, or be checked in. Drew’s team made generated code signed and kept up to date, then added “partial codegen,” which generated almost everything while allowing engineers to fill in selected method implementations. For example, an email-address field could receive the standard generated behavior while retaining a small amount of custom logic without forcing engineers to abandon code generation. That choice came from recognizing a common scenario—something is almost standard but has one exceptional behavior—and handling it gracefully. Drew says the framework spread because those decisions addressed recurring user pain rather than merely showcasing clever implementation.

To write the book well, Drew first planned an API-design book, but O’Reilly told him the topic was too narrow. They liked the larger themes of user empathy and product thinking, so Drew rewrote the outline as The Product-Minded Engineer. He then spent two years as a product manager at Temporal Technologies, a durable-execution platform, to accelerate his understanding of product work. After the book shipped, he returned to engineering at Stripe because he wanted to practice the product-engineer role he had described. Drew says his most valuable product lesson was learning how to gain user understanding quickly instead of having the luxury of spending years as a user of an internal system. He criticizes interviews that begin with, “We have this product idea; what do you think?” because people tend to be agreeable. He calls this the “Cthulhu effect”: presenting the idea can corrupt the conversation, leading users to say a product sounds cool even when they have no intention of using it. He recommends starting in the user’s world: ask about their problems and let them volunteer information before introducing a possible solution. Only later should the interviewer probe a specific area or reveal the proposed product. The earlier users raise the relevant problem without prompting, the stronger the signal; the more prompting required, the less confidence the team should have. When Kent asks how to find customers who do not yet know they have a problem, Drew calls it “hard mode” product management. He recommends slicing behavioral data for signals such as churn, interviewing people who have already left or who are close to leaving, and learning the underlying motivation rather than accepting a user’s proposed feature as the answer. He acknowledges that this is much harder from scratch than when working with a captive internal audience.

Drew uses an otter as the mascot for product-minded engineering because an otter has paws and flippers, breathes as a mammal, dives underwater, and uses tools to open shells. In the metaphor, the water represents the system and the world above it represents users and product context. A product-minded engineer lives at the boundary and can move into both domains. Drew distinguishes this role from product management by saying that product managers generally do not have the “boxes and lines” system index needed to anticipate technical edge cases, risk areas, build-versus-buy decisions, or which parts of a system deserve extra care. He expects many engineers to become software generalists who can do some engineering and some product work, handling medium-difficulty problems independently while bringing in specialists for security, AI, or product discovery when necessary. Kent suggests that AI agents may replace the coding-machine archetype, but Drew defends the fixer archetype: a staff-level fixer surveys a broad system, identifies the most acute neglected problem, and uses context and judgment to decide what needs attention. They then discuss AI-generated code and the growing burden of review. Kent argues for reviewing system changes rather than mechanically inspecting every diff, especially when a change merely combines existing primitives. Drew describes this as “deferred” or “referred” trust: an engineer may conditionally approve a change if an agent verifies that specified conditions were met. They also discuss “test slop,” including tests that assert implementation details or even verify that removed code is absent from a file. Drew says teams may need to review tests as a distinct problem, ensuring they assert what the product should do rather than simply making the implementation appear covered.

Kent closes by asking Drew for homework. Drew recommends taking one feature currently under development and sketching its user journey in detail. The exercise should cover discovery, understanding, usability, and safe usability: how does the user find the feature, determine what it means, use it correctly, and avoid getting stuck or causing an unintended result? Drew says engineers should be skeptical of their own story and look for “plot holes.” A journey that sounds complete at the implementation level may still omit how the user encounters the feature, what information they need, what happens in unusual circumstances, or how the system responds when multiple steps or actors are involved. Kent emphasizes that this is concrete homework with no excuse not to do it. The episode ends with Drew pointing listeners to his book, Substack, and LinkedIn, while Kent reiterates that practicing this exercise makes engineers more product-minded and can produce better products.