When it comes to new products and feature introductions, we’ve all seen our share of successes—and flops that hit the floor with a loud and sudden THUD. Some launches were an instant hit while some got almost no traction—and certainly displayed no stickiness. But when success strikes, does all hell have to break loose? Can we prevent the process from collapsing under the heavy load? Perhaps we need to properly plan for success.
You’ve just launched a new product or update. All your homework shows that you understand your customers and are delivering a solution that will truly address their pain points. You’ve got your marketing activities—including social media—lined up to create the needed buzz with your target audience. And then. . .
Nothing.
Users don’t use the product, and even if they try it once or twice, they don’t embrace it.
If you apply traditional processes and have just invested a significant amount of time energy and money into this new product, your tendency will be to invest even more to improve things in the next version. After a few cycles of this, you might finally realize that this won’t solve the root cause of the problem. In some cases, especially if the product was the founder or the CEO’s idea, it might take a considerable amount of time to arrive at this point.
If you are following even the most rudimentary version of a lean-startup methodology (Lean Startup by Eric Ries should be mandatory reading for start-ups and mature organizations, if you ask me), your minimum viable product (MVP) has clearly failed and it’s time to pivot.
What would be considered a failure and what to do if it happens?
While product managers and business owners alike should be thinking about the whole life cycle, pulling the plug on a product is very hard to do. Telling your early adopters or your remaining few loyal customers that the product is now nearing the end of its life is difficult. It is a lot easier if you can agree beforehand what a failure looks like and when the plug will be pulled.
Yes, talking about failure early in the development cycle is difficult—especially in larger companies—but it also clearly defines key metrics that can be monitored. Having a plan also makes it a lot easier to let go.
What if the product is a runaway hit?
While few companies plan for failure and know when to pivot, it seems that even fewer plan for the overwhelming success that can sometimes happen. Imagine your users getting the equivalent of a Twitter Fail Whale because you cannot handle the orders. Is firefighting really the only answer here?
As much as you need to think ahead in case you deliver a flop, you should also put your entire development and delivery process through a test that begins with “What happens if we under-estimated the potential for success by an order of magnitude and we experience exponential adoption?” In other words, what if this product blows our door off? How will we continue to deliver our product without a loss of quality?
“That will be a good problem to have.” This simply won’t cut it if you suddenly find the customers who were jamming up at the order desk suddenly now jamming up at the exit buttons and on the reviews pages.
If you have a great product that’s been crafted with care, you want—and should expect— growing sales, not bad reviews because of your inability to deliver.
At the same time, you don’t want to invest significant effort up-front to ensure scalability just in case.
The whole product-development cycle is based on choices—from low level architectural and platform decisions to the shape and color of a button. But because all product releases live under the constraint of time, quality and the resources available, it is important to pay attention to the highest priority items first. One approach might be to keep a simple question front and centre during development: What if the product is a runaway hit?
This is not about implementing a solution that will be able to cope with exponential growth. It would be nearly impossible to resolve all possible problems that might arise—the assumptions could simply be wrong. It’s about thinking ahead and choosing from available options. In other words, you have to constantly ask yourself, “although these two options may take similar effort, which one would work better (e.g., scales better, is faster, is more secure, etc.) or will help us satisfy demand if sales exceed expectations.”
If your software resides on the client, there is a high chance it will integrate with online services in the background. Some of these services might include checking for updates or providing anonymous usage tracking. Others might enhance the features available to the user through the app by leveraging storage, databases or communication forms.
In all of these cases, you should consider the bandwidth requirements, load balancing, scalability and the user experience of the actual client software (mobile or desktop) if and when that connectivity slows down due to overuse. Also consider the cost implications of hyper-success.
If your software resides in the cloud, consider scalability—will it rise to the occasion? Your plan must address the ability to scale the back end so it can keep up with user adoption, including server instances, bandwidth and less obvious things such as subscription and payment methods—you do have a recurring revenue business model, right?.
Also, think about security and design with best practices in mind when it comes to sensitive customer data. After all, a successful product is much more attractive to hackers than a flop. Don’t leave yourself vulnerable.
Defining failure with steps to take if it happens is important to avoid significant waist. Making choices based on a best-case scenario is, I would argue, even more important. While you don’t need to implement everything, thinking about these throughout the development process will make sure you are as ready as possible no matter how it rolls out.
—
Original picture and photographer credits available at unsplash.com.