Software teams want to ship faster, reduce release risk, and stay in control as products become more complex.
That sounds obvious now. It was much less obvious a decade ago.
LaunchDarkly was built around a simple but powerful idea: software teams should be able to release features safely, test them with real users, measure impact, and turn things on or off without waiting for a full deployment cycle. What began as a better way to manage releases has grown into a broader philosophy about how modern software should be built.
That philosophy feels even more relevant in the AI era. Teams can now generate code far faster than before, but release processes, measurement systems, and control layers have not automatically kept up. That gap is exactly where feature management becomes more valuable.
Here are the biggest ideas behind LaunchDarkly’s growth, category creation, and leadership philosophy.
What Feature Management Actually Does
Feature management helps teams launch, measure, and control software changes with much more precision.
At a practical level, that means a team can roll out a new feature to a beta group, test two signup flows, expose a capability only in specific markets, or turn something off instantly if an issue appears. Instead of bundling every change into a risky release, teams can control features at runtime.
That matters because software releases are rarely just technical events. They affect customer experience, revenue, experimentation, and team confidence. If every release feels high stakes, teams slow down. If they can separate deployment from release and keep control after code goes live, they can move much faster.
A helpful way to think about it is this: feature management gives software teams a safety layer between writing code and exposing it to users, much like the experimentation mindset behind product-led growth and strong product experimentation.
The TripIt Insight Behind LaunchDarkly
The insight for LaunchDarkly came from a real operational pain.
At TripIt, constant releases were part of the job. The company had to handle both mobile app releases and frequent backend changes to keep travel itineraries updated from airline and hotel emails. That environment made release control essential.
An internal feature flagging framework made it possible to run beta tests, gradually expose new functionality, and shut things off quickly when needed. Once that system became part of everyday work, a bigger question emerged: why didn’t every software team have something similar?
The answer was fairly clear. The most sophisticated companies built these systems internally, but most teams either did not have the time, did not have the resources, or had a rough homegrown version that was not well maintained. That created the kind of pain that often pushes companies to rethink their product-led growth strategy.
How to Create a Category People Want
Creating a category sounds glamorous from the outside. In reality, it often starts with a lot of confusion.
In the early days, many companies were still releasing software quarterly or even twice a year. So the pitch around rapid releases and fine-grained control did not immediately resonate with everyone. Some buyers were still working through the shift to cloud software, agile development, and shorter release cycles.
That is what made customer empathy so important.
Instead of telling teams how they should work, the better approach was to ask where they were today. How often were they releasing? What was stressful about their current process? What was the ideal state they wanted to reach?
Those conversations surfaced the real pain. Large, infrequent releases created merge chaos, long war-room incidents, painful rollback decisions, and a lot of stress across engineering teams. Once those problems were out in the open, the value of feature management became easier to understand.
Category creation worked because the message started with the customer’s current pain, not with a lecture about best practices, which is also why so many strong product-led growth examples begin with a painful user problem that the product solves directly.
Why Early Customers Chose Buy Over Build
One of the most interesting early customer patterns was that some of the best buyers had already built their own version of feature management.
At first glance, that seems counterintuitive. If a team already built the tool, why would they pay for one?
Because building the first version is only part of the cost.
Teams with homegrown systems understood exactly how much time it took to create a basic framework. They also understood how much more work it would take to make that system reliable, scalable, secure, and easy to maintain over time. At some point, feature management stopped being a side utility and started looking like a product category of its own.
That is when the build versus buy equation changed. These teams wanted to focus on the business problems their software was meant to solve, not on maintaining internal infrastructure that had quietly become mission critical.
Market Pull Matters More Than Pushing
A big lesson from LaunchDarkly’s growth is that category creation depends on pull.
Trying to force a movement before the market is ready is exhausting. If a prospect is committed to releasing twice a year and has no desire to change, there is not much to sell. But if teams already feel the pain of slow releases and want a better way to move, the conversation changes completely.
That is why the most effective approach combined education with selective focus. Industry talks helped explain the broader shift toward safer, faster software delivery. But traction came from finding teams that were already receptive to that message.
This is a useful reminder for founders building in emerging markets. Thought leadership helps, but it does not replace timing. The strongest category momentum appears when customers already sense the problem and are actively looking for language and tools to solve it, which is a recurring theme in how product-led growth actually takes hold.
The Free Tier That Survived Enterprise Sales
One of the more unusual parts of LaunchDarkly’s growth story is that it kept a free tier even after becoming an enterprise sales business.
Many companies see those motions as incompatible. LaunchDarkly did not.
The reason is simple: developers want to try the product before talking to sales. That behavior does not disappear just because the eventual buyer is a large company. In many cases, the self-serve experience is what starts the buying journey. A developer evaluates the product, proves technical fit, and then brings in the rest of the organization to talk through architecture, security, support, procurement, and pricing.
That makes the free tier part of the sales motion, not a separate lane.
This is a strong example of product-led sales and enterprise PLG working together rather than competing with each other.
The product builds belief. Sales helps buyers navigate complexity.
The First Enterprise Deal Changed Everything
The company’s first real enterprise sale made the go-to-market reality impossible to ignore.
An early customer had already tried the product and was ready to buy. The only problem was that they refused to complete the purchase through a simple credit card flow. Their process required procurement, legal review, and all the mechanics of enterprise purchasing.
That moment forced a strategic decision. Keep resisting the buying behavior the market was clearly showing, or accept that the company was being pulled upmarket.
Once that sale closed, it clarified a lot. Enterprise buyers often do want hands-on product experience first, but they still expect a formal buying process afterward. That combination shaped LaunchDarkly’s long-term go-to-market model.
The lesson is broader than one company. Founders often hold a strong idea of how customers should buy. Markets usually reveal how customers actually buy.
Why Edith Came Back as CEO
There was a period when the business was growing in a relatively steady and predictable way. Cloud adoption was rising, release frequency was increasing, and the market tailwinds were strong. That made it a reasonable time to bring in an external CEO.
AI changed the pace.
Now the software world is moving much faster, and the biggest constraint is no longer just how much code a team can write. Teams can generate far more code than before. The bigger challenge is how to release, validate, monitor, and control all of it safely.
That kind of transition creates a very founder-heavy moment. The company needs clear conviction, fast adaptation, and a refreshed story about where it fits in the new landscape. That is a big reason LaunchDarkly’s original vision matters again right now.
LaunchDarkly as Runtime Control for AI
AI has accelerated software creation, but it has also increased the need for runtime control.
If teams are shipping more changes, they need better ways to expose features gradually, test performance on different user groups, measure outcomes, and roll back instantly when something behaves unexpectedly.
That is why LaunchDarkly now frames its role as runtime control for the AI era.
The core jobs remain the same: launch, measure, and control. But the urgency is different. When code volume rises dramatically, mistakes can move faster too. A control layer becomes even more important because speed without safeguards creates operational chaos.
This change is also affecting internal operations. AI can reduce a lot of the toil that used to drain teams, from ticket creation to backlog triage to repetitive design work. Used well, these tools help people spend less time on coordination overhead and more time on the parts of work they actually enjoy.
Why Founders Should Make Work Fun
The most memorable idea in this conversation is also the simplest: work should be fun.
That does not mean work should feel casual or unserious. It means people should feel the satisfaction of making something useful, solving meaningful problems, and seeing the impact of their effort.
For software teams, that often starts by removing toil. Fewer painful release processes. Less repetitive project management overhead. Faster feedback loops. Better tools. More time spent building.
For founders, it starts with genuine care for the problem. The companies that struggle most are often the ones built around an idea the founder does not deeply care about. Without real empathy for the customer pain, burnout comes much faster.
But when founders care deeply about the market and the people they serve, the work has a built-in source of energy. Revenue matters, of course. So does the feeling that you made someone’s job easier, gave a team their evenings back, or helped people build better software.
That is a durable kind of motivation.
Resources
🚀 LaunchDarkly: https://launchdarkly.com/
💼 Connect with Edith Harbaugh on LinkedIn: https://www.linkedin.com/in/edithharbaugh/
💼 Connect with Wes Bush on LinkedIn: https://www.linkedin.com/in/wesbush/
💼 Connect with Esben Friis-Jensen on LinkedIn: https://www.linkedin.com/in/esbenfriisjensen/
🧠 Sign up for the ProductLed Newsletter: https://www.productled.com/newsletter
Want to build your own product-led success story?
LaunchDarkly’s story is a great reminder that product-led growth does not mean avoiding sales. It means giving users a real way to experience value early, then supporting the buying journey in the way customers actually want to buy.
If you want to build a stronger product-led engine for your business, here are a few ways to go deeper:
👉 Book a Free Growth Session to get personalized advice on your biggest PLG challenges
👉 Join the ProductLed MBA™ and learn the frameworks top product-led companies use to scale
👉 Download the ProductLed Playbook for free resources you can apply right away
👉 Subscribe to the newsletter for weekly insights on building smarter
