 Hey, what's going on you too? My name is Lee Brand. I'm a developer advocate at Akta today We're gonna be talking about when you should stop adding features to your software Let's check it out Okay, so When should you stop adding features to your software? There's basically three three times we'll be thinking about for this one time is For the initial release of your product That's For me, I talk a lot about this with startups Your minimum viable product is Smaller than you think If you're developing a new product because you have a need Then it's simpler, right? You just develop it until it has everything you need in it And then you may decide to release it later But if you're developing a new product Like you have an idea for a product that you think people will enjoy Hmm generally the features are gonna be less than you think mostly because Look, I've been doing this for 30 years and I've been on plenty of teams where we're developing a new product and We're just spitballing ideas for features and nobody Almost nobody has ever sat down and said Should this feature actually go in the product? Nobody says that might be overreaching Or that might be too many features a lot of the times people are just so excited to be working on a new project and a new product that Engineers especially would just you know, we're just spitballing. Oh, and we can make it do this and we can have it do That and who users can do this with it without thinking a lot about Whether or not that should be part of the product release Generally Minimum viable product is less than you think it is and we'll leave that there because I want to spend more time on on the third one the second one is For just a specific release like how do I know when to stop adding features to a release? This is a little bit more simple and there are steps that you can take to keep yourself on track One is stack rank all the features that you think should go So let's say there's 15 features that you want to put in this next release Stack rank them based on how much business value you think they add to your product and How much how many customer requests maybe you've gotten for those For those features that obviously customer requests should take higher precedent, but Um Once you've got them stack ranked Then you can just estimate the effort needed to complete each feature if you've got an established History, it's easier to say. Hey if if we If we plug these in as large medium small whatever Then we can look back at our history and say a large tends to take us about 10 days Medium tends to take us about seven days and a small tends to take us about two to three days Then I can go back through and say each one of these things is small medium large And then come up with an overall idea. How long I think it's going to take to get this whole thing done so little side note on estimation Their guesses all engineers know this their guesses One of the things that engineers don't realize I don't think is when business people go out and do Projections when they say that adding this feature will add 200k to our bottom line by the end of the year Those are guesses too So just understand that everybody's guessing at the beginning enough said about that then you just work on each one of those features To completion and when I say to completion, I mean all the code is written. It does what it's supposed to do the it's all Got tests around it to whatever your company's Level of testing should be if that's 80% or 85% whatever that is And they should have some documentation around that feature ready to go into the docs That that makes a completed feature The reason is because if something happens and we have to release today We can because we've completed The next feature right even if we've only completed one feature that features Complete it's done. It's got all the documentation and everything so you don't have to go back This also means that all along the way one through 15 you can stop and release at any time Because you even if you're halfway through say feature seven You can say hey, we're gonna release the first six features as the next release cool maybe a New trade show started up. I know in the time of in During the time this is being recorded. We're in the time of COVID. So there's not a lot of trade shows going on But if there's a trade show that you want to show off a new release Then you can just say hey, we're gonna cut it off at feature six And that's gonna be the features that we release for the next release of our product so that we can show them off at a trade show Or so that I can land a huge client maybe there were in meetings with a really big client and one of the features in that six features is Something that's a make-or-break deal for them. We can do a release right now and capture that business Without having to worry about whether or not things are torn apart or you know We're removing things or things like that whether things are broken because that those features have been tested and documented So if you release if you release on the original release date that you thought you're going to at 15 days Are some of those features going to take longer than you thought? Yes Are some of those features going to take less time than you thought? Yes In a world of Averages hopefully that means that all 15 features are done by the date you thought Because it all comes out in the wash But in case they don't Let's say you're up to feature number 12. You're working on feature 12 right now And you're getting so close to the release date that marketing wants to start marketing this new release I mean that's their job and that's part of the way your company stays in business So it's got to happen But the good thing is you can release features 1 through 11. You can just stop production on feature 12 Build a release with the first 11 features in it and get it out there today if you needed to right This makes this helps marketing have more confidence in The features that they're marketing in your product Now the other thing is if we get down to release day and we don't have all 15 features done Let's say we only got up to 12 we finished 12 and then we just didn't have we weren't gonna have enough time to do 13 14 and 15 Because you stacked ranked them at the beginning Feature 12 13 and 14 13 and 15 are the least important features So it's totally okay if they don't make it into this release and they're put off until next release So to me, that's how you know when to stop adding features to your software for release basically when you hit your deadline and as long as you're Developing those features to completion with unit tests and documentation Then you can release at any point during that. Maybe it's three months. You set aside to do this next release Okay, this is the one that I want to spend the most time on because this is the one that I've been thinking about it a lot over the last couple of years and I don't know that I've come to a great conclusion and so I just want to put it out there and put my thoughts out there and May hopefully start a conversation because I I think we need to have this conversation as an industry and We've been having fringes of this conversation for a long time But let's let's dive into it for a product overall So you've you've got a product out there a software product out there that's got customers. It's doing pretty well At what point should you say this product is fully baked? We're not adding any more features to it generally in our industry what I've seen is That usually happens when You're about to sunset a product So we're not going to even have this product around anymore Which basically means that they're adding features to this software for its entire life cycle, which may be 10 years right, so the problem is We all know especially me as someone who does a lot of JavaScript developing We all know and it's kind of a running joke that since I started this video. There have been 15 JavaScript frameworks released I think one of the big things that Happens is I've got a product and I keep adding features to it and when it first comes out Everybody loves it. It's because it's lightweight and it's fast and it does exactly what I need it to do and Did I start I continue using it I build off off of that Angular or react or insert your own JavaScript framework here pre-act view whatever You start using it because it's lean. It's fast and it does what you need then The developers of the software probably from user requests start adding features Do this and it can do that now and you're some of them you're like, okay cool That's that's kind of cool. I never thought about doing that, but that would be good for our product That I'm building here or our website that I'm using this this framework for I'll probably Spend a lot of time talking about JavaScript frameworks, but this applies to all software across the board But since that's the place where I live is as a JavaScript developer. That's the place where it's most apparent to me So we've got this cool new framework. We're building on it. It's going well And people keep adding features and we keep upgrading to the latest version some of the features We take advantage of something we don't but after a while it starts to become known industry-wide and an industry kind of joke joke for lack of a better term That this framework is now bloated and it's slow and it's just got too much in it, right? So this is what gets me to thinking about it is if we start with a product that people love because it's small and It's nimble and it's fast and then six years later that same product is Slow and bloated and has a bunch of unnecessary features How do we stop from getting to that point? That's part of the reason that there are New JavaScript frameworks coming out every 15 minutes Because there's new JavaScript frameworks releasing bloated versions of their frameworks every 15 minutes, right? So I think this is one of those things where It's very easy to get sucked down into that because you want to keep progressing as as a piece of software But at the same time you don't want to alienate your current customers, right? So One of the biggest things that I think Maybe is missing or at least it has been missing from a lot of the products that I've been involved with is Kind of a mission statement or a product focus What should be the purpose of this product? For instance If i'm creating uber I'm like, well, I want to be able to get on my phone request a ride Have them show up in 10 15 minutes pick me up and take me where i'm going And I can pay them through the app. So I don't have to exchange any money Don't have to give them my credit card any of that stuff so I can get Nice payment secured Anonymous rides places kind of like a taxi except I don't have to carry cash or Give you know a taxi driver my credit card information so Good idea But then they start adding other features that may not have anything to do with that core statement That's when I think it's gone awry so I feel like if this is your focus then adding a feature like Like the corporate uber account is a great idea Um, not just for corporations, but for families think about like a father who gets a family uber account So that all of his kids Can get rides wherever they need to go or back home from wherever they're at Without having to wait for mom or dad to come pick them up um That's a great great idea and it fits within the mission statement of This kind of rideshare app, right? That is the product focus for uber and if uber started Allowing you to order food like maybe Somebody requested it would be really nice if when I got an uber requested an uber. I could also request from some food from Door dash or something To be at my house when I get there to be at my my destination when I get there at uber um That starts to muddy the water on what actually a rideshare app should be So I think some of that product bloat comes from losing product focus and I feel like There's really two ways that you can combat this kind of losing product focus um three ways if you say pin a Pin the product focus on a wall somewhere or whatever um but if you start with um Asking for every feature that you you want to add or that a customer requests You say Does it belong in this product or is it a new product? Because that's a really good way for your company to diversify and build other products So when somebody requests a feature you can look at it as Is this a new product or does this belong in our original product? And that helps you go back to the product focus that says Hey, this is what this product should be And you can use that as your guidelines to answer that question of Whether or not this is outside of the realm of our original product focus or whether this actually enhances our product focus the other thing that you can do um is Constantly think about how you explain your product to other people Um, we talk about the elevator pitch all the time, right? So how would this feature then affect your your elevator pitch? Does it stay the same? Does it add something new? When you give that elevator pitch is it starting to become not such an elevator pitch anymore? Like if you're having a hard time explaining to someone clearly what your product does concisely and in a small elevator pitch type thing Then maybe that feature doesn't belong in the product. It's a new product Okay, um And I think that that can help with the Because everybody wants to listen to their customers and actually that's part of the minimum viable product um Idea is that you develop these features Just the bare minimum and you let your users Decide what features get added to it what features they want in this software, right? So it's easy to get mired in that if we get enough users Asking for this feature we're going to add that feature to the software Uh But here's the thing at a certain point users are asking for features that may be um Parallel to our product But really shouldn't go in our product So if you take those users features that they're requesting and you ask of yourself How does this affect my elevator pitch? and Does this belong in the product or is this a new product? If you ask those two questions of every feature request that comes in I feel like you'd add less features to your product. You may end up with a more diverse product portfolio for your company, which is a good thing But it also means that your products then stay lean and mean and they do The thing that they do really well Because then you can actually hyper focus on making the features that are there As solid and stable as they can be And it also helps you to respond to New versions of mobile device Uh operating systems new versions of operating systems If you're not worried about constantly adding features to a product you can make the features that are there Rock solid and be on top of new things that come out A new browser release a new operating system release And one of the things that I think Ends up happening to these products and the reason that they end up being Um bloated and slow is because every feature that you add Adds complexity and it adds complexity on multiple levels, right? So it's not just Product complexity. It's not just my product is now more complex for the user. It's also more complex for our engineers um hiring and Onboarding new engineers may take a little longer now Because you've got this feature that uses this thing that not very many people use so You're gonna have a harder time finding people who have experience with that product or that that dependency plus um You're going to have a hard time onboarding them because they weren't there when you decided to add that feature And they they don't necessarily know the intended purpose Of adding that feature. So there's some more knowledge transfer that has to happen When on boarding new engineers to the product team And if your product is getting bigger your customers are getting Customer base is getting larger, which is what you want You're going to have to hire more engineers. So this kind of becomes Um a cyclical problem. You add more features. You need more engineers. You need more engineers. They add more features That sort of thing So then there's also organizational complexity that gets added. So not only are you adding more engineers But you're also adding Teams of engineers, right? So now all of a sudden you're breaking off the the team of engineers that are working on The admin side of your app And the team that's working on the the customer facing part of the app Or maybe it's broken down into an api team and a front-end team that happens a lot, right? Maybe there's A team that works exclusively on a specific feature. Maybe it's a core feature of your business And you want to have core engineers Working on that core part of your business because that thing's got to be rock solid But then you have other engineers who are working on new features or What do they call it um spiking doing, you know spikes to to try out some feature Maybe you're have an engineered engineering team that do nothing but develop a b-tests for a feature, right? But it's not just engineering right now you've got to add a product owner or maybe a product Not a product owner, but a product project manager, right? So you need a pmo to manage The projects that you have going on the features that you have going on Um, maybe you need a design team to make this new feature look pretty if you're developing websites You may have a whole team that does nothing but front-end design css work So adding new features means adding new team members and maybe adding new teams. So the Organization becomes more complex as well Which as a side note also leads to so we were talking earlier about bloats and A piece of software being slow Or being Huge to download whatever it is This can be the same thing with your organization You have this many people in an organization It can be harder to respond to customer requests Because you've got more people in the organization that are now fighting over what's a good request and what's a bad request Um, what can be done? What can't be done? Um, what's going to take a little bit of time? What's going to take a lot of time? so Responding to your customers and your customers needs Slows down because your organization has become bloated and slow And it's because your software Is your organization has become has started mirroring your software, right? Um There's also Maintenance complexity or maintenance cost that goes every feature that has that gets developed has to be maintained maintained by somebody Probably more than some one somebody, right? So Now you have teams of engineers that do nothing but bug fixes, right? um, you have a ticketing system Like jira or whatever to to manage and triage these bugs and and prioritize those bugs and Fit them into a bug release that goes along with a feature release as well So, um, it also means that Just by the sheer People always talk about technical debt as as if Someone did something wrong Right. So somebody cut a corner And accrued some technical debt But the fact is is you don't have to do anything to accrue technical debt A new version of the framework you're using to build your website So if you're building a website a website an angular and a new version of angular comes out There may be technical debt there because the new release supports Async await and the old release was all promise based So now you need to figure out when or if you're going to go back And update those promises to async await calls Those sorts of things are technical debt that you've accrued Not by doing something bad, but just because The other company did something good. They came out with a new release of their software. They added features, right? So this is where we get into the part where I'm saying I haven't come up with a good answer for this like I don't I don't actually know When you should stop there's no hard fast rule that says hey when you get to 72 features No more features for you. It's a new product, right? That's not the case at all When you're adding features, I just think we need to be more judicious about it There are pieces of software that I loved using For their one specific purpose And then they started to add more features and all of a sudden It's really slow to do and really painful to use the product and it's memory intensive and My fans spin up every time I try and use this thing And it really the only reason I ever used this product was to do this one or two things. That's it So the fact that it's got 17 other features in it that I don't use means nothing to me Right. It doesn't help me. In fact, it hurts me because now I've got to Download a bigger binary or I've got to wait for wait longer for it to pop up or I've got to You know wait longer for it to execute whatever it is. It's doing right Or in the case of something like angular reactor view I've got a larger JavaScript payload that has to be downloaded to my users when they use my app built with this thing now right so I guess the the question I want to put to All of you youtube watchers Anybody who happens to see this In the comments below Try and expand on your ideas of what you think why you think A feature should not be included in a piece of software When you should stop adding new features Is there a point where because I feel like there are some products that I've used in the past That were perfect. They were perfect for what they did. They did what they did astonishingly well They were really small to download really easy to run. They were really fast really light on the computer. They weren't graphics intensive or cpu intensive or memory intensive and they did what they needed to do beautifully And after a while, they just kept adding features and kept adding features until The product was hardly recognizable and it took gigabytes to download and It when you double click on it to open the app, maybe 30 seconds I mean, it might as well be double click on the app and go get a drink and come back Right. This is not Not ideal But there are a lot of engineers out there who are a lot smarter than me a lot better engineers than me That fall victim to this that end up building these products that are bloated and overblown And so I guess my question is How do we as an organ as a as an industry? How do we as an industry? Avoid this. How do we keep from adding too many features to a product? Is there a way or are we just doomed to Keep adding features and keep adding features until people stop using our product and go on and something else That's lean and mean and fast like we used to be back in the day So The fact is Just saying that I do whatever the users ask for Um is not good enough, right because Users are going to ask for things in their own self-interest and you can also say that Whatever gets the most user requests, that's how we're going to prioritize So the thing with the most user requests will be the the feature that we add to the next release But at some point When you first release the product There may have been 5 000 people who agreed with This this top feature request, right? Whereas two three four years down the road There's only 200 people that agree with that feature request Should it still be put on the backlog? You know if you've got A million customers and 200 Is your 200 people asking for a feature is your highest number of people Do you go ahead and add that feature? Or should you actually spend time Solidifying the features that already exist Should you spend that time going back and making sure that the features that do exist? I hate to say the word bulletproof, but Should you go back and make sure the features that you do have in your product Are as solid as they can be Right um Going back and fixing little annoying bugs that most people have already figured out how to work around But we're going to fix it anyway, right? um, maybe the fix is to Explicitly say that that's how you do it now this workaround that people have been doing is now the officially Sanctioned way for doing this right? um, I'd like to close with a quote from andu chen from Andries and Horowitz probably one of the Best known venture capitalist firms at least in silicone valley probably in the world um Where he's talking about a lot of the times people add features To try and attract more customers if you're your customer if your customer base isn't growing or you're not doing Very very good. You're not getting a lot of new customers um Will add a new feature and He was saying that Sometimes adding new features won't help right, um adding new features to a failing product sometimes means you need to back up and um, what he and uh, eric reese from um From a lean startup call a zoom in pivot Where you actually Instead of adding a new feature you come back to an existing feature and you zoom into that feature And try and make that feature more robust try and make that feature more solid or make it um the best If it's a table stakes feature All of your customers or all of your competitors probably have that feature So a zoom in pivot could be going back and making that feature The best version of that feature that all of your competitors have So you haven't really added a new feature You've just made that one feature that is usually Sometimes a deciding feature Right, it's a feature that helps people decide to use your product over competitors Go back and Zoom in on that feature and say how can we make this feature better? How can we make it more solid? How can we make it do what it's supposed to be doing As fast and as good and as low on resources as we can make it Um That is a zoom in pivot and it's one of the things that Andrew chin talks about instead of adding new features You can turn around and look at a specific feature and zoom into that so again It's another so long rant But I'd really like to hear your ideas. Um, this is something that I've been struggling with For at least the past few years As I've seen products That I loved get bigger and bigger add more features Until the product is almost painful to use And then you have to go looking for an alternative because you're like that one just I use it for these two things like Why do I need all 17 18 of those other features that make it 500 megabytes to download and Takes up almost all of my cpu and half of my ram Just to run the app much less to do anything in it right, so I'd love to hear your ideas about What are some tricks or tips that you've used in the past to keep your products from getting bloated to keep your products from um from getting slow and being replaced by uh a smaller Faster version of the thing that you've built and spent your time Because it's not like these people that are developing these products that End up being bloated or bad engineers or even bad business people They're probably some of the brightest minds that we have to offer So it's definitely not an intelligence issue There's got to be some sort of ideas and frameworks For deciding whether or not to add new features to your software And I think that's what I really want to get at is Can we as an industry come up with some tips and tricks to help us keep from Bloating our software with unnecessary features And use as a signal For us to not add any more features. So leave a comment below Um, if you liked this don't forget to like and subscribe Um, go ahead and roast me in the comments. If you think I'm a total dimwit It's totally fine. Um, just let me know what you think in the comments below and we'll see you next time