If it's a Nice Problem to Have, Don't Solve it Now

When building a product from scratch you need to do a lot of hard things all at once, with limited resources. The standard advice is to take an iterative approach, prioritising things and then cycling quickly through them, finding solutions just good enough to move things forwards before moving onto the next thing.

It's good advice, but hard to follow in practice. Often when you explore solutions to a problem, even simple ones, the problem reveals itself to be more complex than you'd anticipated. You find sub-problems, and tangental problems, which look just as important as the original. It's easy to go off track and end up deep into the problem you were supposed to just find a quick solution to. After all, it's just one more thing, you're thinking about it, and you'll have to solve it at some point anyway. Why not now?

I've made this mistake a lot. I'm trying to get better at being strict about saying "not now" to new problems that I discover in the middle of an iteration, and avoid getting sidetracked from shipping by working on things that can be left for later. I'd like to share a tactic I use to do this that has worked well for me. It's to ask a simple question about each new problem I encounter: "From my perspective right now, is this a nice problem to have?". If yes, I skip it. If no, I work on it immediately.

An example to illustrate is signup functionality. Let's say I'm starting on a new product. Without signup, there's no possibility of getting any users, which is a problem. From my perspective right now, is this a nice problem to have? No - I have zero users right now, and can't get any until signup is done. The only way to move forwards is to build signup.

Whilst I'm building signup, I realise that I probably also need reset password functionality. If a user signs up, but then forgets their password, that's a problem. But from my perspective right now, is this a nice problem to have? Actually, yes! I have zero users, but having this problem implies I would have users, which would be great. Reset password functionality is important, and will absolutely be required eventually, but I can do it later. First, I should ship anything that's stopping me from getting users in the first place.

There are always tiers of functionality which build upon one another, and this simple question provides a neat hack to sort things in order of when they'll actually be useful so you can build and ship that functionality in faster iterations, rather than delaying shipping while you batch and build everything up front. Try it out when you next build something.