Instilling Product Thinking in Engineers
Final Prep · People Management — how you coach a deeply technical, execution-focused engineer to think like a product owner and focus on the real internal-customer experience.
This question tests whether you can grow people, not just direct them. A weak answer treats product thinking as a lecture (“I told them to care about the customer”) or as a personality they either have or don’t. A strong answer shows that you connect the engineer to the real customer and the real “why,” shift how success is defined from output to outcome, coach through questions rather than answers, and then hand over genuine ownership of a customer-facing result so the mindset sticks. Answer in CARL shape (Context, Actions, Results, Learnings), with most of your words on the actions.
What this question is really testing
Two things. First, whether you understand that product thinking is a learnable skill, not innate talent — and that the fastest teacher is contact with the customer’s actual pain, not a slide about “customer obsession.” Second, whether you can coach without stealing the work: the point is to grow an engineer who asks “should we build this and for whom” on their own, not one who waits for you or the PM to hand them fully-specified tasks. On an infrastructure team this matters even more, because the “customer” is usually another engineering team, and it’s easy to optimize a system nobody actually finds usable.
How to answer- Start with the why. Before any task, make sure they can name who the internal customer is and what problem the work solves for that customer — not just the technical spec.
- Take them to the customer. Have them sit with the downstream team, watch how the system is actually used, and feel the pain firsthand. Nothing builds empathy faster than seeing your API confuse a real user.
- Shift the definition of success from output to outcome. Redefine “done” from “the service is fast and correct” to “the customer’s job is easier and they adopted it.” Reward the outcome, not the effort.
- Coach through questions. In reviews and 1:1s, ask “who is this for, what happens if we don’t build it, what’s the simplest thing that solves their problem” — and let them answer, so the reflex becomes theirs.
- Give them a customer-facing outcome to own. Hand over a real deliverable with a real user and let them talk to that user directly, then recognize the product wins publicly so the mindset compounds.
- Treating product thinking as coachable, with a concrete method.
- Using direct customer contact, not exhortation, as the teacher.
- Redefining success as outcome and adoption, not output.
- Coaching by asking, so ownership transfers to the engineer.
- Awareness that infra has internal customers who can be neglected.
A worked example (CARL)
Context. I had an excellent engineer on the Ads Events storage team — deeply technical, one of the best debuggers I’ve worked with — who consistently built things that were elegant but that downstream teams struggled to adopt. He’d shipped a new ingestion client library that was, by every internal benchmark, faster and more correct than the old one, and he was frustrated that adoption had stalled. His instinct was that the downstream teams were being lazy. The real issue was that he’d optimized for the system’s internals and never for the experience of the engineer who had to integrate it, and he genuinely didn’t see the difference.
Actions. I started with the why rather than the what. In our 1:1 I didn’t tell him the library was hard to use — I asked him who the customer was, and he answered with a system, not a person. So I made it a person: I arranged for him to pair for an afternoon with an engineer on one of the downstream analytics teams who was mid-migration onto his library, and I asked him to just watch and take notes, not help. He came back visibly rattled — he’d watched a competent engineer take two hours to do something he thought was a five-minute setup, tripping over unclear defaults, a confusing error message, and missing migration docs. That single afternoon did more than any feedback I could have given. From there I reframed success explicitly: I told him “done” for this work wasn’t “the library is fast,” it was “three downstream teams have migrated and would recommend it,” and I made that the goal we tracked. Then I changed how I showed up in reviews: instead of critiquing his design, I asked questions — who is this default for, what does the integrating engineer see when this fails, what’s the smallest change that would’ve saved that engineer the two hours — and I made myself wait for his answers instead of supplying them. I also gave him real ownership of the outcome: I made him the DRI for adoption, not just for the code, which meant he owned the migration guide, the office hours, and a short feedback loop with each adopting team. I deliberately did not take that customer relationship on myself, even when it would have been faster.
Results. He rewrote the defaults and the error messages, wrote an actual migration guide, and ran two office-hours sessions — and adoption moved from stalled to the majority of target teams over the following quarter. More importantly, on his next project he opened with a one-pager about the internal customer and the problem before he wrote any design, unprompted. The change generalized: he became the person on the team who’d ask “but who is this for” in other people’s reviews.
Learnings. I’d been tempted to just tell him “make it easier to use,” which would have gotten me a slightly better library and no change in the engineer. What actually moved him was contact with the customer’s pain plus ownership of the customer’s outcome. The lesson I carry: you don’t install product thinking by explaining it, you install it by connecting the engineer to a real person they’re accountable to — and then getting out of the way.
Common follow-ups
What if the engineer resists — “that’s the PM’s job, not mine”?
How to answer- Reframe, don’t argue. Product thinking isn’t doing the PM’s job; it’s building the right thing well, which makes their engineering better and their impact bigger.
- Tie it to their growth. Show that senior and staff impact comes from judgment about what to build, not just skill at building — it’s a career accelerant, not a chore.
- Start small. Ask for one product question per design, not a full PRD; make the first step low-friction.
- Let a customer convince them. One conversation with a frustrated internal user usually does more than any argument from you.
How do you coach product thinking on a pure infra team with no external users?
How to answer- Name the internal customer. The downstream engineering team is the customer; their integration and operational experience is the product.
- Measure adoption and satisfaction. Track migration rates, support load, and developer feedback the way a product team tracks users.
- Treat DX as the product. Docs, defaults, error messages, and onboarding time are the user experience of infrastructure.
- Connect to the end user. Trace how the infra ultimately serves the real customer, so the “why” doesn’t stop at the API boundary.
How is coaching this different for a junior versus a senior engineer?
How to answer- Junior: give more scaffolding — the explicit “who is this for” questions and a concrete customer to shadow.
- Senior: raise the altitude — expect them to define the customer problem and shape scope, and hold them to owning the outcome.
- Senior as multiplier. Coach a senior engineer to model and demand product thinking in others’ reviews, so it spreads.
- Match the stretch. Give each a deliverable one notch beyond their current altitude, not a generic lecture aimed at everyone.
How do you know it worked and make it stick?
How to answer- Watch for unprompted behavior. The tell is when they open with the customer and the problem before you ask.
- Measure the outcome. Adoption, satisfaction, and reduced support load show the mindset changed the work, not just the talk.
- Recognize it publicly. Reward product wins visibly so the team learns what earns credit.
- Bake it into the process. A lightweight “who is this for” section in design docs makes the reflex a team norm, not one person’s habit.
- Adoption / usage dashboards — pull the migration and adoption numbers that reframed success from output to outcome.
- 1:1 notes — pull the coaching arc, from the “who is the customer” question to the unprompted product framing later.
- GSD — pull the deliverable where the engineer owned the customer-facing outcome, not just the code.
- Workplace / downstream feedback — pull the internal-customer feedback and support threads that made the DX pain concrete.
- Perf / calibration records — pull the growth-in-scope evidence tying product thinking to the engineer’s trajectory.