KNOWLEDGE GRIND NOTES
Avoiding MVP Feature Creep
Features aren’t always beneficial
A Primer About Product
Why do products have features?
Simple — features ensure that your product does what it’s supposed to do.
A phone has a calling feature so you can call people with it.
A fork has pointy prongs to ensure that you can skewer whatever delicious food you have on your plate.
A keyboard has identifiable keys so that you know what you’re typing.
Each feature contributes to a product’s end goal, which is to help the product’s target user get a job done.
For example, a smartphone, in addition to having a calling feature, has buttons so you can dial in a number (a feature), a screen so you can see what you’re typing (another feature), and possibly a few apps (depending on the phone you have) to keep you entertained on your morning commute (another feature).
Its job is to be a device of convenience for its user.
Diagnosing the Problem — Why Feature Creep Exists
Applying these product concepts to the process of building an MVP:
An MVP should have features that altogether contribute to its end goal of helping a user get a job done.
It should have no more, no less, as over-featuring can create confusion for the user and lead to frustration.
And yet for many product professionals out there, MVP feature creep continues to be a problem.
Why is that?
Two possible reasons:
- You don’t understand what job you want to do for your user.
- The job you think your target user wants done is not the job that they want done.
A Solution — Customer Interviews
A product is supposed to offer benefits. However, if you offer the wrong benefits to a user, benefits that they don’t care about, then you might as well not have offered them in the first place.
Feature creep is when you create a product that offers a number of benefits that your users don’t care about.
How do you avoid this predicament?
Ask the right questions during a customer interview.
Instead of asking your user for ideas on what to build, which is essentially asking for features, ask to have benefits explained to you. Why is this a benefit? Is it offered by any existing product? How much do you currently pay to have this benefit?
A benefit can appear in many forms but essentially comes down to:
- Something that creates positive emotions for the user.
- Something that removes pain and discomfort.
How to Conduct Interview Your Target Customers
- Ask why
- Ask for facts
- Ask for a commitment (show that you’re not just wasting their time, that you are serious about building a solution to the problem identified)
If you’re asked for a feature, it’s your job to understand why they’re being requested and the motivations behind the request.
If your customer reacts strongly to a statement or a question, it’s your job to understand where that emotion is coming from. Is your customer’s frustration coming from an unmet need? Is their joyful reaction at your statement about a potential benefit that your product offers a sign that they’re currently experiencing a painful problem and are desperate searching for a solution?
A word of advice from the Mom Test by Rob Fitzpatrick:
Ideas and feature requests should be understood, but not obeyed.
More Features = Better?
I see this thinking all the time. During an early customer conversation, a customer mentions a cool feature that your product should have. Eager to impress, you quickly jot down the feature, rally your engineering team, and get building. A week later, you serve up the feature to your customer — they’re thrilled and quickly adopt the feature. A week later, the same person comes up with another feature. Again you rally your team to churn out the feature. Your customer is again thrilled to find another one of their features implemented, but this time doesn’t use the feature.
Congratulations — you’ve just wasted valuable engineering resources and time .
What went wrong?
Not all feature requests are made equal. Features are benefits, sure. But not all features produce benefits of equal weighting. Sometimes, a feature might only be marginally beneficial to your user. You’ll get asked to create the feature, that’s for sure. But that doesn’t mean you have to, and it sure does not mean that the feature you create will be fully adopted by the user who requested it.
Users are fickle. At least their desires are, but not their actions.
Also, the same benefit can be delivered with a different feature than the one specified by your user. Hopefully one that’s easier and less costly to build.
Features that don’t provide benefits that your users care about can also confuse them.
Why is that?
Because simplicity is what users want. Simplicity ensures that the job that the user wants done can be done quickly and efficiently. Unless every feature included contributes in some way to helping your user get a job
Not all features are beneficial because customers only care about certain benefits and not others.
So know your customer.
I started Knowledge Grind Notes with the goal of reading 10–20 pages of a book every week and then writing an article to recall what I learnt and my thoughts on what I learnt.
I wrote this article to summarize what I learnt from pages 29–33 of the Mom Test by Rob Fitzpatrick, which is a book about how to interview your users and draw insights from them to help develop your business and product.
