It is easy to assume that if you add more features, you can create a better product. More features directly translate to more value for your users, right?
In most cases, the answer is no.
Not only that, stopping feature creep in its tracks means that you can stay on budget, meet your timelines and make your app users happy.
Feature creep, or scope creep refers to when stakeholders add excessive features to a product.
Name a time that you have felt overwhelmed. Perhaps it was your first day of work at a new job, where they use systems that you have never encountered before.
From a user’s perspective, this is what feature creep feels like. The app will become too busy from all of the unneeded features and can cause an awful user experience.
Any additional features you introduce into your product will directly add to the complexity of the build. In turn, this can diminish the usability of your product.
Feature creep is also a real problem when it comes to managing your product. It can become almost too easy to go over budget or miss deadlines when you don’t have a clear understanding of how changes to the product backlog will impact your resources.
And worse, this can continue indefinitely.
You can continue to request more and more changes to a product that ultimately never ends up being launched.
Typically, requests for new features are added in after the product has started. They are out of scope and the changes are not properly reviewed.
If you are building an app for your own business, what you should aim to do is create a strong, minimum viable product (MVP). Or the minimum features to test the maximum functionality.
Remembering that you can always add features later down the track after you have received feedback from real-life users in real-life situations.
It is important to think of your software product as a living and breathing thing, if you are not trying to add features in to your MVP, then your scope is already too large.
It can be tempting for a business owner to just keep adding features in an attempt to make the product perfect. Unfortunately, these are the people who can become a victim of their own circumstances. Adding and adding and adding. When they should be launching.
Here are a few simple techniques:
You need to identify the parts of your product (core features) that provide the maximum value to your target audience.
And if you are even finding that hard, ask yourself what is the core value of your business and determine what features complement this from there.
Once we were developing an app for a client and the owner asked to implement a new feature. After I listened to their description of the feature, I asked, “how many people do you think would benefit from this?”
To which they replied, “I could think of one or two already.”
One or two.
Their app had 700 users in their business. And one or two could benefit from a feature.
0.29% of users.
At Konnect we use Epics, User Stories, and Story Points to determine two things about the project; development complexity and business impact.
Development complexity relates to the following:
Business impact relates to the following:
Sometimes, it can be hard to avoid feature creep in development. As software teams we are designed to be agile. But for an MVP holding tight to the key features of the app means you can get real users on the product as soon as possible.
But creating a roadmap is a great way to add features into the development schedule post MVP. Identify an major or minor features and put them on a timeline.
When you introduce a new feature into the scope, project managers can take some features out of the existing scope to meet the product deadlines. Or alternatively give the development team an extension of time and project budget.
The ability to say ‘no’ is one of the most critical skills a project manager can do, because it prevents feature creep.
All too often, project managers will follow the idea that because a client wants this feature, it will make everyone happy. But this will introduce unnecessary features into the product.
Often we like to use this analogy when adding features in to the product, as seeing your entire development process as a round boulder.
The development team is pushing the boulder, at first it can be heavy and hard to move, but once it starts to turn a few times it begins to gain momentum. Soon the boulder is humming along, and the development team only has push it with one hand to keep it moving.
When a new feature comes along that significantly changes the scope, the boulder comes to a halt. When the scope is redefined, the development team starts to push the boulder again. At first, it is hard, it takes them time to get it moving.
Momentum is the most important thing to developing. Developing, especially a completely custom product is complex and there is alot that goes on in the background.
It is better to focus your resources into developing a few features really well, than alot of features kind of well.
Simplicity should be the key goal for an MVP. People love simple products because they don’t have to spend time learning how to use it.
Sometimes it can be hard to take off the business owner hat and focus on the end user of the product. It can be addicting to just keep adding features until your product is a slightly dull swiss army knife and not a very sharp, very useful pocket knife.
In the end, you should be tireless in your pursuit to deliver a sturdy MVP, selecting only features that are essential to the success and uptake of your product.
.svg)
.svg){kind=logo}
