For me, the news of Healthcare.gov failing to launch hit too close to home. Imagine that the product you’ve been working on for years implodes on its first day of life. That’s a Product Manager’s worst nightmare. Unfortunately, this story happens too often in the software world. So, what can we do to prevent it?

Launching Healthcare.gov was a key cornerstone of President Obama’s political platform. Stakes couldn’t be higher. And yet, it seems that the release planning was off-way off.

In this post, I share some of the precautions I take to minimize the risk of a failed launch. With some strategy, planning, hard work and a bit of good luck, I believe it’s possible to avoid situations like Healthcare.gov. Let’s get started.

Define a Minimum Viable Product (MVP) that fits realistically into your timeframe

In any project, no matter how high the stakes, it is very important to have a clear understanding of the requirements and propose an MVP that is doable within that timeframe.

Agile purists might say that you can’t really attach deadlines to Agile development. “It will be ready when it’s ready,” I often hear. I don’t agree. The reality is that we live in a world with deadlines, and development deadlines are not the only ones that matter. To release a product, we also need to train Sales, Marketing, Support, etc, and there are usually very clear deadlines we need to hit to avoid missing our market window or client commitments.

Overall, it is better to release something with limited functionality or limited geographical reach than not releasing anything at all. Remember that software is always a work in progress. The only certainty after a successful “version 1.0″ release party is that the following Monday you’re back to work on version 1.1.

Be realistic about your team’s capabilities

As you create the product roadmap and pitch it to executives, it is important to be honest about the capabilities of your team. We often fall prey to the “halo effect” and believe that since we have a great team of back-end developers, they can tackle any other area, like mobile, UI, etc. Software disciplines are very specialized these days. For example, in SaaS software teams, it’s common to find specialists for services, database, networking, front-end, security, mobile, etc.

My point here is make sure you understand what it will take to build your product and hire/train the right people. If your product is very complex, needs high availability or has very tight deadlines, be realistic about the team you have. You might need to change scope or convince the executive team to hire the resources that you need. Otherwise, it’ll be almost impossible to deliver on the product promise you are making.

Don’t forget to include a Project Manager

Many reports indicate that the development of Healthcare.gov didn’t have a clear leader. No wonder the results were catastrophic.

A project so complex and with as many moving parts as Healthcare.gov needs a clear leader; somebody to own the day-to-day operations and keep everybody on the same page. A strong Project Manager could have prevented the failure by coordinating multiple departments, vendors, engineering, etc and keeping track of the goals vs the schedule. This person could also be the central point of communication.

A note of caution: the fact that PRODUCT Managers often have a PROJECT background doesn’t mean we should take on both roles at the same time. The more we can offload those responsibilities to a dedicated Project Manager, the more risk we mitigate and the more time we’ll have to focus on key Product needs.

By the way I recommend looking at my article on how to hire a Project Manager in case you don’t have one on staff.

Agile can help

Agile provides a framework to minimize risk by implementing iterations that produce working software. It is not a silver bullet, but it does help a lot. Agile provides us with a framework for continuous improvement, one sprint at a time.

Each iteration is self-contained, meaning that it includes design, development and testing. Therefore, the code on every single iteration is tested to ensure it meets the desired levels of quality.

As part of the testing strategy, the QA team should develop unit tests, perform regression testing, and build a comprehensive automated framework to validate all the use cases defined by the Product Manager. You will still have some manual testing on every iteration, but the better the automated coverage, the better the chances of success.

Plan for performance and stress testing

Product Managers must understand the impact to customers when their product is down. For example, if my system fails, will businesses cease to operate? Will electricity go down? Will people’s lives be in danger? The bigger the impact, the more you have to plan for performance and stress testing.

As Product Manager, you also need to understand your audience and the overall usage of your product. For example, will you have 100 or 100,000 concurrent users? What times of day are more likely to be peak times? What redundancy and elasticity specifications does your product need in order to meet demand at peak times? Understanding the constraints is the first step. The next one is to come up with a plan to test them and ensure you’ll be ready to handle them when they occur.

Many articles commented that Healthcare.gov was intended to support 10,000 concurrent users, but weeks before the launch, it wasn’t able to support even 500. This fact alone raises big red flags in the overall management of the project. Performance testing must be part of every sprint, and it should be done in an environment similar to the real world. Anything less, and you risk maxing out your website very fast.

You can perform these tests on isolated portions of the code during your regular sprints. In fact, the performance team should have its own stories in the backlog and should have deliverables for each sprint. Additionally, I recommend doing end-to-end performance testing several times before the release. Which brings me to my next point…

Allocate Time for Integration Testing

Even though Agile promotes creating production-ready code on every sprint, the reality is that it is very hard to get there. If you have a big development team, each “Agile Pod” might be able to test their part of the code, but there is no guarantee that everything will work flawlessly when you merge the code of hundreds of developers.

To mitigate this risk, I recommend putting aside at least one sprint for integration testing and stabilization before every major release. The goal of this sprint is to stabilize the system and get it ready for production. No new features will be developed during this sprint.

On top of the technical challenges associated with integration testing, be prepared to convince your executive team that no new features are going into the product during that final sprint. They might not be happy, but it’s our job to educate them on the process and help them understand that in the end, this effort will benefit the product, the users and the company.

Communicate

During the launch of Healthcare.gov, I find it hard to believe that the President and other top executives were not aware of the problem. Obviously the engineering team knew the website wasn’t ready to support that traffic, but somehow that information never made it through.

When faced with a delay or any other roadblock, it’s imperative to have open communication with the executive team. Sponsors need to have timely access to information so they can make decisions that might affect the whole company (not only your product). In this scenario, take advantage of Agile and use the end of each sprint to inform your executive team about the progress, and more importantly, about whether the product is on track to meet the deadlines you agreed upon.

It’s better to delay than to implode

If after all these precautions, you realize that your product still won’t be “ready” by the deadline, then you need to make a decision: to push the release out further or to cut scope to ensure that at least something is released. Notice that I say “ready” in quotes, meaning that it’s up to you, along with your team to determine what ready is.

In the Healthcare.gov example, they decided to release when they weren’t ready and the backlash has been horrendous. I’m not saying that delaying is easy, but it might be less expensive than pushing forward with a faulty product. To make these decisions/recommendations, it’s important to understand both the technical and business side of your company so you can understand the impact even before you make the recommendation.

It’s interesting that the government announced “victory on the healthcare.gov” website just a couple of months after the failed launch. If the site was going to be ready after just 2 months, wouldn’t it have helped to delay as opposed to launch and face ridicule? In my opinion, managing PR for a delay is much easier than managing PR for a failed launch.

A good example of managing a delay comes from Gran Turismo, the best-selling car racing game in history. The release of Version 5 was delayed for a couple of years due to “executive decisions” because they believed the game was not ready to meet expectations. In the meantime, the company release a “reduced” version called Prologue to keep the fans engaged while they worked on the final product. The approach worked. Although Microsoft and others launched competing products during the wait period, the launch of Gran Turismo 5 was a huge success, in part due to the credibility they maintained with their audience and the fact that when the product came out, it truly delivered on its promise. Not all companies have this luxury, but it’s worth considering whether there might be some middle ground.

In Summary

At the end of the day, it’s the Product Manager’s responsibility to bring the product to light. Failure to launch can be a disaster not only for your company, but also for your career as head of the product. Luckily, many of the risks can be mitigated with good planning, foresight and great communication.