TTL 42
Good Morfternight, friends,
Today, I have a general rule for building products: treat “everything works” as the exception.
Because real life isn’t neat: people use your app when they’re tired, on a phone, in a rush, just trying to fix something today. Design for that.
I use this idea a lot in product management, because it’s the only way you can keep customers satisfied—even on the worst day of their lives.
Why am I telling you this?
Because last week I had one of those days. A day that software improvements could have saved.
And I want to make sure this lesson won’t be lost.
The Palermo tale
A little context.
I woke up in Palermo with a simple plan: coffee, drive my colleagues to the airport, then check into the room I’d booked the night before to spend the weekend. At 8:12 am, the hotel emailed: “We’re sorry, there’s been a problem; your room isn’t available. We’ve canceled your reservation.”
Annoying, but manageable—until the systems made it worse.
- I opened the support chat, only to hear “We’re so sorry.” Then a human, not even an AI bot, told me refunds only happen on the original checkout date. So they canceled today, but keep the money until the day I would have left a stay that never happened. Annoying, but I can deal with that.
- I still need a bed for tonight. I open the Hotels.com app. It groups bookings into Trips, defined as a location+dates. At the bottom of my Palermo Trip, there are offers for alternative hotel options. I browse, filter, find a suitable option, pick a room, pay.
- A few minutes later, as I receive the confirmation email, I notice I booked for the wrong days. My original booking was for September 19–21. The app “helped” by shifting my search to 21–23, as if I wanted to extend my stay. It didn’t tell me. It just did it.
I contacted support again, only to hear about non-refundable policies. Not to mention, you can’t even step away from the chat to call an Uber without having to start over.
The reason I’m telling you this isn’t to complain about the trip (even though I feel a little better now, thank you) but because this is the perfect example of a customer using your product on a shitty day.
What went wrong here is that the “alternative options” at the bottom of a Trip in the Hotels.com app assume everything is going well, and that you are trying to extend your trip because you’re oh-so-happy with it. Why would anyone extend a journey in the same location but at a different hotel? It is beyond me. Maybe the people building this app should travel a bit.
The fact is, in the mindset I was in (this is an emergency, I need a room NOW) and the way it was presented, it seemed obvious to me that the app was offering to help, when, instead, it was adding to my misery. Combine that with an inflexible refund policy that makes it impossible to get a refund within 10 minutes of booking, and you have the perfect combination that led me to throw 500€ into the trash.
It wasn’t even lunch time, and I had learned that my room wasn’t available, that the payment I had made for it wouldn’t be refunded until after the weekend, that the second room I booked was for the wrong dates, and the payment I had made for that one would never be refunded.
I still had to find a place to sleep that night… all of that because the Hotels.com app assumed that, if I was looking for alternatives to a hotel that canceled on me, surely it meant I wanted to extend my stay…
So, back to rule zero: design as if nothing works.
Any system that depends on the happy path will fail its users when the real world shows up—bad network, stale caches, time pressure, human stress, upstream glitches, ambiguous emails, half-completed flows.
If you assume things will go wrong—timeouts, duplicated requests, wrong dates—you’ll build software that protects the user. That’s good product design.
Let me ground this in another domain—literally, domain names.
1) The renewal problem
Years ago, we noticed an unusually high number of domains expiring. We investigated, traced the pattern, and found the root cause: the system that sent out “your renewal is due” emails was broken, so many customers never got a reminder. Our setup at the time relied on those emails and manual renewal. If we heard nothing, we assumed the customer no longer wanted the domain.
We changed the rule: renew by default, cancel if the owner tells us to. If we renew and they didn’t want it, we can undo it and refund the fee—annoying, but fixable. If we let it expire by mistake, the address can be taken by someone else, emails won’t reach our customer, search traffic can drop, and trust can erode.
One mistake is reversible; the other isn’t. So we chose to design to avoid the more expensive error.
2) The “do nothing” check that backfires (ICANN)
There’s an annual check of domain owners’ contact details (WHOIS verification). The rule is simple: we email you your details; if they’re correct, do nothing. But, again, if the email on file is already wrong, you never receive the message. You “do nothing,” and the system records that everything is fine.
It meets the rule on paper, but fails the person in reality. Compliance is the floor, not the goal.
There’s a complementary rule I like in development. It’s called the Robustness Principle, or Postel’s law:
“Be conservative in what you do, be liberal in what you accept from others”
On the way in: accept messy formats, partial data, non-standard punctuation, duplicate clicks, and responses that arrive out of order.
On the way out: produce the clean, unambiguous truth your consumer expects—one meaning, one date range, one currency, one confirmation.
The more chaos you absorb, the less you export.
In Palermo, the app already knew my location and my dates. A helpful product would have recognized the urgency and said: “You’re at Palermo Airport and booking for today. Here are the rooms available tonight, sorted by price and response time.”
Much information in, only the right one out.
I have a job for you: find the single worst, most stressful use case for your product—and make it smooth there. If it works on a bad day, imagine it on a good one.
That’s it for today, see you next time.
If someone forwarded this to you, you can subscribe.
I also publish on paolo.blog and monochrome.blog.
Leave a Reply