Book Club: Product Delight by Dr. Nesrine Changuel

Product Delight by Dr. Nesrine Changuel argues that in a market where almost everything works, working is no longer the differentiator.

Once a product reliably does its job, what sets it apart is how it makes people feel. Changuel, who has built products at Google, Spotify, and Microsoft, set out in her book to "demystify the concept of delight and raise awareness of its power.” What we learn is that delight is something you can design on purpose rather than sprinkle on at the end.

She splits delight into three understandable buckets.
1. Low delight solves a functional need and nothing more.
2. Surface delight speaks to an emotional need but not the core job, the playful flourish that makes you smile and then fades.
3. Deep delight does both at once, solving the problem and earning the attachment.

Her Delight Grid maps solutions against functional needs on one axis and emotional needs on the other, so a team can see at a glance how much of its roadmap is low, surface, or deep.

Source: Nesrine Changuel, "The Delight Grid."

What I keep coming back to is her 50/40/10 rule: roughly half your roadmap on core utility, 40% on deep delight, and 10% on surface delight. It is genuinely hard to balance delight against function, and a simple ratio gives a team shared language for that tradeoff instead of relitigating it feature by feature.

She is just as practical about proving it matters. Rather than trying to put a number on an emotion, she tracks its effects, like moving Skype from a vague satisfaction score to a single operational metric, the Poor Call Rate, that the team could actually move. Each product will have a different way to measure delight, but she gives some ideas on how to get started. The through-line is her case that "when delight is treated as a strategic lens rather than a finishing touch, entire organizations can rally around creating products that are not just functional but unforgettable."

Some questions worth sitting with as a product team:

• If we sorted our current roadmap into low, surface, and deep delight, where would it land? Anywhere close to 50/40/10? (Read her book or website to learn about motivators and how to more accurately create your grid.)

• Where could something we have already shipped be lifted from low delight into deep delight without much added scope?

• What is our version of the Poor Call Rate, the one metric that would tell us whether delight is present or missing?

• If functionality is table stakes in our market, what emotional need is our product really meeting, and do we agree on what it is?

I saw Dr. Changuel speak earlier this year. She was a dynamic speaker, introduced and then in a Q&A with Matt LeMay, whose own book, Impact First Product Teams, I wrote about here. Seeing the two of them together was a nice bit of synergy. What stuck with me was how concrete she was, pulling delight out of ordinary daily interactions and out of her own work as a PM, walking through how she reasoned about these tradeoffs with her team and made the case for them. It is one thing to read the framework and another to watch someone use it to advocate for the work. Definitely a book to add to your professional product library. 

Research Your Stakeholders Like Your Users

Product and UX folks ruthlessly research and analyze their users, to great effect. In fact a closing statement of mine in my team meetings is “go talk to your users”. While there is always room for improvement, this is a skill that we all know and employ well.

An artifact of that is often a user map. At its core, a user map is trying to answer questions around what is this person trying to do, what's getting in their way, and what do they actually need (which is often different from what they say they want). You're looking at goals, pain points, context, and behavior. And crucially, you're looking for the gap between what they say and what they do.

In contrast, the traditional stakeholder map, which we've explored before, is mostly about power and interest. Where does this person sit? How much do they care? How much can they affect your work? It's a useful diagnostic. But it's organizational, not human. It helps you categorize people. It doesn't help you understand them.

An interesting move is what happens when you apply the user research lens to a stakeholder. Instead of asking how much power this person has, you ask: what are they actually trying to accomplish this quarter? What are they afraid of? What are they protecting? What do they say they want versus what do they actually respond to? What context are they operating in that you can't see from your seat? Where is the friction in working with you (even if they'd never say it out loud)?

That's user research, but applied inward.

Designers, researchers, and product managers use this kind of curiosity every day. It's a skill. The shift is simply in recognizing that your stakeholders have pain points too. They have constraints you can't see. They have things they're trying to protect. Treating them accordingly - with the same rigor and genuine interest you'd bring to a user interview - tends to change the quality of the conversation. You can stop negotiating and start understanding.

---

STAND-UP EXERCISE

Choose one stakeholder your team interacts with regularly, perhaps someone whose priorities feel misaligned, or whose feedback is hard to predict, or who you find difficult to bring along.

Using the same empathy map format you'd apply to a user map that stakeholder as a team. Work from what you already know: how they show up in meetings, what they push back on, what they consistently ask for, what seems to matter to them. Note where your knowledge is thin — those gaps are as useful as the answers.

I like to use a virtual whiteboard with the following sections:

• Says: What are they saying about their expectations, concerns, and feedback? Get direct quotes from the stakeholder. 

• Thinks: What are they thinking but might not be vocalizing? Consider their worries, aspirations, and priorities. 

• Does: What do they do in relation to your product? Note the stakeholder's actions and behaviors. 

• Feels: How do they feel about the product or their involvement? Observe their tone and body language.

• Hears: What might the stakeholder hear from others that influences their perspective? Feedback from colleagues, market trends, or industry news…

Once you have this, you can begin brainstorming pain points and opportunities. Try to pinpoint specific areas where the stakeholder faces challenges or frustrations. And then highlight areas where improvements could be made to better meet stakeholder needs and expectations, and improve the relationship.

When you're done, sit with the map for a moment. Does anything surprise you? Where are you making assumptions you haven't tested? Is there a conversation you could have, or a way you could frame your next interaction, that accounts for what you now see? Which of the opportunities are you going to take advantage of?

The goal isn't to psychoanalyze your colleagues. It's to bring the same quality of attention to the people inside your organization that you already bring to the people outside it.

Use Context For More Influence - A Podcast

This month I was invited by User Interviews to be on their UX research podcast, Awkward Silences. The theme of our discussion is how designers, PMs, and researchers can wield greater influence in their organizations, through learning about the environment and the context. We talk about understanding decision-making processes (what I call “decision literacy”), translating design work into business impact, and creating the conditions where teams do their best work.

I encourage you to listen (perhaps with your product team!) and bring some of these strategies or exercises back to your day to day.

Highlights include:

• 11:08 Design Skills That Can't Be Replaced by AI

• 15:56 Decision Literacy in Organizations

• 21:42 Surprising Realities of Leadership Meetings

• 24:36 Building Influence Without Organizational Power

• 29:01 Storytelling via Roadmaps Exercise

• 35:47 What Trade Off Are You Most Uncomfortable Making

Listen to the full episode here, or wherever you get your podcasts.

The New Hire Test for Success

What would success look like if we had to explain it to a new hire?

When someone new joins the team, they often ask deceptively simple questions.
“How do we know if we’re doing well?”

On the surface, that question is about clarity.
At a deeper level, it’s about coherence.

Having a new team member is a quiet forcing function that you can use to accelerate the team’s coherence. New hires don’t know your history, and they don’t know your internal shorthand. But maybe most importantly here, they don’t know which metrics are sacred and which are ceremonial. 

John Cutler often critiques “success theater”, where vanity metrics or dashboards look like they are creating signal, but actually generate noise. A new team member won’t know the difference right away. They’ll take what we present at face value.

Many teams can list metrics. Fewer can describe what winning actually feels like. And if explaining success requires a 40 slide deck, or a dozen KPIs and OKRs layered together, that’s a signal worth noticing. As Richard Rumelt has written, “Good strategy is simple enough to explain, but disciplined enough to execute.” If you can’t explain success simply, there’s a good chance your strategy is either fragmented or overly abstract.

---

STAND-UP EXERCISE

Use the idea of a new team member as a diagnostic lens.

Take a few moments asynchronously to write down how you would explain success of the team to a fictional new hire. Don’t just think about metrics, but also the meaning. What would you have them pay attention to? What matters most?

Then bring those explanations together and look for themes. Did different practice areas have distinct definitions? Did folks with varied lengths of tenure on the team explain it differently?

This exercise isn’t just about onboarding; it is about potential misalignment within the team. The places where definitions diverge are often the places where tension quietly lives. Use this to come together on a shared definition of success for your team and for your product. If success can’t be explained coherently, it can’t be protected intentionally.

Dimensions of Quality

Most product teams care deeply about quality. But when timelines tighten or pressure increases, quality often becomes a vague, emotionally loaded concept. One person worries we’re moving too fast. Another one worries we’re overthinking. Conversations stall because we’re using the same word to mean different things.

Quality isn’t a single standard you either meet or miss. It’s a set of attributes that compete for attention. And different moments in a product’s life put different kinds of quality at risk.

Quality Isn’t One Thing

One of the most useful ways to talk about quality comes from Ami Vora, who describes four distinct dimensions teams are constantly balancing:

• Performance — how fast, responsive, and reliable the product feels

• Bugs — correctness, stability, and freedom from defects

• Completeness — whether the solution actually solves the full problem

• Consistency — coherence across flows, surfaces, and behaviors

Every team makes tradeoffs across these dimensions. That’s not a failure; it’s reality. The problem arises when those tradeoffs are implicit. When no one names what’s most fragile, teams start talking past each other, and quality debates become personal instead of practical.

When quality discussions stay abstract, they tend to escalate quickly. Engineers may feel asked to cut corners. Designers may feel pressure to ship something unfinished. PMs may feel caught between speed and responsibility.

But when a team can say, “This quarter, completeness is the riskiest thing for us,” or “Performance is the edge we can’t afford to dull,” something shifts. The conversation becomes about judgment, not virtue. It frees you up to focus on intent, not blame. Naming risk creates shared context. It gives teams language to explain decisions and empathy for why others feel tension.

Where Quality Risk Shows Up

You can usually spot quality risk by paying attention to where friction accumulates.

• Where are we cutting scope, and what kind of quality does that affect? Are we creating an experience that feels partial or awkward to a user?

• Where are we deferring work, and what assumptions are we making about impact? Are our inconsistencies eroding trust with other teams?

• Where are customer complaints, internal friction, or workarounds starting to cluster? Are there bugs that felt acceptable individually but now feel risky in aggregate?

Each of these points to a different dimension of quality, and recognizing which one matters most at this moment is what enables better decisions. The goal isn’t to eliminate risk. It’s to make it visible. When teams agree on which kind of quality is most fragile, they can protect it more deliberately, communicate tradeoffs more clearly, and move faster with less friction.

---

STAND-UP EXERCISE
In your next stand-up, on a shared workspace ask the team to vote on one question:

Which quality dimension feels most at risk right now?
Performance · Bugs · Completeness · Consistency

Notice where there’s alignment, or surprise. Invite people to talk about why they voted the way they did. Listen for patterns across roles or perspectives. Engineers, designers, and PMs often see different risks, and all of them are valid signals.

Going forward for this sprint / quarter / release explicitly name which quality dimension you’re prioritizing, and which one you’re consciously putting at risk.