Category Archives: Start-up

In reply to Stop Chasing Exit Strategies …

Jason Gorman has written an interesting article: “Stop Chasing Exit Strategies And Start Chasing Great Software“. @robbowley tweeted enthusiastically about it and I enjoy a lot of what Rob reads and writes so I went and had a look. The whole thing left me with a great big feeling of “Hmmm”. Normally I’d leave a comment but Jason’s blog doesn’t allow them so after a bit of consideration I decided to write this. I hope Jason reads it and takes the opportunity to respond … I’m not really a fan of blog posts that deconstruct other posts but if I can’t comment there, I can only really comment here.

Let’s start with the detail and then think about the overall message. First off the title. Very eye-catching and if it were “Stop Chasing Exit Strategies” I’d have to agree; I’ve long advocated an approach to entrepreneurship that emphasises building a solid, sustainable business on the basis that if you do, exit opportunities will come (should you want them). Hyping the hell out of a business and then cashing in your chips just before the whole thing implodes is a strategy that has worked for some and failed for many others. I’m not saying its wrong but it’s not for me.

But what do exit strategy, or lack thereof, and software quality actually have to do with one another?

Reading on a bit further the impetus for the article is revealed:

Today it was announced … that police state-friendly social networking site Facebook is acquiring pointless image filter service Instagram for $1 billion.

You don’t have to be a psychoanalyst to determine that Jason isn’t a fan of either Facebook or Instagram and I understand that as neither am I. But it does reveal a prejudice. I know a number of smart, savvy people – many of them top-class developers – who think Instagram is fantastic. I also read this interesting piece by Om Malik where he says (at the bottom):

People love Instagram. It is my single most-used app. I spend an hour a day on Instagram. I have made friends based on photos they share. I know how they feel, and how they see the world. Facebook lacks soul. Instagram is all soul and emotion

From Jason’s article:

My goal is to create better software (and, more recently, to try and help other people create better software). Most important to me is what value software brings to the people who use it.

By Jason’s own definition it sounds like Instagram has hit the nail on the head with the quality of their software in that their users get a great deal from their service. What’s more its not clear to me that Instagram have been chasing an exit in the sense of hyping the hell out of it before it implodes; they’ve grown very quickly and taken on a lot of VC money, and I can’t say whether they are really worth $1B to Facebook or not. But, from what I’ve seen, they’ve taken an idea that people like, have developed it in the face of real user feedback, have scaled their operation and so have attracted an exit opportunity. What’s the problem there?

Okay, enough of the nit-picking. Perhaps Jason just picked a bad example in Instagram. What about the general concept that chasing great software will lead to a good business?

Er, well, no. What defines a ‘good’ technology business, or any business for that matter, is its ability to make money and we all know of many successful businesses, including ones that have been around for many years, who get away with pedalling shit software through weight of market share, iron-fisted defence of patents, or just lack of credible competition. But like Jason I’m personally not interesting in pedalling shit software just because it makes money. However I am interested in making money with my business because that’s what pays our salaries which enable us to keep developing software. And here’s where things get tricky. You see quality software does not necessarily equate to software that users get value from. And users getting value from software does not necessarily equate to a good business model.

But a good business model is necessary for a good business, whether your own or one you work for.

Returning to Jason’s article:

A classic example of this kind of thinking is the very damaging advice being propogated among the tech start-up community that the software that powers your new business only needs to last until you find a buyer.

Jason doesn’t name Lean Startup or Customer Development so maybe he is talking about something else. However, if he is, then I think he’s got the wrong end of the stick. Both Lean Startup and Customer Development – of which I am a passionate advocate – are about understanding what it is your customers want and how valuable it is to them without spending lots of time and effort (yours and theirs) that turns out to be wasted. Its about learning how your business can work. Jason has it absolutely right when he says

The game’s afoot when we start getting feedback from real users. That’s when we really start to learn what works for them and what doesn’t.

Spot on. But let’s not confuse good software that users like with software that customers will buy, or confuse sellable software with a good business (with our without exit opportunities). Personally I think you need to figure what you want from a given situation and work to make that happen. If you want to play high-stakes all-or-nothing exit strategy chasing, be my guest but count me out. If you want to produce software that users love without reference to whether the business makes any money or not, ditto. If you want to produce, and keep producing, valuable software then you need to constantly balance, and rebalance, the many opposing forces in software development, software delivery, sales and marketing, customer acquisition, customer retention, investment, and so on. You need to listen to your users, your customers, the market, your peers, your competitors, current and potential investors and to that little voice which tells you what’s right despite all the evidence to the contrary. You need to work out what makes your software valuable, not in the ‘oh, gee, I really love this” sense but in the “I’m prepared to pay $XYZ for the opportunity to use/advertise through/invest in/acquire” sense.

Fair enough: Stop Chasing Exit Strategies. But don’t Start Chasing Great Software if you’re aiming to build business value. Instead: Chase a Great Business.

Stopping Starting-up

I love start-up. The early ‘wouldn’t it be great if …’ conversations, the commitment to going on a journey into the unknown, the first days when absolutely nothing is in place and things like name, logo, and website are the focus of endless creative conversation, the first customer, the first hire …

Its a hell of a ride.

There’s a huge amount of start-up advice around for the would-be entrepreneur. May favourites are the writings of Steve Blank and Eric Reis; Customer Development and Lean Startup have more to say about how to go from a vague idea to a functioning startup than any other business approach I’ve seen. There’s an increasing amount of support for start-ups, in the UK at least, from various tax breaks for would-be investors to the well-intentioned but somewhat ill-executed Startup Britain. There’s also a lot of very early stage investment money washing around from Angels and Micro-VCs; let’s face it if you’re going to invest in a hare-brained, high-risk scheme dreamt up by a bunch wide-eyed idealists you’re probably better off taking a punt on someone’s idea for a new type of social network than buying Euro-zone bonds.

Start-ups will save us from the global economic crisis!*

But once you’ve started your startup, you’ve done some customer development, you’ve perhaps pivoted your idea, you’ve reached a core of a product and you have some paying customers, then what? Its time to stop being a start-up and establish your business. Steve Blank calls this phase ‘Company Growth’ in Four Steps to the Epiphany.

In my experience** there are a few things you need to stop being a start-up:

A sustainable business model

On day one of your start-up you are concerned with the necessary detail of the company: what are we called, what do we do, where do we work? On day two you should be out there discovering your customers and understanding your potential market. On day three you should be trying to show those potential customers why they should become actual customers. And so on. You shouldn’t be worrying about sustainability, about what you need to keep being successful in 12-18 months time because unless you focus on finding your customers and your product-market fit you won’t be around in 12-18 months time.

But at some point you’re going to know roughly who your customers are and your product will have demonstrated a reasonable fit with the market. At this point you need to be worrying about sustainability because things like cash-flow, excessive overheads, technical debt and the like might just prove fatal if you don’t deal with them.

A sustainable business model is simply one where the revenue exceeds the cost (and beware hidden cost; many lean start-ups rely on the early joiners living with a reduced or waived salary in return for a stake in the long-term success of the company, which is an inherently unsustainable situation). It doesn’t necessarily have to be by a lot and it doesn’t necessarily have to make month-on-month profits, but it does need to support itself. But whilst it is defined by financial security, sustainability is about more than just about the money: a sustainable company will retain its employees, improve its processes, and learn from its internal influences as well as its external ones.

Less Product-Market Fit, more Market-Product Fit

A good product, one that meets the needs of its customers and has established itself in the market, should start to distort that market, no matter how niche (“Find your niche and dominate it”† was one of the excellent pieces of advice we were given on starting Singletrack). Disproportionately successful products like the iPad and Facebook demonstrate this in extremis; the newly-perceived tablet market is actually an iPad market, many times greater in size than the tablet market ever was, and early social networks simply never imagined the market was as big as Facebook has demonstrated it to be.

But all successful products demonstrate this effect to a degree. The current dominant player in our market does one thing well and many other things poorly (according to their customers we’ve talked to). They have distorted the market to be all about their core strength and we are actively seeking to displace them by redefining that market. Some of their customers will buy into us, some won’t, but we hope that in the next couple of years, when people talk about the market we’re in, the conversation will be much more diverse than it is today.

What I’m not saying is that Customer Development is a short-term process, or that an established company no longer listens to or learns from its customers. What I am saying is that in the early days a lean startup will do almost anything (within boundaries of ability, desire and possibly legality) that customers commit to paying for. But as time goes on you have a lot more data to go on and a lot more experience in your market and there will come a time when leading your customers on a market-defining journey is more valuable to you and them than focusing on fitting your product to the market.

Weaning off the founders

In the early days the founders are the company. As the company grows this effect lessens but it will be quite some time until the company is immune to the loss of some or all of its founders. But that is precisely what an established business needs to be. In the early days people will buy into the founders of the business as much as they buy into the product.

In fact I’d go so far as to say that believing in the founder has far more to do with an early customer making a commitment to buy something that doesn’t actually exist yet as whatever it is the product is portrayed as shortly to be doing.

But as time goes on the founders’ need to replace themselves with others who do the jobs they’ve been doing better than they can. They need to reduce their day-to-day involvement and ensure they are steering the company in the right direction. This doesn’t mean they need to make themselves redundant or irrelevant, just that the company should continue on if and when the founders decide to leave.††

In Conclusion

These are the things I think you need to stop being a start-up and get established. But I’m sure there are more and am interested in other people’s experience. It seems to me that with all the buzz about start-up around at the moment, a good body of experience and knowledge about how to successfully stop being a start-up is going to be increasingly important.

*Actually start-ups won’t save us from the global economic crisis but they might just create a few much-needed jobs, create a bit of excitement and confidence, and instil more entrepreneurial spirit in this country.

** Background: I’ve started three companies. The first never got out of being a start-up and died midway through its second year. The second was modestly successful and is still around after 10 years. The third is currently making the transition from start-up to established business.

† Parker Harris, co-founder of

†† I’ll know Singletrack is doing okay when the team start telling me to shut up and let them do their jobs. I’m looking forward to that day.

Technical Debt and the Lean Startup

A conversation on twitter between @david_harvey,  @rachelcdavies@RonJeffries and myself made me to think it was about time to post on my view of technical debt in a lean startup and how that view has changed since the days of running XP-based projects for established companies.

There’s a lot of information about Technical Debt out there on the web (including Ward’s Video, a clear summary by Martin Fowler, and an interesting, albeit somewhat flawed, article by Rod Hilton) and I’m not going to get into a detailed description here, but at its simplest level it says that making some quick-and-dirty choices today may lead to pain later on, and that pain is like a debt that you’re going to have to pay back at some point.

Its that ‘at some point’ which has led me to believe there is a difference between technical debt as applied to a lean startup vs. that applied to a project for an established business. In a project you are trying to deliver something which meets some kind of business case. You will know roughly who the customer is, roughly what their objectives are, roughly what you can spend (time and money) in order to achieve them, and so on. There’s going to be a lot of stuff that isn’t known but there are some constraints in place. When I used to use XP to deliver these kinds of project we had a very simple view of technical debt: don’t incur it if you can avoid it and, if you can’t avoid it, pay it down at the earliest possible time. Why? Because in these projects sustainability is a primary objective: you know you’ll have to pay the debt down at some point so why let it grow uncontrollably?

In a lean startup not only do you not know what your customers want, you don’t even know who they are, and you usually have less time and money to spend on finding out than most established companies would try and run a project with. Your primary objective is finding those customers and learning what they want, not sustainability. Which isn’t to say sustainability is unimportant, just that its not your primary objective; once you have a business, then you worry about how to make it sustainable. Its a High Quality Problem.

Here are some examples of technical debt we incurred at various stages of our search for customers and what they wanted:

  • Areas of the system understood by only one person. I’m a pair-programming fanatic and would love for everything in our system to be developed by pairs. But when you have only one developer in the company, that isn’t possible. When you have two developers and one has to go support a sales meeting, that isn’t possible. In fact, our experience is that until you have 5+ full-time developers there are going to be times when it isn’t possible to have everything paired. And do you know what? That’s okay. Code can be developed by a single developer but the fact that they built it on their own is a form of technical debt: until others have worked on the code, it is more widely understood, and has had the benefit of many eyes on it, you are in debt to the system.
  • Large scale refactorings left undone. We use a number of underlying platforms and tools. If the platform or tool doesn’t do what we need we develop custom code. It isn’t uncommon for the tool or platform provider to then release something that does what our custom code does at a later date and, until we refactor to use the new platform or tool feature, we have some debt to the system. But that’s okay – the custom code still works, its just not as simple as it could be nor as future-proof if the provider develops the feature further.
  • Limitations left in place. Sometimes a truly scalable solution is much harder than a simple but limited one. We had a situation where using in-memory collections led to a hard limit on the number of objects we could handle but the in-memory version of the code took a couple of hours to produce. We knew how to get around the limit – by adding in a system of creating permanent records and then processing them asynchronously using scheduled jobs – but that was several days work. The limit was okay – the function still worked, just for small collections of objects, and we had a debt to the system as and when our customers couldn’t live with the size limit.
  • Sub-optimal design approaches. Sometimes it is easier to deliver a simplistic design than a well-crafted one. For example we delivered a quick-and-dirty reporting function that was simple but slow because we were making it work, then making it right but hadn’t yet got to making it fast. But that was okay, the information was available to the users and correct, just not very quickly delivered.

But why would we live with such limitations? Aren’t we just delivering a shoddy system?

The answer to the first question is that we’re prioritising learning what makes our business work over some abstract notion of quality. If we develop a feature and it turns out that customers don’t want to pay for it, does it matter if it is only understood by one developer, that it could be refactored, that it is limited or sub-optimal? We develop the feature to get it into customers’ hands as quick as possible, to understand whether it is something valuable or not, to understand how it should work. Only if that features is valuable is it worth paying down any debt we have incurred building it. In fact, never mind the feature, the same applies to the whole system: unless the system is sufficiently valuable to customers we have no business and if we have no business the whole question of quality is moot. Customers pay for features and benefits, not fully-paired, beautifully factored, limitation-free, optimised code.

The answer to the second question is an emphatic ‘no’. We produce production quality, tested code. The testing is something we don’t compromise on simply because it is the mechanism by which we will pay down the debt if and when the time comes to do so. I can live with the fact that a design is sub-optimal if we have tests which will help us optimise it when we have to. I can live with code that need refactoring if we have tests which will help us refactor it when we have to. I can even live with something written by one person if … well you get the picture.

In a startup, technical debt is something to be managed, not minimised. We make sure we understand how much debt we have and which bits of the system it affects. We make sure we have the ability to pay down that debt as and when we need to. And we make sure we work the time and money required to pay down debt into any timsescales or budgets we agree.

Anything less would be irresponsible. Anything more is prioritising some notion of ‘code quality’ over learning what makes our business work and equally irresponsible.

Using eXtreme Practices to Run Your Business

To me the great innovation of XP was to shift the emphasis of software development away from realising a set of specifications to realising value for the customer and the twelve practices are all about maximising the team’s ability to do so. Its no great insight to recognise that running any kind of business is also about realising value for the customer and about a year after starting my first business I saw that we could usefully apply some of the XP practices to the business management as well as software delivery.

That was a number of years ago but this week I was reminded of the value of applying these practices, especially in the context of a lean startup where the need to discover your product/market fit and develop your business model is directly analogous to the XP team’s ‘discovery’ of the system implementation that achieves the greatest value for their customers and to keep on doing so.

Pairing – In a startup you can’t afford to do everything together; there has to be some division of responsibility and labour. However, the key business management activities – accounting, customer discovery, sales, marketing, product development – are best paired. Working as a pair to produce the monthly financial summary is so much more valuable than reviewing a spreadsheet produced by someone else and everyone on the management team needs to know what is going on in sales and customer discovery. The pair-programming benefits of lack of a single-point-of-failure, cross-pollination of skills, improved quality of output and so on are just as desirable in business management as software development.

Planning Game – However you execute the ‘planning game’ the same principles and outcomes are desirable in business planning as software delivery planning:

  • Quick and Easy. If you spend all your time plotting how to take over the world only one thing is certain: you wont.
  • Short-term Focussed. You need some idea of where you’re going but the emphasis has to be on what you do in the next few weeks to find out what your customers want and to make those sales.
  • Feedback-Driven. Don’t forget, in the relentless drive towards growth, to look at what has been working and what hasn’t.
  • Priority-Driven. There is no such thing as “not enough time” only “too much to do“. Make sure you’re doing the right things.
  • Visible. Getting the tasks up on the wall and making them visible to everyone is a powerful way of ensuring the priority tasks get delivered, everyone can see when things aren’t happening fast enough or when someone is struggling, and everyone can contribute to ensuring the goals for the business iteration are achieved.

Test Driven – My personal moment of epiphany with XP came when I realised how TDD meant we could spend a lot less time worrying about ‘architecture’ and ‘the design’ (less, not none) and more on saying what we wanted to happen and then making it happen. Setting simple tests for business management tasks like running a marketing campaign or pursuing a particular deal makes it easier to focus on getting things done and to learn from the outcomes.

Continuous Integration – Just as separately developing several streams of code and then trying to bring them together after a long period of time is usually a disaster, having the product people go off and develop the product separate from the sales and marketing people, separate from the people worrying about the money will usually end up with a bust company. Even in startups such as ours where the product people, the sales and marketing people and the people worrying about the money is actually a grand total of two people, the various strands of thinking and work need to be ‘integrated’ on a continuous (daily or weekly) basis.

Sustainable Pace – The first six months of a start-up are the hardest, except for all the months that come after. Which is to say that, if your startup is a success, you will work extremely hard to get it off the ground and then have to step your game up to keep it in the air. If you need to work 20 hours a day, 7 days a week just to get it off the ground, there’s a very good chance that you don’t have a business there. There’s also a very good chance that you’re just trying to do too much. Either way, you will have difficulty sustaining that level of effort when you get to the point the business really needs it.

As an aside, one thing that’s important to recognise about Sustainable Pace in running a startup is that for many people its not just your Sustainable Pace. If you have a partner and/or children, or just friends that you value, what’s the pace that you can sustain and that they can too?

I think its also worth saying that I don’t see XP as being a blueprint for lean start-up management and there are at least two XP practices that I think don’t really work:

Collective [Code] Ownership doesn’t really have an analog in business management. As mentioned earlier, most startups rely on some degree of division of labour. The fact that delivering a new sale or a marketing initiative requires building a whole load of relationships and interacting with people rather than a deterministic machine means that someone else can’t just step in at any point, make a bunch of changes and then roll back if it doesn’t work out. By all means collectively own the business and the objectives but no-one should be able to just go and interfere in someone else’s work at the drop of a hat.

Whole Team – Possibly a controversial one this but, after 13 years of running startup businesses, I’ve come to the conclusion that the running of a business is not a matter for the whole company. Yes objectives should be shared, there should be some form of vision for everyone to buy into, everyone should have a voice that is listened to. But not everyone has the skills and experience to make good judgements about the business direction or about the business’s current position. Especially in startup where things like cashflow, market conditions, and sales prospects are extremely volatile, the management team needs to know how and when to communicate about how the company is doing to everyone in it and how and when to respond to feedback and ideas from outside management.

Minimum and Viable

I love Eric Reiss’s concept of a ‘Minimum Viable Product‘ – such an evocative phrase for anyone doing a lean start-up. However, like many evocative phrases it carries the broad concept well but doesn’t stand up to much scrutiny; how minimal is ‘Minimum’ and how workable is ‘Viable’?
There are other phrases knocking around that signpost the same concept. I like Minimum Marketable Feature, often talked about Minimum Usable Implementation when delivering projects rather than product, and Kent Beck recently tweeted:
i’m liking “minimum informative increment” as an alternative to “minimum viable product”
(to which Karl Scotland replied
@KentBeck I wonder whether its more about the learning than the information – “minimum learning increment”?
A year into our lean startup I guess I’ve come to the conclusion that minimum viability comes in different flavours and has different purposes for different people.
  • Developers can often learn a lot from doing very little in terms of scoping a new piece of work, understanding a technical challenge, trying out alternative approaches, etc. I’m often amazed that a spike of a couple of hours can tell me much of what I need to know about a piece of work that may take days or weeks to complete. This is the minimum investigation to get viable information about the work required.
  • Product owners and sales people can get a lot of value from doing very little in order to demo a concept or feature to customer or prospective customer. Working on the platform allows us to rapidly show a ‘this will never work for you but at least shows you the idea’ type prototypes and we’ve also started using mocked-up screen shots and wireframes to solicit feedback on our road map and UX ideas. This is the minimum demonstration to get viable feedback.
  • Customers and Users can get a lot of value from a product feature that has had the minimum work done on it to deliver the necessary functionality. The Customer/User can benefit both from getting the feature earlier than they might have done if they waited for the ‘bells and whistles’ version to come along and from being able to provide feedback that helps to ensure they get what they actually need rather than what the product owner or developer things they need. This is the minimum implementation to allow the user to viably achieve their objectives.
  • Start-ups can get huge value from releasing a minimum set of workable features to paying customers. The presence of paying customers goes much further towards validating the business model than legions of people expressing ‘an interest’ and the handing over of money focuses the mind of the customer on giving good feedback far more than any prototype or free trial. Oh, and in any start-up cash is king: getting money through the door enables the business to provide increasingly good service (even if only because the founders get a better night’s sleep). This is the minimum product that allows the business to charge their customers a viable sum of money for which the customers get a viable solution to their needs.
There are pitfalls in all these and the other forms of minimum viability (the minimum viable development team is my current area of consideration) – if you get your spike wrong you can easily find you don’t understand your problem as well as you thought you did when it comes time to implement, and getting customers excited about features that don’t yet exist has many well-known issues – but it is the last two that concern me the most.
In our world the customer is often not the main user of the system (we sell SaaS to businesses and so the customer is usually the COO or the CEO and the users are people who work for them). In one instance the COO saw a very minimal version of a feature and decided it was pretty close to being sufficient for their staff. 10 minutes with the actual users told us that this was far from the case and we had a lot of work to do. In another case we had a working feature that allowed the user to do something but it was just too convoluted a process and our argument that, whilst not perfect, the feature was actually there was met with a blunt “if I have to mess about with it for 10 minutes it might as well not be there”. Fair enough; great feedback and the streamlined version of the feature is in QA as I write.
Those are just examples of where what we or the cheque-writer thought was minimum and viable feature turned out to be anything but. When it comes to releasing a minimum viable product we have an order of magnitude more difficult problem. To some of our customers what we offer is their first truly integrated, domain-specific application so almost anything that works is an improvement over what they’ve had before. But to others who are replacing an existing system their expectation is that our stuff does at least the same and hopefully a great deal more (or else why go through the pain of moving to something new) which really challenges some of the areas of functionality that are more minimal than others.
The more lean and scrappy start-ups succeed, the more the concept of minimum and viable will be understood in subtle as well as broad terms. My own small contribution to the debate is that learning, information, usability, ‘marketability’ and even ‘sellability’ are all great things but are often in tension with each other: if we place too many minimum features or feature sets in front of users that are the wrong side of being viable we may learn a lot but also risk gaining a reputation for delivering crap products that don’t really work. So when we’re talking about Doing the Simplest Thing or what the ‘minimum viable/informative/learning increment/feature/product’ is, its really important for us to understand:
  • Who is the beneficiary of what gets delivered?
  • What do they benefit from (learning, usage, cash through the door, …)?
  • What is the right way to deliver to them (spike, prototype, polished implementation, …)?
  • And, most importantly, what are their expectations? Because what they expect may not match with what we think is good enough for them.
When we’ve got the answers to these questions we find it a lot easier to calibrate what ‘minimum’ and ‘viable’ means for the particular situation.

High Quality Problems in a Lean Start-up

A tweet by @isaach the other day got me thinking:

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:

  1. Identify it as an HQP.
  2. 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.
  3. 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.
  4. When those circumstances come about and the problem is real: now is the time to start worrying about how to solve it.
  5. 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.
  6. Get it solved.