Rebuilding a product from scratch is like upgrading to the latest model of your car – it happens all at once, and until you do it, you’re still driving a beat up jalopy.

I see it all the time.  People spend years building a product and then throw it away to rebuild it from scratch.  It’s one of the most expensive SaaS product mistakes out there, especially if you’re planning a “big unveil” – a single day when all users/customers will switch entirely from the old version to the new version. Here’s why it’s not a great idea to throw away an entire product and start over:

The New Product Can’t Be Sold

I’ll use the new car model analogy above.  Even the slickest car salesperson couldn’t sell you a car that didn’t have doors, or an engine.  Think about it: you’re working on a new version of your product but it’s not quite ready because it doesn’t have feature X or Y yet, so you’ll never sell it.  Maybe you can demo parts of it, but if it’s not all done, customers won’t (and can’t) buy it.  So what value has your new product generated?  None, until it’s ready for prime time.

It Takes A Long Time To Rebuild

This may sound obvious but if you’re building a new version of your product you can’t take features that your existing product supports away, unless they’re not used at all.  (and even if they’re only used a little, you’d have to figure out a transition plan for the users who are using them).  Assume it will take about 50% as long to rebuild each feature as it took to originally build it.  So if you built your existing product in 2 years, a rebuild will take a year.  That’s a long time to not have new sales. (I’m assuming you’re rebuilding because the current product isn’t selling).

Feedback Is Hard To Get

Maybe you have a really engaged user base willing to beta test your new version (or whatever’s built so far).  But probably not – maybe you’re disciplined and are running usability tests along the way.  But that’s not with your existing users, and it’s not with their own data.  The point is this – in a world where you’re betting big on the new version, not having a way to validate your new product from existing customers/users is really risky.  What if they don’t like it?!

Migration Is Painful

In the wild, migrations are ugly – water buffalo get eaten by lions, birds die flying south for the winter, etc.  You’re gonna lose users along the way.  Plus moving data around is hard – especially if the data doesn’t map exactly to the new feature set.  (“well, what should we do with THIS user data?  It doesn’t exactly fit into our new version properly.”)

An Alternative Approach

So what’s a better way to upgrade your product without a “big bang” release? Unlike cars, software can be updated slowly and doesn’t require that “all at once” upgrade.  You can update each page in your web app, you can update the most important features in your mobile app.  You can take a much more Agile approach.  And I’d strongly recommend it.

Fix The Biggest Problem First

You thought you needed to rebuild for a reason.  Maybe Tech told you the existing product can’t support a new feature.  Or that the current architecture is brittle.  Or that you got a new team and no one likes / understands the existing product / code base.  All legit motivations to want to rebuild, but not legit reasons to actually rebuild.  Product should prioritize what single change would make the current product better.  Start there and see what you can do to address that issue.

Partner With Tech

This approach can’t be done without some help from Engineering and QA.  They’re gonna have to think of an iterative approach to get from what you have today to where you want to go, whether it’s a backend replatforming, a Service-Oriented Architecture, or a new front-end tech stack.  The ultimate question is what can we do in 1-2 sprints to start releasing parts of “the new product”?

See Immediate Value

Google Drive did a good job with this a year or two ago.  They wanted to revamp their product, but they did so iteratively and told users they could “Try the new Drive”

Great – users could still use the existing product, but they could also explore the upgrade and provide feedback.  Perfect for Google to slowly perfect the new version and eventually sunset the old one.  You can even default users into the new version, when you feel like the feedback suggests that it’s “good enough” – just make sure they know they’re looking at a new version, and give them the ability to toggle back to the old version in case they really like a feature that doesn’t yet exist in the new version, or just hate the new version (tracking how many users toggle to the old version and for what is a great way to gather data to know if you’re new version is ready for release).