📣 The feature that was "nice to have" until customers saw it

👋 Hey friends!

Somewhere in your backlog right now, there's a ticket called something like "make this feel smoother."

It's been there for three quarters.

Everyone agrees customers would like it. Nobody can explain why it should beat the bug fix sitting next to it.

On Wednesday I wrote about delight being customer success built into the product. Today is the harder part: getting it past planning.

My team was building a new in-context library for adding reports to a dashboard. Before this, adding a report was a long process that didn't even happen on the dashboard itself.

The new library fixed that. The panel lived right on the dashboard page. Big improvement.

But one thing didn't change. When you added a report, it still dropped to the bottom of your dashboard, and you had to drag it back up to where you actually wanted it.

It worked. It just didn't flow.

That's exactly the gap where delight lives.

I knew we needed drag and drop, so you could place a report exactly where you wanted it, right from the panel. It was hard to prioritize. It added technical complexity, and on paper, it wasn't core to the problem we were solving.

So instead of arguing for it, we showed it. We put prototypes of the before and after in front of customers.

With the old flow, customers said things like "yeah, this is better than before."

With drag and drop, they said "this feels so much more intuitive and smooth."

That shift in language changed the conversation, and drag and drop went from nice to have to must have.

1. Find the "it works, but" moment.
Delight hides right after a big improvement, wherever an old default survived.
If customers can finish the task but have to clean up after themselves (rearranging, renaming, re-clicking), then you've found a delight opportunity that's actually part of the core problem.

2. Stop arguing. Prototype the before and after.
"Customers will love it" is an opinion. A side-by-side comparison is evidence.
If your idea keeps getting pushed for being "not core," then build the cheapest prototype that shows both versions and put it in front of 3 to 5 customers.

3. Listen for the language shift.
"Better than before" is a polite pass. Words like "intuitive," "smooth," "finally," or "oh, nice" are the signal.
If customers only describe the new version as an improvement, then it's probably still a nice to have. If they describe how it feels, then write down their exact words. That's your pitch.

4. Name the cost honestly.
Delight usually costs something. For us, it was technical complexity.
If engineering flags extra effort, then put it next to the customer quotes in the planning doc. Let the team weigh real effort against real reactions, not guesses.

5. Tie it back to the problem you're already solving.
Don't pitch delight as a separate feature. Pitch it as finishing the job.
If the project goal is "make adding reports easier," then dragging a report back up from the bottom is part of that problem, not an extra. (👀 This framing does a lot of heavy lifting.)

Customers rarely ask for delight directly. They'll tell you the new version is "better" and move on.

Your job is to show them the version that feels right, then listen for the moment their words change. That's when nice to have becomes must have.

P.S. If you’ve been affected by a layoff recently, I’m sorry. Hit reply and tell me where you’re at. I’ll do what I can to help, whether that’s feedback on your resume, interview prep, or just someone to talk it through with.