FeatureOps: The Safety Net You Need When Shipping With AI  🔗 **Source:** [FeatureOps: The Safety Net You Need When Shipping With AI](https://share.snipd.com/episode/e832b3c5-db7e-4c7c-b99e-ceb9d58d222c) ## Highlights - **Project Mindset Versus Product Mindset** - Moving from a project mindset to a product mindset shifts focus from shipping scope on a date to delivering business outcomes for end users. - Egil Østhus says product teams must iterate with user feedback and measure value rather than celebrate the mere act of going live. Transcript: Egil Østhus Yeah, that's a great question. I think, and then you course, you're right. I mean, in its simplest form, it's about the if statement in code and sort of, do you do this or do you do that? And what by the cohort that is having this or the other? I think the biggest challenges that we are facing is, it's a lot about maturity and also willingness to operate differently than typically what you've seen or at least what has been In the industry for quite some time. I think one of the phrases I'm hearing quite often when talking to senior leadership and executives is sort of this change of moving from a project mindset to a product mindset. And I think also the project mindset is sort of parts of what I do read or get from sort of the DevOps type of way of operating. So let me explain this and sort of go a bit on what does this mean. So to put it a bit, simplify a bit, I would say a project mindset is where the team, the organization is very focused around getting a very given scope. So project is typically kind of scope type of focus. Deliver a certain given, pre-given scope and get that into production at a predefined timeline. So you have a time box period of time. It's really important to get in production and to put that scope or that sort of those level of that type of feature, whatever, into production in itself is the meaningful event. That's what you celebrate. You go live. You are super happy. So I think we can recognize this. Either we used to work this way and now we are shifting towards something different or this is still how we operate. So you have a scope and that scope, think of that as a feature or multiple features, written, tested, put in production, go live. It's a very specific date that is an important event. The problem with this, I would say, is that you are forgetting the key purpose of why do you exist as a developer? At least, well, I would argue why you exist as a developer. Your job as a developer is to deliver business value or develop and deliver value outcome for your end users. So the product mindset is less focused around getting that particular scope available in a production environment at a given date. It's much more focused around, are we providing the use case? Are we providing the business outcome, the value? Or are we solving the pain that the end user is looking to solve? And I'm not necessarily stating with a product mindset. You are not sort of saying, I'm also looking to understand and talk to my end users, get the feedback from my end users to iterate and improve. So I would say what we are seeing, and I think this is a fundamentally different way of operating your organization. So if you are a tech leader out there, on how do you define the scope? How do you work together with your stakeholders, your end users in understanding what are you trying to solve versus committing to this is my scope. I will deliver this at this specific timeline at a specific date. That's a fundamental difference. And I would say, if you're not having this mindset, if you're not able, willing to allow your engineers to work according to this way of operating, I don't believe that buying a tool will Make a ton of difference. So it's all around, do you allow this to happen? How do you facilitate this? How do you commit to your end users, customers? We are operating a B2B type of environment, so that's like very individual contracts. In a B2C environment, obviously that's slightly different, but it's the same type of philosophy. It's are you committed to solve the business outcome or are you committed to put a scope into production at a very specific timeline? ([Time 0:06:06](https://share.snipd.com/snip/8cb8a14a-646b-4e9b-a03a-6e4b95bbb246)) - **Four Pillars Of FeatureOps** - FeatureOps is composed of gradual rollout, full-stack experimentation, surgical rollback, and lifecycle management to manage risk and measure value. - Egil frames full-stack experimentation as combining engineering metrics, business KPIs, and user satisfaction into rollout decisions. Transcript: Egil Østhus And basically what we're saying is that, so maybe break down the future ups, it's about the gradual rollout. So this is something you can do with future ups. Sure, I get that. It's also about full stack experimentation. And what we talk about with full stack experimentation is that we have seen A-B testing and that type of conversion rate focus. It's well known in the industry, but we are looking at this as a holistic 360 point of view saying when you build software, it's about the engineering best practices and engineering Optimization. There is also about the business outcome. This is the typical A-B testing, right? And by the end of the day, you'll also have end users. We believe that there is still end users, a human beings, even the AI world that is consuming software. So to develop software that is consumed and easy to operate or kind of be, I mean, how you use your end users is still being super valuable. So that's typically the NetPromotive score, customer satisfaction score, that type of measurement. So all of these three together is coming in, educating how well is your software operating. So that's the 360 point of view, which we refer to as a full stack experimentation. And the last pillar that is important for us is what we refer to as the surgical rollback. Fact is that we're seeing, in the AI driven development, issues are put in production and issues have real impact on businesses. We all remember the cloud failure outage that was a few months back now and the Google outage back last summer. And we will still see those, So having issues in production, even though it's quite quick to redeploy your image into production, the nature of the distributed software is out there In the world still makes a ton of time to really come back from such an outage. So the surgical rollout is basically to allow and make sure you have the kill switches in your software to very rapidly turn off parts of the application in case there are these type of Challenges. And of course, also, if you look at this as an enterprise level where we operate, you need to have a fully solid governance and privacy capability in place. Need to make sure that it's all kind of tied back to your requirements for your industry, whether you're a financial or other parts. And on top of that, also what we refer to as a feature management or feature ops control plane, sort of the life cycle of everything. And I think you alluded to it in the earlier conversation, sort of how do you make sure also that you keep this under control, that you keep cleaning it up. Because by the end of the day, it's a if statement, code. If statement is great because it's simple, but at the same time, it creates unnecessary complexity. And I still believe that clean code is what we are striving for. So having support in the platform to make sure you are cleaning up after yourself is still important. ([Time 0:12:28](https://share.snipd.com/snip/5a993bfa-a7ea-4516-94e0-4749c2b599d9)) - **Start Small And Build Internal Champions** - Start small and use internal champions to prove FeatureOps value before scaling across the organization. - Egil recommends picking low-risk projects, celebrate early wins, and let those teams tell the story to convert skeptics. Transcript: Egil Østhus So when you think about this, this is basically about change management, right? So change management is all about how you move individuals, organizations, teams from this is how we work now into something we're doing something different? Right. And there are some models, some kind of key takeaways there. You need to start. So if there is an external factor, there is like a massive, like, I don't know, we had a massive outage. We need to rapidly change in order for making sure this doesn't happen again. So the crisis is the best enabler for a change. But let's assume that is not the case. Let's assume that we are in this status quo. We want to push ourselves. We are on a tech leader. I want to move my team towards something that makes sense. And it's the thing to do. So basically what I'm seeing working the best is you need to identify, okay, where do you have your supporters? Because there are always somebody in the organization that is sort of hungry to do something different, hungry to learn, hungry to challenge themselves, really kind of always want To do something new, allowing them to be successful. And of course, start small. Don't try to make this sort of into a big, massive, everything is changing at a given date, but sort of start small. And find those supporters, start it small, and also make sure that you are very, it's early success is your biggest champion in your organization because everybody wants to join a winning Team, right? So what you will face is that we are getting this, okay, let's assume I'm a tag leader. I want to kind of get my organization to move from this to the other. I want to get this to work. So I'm identifying some of my champions. I'm allowing them to get to start small. Maybe you want to start in an area where if they fail, it doesn't really have a dramatic impact. And soon as these these team or teams or whatever are starting to gain those or have those wins, make sure to celebrate. Tell that story, tell that story and make that easy shareable within your organization because then what you will see happen is that you're turning those sort of skeptical people or Kind of blockers or pushback individuals coming back saying, oh, this sounds to be interesting. They're doing something smarter. And they start to kind of be intrigued and interested. And then you start having this positive impact mechanism that is happening in the organization. So I think that is my best advice. Start small, identify a champion that is willing to run with you and make sure that you do whatever it takes to make them successful and tell the story. You don't need to tell the story, but let them tell the story. ([Time 0:16:57](https://share.snipd.com/snip/124f75d6-5030-4af9-a405-fd9a9197f9c6)) - **Plan Release Strategy As Part Of The Feature** - Define release strategies early and create repeatable rollout templates as part of the product playbook. - Egil notes templates (e.g., VIP cohort then wider rollouts) let PMs and engineers reuse proven patterns for safer launches. Transcript: Egil Østhus You're absolutely right. It starts very early and typically it would start in the product management level, I would say. So this is where you start putting together some release strategy. So in my context there, just kind of give some insight there. My product management focus or kind of definition is a very commercial role. It spans also into product marketing management and sits very close to the product team, but also very close to the engineering team. So what we are seeing, I would say the best sort of best practices out there is when you start building new features, like start thinking about how do you want to test roll out kind of the Release strategy very early. One of the beauties that we have defined in our product is also to create templates of how you roll out those features. So basically saying, in your playbook of working with software, you have maybe three, four, five very specific release patterns that you're applying again and again and again. So that's something that also we are seeing being adopted more and more, which basically means that when you start thinking about, okay, what I'm building, this is maybe I'm doing a Greater rollout. I'm rolling it first out to my VIP customers. Maybe I'm having a close relationship with this five, seven close customers. Then I'm doing this and I'm doing that type of thing. And that is sort of repeatedly we handled and applied to the development process. ([Time 0:25:46](https://share.snipd.com/snip/d1d313fd-97dc-47d5-80cd-1f6159ce8379)) - **Enable Safe Releases Including Fridays** - Use feature flags and kill switches so teams can deploy anytime, even Fridays, because you can quickly disable problematic changes in production. - Egil argues a proper safety net lets teams detect issues quickly and revert via flags rather than fear weekend deployments. Transcript: Egil Østhus It does. Actually, our slogan when we started Unleash was, baddest developer release on Fridays. Because you don't release on Fridays, And we think that is just a stupid thing to not do so well. But then again, I understand where it comes from because I think we have all been burned on working late hours on a Friday and into the weekend. And that's not a fun thing to do. But yeah, I would say there should not be any reason to not release on a Friday, right? But then again, it depends, right? If you are kind of very, this is a fresh idea, you already kind of, or like you have just finished your automation of the CRCD or kind of just getting up and running on these and you may be Releasing on Fridays is not the first thing you do. But basically, if you do this in a proper way, I mean, you know pretty quick if you've made some mistakes. I mean, yes, we are seeing that the issue is sort of hidden very well deep and it's very, very much a core case. You don't control them anyways, but most of the time when you have and you need to do a post release fix or deploy post release, it's typically happening quite quickly, after the release. So if you are wrapping your changes in a feature of flags and really make that adoption into a robot and or a kill switch type of scenario, you know quite wholly if this is working or not. And if it doesn't, you can always, you have the measures and the safety net to go back to a last known stable deploy of your code. So, I mean, yes, I get your joke in saying this is not what you want to do. But then again, I would say, well, this is actually what you want to do and strive for it. ([Time 0:28:20](https://share.snipd.com/snip/36c30a4f-7a73-468d-9172-2a08eed17fb5)) - **Unleash Offers Enterprise Grade Open Source Feature Management** - Unleash is an open source feature management platform designed to scale to enterprise needs while preserving compliance and auditability. - Egil cites customers like Lloyds, Wayfair, Prudential, and Visa as examples of high-scale, regulated use. Transcript: Egil Østhus So Unleash is the largest open source feature platform that is available in the market today. So all of the use cases, all of those scenarios, all of those kind of capabilities that we talked about is available. And of course, much more. It's also the platform for the large enterprise needs. So what does that mean? It means that we are highly flexible, adapting to any type of tech stack, any type of scenario. And because it's an open source platform, it can really be twisted to any need. And we have been very focused on building a platform that really scales to the millions and billions of end users. So we are working with some of the biggest and most interesting companies on the globe. We are working with companies such as Lloyd Banking Group. I think they are 25% of the UK GDP is going through Lloyd's system. So that is a massive operation. Vafer is one of the biggest e-commerce players in the US. So again, Black Friday and the Black Week is a massive, massive event for Vafer. And we have worked very close with them in order to make sure that Unleash is supporting them through that very important time of year where they make a ton of money per minute. All of this is as well as Unleash and also we are very well integrated into all of those audit logs and audit trails and all of those kind of legislation capabilities that is needed in this Large organization. I mean, as an end user or kind of an end developer, a software engineer, you may or may not be super well aware, or maybe you are, or maybe you have an organization that is good to sort of allow You to be operating without being super detail focused around all of the compliance requirements. But we also are working with a massive organization such as Prudential, which has a high, high number of requirements. They are similar with Visa, again, a large organization where there's security measures and all of those resiliency and compliance parts is really, really important for them. So the beauty here is that we are able to do all of those capabilities and integrate into those compliance processes or needs at the same time not complicating the process because I think That is often what you're seeing or what you're facing or at least what you are afraid of happening is that you are saying I need to stay compliant, I need to be able to have the audit trail, I need to be able to have all of those proofs in case something happens or that's just the world I'm operating in. I cannot sacrifice, I cannot go compromise there. So a lot of the customers we are working with, in particular in the financial industry, are saying, I need to make sure that I don't compromise here. Or they are expecting that we are saying you need to compromise some of that. And by doing this, the beauty here is that we are able to connect those together in order to make sure that this is happening. And you're allowed to operate as the smaller digital first startup type of organization at the same time staying highly compliant or staying compliant according to your needs. So that is what Unleash is. It's been around for many, many, many years. ([Time 0:30:52](https://share.snipd.com/snip/a6a329a6-e095-443c-a86e-4db84b4770f4)) - **The Hidden Cost Of Building In House Flags** - Rolling your own feature flag system is deceptively easy initially but becomes costly and risky at scale, often leading teams to migrate later. - Egil says home-built systems have caused outages and revenue loss before customers moved to Unleash. Transcript: Egil Østhus So we have done quite some research here. And I think the challenge in this area, this category is sort of that it's a very simple problem to understand. As we talked about earlier in this conversation, it's purist form is a if statement. And that if statement triggered, it needs to be triggered by some input fields, obviously. So it's an easy problem to understand. And the beauty with the engineers, but that is maybe also sometimes the cure, is we are builders. Developers are builders. We love to build. And when we need something, if we find it either too expensive or it's too complicated to get the budget approval or there are so many reasons why this is not something... I haven't really met any developer that is saying, oh, I'm super excited to go through this sales process and get the approval for my management. It's like, that just does. I've never seen it. Maybe there it exists, but I haven't met them that often. So basically, it's sort of, ah, it's too tedious. I can build this. And they can. They can get started. The problem is basically that, yes, it's easy to get started, but the complexity lays into getting it right, getting it right every time, making sure the audit, all of those, it's resilient, It's always happening or very like the optimistic piece. So the complexity is in the scale on the size, it's not on the purest form. So what we are seeing when we are often in market is that there is a lot of engineering organization that has started to build this and typically they come to us when it's getting too expensive, Too complicated, it doesn't really work or even worse, it caused outage. I don't want to drop names here, but we have had customers coming to us saying, we need to get out of my home built feature management, whatever, or feature flag system. It created issues. We lost revenue like big time. How quickly can we migrate over to you guys? And that's what they're buying coming to us. They know that we are resilient. They know that we are able to operate at scale. They know that we are highly capable of doing all of that privacy compliance pieces. ([Time 0:35:42](https://share.snipd.com/snip/1bd7d3f0-b8ac-4f90-861c-b47a00687f4f)) - **Local Evaluation Protects Latency And Privacy** - Local evaluation keeps flag decisions fast and preserves privacy by avoiding sending user data back to a central control plane. - Egil explains Unleash SDKs evaluate flags near the application to protect latency, GDPR concerns, and data control. Transcript: Egil Østhus So the local evaluation, and also if you go to our webpage, we, some time back, we published what we call basically a sort of a high level, what do you need to think about when you build a Large scale, the feature management platform. So one of the key concepts is you need to make the evaluation happen as close to your application as possible. One of the things that we have spent a lot of time thinking about is saying, okay, we are putting an SDK into your application. So what is important for us is that when you start building and using feature flags or our capabilities, all of those strategies that we can provide you, that doesn't really impact the Execution speed of the code. Because we know that, at least I've seen when NetPermotor score is dropping, that is typically because if the application is not responsive, if it doesn't operate in a consistent way, That is having a massive impact of your net-multi You don't want to make sure that it doesn't happen. So local evaluation is basically making sure that you make the decision of what type of experiment or what type of feature strategy are you applying to this individual cycle. And you need to make that that's close to the execution of the code as possible. So that's sort of local evaluation. And also the privacy of things there. I mean, when we started to build this, we were, you know, Europe were in this GDPR kind of holidays of the GDPR. So we need to be compliant with that. We come up, we are born out of Europe. And I think that also with AI coming into this world, I think there has been an increased awareness of, okay, data actually make a difference. Data is an asset. Data is important. We need to be very careful of where does the data flow and then where and who has access to that data. So for us, it was very important to design a system where data didn't flow back to the backend engine. It's sort of happening locally with the application because from the security point of view, from a scalable point of view, and also from the privacy point of view, that makes it very Simple for the end users, for the customers of Unleash to make sure that they stay in control, that they are in control. And I think that is also the beauty of being an open source vendor, because I think that these days with the latest events that is developing globally, trust is really put at risk. Trust is something that is starting to be challenged first. Open source is the ultimate trust. It's sort of you, I can tell you my story, I can tell you how I design my system, and you can take my source code and inspect if what I'm saying is true or if I'm not telling the full truth. So what you would be able to do is basically saying, yes, I are in control of the data, I am in control of where the execution happens. And also I can go and inspect and build trust in you as my vendor to understand and really believe that what you're saying is true because I can really inspect. So you can listen to what I'm saying but you can also inspect with yourself that what is happening is real. And I think that is something that the SaaS vendor is out there is not capable of doing. And I would say the last part that you didn't mention, but you were briefly stating, is also this nature of our flexibility when it comes to deployment scenarios. So back in the early days of SaaS, everybody was moving to a public cloud that was sort of everybody needs to go there. Unleash, because of the nature of how it's been built, is sort of saying you can basically deploy this on your cloud, in your private cloud, in your hybrid cloud, in your public cloud Even. Or of course, we also have the SaaS offering for you if you want to go and consume it as a traditional SaaS play. But by the end of the day, it's sort of allowing you to stay in control on the privacy side of things. ([Time 0:39:52](https://share.snipd.com/snip/535de3dc-105f-469f-a16f-09c1ac277888)) - **AI Accelerates Releases And Raises Blast Radius Risk** - AI and agentic development will increase deployment velocity and number of feature flags, making FeatureOps more critical to limit blast radius. - Egil cites DORA data and predicts AI will drive more micro-decisions in software, requiring oversight and surgical rollback mechanisms. Transcript: Egil Østhus Yeah. So, so I think, I think that sort of, it's obviously it's an obvious topic everybody's doing or starting to do agentic development these days. Right. So, so what we're seeing on the, on the short term here is what happens with Gentic Develop is basically that the SDLC is speeding up. You are creating more software quicker and deploying more frequent because of this. But you still need the guardrails. You still need the issues, the possible issues and the impact of issues doesn't go away. So we are seeing that for us, this is a massive opportunity, actually, because when you are putting more through your SDLC pipeline or kind of putting more software to production, and There are either an equal or even what we are seeing some studies, I think the DORA report from 2025 was sort of indicating that the number of issues because of the AI adoption is slightly Increased. I think it's increased by 7%, which is when you increase the N, obviously that's getting into a significant change. That is currently what we're seeing. So the feature of story is even more important in the AI world than ever before, because what you need to make sure is that you have really strong, solid foundations of how do you release The software, how do you kind of have that surgical rollback, and also how do you measure those 360 full-stack experiments in your environment. And also we are seeing that, and of course this is also a risk that comes with AI, I mean everybody has tested the AI prompts. Some is very, very, again, forward running ahead of everybody else. And then it's more complicated in this usage of this. But you've also seen, we have seen this ourselves and also part of that, the stories of the AI holonetization. Starting to write something, do something that it doesn't really see, feels right, or isn't really even accurate. That also happens in the source code development. So this is also for you as a software engineer, as an tech engineer, and a tech lead to make sure that you have your AI guardrails in place. Because you are eventually still responsible for what happens. And I think also what we talked to industry leaders and we talked about it to to senior executive members what they're saying is that ai is important but what really makes my kind of judgment Is sort of the blast radius independent of is written by ai or a human being so basically what they may mean is if the hits the fan i'm not sure if i will learn to say so in your show but you know When when goes wrong, what is the blast radius of that issue? Is that a big, massive kind of impacting all of my end users or is it a small thing? So that is important. That is top of mind. That is not necessarily written by AI or a human being, because if that happens, independently of who to claim, so to speak, or who was sort of causing that issue, you are still responsible For making sure that data is having as least blast radius as absolutely possible. ([Time 0:45:13](https://share.snipd.com/snip/04b1f2c4-c29c-4e54-a89f-b57bfc2c2c7c)) - **Use AI To Help Rollouts But Keep Humans In The Loop** - Consider AI-assisted rollout automation but keep human oversight until trust and accountability are established. - Egil notes Unleash already supports automated rollout decisions but customers debate trusting AI versus keeping a human in the loop. Transcript: Egil Østhus Now this is something that we partly, I would say we support this already and we are keep investing in this as part of our AI's narrative. So this is already here. I don't see this being, we are starting to see customers really adapting this but then again this is uh this is my read is more about okay uh do you trust this do you kind of is this sort of Consistent behavior is this something where i i i want to trust my ai agent to to to do this or is this something where i kind of want to be you know having a human in the loop because of uh by The end of the day i'm still responsible for the blast radio status happening there. ([Time 0:54:52](https://share.snipd.com/snip/a7e6e21e-14da-4637-b30c-b06809f76b51)) - **Vibe Coders Should Prepare For Day Two Operations** - Vibe coders must plan for day-two operations by adding guardrails like feature flags before projects scale. - Egil warns rapid prototyping focuses on day one; successful projects need lifecycle controls for production scale and compliance. Transcript: Egil Østhus It's a big question because vibe coders, I mean, there's so many different things, right? It's everything from the hobby developer that is want to test some great ideas and see the possibility there to sort of enter large enterprises, product management, different, and So what have you. I would say the needs of the piece drop doesn't go away. It's been very much like everybody's amazed on how much you can get done in a very short period of time to get kind of, you know, get off and running and build your, I mean, I've been talking To Invis building like a CRM system in a week and then sort of these things, which is probably true, but it also definitely is not a fall through. So basically what we're seeing is that this is very heavily focused on the day one, meaning getting up and running and getting off the starting blocks. But the day two is less so talked about. What happens when you are in production, when you are getting into scale, when you are getting kind of into the core system? I think eventually, as we discussed, AI will also be able to disrupt a lot of those areas, but the guardrails, this sort of need for and make the sense out of what happens doesn't really Go away. I don't see that is happening. ([Time 0:56:14](https://share.snipd.com/snip/275f3648-4dfd-4761-a451-7eefc700a382))