Can we just add one more feature?
When you’re building a digital product, it’s all too easy to get carried away, both as a client and as a developer. The story usually goes like this: what starts out as a small change request quickly turns into a growing wish list. You keep creating functionality after functionality, adding feature upon feature. And before you know it, you lose sight of the project’s initial goals and end up with something that looks nothing like what you’d set out to do.
The result is rarely, if ever, a pretty sight. Typically, you’ll find yourself with:
- A project that’s gone over time and over budget.
- A bloated, Frankenstein-like product, which is difficult to understand. And even more difficult to use.
- Frustration across the board, including users, the client and the project manager.
- A lot of resources down the drain.
Enters the feature creep
Aka scope or requirement creep, feature fatigue, featuritis and feature bloat. Born out of the best intentions, the feature creep is usually rooted in the wrong assumption that having more features means more customer value. The truth, however, is often quite the opposite: excessive features can actually make a product less valuable to customers. No one needs fifty-button remote controls, gadgets that come with book-length manuals or apps offering a dizzying amount of functionalities that nobody understands. Or cares about.
Don’t get me wrong, any of us can catch featuritis. In fact, according to the Project Management Institute’s 2018 Pulse of the Profession survey, 52% of projects suffered from it in the past 12 months, up from 43% five years ago. The feature creep may pop its nasty head up for many reasons, from poorly defined project scopes through sketchy planning and lack of research to changing priorities. But whatever the cause, one thing is for sure: you need to tame the beast or it will eat up your product.
Our feature prioritization scoring system
When we start a new project, one of the first things we do is define the product as clearly as possible, and narrow the concept down to its main objectives. Take a GPS satnav, for example. Its fundamental aim is to find the best way of getting from A to B. Not to listen to music, let alone to watch movies. The questions we ask at this point are: What does the market need? And the business? The product will only work if it answers both sets of needs.
We collect all potential functionalities and add why a particular feature might be handy. Then comes the evaluation process, that we like to call the value scoring model. It is based on three aspects: business value, customer value and the complexity of the task from a technology point of view. But what do they exactly mean?
- Business value: Which features serve the business goals of the product best?
- Customer value: Which features will potential users find the most important and most valuable?
- Technology Complexity: How technologically challenging is the feature? What components does it have? How hard is it to build?
We like to use a Fibonacci sequence – you know, 1, 1, 2, 3, 5, 8, 13 – to estimate how valuable each feature is for the business and for the market, and how much effort it will take to build it.
First off, everybody needs to get inside the user’s head and rank the features according to customer value. What motivates users? What do they say about similar products on the market? If a feature is super-important, we give it 1 point, if moderately important, 5, 8 or 13, if unimportant, 21 or 34 and so on. Then we go through the list again and do the same for business value. When done, the developer team also scores the proposed functionalities for complexity: if something is very simple, it gets 1 point, if fairly complex, 34 or maybe 55 points.
You add the points up and get rid of the features with the highest totals. Show no mercy. Only those features should be built that are business-critical or create the most customer value, and are also feasible within the project’s scope, timeline and budget. Take user authentication, for example. In many apps, it has hardly any benefits for the customer so it gets a high score. By contrast, it represents a core value from a business perspective, resulting in a low score. It’s also very easy to build into any digital product these days. Another low score. The verdict? This feature is a top priority so it will be created early on.
How to keep a product on track?
Rule No. 1: Never ever build everything that everyone wants. A useful rule of thumb is that if a new feature comes up, another one of the same size should be removed. Otherwise the team won’t be able to deliver the project on time and budget.
Rule No. 2: Talk to customers and test with users. Product development is not a guessing game.
Rule No. 3: Don’t just copy your competitors. “Competitors have it” is hardly a strong argument in product development. If you copy your competitors’ bad features, you will deliver the same bad product. With delay.
Rule No. 4: Assess your backlog regularly, using the feature value scoring model (or any system of your choosing) so your feature backlog and the product stay nice and tidy.
How do you say no to the feature creep? Let us know in the comments below. And while you’re at it, see how we built LiveRobe’s minimum viable product here.
