The only reason to build software is to sell it
When we were a small young company, this quote went unsaid and was probably fairly obvious, because we had no other option. If we couldn’t get people to buy our software, we wouldn’t be able to pay ourselves, and we wouldn’t be able to buy food or pay our rent. There was no choice but to build features that people would buy.
These days, if someone walks around the office saying “the only reason to build software is to sell it” it might draw confused looks from half the company.
A lot’s changed in five years. We’ve grown past 100 people, and one thing that’s changed is that there’s a lot more specialisation within the business. It’s not just 4 guys sitting in their living room trying to do sales, marketing, customer success, support, design, development, finance, and strategy all at the same time — there’s now entire teams around each of those functions, plus other things we didn’t know should exist.
We now have a big pool of customers who are happy, and a big pool of customers who are mostly happy. One side effect of this has been that “the only reason to build software is to sell it” has become a bit of an abstract idea. It’s easy to forget that there is still a much bigger pool of people for whom there’s more we need to do to win their business.
Some people’s instinctive response when they first hear this quote is “there’s other reasons to make software — to solve people’s problems, to improve the experience for current customers, etc”. I don’t think these are at odds. If we make software that solves problems and makes customers happy, then we’ll be able to sell it. If we can’t, then we’ve built the wrong thing.
I don’t think product/market fit is a fixed state. It’s not binary, something you “have” or “don’t have”. I think it’s a scale, and every time we build something that shrinks that pool of people who can’t use our software, we are improving along that scale. But if industrial relations law changes, or if something that used to be a delighter becomes a basic need, then we move down on the scale. It’s a constant battle.
Every product team’s goal should be to build the best product ever. Mine certainly is. Once I set that goal, I struggled to define “best” for a long time. Is it the prettiest, or the easiest to use, or the fastest? I think a better definition is the most sellable. If we build the prettiest, fastest, easiest to use product in the world but nobody buys it because it doesn’t solve a problem, then we haven’t really made the world a better place. But if we build the most sellable product then we are going to have a positive impact on the biggest number of people.
In my opinion “the only reason to build software is to sell it” is always a good motto. It seems unlikely that we’ll reach a point where we have the perfect product that covers every single use case ever. But it’s worth striving for! And even if we do get there, customers are divinely discontent, so we’ll need to keep innovating to ensure our customers keep buying from us. In the meantime, there’s plenty more work to be done.
