Design Thinking Is Not a Workshop — It’s a Hiring Criteria

It was 10:15 on a Wednesday — mid-sprint planning — and Somchai was leaning forward in his chair, palms flat on the table, making his case for the third time. Not about scope. Not about user impact. About whether the ticket was a five or an eight. The meeting room on level 6 had that particular warmth of too many people and not enough ventilation, the glass walls fogging slightly at the edges, and the engineers around the table had developed a sudden fascination with their laptops. Someone’s Thai iced tea sat untouched, condensation rings spreading across the table. “But my points,” Somchai said — not loud, but with the kind of quiet intensity that makes everyone else go very still. Nobody in that room was thinking about the user. Least of all Somchai.

Here’s the thing: Somchai wasn’t broken. Somchai was perfectly calibrated to the system we’d built around him. Months of velocity-driven conversations had taught him that points were the scorecard, and he was playing to win. The fact that nobody — including Somchai — could tell you whether anything he’d shipped in the last quarter had moved a single metric? That wasn’t Somchai’s failure. That was ours.

There’s a two-day design thinking workshop happening right now at a company somewhere in the world. Forty engineers are learning about empathy maps. They’ll do a post-it note exercise. They’ll prototype something in cardboard. They’ll go back to their desks on Monday and build exactly what the product spec tells them to build. Nothing will change. And the reason nothing will change has nothing to do with the workshop’s content and everything to do with a fundamental misunderstanding: most companies treat design thinking as a training programme when it should be a hiring criteria.

The Feature Factory Is a Hiring Problem

John Cutler’s “12 Signs You’re Working in a Feature Factory” resonated so widely because it described a symptom almost everyone recognises — teams cranking out features nobody measures, nobody validates, nobody questions. The standard diagnosis is that it’s a process problem. Fix it with OKRs. Add measurement rituals. Run product discovery sprints. And yes, those help. But they all share the same assumption: that the people executing the process have the underlying capability to think in outcomes rather than outputs.

What if they don’t?

Most engineering interviews test for technical competence — can you solve this algorithm, design this system, debug this code? They don’t test for product instinct — can you question whether this feature should exist, identify the user need behind the request, recognise when a solution is technically elegant but practically useless? The result: you hire engineers who are excellent at building things and terrible at questioning whether those things should be built. Then you send them to a workshop and wonder why nothing changes.

Here’s the number that should keep you awake: according to research by Ronny Kohavi at Microsoft, only 10–30% of product changes actually improve metrics. That means 70–90% of what we build doesn’t move the needle. The engineer who asks “should we build this?” before writing a line of code is worth more than the engineer who builds it twice as fast. We just don’t interview for that engineer.

I’ve written before about how engineering leaders should focus on measurement over implementation — my old CTO Yaron’s relentless “what’s the KPI?” approach. But Yaron’s question only works if the engineers in the room are capable of thinking in KPIs. If their mental model is “I ship story points,” no amount of KPI-focused leadership will bridge the gap. You’re layering methodology on top of a capability gap.

What You’re Actually Looking For

This isn’t a checklist. It’s a mental model for the traits that separate product-minded engineers from pure implementers.

The first trait is curiosity about the user, not just the technology. It’s the engineer who reads the Jira ticket and asks “why does the user need this?” before asking “how should I implement this?” This isn’t about being difficult — it’s about a natural orientation toward understanding the problem before jumping to the solution. When you describe a feature request to a candidate in an interview, do they ask about the user context, or do they jump straight to architecture?

The second is the instinct to question the spec. Not contrarianism — genuine critical thinking about whether the proposed solution matches the stated problem. The engineer who says “the user asked for a filter, but looking at the data, they’re really trying to find X — would a smarter default solve it better?” This connects directly to Amazon’s “working backwards” approach: starting from the customer need and working backward to the solution, rather than starting from a technical capability and looking for a problem to solve.

The third is comfort with ambiguity. Product problems are messy. The user doesn’t know what they want. The data is incomplete. The requirements are contradictory. Engineers who need a perfectly specified ticket before they can start are implementers, not product engineers. The ones who can operate in the grey space — who can take an imperfect understanding and still make progress — are the ones who build products that users actually want. I’ve written about how this same capability manifests as constraint literacy — the ability to negotiate the gap between what’s asked and what’s possible, rather than defaulting to hero mode or wall mode.

The fourth is business context awareness. Does the engineer understand why the company exists, how it makes money, and where this feature fits in that picture? An engineer who understands the business model will naturally question features that don’t connect to value creation. As I wrote in Semantic Monitoring, the question “what does this application do?” separates engineers who own their systems from those who merely operate them. The product engineer answers with the problem their system solves. The implementer answers with the tech stack.

How to Interview for It

Most engineering interviews are 100% technical. Adding a single product-thinking question changes the signal dramatically.

The “Why Would We Build This?” question. Present a real feature request — sanitised from your own backlog. Ask the candidate to evaluate it. Not to design the solution — to question whether it should be built. Good signals: they ask about user data, suggest alternatives, identify assumptions, propose a way to validate before building. Bad signals: they immediately start designing the solution, don’t ask about the user, treat the spec as given.

The question I actually use: “Tell me at a high level what your application is and what it does?” It’s purposely broad and open-ended. Deceptively simple. The way candidates answer reveals how they understand their system. Some start with what the UI looks like. Some start with the technical architecture. None of these are wrong answers — but all of them tell you about the person.

The product engineers? They start with the problem their system is solving. “We help users find the right hotel for their trip by…” or “Our system processes payments across 300+ methods so that…” That’s the signal. That’s the person who understands why they’re building, not just what they’re building.

An engineer who describes their application as “a React frontend with a .NET backend that talks to three microservices” has told you their mental model is technical. An engineer who says “we help small businesses manage their inventory so they don’t lose sales to stockouts” has told you their mental model is user-centred. Both can write excellent code. Only one will question whether the feature they’re building actually solves a user problem.

This question works because it can’t be prepared for. There’s no “right” answer to study. It reveals a worldview, not a skill. And it’s something any interviewer can use — you don’t need to restructure your entire hiring process to add it.

Why Workshops Fail (And What Works Instead)

Workshops fail because they try to install a capability through information transfer. You can’t install empathy through a slide deck any more than you can install taste through a coding standard.

The basketball coach Pat Riley once said, “Excellence is the gradual result of always striving to do better.” He wasn’t talking about software, but he was describing exactly why a two-day workshop doesn’t work — excellence in user empathy, like excellence in anything else, comes from daily practice embedded in the work itself, not from a one-off event followed by business as usual.

So what actually works?

Exposure to users — not user research reports. Engineers sitting in on user testing sessions. Not watching a summary — sitting there, watching a real person struggle with the thing they built. This is visceral. It can’t be abstracted away into a report. When an engineer watches a user fumble through a booking flow they built, the business impact becomes immediate and personal in a way no dashboard ever will. We use the Jobs to be Done framework to bring engineers into product thinking — understanding the “job” the user is hiring the product for. It’s not about making engineers into designers. It’s about developing the empathy muscle that makes product instinct possible.

Pairing engineers with designers during discovery. Not the handoff model — design produces spec, engineering implements. The collaboration model — engineering and design explore the problem space together. When engineers participate in discovery, they develop the empathy that workshops try to teach. They surface constraints that change the solution. They understand the why behind the what, and that understanding compounds with every project.

Celebrating “we didn’t build it” decisions. Culture eats process. If your organisation only celebrates shipping, engineers will optimise for shipping. If you also celebrate the decision not to build something — because the team determined the user didn’t need it, or found a simpler solution — you create an environment where product thinking is rewarded. Researchers at the University of Virginia, led by Leidy Klotz, found that people overwhelmingly default to adding rather than subtracting when asked to improve something. The engineer who asks “should we build this?” is fighting a cognitive bias that’s hardwired into all of us. That deserves celebration, not a puzzled look from the Product Owner.

Making “how will we know?” a reflex, not a ritual. When every engineer asks “how will we know if this works?” naturally — before writing a line of code — you’ve succeeded. When it requires a facilitator to prompt it, you haven’t. This is the daily practice that no workshop can replace.

The Organisational Immune System

Why do companies that know about design thinking, that send people to workshops, that talk about user-centricity, still operate as feature factories? Because the organisational immune system rejects the change.

“We don’t have time for discovery.” Same energy as “we don’t have time to do it right.” The cost of not doing discovery is invisible until a feature ships and nobody uses it — which, remember, happens 70–90% of the time.

“That’s the PM’s job.” The division of labour that creates the feature factory: PMs decide what, engineers decide how. In a product engineering model, engineers participate in the what — not to overrule PMs, but to bring technical constraints and possibilities into the conversation earlier. This is constraint-talk in action — and it requires product instinct to do well.

“Our interview process is standardised.” Adding a product-thinking question feels risky because it’s “subjective.” But so is every system design question — we just pretend it isn’t. The interviewer’s judgment is already the mechanism. You’re just adding a dimension to what they’re judging.

“We hire for technical excellence and train for everything else.” This is the assumption this entire post challenges. You can teach someone React. You can teach someone system design. You cannot teach someone to care about users. You can create environments where caring is expected and rewarded — but the seed has to be there. As Tim Brown of IDEO argued in Change by Design, what you’re looking for is the “T-shaped” quality — deep technical skill with a genuine, intrinsic curiosity about the people who use what they build.

There’s a cultural dimension here worth naming. In a South East Asian engineering context — the same dynamic I explored in Teaching Engineers to Speak in Constraints applies to product instinct: engineers may not question the spec not because they lack product thinking but because culturally they don’t feel it’s their place. In these contexts, screening for product instinct at hiring is even more important, because the environment may not naturally encourage it to emerge. You need to select for the seed and then build the culture that gives it permission to grow.

The Transition: From Feature Factory to Product Engineering

I’ve done this — transitioned teams from feature factories to product engineering teams. Here’s what I’ve learned.

Most engineers are fine. They adapt. Many flourish — they were waiting for permission to care about outcomes, and now they have it. The ownership gradient I’ve written about before maps directly onto this: engineers who were stuck at Station 1 — waiting, executing what’s asked — often had product instincts that were never given room to breathe.

But some hit a wall. The resistance sounds like this: “Before, I was responsible for X story points per sprint. Now you want me to be responsible for business results?”

That sentence is the feature factory’s final defence mechanism. It’s an engineer saying: I understood the old game. I was good at it. The score was clear. Now you’re changing the rules, and I don’t know how to win anymore.

It’s a hard adjustment. Some don’t make it. But most do — and the ones who make it tend to flourish, because they’ve gone from being measured on activity to being measured on impact, and impact is more meaningful work. The senior engineer plateau I wrote about — that quiet disengagement that happens when technically excellent engineers stall — is often caused by exactly this: an engineer who’s never been connected to the purpose of what they build. Design thinking as a capability prevents that plateau because it keeps engineers connected to users, to outcomes, to the reason any of this matters.

The Somchai story opens this post. This section closes the loop. Somchai didn’t need a design thinking workshop. Somchai needed to have been hired into a team that never let velocity become a scorecard in the first place — or, better, Somchai needed to be the kind of engineer who would have questioned that scorecard himself. Velocity should tell you whether your sprint was realistic. It should help you plan the next one. The moment it becomes something you report upwards, it becomes something you game. And gamed metrics tell you nothing about whether you’re solving problems for the humans who use your software.

From Workshop to Worldview

Design thinking isn’t a methodology. It’s a worldview — a way of approaching problems that starts with the human and works backward to the technology. Steve Jobs is often quoted as saying “people don’t know what they want until you show it to them.” But Jobs himself corrected this reading at the 1997 WWDC: “You’ve got to start with the customer experience and work backwards to the technology… I’ve made this mistake probably more than anybody else in this room.” The real lesson from both Ford and Jobs isn’t “ignore your customers.” It’s “customers have problems that need solving, not solutions that need implementing.”

When design thinking lives in a workshop, it dies on Monday. When it lives in your hiring criteria, your onboarding, your promotion criteria, your shared taste, and your culture — it becomes the way your organisation thinks.

The test is simple: can your engineers explain who benefits from the thing they’re building, and how you’ll know if it worked? If they can, you’ve hired product engineers. If they can’t, you’ve hired implementers. Both are useful. But if you want to stop being a feature factory, you need more of the former and fewer of the latter.

Now, if you’ll excuse me, I need to go prepare for an interview. I’ve got one question ready that isn’t about system design or algorithms. It’s “tell me what your application does.” The last candidate talked for four minutes about their tech stack. The one before that talked for thirty seconds about the problem their users have. Guess which one I’m recommending we hire.