A “good problem to have” is very rarely, in fact, actually good to have.
The timing of the tweet was perfect – I read it the morning after I’d been reading Steve Blank‘s Four Steps to the Epiphany in which he talks about the received wisdom of the Technology Lifecycle Adoption Curve and how startups that focus on the execution of product development and the adoption of their product are in danger of never even getting close to that point. Steve quoting his grandmother:
You should be so lucky to have that problem.
In a lean startup like Singletrack we talk about “Nice Problems to Have” or “High Quality Problems” all the time. When we were looking for our first customer we talked about the need for customer support and particularly how we would cope with supporting a customer in a totally different timezone. That was a HQP – we should be so lucky to get a customer that needed support. Once we got that customer and started looking for our second we talked about how we were going to need a much more formal and robust release process for our product. Another HQP – we should be so lucky to get another customer.
After the second and third customers arrived in quick succession we found the HQPs were multiplying. If we were to hire a salesperson to help us push this thing to a wider market than the very narrowly-focussed one that brought our first three customers we’d need some sales collateral including a much improved website. If the salesperson were to have a chance of building a sales pipeline from scratch we would need to do some marketing. If these efforts were successful we would no doubt have to grow the development team. All problems that we would be lucky to have.
But the thing about Nice Problems to Have is that they are still problems, and some of them are big, nasty, difficult problems. What makes them Nice to Have or High Quality is the situation we find ourselves in when we first recognise them, not the problems themselves. When we recognised the support problem it was an HQP because we didn’t have a customer to support and we really wanted to land that first customer. Once we got that customer and they were in a timezone five hours behind us it was a real problem … and when we got another customer in a timezone 10 hours ahead of us the problem got harder. It was very good to have the customers that brought us these problems, but as @isaach put it, these were not problems that were actually ‘good to have’.
When you realise that HQPs are just problems its tempting to think you should do things earlier in order to mitigate them. Don’t.
What we’ve learned in our startup is that when we spot a problem looming on the horizon that comes as a consequence of achieving the next step in growing our business we:
- Identify it as an HQP.
- Spend more time worrying about identifying when we need to solve it rather than how we are going to solve it. But we don’t spend too much time worrying about it.
- Concentrate our efforts on bringing about the circumstances in which the problem we’d be lucky to have becomes a problem we’ve actually got.
- When those circumstances come about and the problem is real: now is the time to start worrying about how to solve it.
- Don’t beat ourselves up about what we could have done earlier to mitigate the problem, especially if it is a big, nasty, difficult problem.
- Get it solved.