Releasing Early Is Not Always Good? Heresy!

By Jason Cohen on December 21, 2009

The following is a guest post by Jason Cohen. Jason's got a knack for stirring pots and getting us thinking a bit.  And, thinking is a good thing.   Even when the thinking makes me awfully uncomfortable and goes against my strongly held beliefs.  I couldn't be a stronger advocate of "Release Early, Release Often", so it took a bit of effort to post this article "as is".  But, as I hope you'll see, Jason does make some pretty good points.  Well worth debating -Dharmesh

[UPDATE: I originally stated that Eric Ries was a proponent of "Release Early," but I was completely wrong.] OnStartups No Hear

You can't throw a stone in the blogosphere without hitting someone arguing in favor of releasing software as early as possible. The idea is that it's best to push new software onto potential customers before it would be traditionally considered "ready."

Here's the general line of reasoning: In the beginning, you have a theory about who your customers are, what their pain is, what your product needs to do, and how it will be used. But it's just a theory, and it will always be wrong. That's OK! It's life.

Since you're wrong, your v1.0 is really just a foil to get people talking. Therefore:

  • Don't add a lot of features, because you don't yet know which features are actually needed.
  • Don't fix every bug, because half of this code might not be here in a month.
  • Don't pretty up the user interface, because it won't look anything like this in a month.
  • Don't obsess over the customer workflow, because it will change completely in a month.
  • Don't worry about scaling, because you won't have that many customers for a while.
  • Don't worry about architecture/extensibility/documentation because most of your code will be different in a month.

Now in general I agree with this line of reasoning, but I don't like how one-sided this discussion is. Even a casual glance through this discussion of the subject shows that people -- me included! -- are recommending this strategy as a knee-jerk reaction.

So for the sake of thoughtful debate, I'd like to present the case against.

The best ideas aren't built by consensus

Would the iPod have been invented if it were built by iterative customer feedback? I doubt it:

  • Do you want a portable music device without a radio? No.
  • Do you want a battery-powered device in which you can't change the battery? No.
  • Do you want a portable music device without Bluetooth? No.
  • Do you want a wheel-based user interface which you don't already understand and which makes certain operations confusing? No.
  • Do you want it to take 5 clicks to toggle "shuffle," one of the most-used functions? No.

Apple doesn't ask customers what they want -- they just go invent awesome stuff. People complain, sure, but in the end the success of the iPod and iPhone is undeniable.

In general, disruptive products by definition cannot be built by consensus. In fact, it's well-known that "design by committee" is a sure-fire way to get mediocre design.

Small, incremental changes pulled by customers blind you to bigger, better ideas.

You're misinterpreting the 80/20 rule

The typical 80/20 rule is: 80% of your customers use just 20% of your features.

The "release early" folks take this to mean: Just implement 20% of the features you think you need, because if that's good enough to get 80% of your sales, this is a much simpler, efficient, and therefore profitable way to operate a software company.

But this interpretation is wrong! To spell out the 80/20 rule more accurately: 80% of your customers use just 20% of your features, but each customer uses a different 20%. That implies you need more features, not fewer, otherwise there won't be enough for the various use-cases for your software.

Take Microsoft Excel. Every person I talk to uses a different subset of functionality. Some people are experts at PivotTables whereas others have no idea how they work. Some people can't live without the database connectivity stuff whereas others don't know what a database is. Some people drive key business data using conditional formatting, some people know just enough Visual Basic to save themselves hours of manual labor, and some are experts with the charting system.

The point is that you can't just remove 80% of the features from Excel and expect 80% of the people to still be happy.

Mock-ups are faster than code iterations, without some of the drawbacks

There's a variety of software and techniques for mocking up applications, both web-based and desktop. Mockups can typically be built in a matter of days and put in front of customers for feedback. Iterating with fake screenshots is always faster than actually messing with HTML, CSS, and back-end code.

Once the mockups for v1.0 are set, actually writing v1.0 is fast because you know the goal ahead of time. The complete cycle is faster than if you started coding in the first place, and the code is cleaner because you don't have traces of major false-starts. (Think database migrations, CSS styles, extra AJAX routines, unused dialogs.)

Releasing too early can ruin your reputation

When your first version is sub-par, you'd better hope very few people find out about it.

Back to Apple: The iPod worked on day one, but back in the 90s the Newton didn't. The Newton (the world's first PDA) was hailed as a revolutionary technology (just as the iPod and iPhone would be), but it didn't work well. In particular, the handwriting recognition sucked and there wasn't a lot of apps.

It never recovered from its early reptutation as "doesn't do a lot, and what it does do doesn't work well." Even when that was remedied, it was too late.

The typical counter-argument to this is that "release early" doesn't mean "release with lots of known bugs," but rather "release with fewer features." But we all know the difficulty in separating a "feature request" from a "bug report" -- what a customer sees as a devistating lack of functionality (bug) you say is missing by design (feature).

Ignoring architecture creates waste

Software architecture is something the end-user never sees, and is therefore usually cast aside in the arguments for releasing early and collecting feedback. But incorrect choices in architecture can bite you later on, causing an immense amount of waste, possibly enough to sink the company.

It's true that most companies don't survive, and therefore having a growing user base with a problematic architecture is "a good problem to have." But it's also true that an ounce of prevention is worth a pound of cure.

Take Twitter. Their scalability problems are legendary. Suppose they didn't have billions of dollars in funding to throw expensive people and hardware at the problem? It's not hard to believe that continuing scalability problems would have sunk their ship.

Or take Netscape. The architecture problems with their browser were so severe it required a rewrite, which took so much time and effort the product (and company) died.

Of course this doesn't mean you should dwell on architecture for six months before working on features, but it does mean you shouldn't just ignore future maintenance issues for the sake of releasing a month sooner.

Untrue: "The worst thing you can do is built an unnecessary feature."

This is frequently used as an argument for releasing early. The logic goes: Every feature is effort. Not just in creating it in the first place, but debugging it, testing it, training customers on it, integrating it into all other features, supporting it in the user interface, covering it in the user's manual, and keeping it even as the product's focus changes. Therefore, never add a feature unless it's absolutely necessary.

I agree unneeded features are a major expense, provided you retain them in the product. But having incorrect architecture is also expensive, yet the "release early" folks tell us that expense is OK!

The fact is, you can change or even completely remove features that have become albatrosses around the neck of your tech support and product evolution. The "release early" argument also includes frequent iterateration, morphing the software as evidence suggests. Changing and removing features is simply a part of that, and doesn't imply that releasing early is smart.

In fact, adding features is one of the few ways to test what customers actually want, because:

Customers are notoriously bad at providing feedback

Sometimes users will tell you that they want a time/date-based voting widget they can send by email, when what they really mean is that they need to coordinate schedules.

In my experience customers are terrible at deciding what features they need, which features they use, or how features should be altered. They're much better at describing what's difficult in their life, what frustrates them, or what takes up a lot of their time.

Customers aren't even good at explaining why they did or didn't buy your product. From Jo Owen:

My research showed customers thought they were rational purchasers of video cameras: it was all about price and performance.

But when I interviewed them as they left a store, they were often unclear about how much they had actually paid for the model after splashing out for warranties, batteries and accessories and sorting out a financing plan. They were also very confused about the relative performance of different models.

Of course it's necessary to gather as much feedback as possible from both customers and lost-sales! But it's not clear how accurate the feedback is or how to weigh it against your own vision and goals for the product.

Relying on unreliable information as the primary driver of product decisions is unwise.

What do you think?

In the end, of course it's better to have more feedback than less, better to be more agile than less, and better to have technical debt with a successful product than a failed product. However, it's just not fair to present only one side of the argument!

Do you have more arguments either way? Do you agree we're taking "release early" a little too far? Leave a comment and join the conversation.  Or, if you've got a question, you can post it on

Continue Reading

How To Price Software Without Just Rolling The Dice

By Dharmesh Shah on November 23, 2009

I’m going to open this article with a short (and true) story.  I officially kicked off my marketing software company, HubSpot, about 17 months ago.  If you’ve read my blog for any period of time, you likely know that I’m a big beliver in the “charge early, charge often” mantra.  As it turns out, in order to “charge early”, you have to figure out what you’re going to charge people.  That is, you have to have a price for your product.  Thankfully, both my co-founder (Brian Halligan) and I had recently graduated from a top 5 MBA program.  And, it wasn’t just any top 5 program — it was MIT.  You know, that place where science and math and uber-geeky analytical stuff happens.  So, you’d think that when it came time to figure out a price for our product, we’d really dig in, do some heavy-duty analysis, some really hard thinking and come up with a relatively well thought-out price.  That’s not what happened.onstartups software pricing

When it came to deciding on the price for our software, we basically just rolled the dice.

I’d love to for the statement above to be an exaggeration.  Surely, we spent some time pondering that oh-so-important factor in our business sucess.  Nope.  We didn’t.  One of us (I think it was me) suggested “how about $250/month”, and that’s what we went with.  And, that’s where the price remained for about 2 years. 

Things turned out fine for me and HubSpot.  But, you still shouldn’t do this.  Don’t just roll the dice when it comes to pricing your product.  Give it some thought, consideration and (gasp!) some analysis.  Your first step towards this path should be to run over, right now, and get the book “Don’t Just Roll The Dice: A usefully short guide to software pricing” by Neil Davidson.  Even if Neil weren’t such a nice guy (he is) and even if he doesn’t run my favorite conference (he does) and even if he didn’t build a really successful software company himself (he did), I’d still implore you to read the book.  It’s got the highest value-to-length ratio I’ve seen in a business book in a long time.  Go get it, right now.  And, if you’re still not convinced, Neil’s even been nice enough to give it away for free in convenient PDF form.  Yes, that’s right, you don’t even have to buy the freakin’ book on Amazon for $9.95 (though you could). 

Just on the off-chance that I caught you at a particularly skeptical time and you’re still not convinced, here are some of my notes from the book.

Insights On Software Pricing From “Don’t Just Roll The Dice”

1.  Your product is more than just your product.  You might think that your software product is just the bits and bytes that your customers download (or access online), but you’d be wrong.  What customers are actually paying you for is the entire experience of doing business with you.  Everything from how you market and sell the product, to how you help people use it and how you maintain it going forward.  All of it.  Your pricing should be based on this reality.

2.  There’s a difference between perceived and objective value.  It doesn’t matter how much “real” (objective) value you have baked into your product if your customers don’t perceive that value, they are not going to pay as much for it.  Hopefully, their perceived value is a function, to some degree, of the objective value.  If not, you’re screwing something up. 

3.  Community matters.  The group that your customers belong to, or want to belong to will impact the price they’re willing to pay.  For example, some people buy hybrid cars not just because of the environmental benefit or the higher mileage but because they want to be part of that community.  The same reason some people buy a BMW.  Determine what kind of community you can build (or tap into) around your offering.  Help people belong to the community they want to belong to.

4. As it turns out, people do buy drills (not holes).  There’s the reasonably famous adage around “people buy holes, not drills”.  The point is to focus on the benefit to the customer (not the product itself).  I generally agree with that notion.  But, it’s useful to keep in mind that holes can be a commodity, but people still sometimes pay $400 for a drill.  Benefits are important, but the direct benefiit is not the only one that customers value.

5. The more differentiated you are, the more you control price.  This one should be obvious.  If you have a product that’s about the same as all of your competitors, then you don’t really set your price — the market does.  Of course, nobody thinks of themselves as being identical to their competition (especially software companies).  But, what we often forget is that it’s difficult — and very risky, to try and create a completely new category and be totally differentiated.  Decide which dimension you’re going to differentiate on and make sure it’s reasonable given your particular constraints (like cash).

6. No battle plan survives contact with the enemy.  This quote is not actually in the book, but I think it still fits the theme.  When setting pricing, it’s important to consider what the “market response” is going to be — particularly if you’re in a well-defined category.  Just because it doesn’t make economic sense for a competitor to get in to a price war with you, it doesn’t mean they won’t do it.  Particularly if they’re big or well-funded. If you’re thinking about competing on price, keep that in mind.  Better yet, don’t do it at all.

7. Remember to be fair.  As humans, we often have a sense of what we think “fair” pricing is.  Even though a particular pricing model is “theoretically optimal”, it might not be wise in practice.  As software entrepreneurs, we often think we can get away with certain types of price segmenting simply because it’s enforceable in the software.  Just because you can keep customers from doing certain kinds of things (unless they pay up), doesn’t necessarily mean it’s the right (optimal) thing to do.  In the long term, it could actually hurt.  Try to put yourself in the customer’s shoes and envision if they think the way you price things is fair.  [Note: I’m not suggesting you be all rainbows and cupcakes and suggest that you price based on being “nice”.  I’m just saying that you might actually make more money by being empathetic]

8. Pricing complexity has a cost.  One of the things you learn in micro economics (and is discussed in the beginning of the book) is the concept of supply and demand curves and how you can segment your pricing in order to capture the maximum value (i.e. optimize revenues).  This can be a wonderful thing.  But, it’s critical to remember that this segmentation has a price — it’s not free revenue.  For example, when HubSpot went from a single price ($250/month) to two prices (still pretty simple), life got a lot harder.  All of a sudden, our marketing, sales and even our operational efforts got more complicated.  The product got more complicated.  All of our pretty charts that we used to talk about the business and measure success got more complicated.  The reality is that when you add a new dimension to your pricing structure, you’re adding a new dimension of complexity.  Oh, and by the way, the *second* price that you add to your product is the most expensive.  After that (third, fourth, etc.) things get a tad easier because you’ve already built some of the infrastructure to support multiple prices.  And by that point, your brain is already used to the pain.

Phew!  I typed this entire article in one sitting while simultaneously reading a majority of the book for a second time.  If I haven’t convinced you yet that you should go read it then I think I’m hopelessly inadequate at conveying the importance of this topic and the usefulness of the book.  Or, maybe you’ve already got it all figured out.  If so, may the wind be in your sails and may you go forth and prosper.  For the rest of you, just download the book.

And, on a more selfish note, what are your biggest insights when it comes to software pricing?  What challenges have you dealt with?  What questions do you have about pricing your software?  If you’re looking for some great answers, you can post a question on where a bunch of smart folks like Neil Davidson (the guy that wrote the book) hang out.  Hope to see you there.

Continue Reading

Recommended For You


Let's Connect

And, you can find me on Google+, Twitter, and Linkedin.

Recent Posts

Chat with GrowthBot

It's a bot to help you with your marketing and grow. You can research your competitors, improve your SEO and a lot more. http:/