Discovery as Insurance

Most product teams treat their feedback loop as a form of insurance.

You ship, you watch what happens, you fix what's wrong. That safety net is what lets a team move a little faster than feels comfortable, skip a round of validation, ship the version that's eighty percent right. The cost of being wrong is small, because the correction comes in days. “Move fast and break things” as some tout, or “ship early, ship often”, or even just the practice of continuous deployment.

Some teams don't have that safety net, even if they don't think of themselves as different. A streaming platform building for the Olympics gets one shot at the opening ceremony's traffic. A retailer's checkout flow either holds on Black Friday or it doesn't. A campaign's voter tool has to work on election day, period, with no next release to quietly patch what broke. Tax software has to be right by April, and whatever's wrong then is wrong for everyone, all at once, for a full year.

In each of these, the thing that normally absorbs risk, the fast follow-up, doesn't exist. Whatever assumption is wrong on the day is wrong at full scale, in public, with no cheap way to learn and correct before the next real test. Discovery isn't just the phase before delivery here. It's the only correction mechanism available, because delivery isn't going to offer one.

If discovery is the only insurance available, the real work is finding ways to manufacture more of it before the day arrives, rather than treating the window as pure risk. The attempt is to pull a version of the feedback loop forward, so the team isn't relying on judgment alone when the real day comes.

One move is looking backward instead of forward. Most teams have already lived through a smaller version of their own fixed window and moved on without mining it, last year's midterm elections, last quarter's biggest launch, the summer sale before the holiday one. That data is sitting there, unexamined. It doesn't have to be your own, either. Other companies sometimes publish what broke after their big days, post-mortems, incident reports, case studies. Most teams just don't know to treat this as evidence.

The other move is building a fake version of the day on purpose. A load test that mimics real traffic patterns. A mock election with real people clicking through the real interface. A full internal rollout of the checkout flow before any customer sees it. Even simple tabletop exercises can help a team find flaws in a launch plan before the launch. None of these wait for the real event to teach you something, they construct a rehearsal because the real one hasn't happened yet.

Many teams carrying this type of business calendar don't name it that way. They talk about deadlines, about launch dates, about the big day. Rarely do they talk about it as a loop length, and rarely do they audit their own assumptions against that length honestly.

---

STAND-UP EXERCISE

As a team, name your own fixed window, even if you've never thought of your work that way. It might be a literal event, or it might be a moment where the cost of being wrong multiplies (a big client's onboarding, a seasonal spike, a public launch).

Then ask: what's one assumption we're currently treating as low-risk, something we've silently filed under "we'll fix it after," that actually can't be fixed after? Where are we borrowing insurance we don't have?

Notice where the room gets quiet. That's usually where the real risk is.

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.