I’m getting ready to launch Sales on Rails, a simple sales order management tool, after nearly ten months in development. If I had made better decisions, I would have been able to do it with half the money in half the time.
If I had focused on the minimum required, launched the product and then watched it mature, then I could have launched much earlier and I’d probably be further along today. But I was too distracted with “Wouldn’t it be great if…”
I was warned, of course. I’ve read 37signals’ Getting Real six or seven times and been told by a been-there-done-that colleague to “design first, develop later”. Unfortunately, I have a bad habit of preferring to learn by experience rather than by advice.
Thankfully I learned my lesson, and it wasn’t learned too late. Thanks to a great team, the development has always hummed along nicely. Building the application was never the problem; I was.
I learned what I needed to by doing the third version of the screen designs myself in order to a) get exactly what I wanted; and b) fully understand how complex and variable building a web app can be.
Start with nothing
Getting Real has a chapter titled “Build less“. I would take that one step further and say start by building nothing.
By “building nothing” I mean start with the basic infrastructure. I call it “nothing” because it has no business value. You can’t recruit users with just a basic, featureless database.
My product, Sales on Rails, has orders, customers and products. Without all of those, the application can’t do what it needs to. There are plenty of other examples as well: Highrise stores contacts; Dropbox stores files; Skitch stores images.
Of course “nothing” is not nothing from a development standpoint. It’s still going to take a lot of time and money to build. But it is nothing from a business perspective. You can’t make money on infrastructure alone. You can’t sell a basic database that only collects data. Without the added value of manipulating that data in a useful way — i.e. without features — your application is “nothing” to your business, regardless of how crucial it is to your application.
Then add one feature
You can’t sell infrastructure, so the next thing you need to do is add features.
The temptation — which I initially succumbed to — is to add the most useful things you can that complete this sentence: “Wouldn’t it be great if…” It’s hard to limit the scope of work that that thinking creates.
The best response to that statement is, “Yes, it would be great, but just because it’s great doesn’t mean it’s going to make you any money.” Just because it would be fun to build features A, B and C doesn’t mean your customers are going to use them, value them and want to pay you for them.
So why add just one feature before launch? Why not add at least a few? Because limiting yourself to one feature will force you to pick the best one. If you only have one slot to fill, you’ll be forced to choose between all of your favorites. And with a launch deadline looming, you’ll end up selecting the feature that your customers are most likely to find valuable in a new product.
But what if I’ve already built a bunch of features?
I made the same mistake with Sales on Rails. I built a bunch of features that may or may not be necessary. So for launch, I’ve decided to hide them — they’re still there, but the buttons and links have been removed from the design. The development costs are already sunk, so yes, I could release them. However, if I released them now, then I’d lose two important opportunities:
- The knowledge that comes from testing (in the wild with real customers) whether the features are actually needed or not; and
- The marketing opportunities that come from new releases.
So the product that I’m going to release in the next few weeks is a stripped down version of what it actually already is. The future code is still there, sitting in the background, but with those elements removed from the design, there’s no way to access it, no way to trigger it, no way to use it. Most of those features will be released eventually, but only when it’s been demonstrated that customers actually need and want those features. And when they are released, it’ll reinforce to customers that the product is worthwhile and has gained some momentum.
Recommendations
- If you’re building a web application, build “nothing” plus one feature — i.e. the basic infrastructure alongside the most useful or most desirable feature — and get your app out into the wild as soon as possible; or
- If you’ve already built a ton of features, but haven’t yet released them, then don’t. Strip your design back down to its most basic, and then only reveal those features when your customers are ready for them.
