The Product-Minded Engineer: Drew Hoskins's book on designing for the client's real users

“Diagnostics may be the most important interface of a product.” The line does not come from a chapter about UX. It comes from chapter 3 of The Product-Minded Engineer, the chapter on errors and warnings, in the book Drew Hoskins wrote for O’Reilly Media.

For a forward deployed engineer, it describes daily life at a client site. Requests come from the buyer: add an export step, connect the agent to the ERP.

But think about the people who have to live with the system every morning: operations staff, accountants, dispatchers. They are often not in the meeting where requirements are signed off, and they may well hit an error message before they understand what the new feature does.

The book aims squarely at that gap: building what the client’s users actually need, not just what was written in the ticket.

An author who has sat on both sides

Gergely Orosz introduces Hoskins on The Pragmatic Engineer as a former software engineer who now works as a product manager. Orosz published an excerpt from chapter 3 and remarked that Hoskins seemed to him the ideal person to write such a book. Hoskins himself says the book took about 18 months to write, starting the day after he joined Temporal.

Booksellers list two different subtitles, “Building the Right Solutions for Your Users” at backstory.london and “Building Impactful Software for Your Users” at Helion, but it is the same book.

It is divided into four parts: Develop, Deliver, Discover, Define. The central argument is direct: beyond technical skill, engineers need deeper empathy for their users. The accompanying goals are to bring product thinking into technical tasks themselves and to learn how to gather valuable feedback from users.

In what order should you read it?

If you are moving from backend or platform work into an FDE role, read it early. Its main argument, that engineers need deeper empathy for users, is exactly what you have to bring with you when working directly with clients. If you have been a PM for years, much of it may feel familiar.

A sensible order is to start with the chapter 3 excerpt on The Pragmatic Engineer, because it gives you something you can use tomorrow. Next come chapter 6, “Understanding Your Target Audience”, and chapter 7, “Discovering Your Product Through Simulation”. These two are closest to customer discovery. Then go back to the beginning.

Idea one: errors are an interface

The most concrete advice in the excerpt is to raise errors from the outermost layer of an API or application, where you still know the scenario the user is working through. At the innermost layer, the code only knows that a key is missing, not what the user is trying to do.

Picture an invoice import pipeline you have built for a client. A parsing function deep inside reports KeyError: 'invoice_id', and the accountant’s only option is to call you.

Catch that error at the outer layer and the message can become: “Could not import the September invoice file: row 412 is missing the invoice_id column; check the ERP export template.”

Now the user can fix it themselves, and you are spared a midnight phone call.

Idea two: simulate before users touch it

One of the book’s stated goals is to simulate and predict how users will interact with a product so that it becomes easier to use, and chapter 7 is devoted entirely to discovering a product through simulation. For an FDE, this is the cheapest exercise available before a demo.

Suppose you are about to hand over an agent for searching contracts. Instead of rerunning the sample questions, play the part of a legal officer in a hurry.

They type a counterparty’s abbreviation, paste a whole email into the question box, then ask a follow-up without restating the context. Every time you have to stop and guess, you have found a bug before the client does.

Idea three: product thinking lives in the ticket

The book sets out to embed product thinking in everyday technical tasks rather than treating it as separate work. That suits FDEs, who are rarely handed a task called “user research”.

The simplest way to apply it: whenever you write a warning or choose a default configuration value at a client site, ask how the end user will read and understand it. The question takes a few minutes and often saves you an entire session of explaining.

This is also worth showing on your CV. A line such as “rewrote the error-handling layer of the import pipeline so client-side users could resolve common data errors themselves” tells a hiring manager you understand end users.

“Worked with stakeholders” does not. In interviews, have a similar example ready, and explain clearly what users ran into before your fix and how things changed afterwards.

If you read only one chapter, read the one on errors. Next time an error message makes a client call you, you will know which layer to fix.