When is it good enough to ship?

Every company sets their bar at a different height.

Everyone wants to move fast (and break as few things as possible).

But building a robust, easy-to-use product that's reliable is also considered table stakes in the world we live in.

The curse of the MVP

The lean startup movement has led to the term “MVP” (Minimum Viable Product) becoming a commonly used phrase in product development at startups and large companies alike.

The intention of building an MVP is to validate an idea as soon as possible. It's about proving or ruling out an idea as soon as feasibly possible before developing it further or ditching it.

It's hard to argue that the concept of building an MVP doesn't make sense. Of course you don't want to spend weeks on refining your button styles or getting your typography spot-on when you are trying to direct the course of your business in the first few weeks or months of starting out. You want to be seeing if anyone gives a damn about your new product.

The problem with the term “MVP” is I hear it being used all too frequently as an excuse in later stage businesses to ship a feature before it's ready for customers.

“It's ok for now, we can improve it later, let's just get it out the door and see what people think.”

“It's good enough for now.”

“Let's see if anyone wants this first and then add the onboarding.”

It seems we live in a world where the term “MVP” now means “fuck it, ship it”.

MVPs are useless unless the purpose of pushing the new feature out is to learn and iterate based on immediate feedback from users and customers. This feedback should then guide the feature to be improved or killed, and everyone working on that MVP should be aligned on that.

Back in ye old days

Before the term MVP came along, and before the lean startup movement, many software teams worked harder to refine an idea or feature before it made it in front of customers. This often led to a slower release cycle, but often the quality of features and the user experience was higher.

Speed and quality

Having a slower release cycle can be the death of a software company. If you're not iterating and learning fast enough then it's only matter of time until someone overtakes you.

But you also can't afford to give your users and customers an experience that's anything less than delightful.

So how do you decide when something is ready to ship?

Here's a few questions we ask to help guide us at GoSquared to try to work out way around this conundrum.

Is it better than what's already out there?

If the feature is replacing existing functionality in the product, is it better than what our customers are already using right now?

Is the new feature providing the same or more functionality than what's already out there? Is the new feature easier to use than what's in production?

Is this feature likely to be used by all of our customers? Or just a few?

What's our motivation for introducing this feature? Is it to please a handful of our customers for a specific use case, or is it likely to benefit the majority of our customer base?

If it's only for a few users, does it actually deserve to in the core product in the first place? Could it be done via our APIs and kept away from the core product?

If it's for everyone then is it ready for that? Is the onboarding great? Will we get a ton of customer support questions on this if everyone starts using it? What are the holes that we can address with a great FAQ rather than cause users to be puzzled and email us questions?

How important is this feature to the people who use it?

Is this feature a critical part of a workflow for customers? Is it a potentially dangerous action they're taking by using this feature?

For example, if we're introducing a button that will give the customer the ability to delete a load of data, or the ability to send a message to all their users, we had better make sure that's one well considered button.

What does this feature say about the people who made it? Are we proud of it?

This is much less of a binary decision, but we hold ourselves to high standards at GoSquared. We don't believe in putting in features in front of customers that we're not proud of. The more considered and thoughtful we are on a feature, the more confidence we have in pushing it out to customers.

All in all, we look at a lot of factors each and every day to make a call on what deserves to go out, and what should be kept back and incubated a little longer.

James Gill

CEO and co-founder of GoSquared.

London, UK