It’s a readymade punch line for jokes about big government and its grand ambitions, a punching bag for Obama haters, and now the subject of a Presidential apology. But Healthcare.gov, the federal government’s online insurance marketplace, also presents an instant case study in everything that can go wrong when you can’t afford to fail and everyone is watching.
We spoke with three tech- and healthcare-savvy entrepreneurs about what the feds should have done differently--and what the rest of us can take away from their rocky healthcare rollout.
Brad Weinberg, a medical doctor and a partner in the health-startup incubator Blueprint Health: “Long and short is that the government should have set the rules--e.g., plan requirements, no discrimination on pre-existing conditions, etc.--and then let private companies build the websites to sell the insurance. Having gone the route they did, they should have managed the project better and probably considered using different companies to manage different state exchanges to lower the risk of failure and create a competitive network of companies that can operate these sites, rather than a single national one.”
The government did, in fact, spread the work around--but in the wrong way. According to the Sunlight Foundation, a Washington, D.C.-based nonprofit that reports on government, a total of 47 different contractors worked on building Healthcare.gov, each tackling different pieces of the site’s functionality. The result: a fragmented system, with no easy way to figure out who messed up, where.
Lesson Learned: Encourage competition among vendors. Distribute development risk, rather than concentrating it in a single product
Rebecca Woodcock, CEO and founder of CakeHealth, an online tool for managing healthcare expenses: “One thing they could have done differently would have been to do a better job beta testing--soft launching somehow, with a trial period to work through the kinks. As startups, we all live by MVP and lean startup, which means by definition it’s not going to be a perfect product. Fortunately, our users are very tech savvy and have a genuine interest in the whole process. If something is wrong, they want to actively participate in figuring it out. We also actively reach out when someone was frustrated or couldn’t get through a process, and ask for their input to make the product better. It’s amazing how their attitude changes from being frustrated to being supportive. I don’t know if Healthcare.gov has a feedback tab or links where people can give feedback right there, but you want to make sure you can engage with people who are invested in the product.”
Lesson Learned: Big tech-system rollouts almost never work perfectly right at first. You need to create a streamlined feedback loop so you can learn quickly where the real problems are.
Indu Subaiya, a medical doctor and co-founder of Health 2.0, producer of the annual Health 2.0 health-technology conference and the Health 2.0 Developer Challenge: “The politics around this would have gone on even if Healthcare.gov worked perfectly, but the expectations were unrealistic and the communications campaign was poor. User testing should have been in small groups, or phases, getting to scale, and that obviously didn’t happen. They knew people were confused about how things worked. And they didn’t connect the solution well to most people’s pain points--that insurance is too expensive and always confusing. The ACA addresses a lot of that. But it's buried in the weeds of Healthcare.gov.”
When new visitors arrived at the new Healthcare.gov site, there was no down-and-dirty way to get accurate information on plan pricing and specific coverage without going through the whole, error-prone application process. So much for transparency. Frustrated users who ran into technical glitches could only speculate what the payoff for their effort might be--and how much longer they wanted to keep trying.
Lesson Learned: Use the pre-launch window to educate customers and manage expectations. Don’t make customers dig for your value proposition