design thinking for pms

Every PM course teaches the five stages of design thinking: empathize, define, ideate, prototype, test. You can find a thousand Medium articles about it. The Stanford d.school poster hangs in every coworking space from Koramangala to Powai.

And yet, most PMs who claim to practice design thinking do not actually practice it. They run a brainstorming session, call it “ideation,” stick post-its on a wall, take a photo for LinkedIn, and then build whatever they were going to build anyway.

I have watched this happen across hundreds of PM cohorts at Pragmatic Leaders. The framework is not the problem. The way PMs apply it is.

This page is about what design thinking actually gives you as a PM — and, just as importantly, what to stop pretending it gives you.

The five stages: what you actually need to know

The Stanford model is not wrong. It is just incomplete for product work. Here is each stage with what matters and what does not.

Empathize — the only stage that actually changes outcomes

This is where 80% of the value lives. Not empathy as a vague sentiment. Empathy as a discipline: going and watching people struggle with their current solutions before you touch a single wireframe.

Kevin D’Souza, who ran product at Ola, made this point sharply in a session with our cohort: the design thinking approach that worked at Ola was not the five-step poster. It was deep empathy combined with lean experimentation. Dunzo started with a WhatsApp group — not a prototype, not an app. A WhatsApp group where people sent delivery requests. That is empathize and prototype compressed into one action.

What empathize means for PMs in practice:

• Sit with your users. Not a survey. Not a Google Form. Sit next to someone while they use your product or your competitor’s product. Watch where they hesitate, where they squint, where they work around your interface.
• In India, go to the field. Your users in Tier 2 cities use your product differently than your Bangalore beta testers. The DELL product leader in our AMA described how design thinking at Dunzo required physically observing delivery partners — not running Zoom interviews from an office.
• Ask about the last time, not the ideal time. “Tell me about the last time you tried to do X” reveals real behavior. “How would you ideally like to do X” reveals fantasies.

Define — framing the problem is your actual job

Most PMs skip this stage entirely. They hear user pain, jump to solutions, and wonder why the solution did not land.

Define means writing a problem statement that your entire team agrees on before anyone opens Figma. It means choosing which user segment you are solving for. It means scoping — explicitly stating what you are not solving.

The failure mode I see most often: a PM runs three user interviews, hears three different problems, and tries to solve all three simultaneously. That is not empathy-driven product development. That is a feature dump with extra steps.

A good problem statement looks like this: “Mid-market HR teams in India with fewer than 500 employees cannot close their monthly payroll within 48 hours because compliance calculations (PF, ESI, TDS) require manual verification against multiple government portals.”

A bad problem statement looks like this: “Users want a faster payroll experience.”

The first one tells your designer what screen to build and your engineer what to integrate. The second one tells nobody anything.

Ideate — the most abused stage

Ideation is useful when you genuinely do not know the solution. If you already know what you are building — and be honest with yourself about this — skip the brainstorm. You are wasting twelve people’s afternoon.

When ideation is actually valuable:

• You have a well-defined problem but no obvious solution path.
• You are entering a new domain and need to explore the solution space.
• Your team has diverse expertise (design, engineering, domain) that can surface non-obvious approaches.

When it is theatre:

• You already decided what to build and want “buy-in.”
• The problem is not defined. You are brainstorming solutions to a vague discomfort.
• Only PMs are in the room. Ideation without engineering and design constraints produces fantasies, not ideas.

Prototype — most PMs get the fidelity wrong

The point of a prototype is to learn something you do not already know. Not to show stakeholders a polished mock-up. Not to “align the team.” To test a specific assumption.

Low fidelity for assumption testing: Paper sketches, Balsamiq wireframes, even a spreadsheet pretending to be an app. Use these when you do not know if the concept works. I have seen PMs at Pragmatic Leaders test checkout flows by printing screens on paper and having users point at what they would tap next. It works. It costs nothing. It surfaces problems in minutes.

High fidelity for usability testing: Figma prototypes with realistic data and interactions. Use these when you know the concept works but need to test whether people can actually use it. If your prototype uses “Lorem ipsum” and fake data, you are testing your layout, not your product.

The mistake: spending two weeks in Figma before validating the core concept. You build a beautiful prototype, show it to users, they say “looks great,” and then they never use the actual product because the concept was wrong — not the interface.

Test — not “demo to stakeholders”

Testing means putting a prototype in front of real users and watching them use it without guidance. It does not mean walking your VP through a Figma flow while narrating what each screen does.

The testing rules that matter:

• Shut up. Do not explain the interface. If you need to explain it, it is not working.
• Watch, do not ask. “Do you like this?” gets you nothing. “Try to complete this task” gets you everything.
• Five users is enough. Jakob Nielsen’s research holds: five users will surface 80% of usability issues. You do not need a 200-person study. You need five people struggling with your prototype on a Tuesday afternoon.

When to use design thinking and when to skip it

This is the part every design thinking course leaves out.

Design thinking is expensive. A full cycle — empathize through test — takes two to four weeks minimum. That is fine for zero-to-one products, major redesigns, or entering new markets. It is absurd for adding a filter to a dashboard or fixing a checkout bug.

Use the full cycle when:

• You are building a new product or entering a new market segment.
• Customer feedback is contradictory and you do not understand the underlying need.
• You have been iterating for months and metrics are flat — something fundamental is wrong.

Use only empathize + define when:

• You have a clear problem but multiple solution paths. The research narrows the path. Then just build.

Skip it entirely when:

• The problem is well-understood and the solution is obvious. Just ship it.
• You are optimizing an existing flow — A/B testing is faster and cheaper.
• You are under time pressure and the downside of being wrong is low.

The India-specific traps

Design thinking was formalized at Stanford and IDEO — both rooted in Silicon Valley norms around user access, research budgets, and iteration speed. Applying it in India requires adjustments that no Western textbook covers.

Trap 1: Users will not tell you the truth in a formal setting.

In many Indian contexts — especially B2B — users are polite. They will nod along with your prototype, say “yes, this is nice,” and then never use it. This is not dishonesty. It is culture. The more formal the research setting, the less candid the feedback.

Fix: informal observation over formal interviews. Sit with them while they work. Watch what they actually do, not what they say they do. A 30-minute shadowing session at their desk reveals more than a one-hour Zoom interview.

Trap 2: The buyer is not the user.

In Indian mid-market and enterprise, the person who buys the software is rarely the person who uses it daily. The IT head evaluates vendors. The HR manager uses the tool. Their needs diverge massively. Design thinking that empathizes only with the buyer produces tools that get purchased and never adopted.

Fix: run the empathize stage with actual users, not decision-makers. Then map the buyer’s needs separately. Your product needs to satisfy both — but the design must serve the user.

Trap 3: Prototyping assumes design resources you may not have.

Many Indian startups at Series A and below have one designer — or none. Running a prototyping cycle when there is no one to prototype is pointless advice.

Fix: PMs should learn basic prototyping. Not Figma mastery — just enough to sketch flows and test concepts. A PM who can create a five-screen wireframe in 30 minutes is more effective than a PM who files a design request and waits two weeks.

Test yourself

Where to go next

• The principles behind good product interfaces: UX Principles for PMs — what you need to know about usability, information hierarchy, and interaction patterns without becoming a designer.
• Getting from concept to testable artifact: Wireframing and Prototyping — tools, fidelity levels, and when to sketch on paper versus build in Figma.
• Making design collaboration actually work: Working with Designers — roles, handoff, feedback, and how to avoid being the PM that designers dread.
• Understanding the people you are building for: User Research Methods — interview techniques, observation, and how to get honest feedback in the Indian market.
• Making sure what you build is usable by everyone: Accessibility — why accessibility is a product decision, not a compliance checkbox.