How to kill the feature creep monster: Launch and sell early!
Which features should you add to your product before you can start selling it?
Many founders get overpowered by the feature creep monster early in the development of their product. They stifle the progress of their startup because they get too hung up on thoughts like:
- Which feature should we add next?
- Is our product ready to launch?
- Is this viable enough to call it an MVP?
- Is it ready to be sold? Should we charge money for it?
- Wouldn’t it be cool if I could build this feature as well? And that feature? oh and this and that?
Here's something I learned about startups that will help you to find the right answer:
You ship something that's lacking a lot of crucial things and people still buy it? Yep, that's the signal that you're on to something.
If it takes a feature-complete product before you can sell it, you're not building something that's 10x better than existing solutions. You're not on your way to product/market fit.
This is a guiding principle.
If you have a working product, even if it's working badly and still has a bunch of bugs ... launch and start selling!
This is going to be super uncomfortable.
Either people will buy or they won't. It doesn't really matter at this point. The important thing is to get out of your own head. The value at this point is not in revenue generated, it's in the lessons you learn from the marketplace by facing it early.
Here's a 3-step process for building successful startup:
- Launch way too early
- Get people to use a product that isn't working well, lacks a lot of important features and is annoyingly buggy
- Scramble to catch up and fix things as you're growing
If you do this with a product which has true potential two things will happen:
- People will buy and use your product.
- A lot of them will cancel because there is something currently missing by your product's performance.
As long as you're losing customers at a slightly slower pace than you're winning customers, you're doing just fine in the early days:
- You will have validated real market potential.
- You will know what your customers care about most. That will give you focus.
- The feedback you get from these people is the best kind of feedback you can get. It's feedback from people who are actually paying for your product.
- You will be sufficiently motivated to focus on what matters most.
It will be a constant scramble to fix and add things. But you won't be just guessing working in your own comfortable bubble. You'll be out there in the real messy market with real customers and real requests. You'll know what needs to be done next.
You'll scramble until you catch up with the promise of your product.
Eventually, your product will deliver all the value that people see when they first took a look at it.
I know this sounds harsh and "unpleasant". And it is. I know you'd rather just build the "perfect product" and then launching in the "perfect way" and have "perfect customers" and live happily ever after in "perfect land" but that's not how the real world functions.
Real entrepreneurship is messy. It's a grind. It's a hustle. Get used to it or look for something else to do.
Don't fall for the false promise of one more feature.
Close wasn't perfect (still isn't)
When we launched Close we didn't have any reporting in our app. Ouch.
We lost some really good customers because of that. It was painful.
But we retained more and kept on growing. Why? Because Close delivered so much value to our customers that they kept using it despite this glaring hole.
If nobody would have bought Close without the reporting, we would have stopped working on it. It's that simple.
And we still got a lot of work to do (stay tuned for a lot of new reporting features being launched soon ;)).
One of the big advantages we had was that we had a deep understanding of our users. Our developers were coding the product in the same room with the sales team. We built our product from scratch as our core users actually used it.
Is your product appealing enough?
At it's core, your product needs to be so good that people are willing to put up with your shortcomings (at least for a short time while you're building a more mature product). It needs to solve a core problem 10x better than existing solutions, or what's the point in even starting to build it?
But users are requesting it!
What do you do if a significant number of users requests a certain feature that is not aligned with your product strategy?
Don't give in if you don't really believe in it. Instead, try to understand the core use case and problem people have behind the feature request rather than just listening to the proposed solutions.
Less is more
More features look good in itemized feature-comparison charts. But when people actually use a product, they don't want a gazillion features—they want an easy-to-use, fast product, that gets the job done.
"Most software is better if it does less stuff." —David Heinemeier Hansson, Creator of Ruby on Rails and Partner in 37 Signals
Cumulative danger of the feature creep monster
Feature creep is addictive. The more you fall for it, the harder it is to stop.
"Focus and simplicity are often more difficult to achieve than building features on top of features on top of features."—Gary Swart, CEO oDesk
One reason is simply that you've invested so much time and effort into building all these features that you're always going to try to justify it as a good investment or your time and energy.
At a certain point, it becomes just too psychologically difficult to face the potential reality that this isn't the right features or even product at all.
That's why you should launch your product as quickly as you can. Start selling it. Don't let excuses get in the way. If you think that you don't know enough about selling or aren't good at it, there's always the 30 day startup sales success email course for you.
How to respond when you lack a feature the prospect requests
Don't have that feature the prospect wants? Sales people often respond by saying what a great idea this is, and that they'll pass this on to engineering to implement their suggestion. Which is a terrible way of responding. Here's how to deal with feature requests you can't fulfill instead.
Product Strategy Means Saying No by Intercom
It's not always easy to say no to feature requests, especially when people bring up good reasons for it. Our friends at Intercom came up with a fun way to help you practice saying "no". Also, here's a great post on the subject.