I used to focus on solutions. 

"We're going to add a bookmarking feature”. 

Solutions get messy. The moment you show your solution to the team, it all begins to devolve. Why don't we add X? I don't think you should have Y. Do we really need Z?

I’ve learned that the only reason I'm ever making something is to solve a problem. If the problem isn’t well-defined, we won’t know what to include or what to omit. 

The best way to understand a problem is to find out when it came up. 

Not what, not why, but when.

Asking when a problem occurred gives you a specific situation and clear context. If you don't have this context then you inevitably end up casting the net wide. The idea being that if we cover enough territory we’re bound to solve the problem. 

A wide net means building more things, which means more moving parts, and that means more stuff to maintain. You know what I’m talking about.

Someone wants to bookmark articles. Ask them when they realised this and they'll you about the time they saw a great article in the feed. They couldn't read it then, now they can't find it. They asked for a bookmarking feature but they really want a reading list. Showing them their saved article count makes sense here. Inbox zero is 👍 because it means they've read all their saved articles. 

On the other hand, someone else asked for bookmarking when they wanted quick access to the same 15 articles they refer to several times a week. They value labels and being able to create groups of bookmarks. Inbox zero makes no sense here. 

Knowing when a problem came up gives you context. Rich context is the antidote to a messy team discussion. It allows you to stop speculating about X, Y and Z because you know what to include and what to omit. 

Starting with a clearly defined problem means clearer criteria, fewer moving parts and a more effective solution.


These Hey posts are thoughts-in-progress, they're meant to be conversational. Let me know what you think. Replies to this email go straight to my inbox.