(source: http://dilbert.com/2013-02-25)
Monday’s Dilbert strip is a perfect illustration of something that happens so often in app development: a collision of design by committee and feature creep that takes a product so far off the rails from its original vision that it becomes a complete trainwreck.
It’s hilarious when it happens to Dilbert. It’s devastating when it happens to you.
How does it happen?
Of course, everybody’s own idea for a feature is the best one. For lots of reasons — usually some combination of politics, people-pleasing, indecisiveness, compromise and insecurity — the developer ends up incorporating everyone’s “best” features, and a product that was built to be simple and elegant becomes a bloated Facebook/Twitter/Google+/Pinterest/LinkedIn-integrated, geolocation-targeted, pop-up-notifying gamified mess.
Minimum Viable Product is a hugely popular concept, especially among seasoned founders, and it’s for good reason. Building a successful app is as much about what it doesn’t do as what it does. That’s something all of us (the development community) need to take very seriously when we’re tempted to add a new feature.
On a high level, it’s easy to say “stay true to the product’s original vision and you’ll avoid feature creep.” But the reality is, it doesn’t work that way. Every member of your team can interpret that vision differently, as well as how that vision should be delivered.
Here are a couple of the methods we’ve found that actually work:
An Undisputed Product Owner
This could be the founder, it could be an executive within the organization, or it could be the product manager (your in-house PM, or that of the firm you hire). The buck stops with this person, and no changes are made without their approval. You want your product owner to be a disciplined member of your team who’s willing to stand their ground, as they’ll have to say “no” a lot more than they’ll say “yes.” People may get mad at your product owner for shooting down all of their feature requests, but when your team launches a focused product with a streamlined UX that brings value to the user without confusing them, everybody wins.
Test Assumptions
In many companies, for the reasons I discussed in the first few paragraphs, an Undisputed Product Owner is hard to come by, especially when there are conflicts of interest; it can be hard to say “absolutely not” to the person who signs your paycheck. The solution? Test it with your users.
Now, there’s an important distinction between testing features conceived by your core team — people who are intimately aware of the product vision and goals — and letting your users dictate the product that you build. DO NOT simply build every feature that you get requests for from your users. As Jason Fried suggests, this can be a recipe for disaster, as frankly, users are not the best builders of products.
If I had asked people what they wanted, they would have said faster horses. —Henry Ford
You should still have a product owner, and you should still diligently nix any new features that don’t offer a clear benefit and an even clearer alignment with the product vision. Use testing as a method to vet features that pass those tests, not as the primary driver of your product roadmap.
Along the same lines, another trick you can use when you’re questioning the value of a proposed feature is to fake it till you make it. Add a dummy icon or button touting the feature you’re considering, and observe how your users interact with it; if it’s getting a lot of clicks, it may be worth pursuing.
Use an event tracking tool (like Google Analytics) to see how many clicks your test is getting. Of course, when a user clicks on it, you’ll have to explain that it’s in the works.
Bonus Marketing Tip: Tell them their account will be one of the first to get this feature when it’s ready.
This way, you don’t spend time building features your users won’t use, and you can turn the test from a frustrating “this doesn’t work!” complaint into an opportunity to show your users that you’re putting them first.
Everyone, founders and developers alike, have their own horror stories about situations like Dilbert’s and their success stories about how they have staved off feature creep and design by committee. Let’s hear yours!
—Nick Kishfy (@kishfy)
· · · · ·
If you’re building a web or mobile app, MojoTech might be able to help. We turn ideas into products, build full-featured applications, mentor and accelerate development teams, rescue stray projects, and help our clients make smart decisions that pay off. Let’s build something you’ll love.