I talked with Alex Hillman about product engineering from an angle that a lot of engineers avoid until they absolutely have to: customer research, product fit, and the work of helping people understand why something is for them.
Alex and his partner Amy Hoy have spent years teaching this through Stacking the Bricks and 30x500. What I appreciated about this conversation is that Alex did not treat sales or marketing as a separate, uncomfortable layer you bolt onto a product after the "real" engineering is done. He talked about it as another kind of engineering: engineering understanding, desire, trust, and action in a way that serves both sides.
That matters for product engineers because the work is not only "can I build this?" It is also "who is this for?", "what do they already believe?", "what are they trying to get done?", and "how do I make the right thing feel obvious at the right moment?"
You Are Not Your Customer
One thread that kept coming up was taste. Engineers often push back on product decisions from a place of craft, personal preference, or best practices. Sometimes that is useful. But Alex's reminder was blunt and important: you are not your customer.
The taste you are optimizing for may not be yours. It may be your user's taste, your customer's workflow, your buyer's priorities, or your company's mission. If you can speak from that point of view, you are not just making a personal argument anymore. You are speaking the language of the customer and, by extension, the business.
That is powerful even if you are not a founder. Inside a company, understanding the customer can make your implementation better, your questions sharper, and your influence more useful. It can also help you get pulled into better conversations because people start to trust that you understand more than the task in front of you.
Research Without the Zoo
Alex contrasted traditional research with what Stacking the Bricks calls Sales Safari. Instead of only asking people what they want in surveys or interviews, go observe real conversations where your audience already gathers.
That might be forums, replies, Discords, Slack communities, comment sections, or wherever people are already asking questions and complaining. The complaining is not noise. It is signal.
Alex gave four things to look for:
- jargon: the words people use to describe themselves, their work, and their problems
- pain: the questions, complaints, and missing context behind what they say
- worldview: the beliefs and assumptions that shape how they interpret the problem
- recommendations: what they suggest to each other, what they trust, and what they avoid
The part I especially liked is that Alex pushed back on outsourcing all of this synthesis to an LLM. An LLM can help gather, organize, and expand search paths. But the understanding has to get into your brain. Taking notes, typing things out, reviewing them later, and looking for patterns is part of how you build the product sense you are after.
Feeling Anticipated, Not Tricked
Near the end, Alex described good product experiences as making people feel anticipated. I loved that framing.
A delightful product is not just a product with cute animation or confetti. It is a product that shows up with the right affordance at the right time, in a way that makes the user feel like someone thought about their actual situation. That is very different from tricking people, patronizing them, or pushing a feature because we think it is clever.
That is also where AI gets interesting. Alex shared an example from his own AI assistant where it generates buttons for likely next responses. The magic is not that the button exists. The magic is that the software sometimes anticipates exactly what he was about to do next. That "you thought of me" feeling is something product engineers can create at scale when they understand the people they serve.
This Week's Homework
Alex's homework was practical and low-risk: the next time you are in a conversation with coworkers or product teammates and there is disagreement about direction, step back and ask, "who is this disagreement in service of?"
Is it serving the customer? The person with positional power? The decision maker? The loudest person in the room? Someone else?
You do not have to immediately do anything with the answer. Start by observing. Then, as you notice patterns, ask how that understanding should shape what you contribute to the conversation.
That is a very product-engineering exercise. It trains you to notice the real beneficiary of a decision before you argue about the decision itself.
