Why I Killed Two Products

Most clients I work with are always interested in the next product or feature. So much so that they don’t often look at if the product should exist or not. I’ve gone through killing two products recently, and I wanted to share that experience.

Not Enough ROI

This might sound obvious, but most groups build products without estimating their return on investment.

When I presented senior leadership with the estimate that the product would not be profitable for over five years, they were concerned but still excited to move forward.

When coming up with these early numbers, I like to use an average run rate for a development team, a rough cost of infrastructure, a rough guess for development time through production as my cost. For revenue, I put numbers on my market size multiplied by a percentage that we can get. I then multiply that by our pricing.

	Cost: Run Rate * Time to Production + Infrastructure Cost
	Revenue: Market Size * Sales Percent * Pricing

There are more complicated formulas, but early on, it’s helpful to look at how the scales want to tip. In this case, this product had no legs on it financially.

When this happens, see if there is a way to shift the variables. Don’t change them to make them look good. I mean, look at them and ask what you’d need to change in your approach to move a variable. Can you cut the scope? Can you raise the price or price differently? Can you influence the marketing approach to get to customers more quickly?

If that doesn’t work, I recommend killing the product.

Though in large organizations, ROI is sometimes a secondary factor to internal political capital—looking good.

Don’t Do Sketchy Stuff

Overwhelmingly my involvement in killing products has stemmed from companies finding themselves in sketchy territory, either legally or morally, and sometimes both.

Someone involved with the product work must do their homework on existing laws, standards, patents, trademarks, licenses, non-competes, etc., as a part of product work.

Will your product email people? Know the CAN-SPAM laws. If you’re texting, know the TCPA laws. Don’t just read a few blog articles and assume you’ve got it. Know the details.

If you’re storing customer information for a product in California, plan to comply with CCPA, and if you’re in Europe, GDPR.

Is your product used by kids? You need to know COPPA.

How about scraping information from a site? Most of them will have terms of service preventing this or a Robots.txt also telling you not to. Scraping is a complicated subject, but you should know what you’re walking into with this technique.

Did you already engage another company that gave you a non-compete clause to do similar work? This one has shown up numerous times over the years for me. Read those contracts!

In this world of sketchy stuff, I’ve killed products to protect my clients from getting sued or breaking the law. Each time has been very unpleasant. This is bitter medicine where people hate the moment but are grateful that it happened ultimately.

More than Features

The bottom line is that there is a lot more to building great products than a list of features and a sleek design. Those annoying details that companies put into contracts to protect themselves can cost you everything if you’re not careful.

I killed one product because it would break laws, and another to protect a client from getting sued.

Read the details for the licenses you accept, contracts you sign, competition’s contracts, etc. Your next million-dollar idea could be a multimillion-dollar lawsuit that you’re building one feature at a time.