04 Dec 2017

LaunchDarkly, #1 Feature Management Platform, Gets $21M in Series B Funding

As founder and CEO of the leading feature management platform, I’ve seen how our customers use LaunchDarkly to help them innovate more quickly, reduce risk, and break down the barriers between developer, product, marketing, and sales. Ultimately, LaunchDarkly helps our customers around the world help their own customers succeed. We take the feature flagging platform that the biggest tech giants (Facebook, Amazon, Netflix, Google) build in-house, and provide it as a service for everyone else. Thanks to a tremendous response—we serve over 10 Billion (with a B) features EVERY DAY— I’m pleased to announce that we’ve raised $21M in our Series B to accelerate our own growth in engineering, customer success, and category education.

Feature flagging/toggling is a deceptively simple idea—by separating code deployment from release with a “flag” or ”toggle”, companies can control who gets what feature in their software. LaunchDarkly allows customers to manage their feature flags at scale, giving them the in-house platform that the big tech giants have. Companies start by using LaunchDarkly for an initial “dark launch” by selectively releasing a feature to a group of their customers. This is something tech giants like Facebook and Netflix do constantly, and it allows them to manage what features we see and use in their products with minimal risk to their business. Once they become comfortable with our platform and services, the product team is able to use LaunchDarkly feature flags for fast feedback, marketing team can use LaunchDarkly for betas and launches, and sales can use us for contract management.  

LaunchDarkly is a unified platform where developer, product, marketing, sales, and customer success teams can manage code in real time. Our three main types of customers are:

Disruptors
These startups want the same feature management superpowers Facebook and Netflix have. We’ve worked with startups as they’ve grown from four people to thriving successful businesses, like Troops.AI. They’ve used us for every feature, usually starting with risk mitigation, then moving into limited rollouts, and then allowing everyone in the business to control their own features. As one startup company’s CEO told me, “We originally started using you as an “oh shoot” button, now we use you everywhere.” Another VP Product said, “Using LaunchDarkly for feature development is like night and day.”

Transitioners
These customers built their own feature management infrastructure and are tired of maintaining it. When companies like Lanetix and a leading ecommerce car buying portal made the switch to our platform, suddenly their developers could do all the things they wanted, like role based authorization and complex rule sets. And what’s more, the rest of the company can also use our tools. Now developers can focus on building and the entire company benefits from access to control and flexibility. When I was in Australia, the company told me “now when we build a feature, everyone asks ‘did you LD it?’”

Innovators
These modernizing companies know they need to move faster to innovate. They are at the forefront of their industry and know that constantly iterating will help them stay competitive. Last year, I gave a talk at NDC Sydney on how to use feature flags. An engineer from a huge IOT conglomerate immediately asked me for a demo and became a customer. This year, he gave a talk on how he’d moved from annual releases to weekly releases.

It’s extremely gratifying for our entire team at LaunchDarkly to see how much customers rely on us to run their own businesses. Customers small and large are looking to us not just as a developer tool, but as a platform that their entire company can use to deliver functionality to the right person at the right time.

While we were in Sydney, a customer’s CEO sent me a personal thank you note for a sales person visiting them and educating them on how best to use feature flags. If you’ve been in enterprise developer software, like I have, you know that usually the reaction to a salesperson visit is not kudos. However, our customers view us as a trusted advisor for expertise in feature management. I am so proud of our team and I hope our funding will help us continue to be the #1 trusted feature flag management platform, as well as invest in more education for our customers and broader market. Want to join our team? We’re hiring!

We found perfect partners in Scott Raney (Redpoint) and Jonathan Heiliger (Vertex). Scott has been a long time friend of LaunchDarkly, giving me advice and guesting on my podcast, “To Be Continuous”. Jonathan is a cloud infrastructure pioneer who is very familiar with the value LaunchDarkly provides from his time at Facebook. I’m looking forward to working closely with them both through the next chapter of LaunchDarkly.

So what’s next? LaunchDarkly has an incredibly broad base of cross-industry customers, from banking to insurance to shipping to ecommerce to hardware. The appeal of feature management is truly game-changing. Instead of code being a static object that’s changed only once a year or quarter, suddenly, code is a living, evolving power. Developers can build, marketing can launch, product can iterate, and sales can sell. Equipping businesses with the ability to move at the speed of every deploy allows an entire company to learn rapidly, deliver value to their customers faster, and produce more value. With this funding, we hope to support more customers and teach the world that there is a better way to build software—feature flagging.

*Header image credit: NASA astronaut Sunita Williams, Expedition 32 flight engineer.

18 Aug 2017

Risk Reduction and Harm Mitigation

Risk Reduction is trying to make sure bad things happen as rarely as possible. It is anti-lock brakes, vaccinations, clothing irons that turn off by themselves, and all sorts of things that we think of as safety modifications in our life. We are trying to build lives where bad things happen less often.

Harm Mitigation is what we do to make sure that when bad things do happen, they are less catastrophic. Fire sprinklers in buildings, seat belts, and needle exchanges are all about making the consequences of something bad less terrible.

What does that mean for a DevOps world where our risks and harms are very different? Charity Majors says we shouldn’t split the world into developers and operations, but into product and infrastructure—and I think that’s a useful way to think about risk too.

Product risk is problems that users experience. We can usually predict and mitigate the danger by testing and being aware of common failings. For example, we can expect and plan for users that may be on a flaky connection, or that they may try to exit a page without saving information. We can work around these problems because we know they’re out there. But our deployments are not something they should see until we’re ready for prime time. For this kind of risk, we use feature flags to control what content is delivered.

Infrastructure risk is more about the inherent fragility of delivering software. CDNs, fiber, servers, switches, towers…the whole system of getting data to people has failure zones. When we are trying to reduce infrastructure risk, we assume that latency is ever-present, networks are intermittent, and we won’t always be able to count on everything working right the first time. We try to build in robust and flexible ways than can route around failures. This is the place we might use feature flags to control failovers or to create circuit breakers to prevent flooding a fragile sector.

Product harm reduction is about making sure that users can have a positive experience, even if something happens that makes it less than ideal. We want to preserve their blog drafts, keep them from committing errors, only show them things they are allowed to change, and above all, avoid giving them a blank page. Something has gone wrong in the trip to the user, but they shouldn’t have to suffer for it.

Infrastructure harm reduction is the ability to pull back breaking fixes, shunt users away from vulnerabilities, and respond near-immediately to things that have gone very wrong. Harm reduction at this level is the kind of action a pager-responder can take to get things back on track before doing more intensive repairs and investigations in the morning.

In my first week, I spent a lot of time thinking about how to summarize our product for a variety of audiences. “Feature flags as a service” is short and pithy, but only works if you can bring your own definition of “feature flag” and a business understanding of why you would use them. What about “Feature flags allow you to make changes in near real-time instead of waiting for a deployment, and LaunchDarkly helps you manage and track flags across an organization”?

Well, that works, but it still doesn’t get to the core of why an organization would want to use feature flags. What I’ve come up with so far is this:

Feature flags segment the risk of creating a product into manageable parts.

Creating and deploying software is risky. We can accidentally build in errors, we can deliver it badly, or to the wrong people, and it can interact in unfortunate ways with existing software or hardware. As organizations, we want to do our best to do no harm and provide benefit. Using feature flags lets us wrap our features in decision points that we can then use to make life easier for our users.

Here are some types of risks that are reduced by using feature flags:

  • Server falls over from too much traffic
  • Canary launch is not well-tracked, problems are missed
  • Old features and workarounds are invisible and get left in place
  • Feature with vulnerable content is deployed
  • API endpoints are exposed to unauthorized users

Managing your feature flags is a post for another day—today I ask that you take a few minutes and think about how you can reduce risk and minimize harm in your organization, your project, or your code. How can you make things robust enough to resist failure, instrumented sufficiently to identify a failure spot, and flexible enough to reduce harmful consequences on the fly?