Preventing Feature Flops

You spend months working on a new release with a big feature, headaches getting your new version approved by Apple. It’s finally the day it goes live. It’s out in the wild. You wait over the next several weeks as users update the app. Observing metrics in your dashboards. And to your dismay, the feature received little to no adoption or, even worse, downright infuriated some of your customers. The dreaded flop. Back to the drawing board.

If you work in software long enough, you’ve probably experienced something like this at some point. If you have found yourself in this situation, don’t fret. We’ve all been there. It is frustrating and demoralizing. You begin to question what the future will hold for yourself or your company. This is an opportunity to analyze what went wrong and make the necessary changes to guarantee it doesn’t happen again. A feature flopping can be the result of improper validation, execution, marketing, onboarding, or some combination of the four, all of which can be fixed.

Validation

The birth of a feature generally starts with an idea or a customer insight. Not all ideas should be implemented and not all customer insights are applicable to the broader user base. The funnel that filters out the weaker ideas and narrow insights is validation. What’s left is things you should ultimately design and build. Validation-Driven Design (VDD) is the process of incorporating validation in the Software Development Life cycle (SDLC) and using it to refine ideas / designs in order to build more customer-centric products. The validation phase is the point where changing requirements is the cheapest because no resources have been invested in the downstream phases such as design and development. Always validate ideas when possible unless the cost of validating exceeds the cost to build and continuously validate in parallel with the design phase.

How to Validate an Idea

Perform validation before any major investment to confirm or reject the idea or feature you hypothesized. The more accurate sampling of your user base the better. Talk directly to your customers. Utilize Slack or Discord channels with your most engaged customers. Use SaaS to conduct your own User Research. Send customer survey emails or use a tool like Parra to directly validate ideas with a larger portion of your customers to avoid any unnecessary investment. Use your user research firm if you have access to one. Run a smoke test to gauge interest. Gather feedback and data to determine if something is worth building then decide if it is important in relation to the opportunity cost of the other features you could be building instead. Refine your product roadmap. Then run through the mechanics, scope it, design it, do some more validation, rinse, and repeat and finally build it. Consider metrics for success and bake them into the process. It’s impossible to know if a feature flopped or was wildly successful without the data to back it up.

Validate to Prevent Flops

Lack of validation can be tied back to the majority of feature flops that I have been a part of over the years. Sometimes the step was just not important to a client. They wanted what they wanted and they were paying us to build it. Sometimes validation was present in the SDLC but overlooked for one reason or another. I wanted to share a few of these examples so these things are easy to recognize.

Blindly following trends in technology is recipe for disaster. Technology X is all the buzz and you’re trying to get in on the action. The time window is shrinking but the hype is growing exponentially. Momentum in the market can be a tremendous opportunity for small companies if you can jump on at the right time and ride the wave to hyper growth. When this goes right, it is incredible. When it goes wrong, it’s just another flop with more time and money wasted. Proceed with caution in relation to trends. You should follow the same process and still validate if a hot trend is something your users care about.

Products are built by people and people, so naturally, ego and office politics are often at play. Features get built because someone important wanted to build it, a manager thought it would look nice as a bullet point on their resume, or someone was extremely passionate and convincing in a few meetings. None of these are reason to disqualify an idea, but they are signal that you should probe further to validate the idea, confirming it is something your customers actually want. The best way to navigate these messy office situations is with cold, hard data directly from your customers.

Execution

Shipping at the pace necessary to compete in the modern economy is extremely difficult. The pressure to ship the next feature is already felt prior to the current one being out the door. Corners are cut and mistakes are made causes lapses in quality, value, and even functional regressions.

I’ve seen some features or units of work that actually make the product worse in some unintended way. In these situations, the feature was a double-edged sword. While it introduced new functionality, it caused the product to regress in some unintended way resulting in dissatisfaction amongst users. The solution here is to think through all the ways this feature could go wrong or be bad up front. Don’t just think of how you’re making the product better. Actively think about how this could make it worse for some users. This generally isn’t too much of an issue for additive features but complete redesigns and rearrangements tend to suffer these consequences. Once you come up with these possible regressions, don’t arbitrarily accept them as a consequence of the new feature and build anyways. Talk to your customers and validate that these are acceptable outcomes. If you can, A/B test designs and roll out to a smaller segment of your user base before rolling out to everyone.

Another common execution flop occurs when the feature didn’t deliver enough value. MVPs are great. Deliver the minimal amount of value and then iterate on that. But sometimes we take the chainsaw to the scope of the feature and chop it down to the point where it is hardly valuable due to constraints on resources, mainly time and budget. Make sure your feature solves the underlying problem behind you building it in the first place while providing an adequate level of quality. These types of blunders compound over time giving your product a sloppy reputation.

Even great features flop occasionally. You did everything right and built a beautiful new feature that a ton of your users desperately wanted but still, adoption is low but it is receiving some positive feedback. This is the best place to find yourself because there is hope to make the feature great with some additional effort and minimal investment. The problem is not with what you built but it just needs a little more work to make it a game changer. Be cautious in this territory though. It’s often difficult to discern the difference between a feature that has completely flopped against one with legitimate hope of it becoming a success. Human nature and the sunk cost fallacy will have us trying to necessitate a feature that was dead on delivery. Know when to cut your losses.

After you have considered that and you still believe there is real hope you have some options. At this point you should reevaluate your marketing, onboarding, and supporting resources for the feature. The first step of effective onboarding is giving users the knowledge of its existence and instilling an excitement to try it out in their mind. Making a feature discoverable is twofold: in-app (onboarding) and out-of-app (marketing).

Marketing

A new feature should be tightly intertwined with your marketing. Why build it if you don’t want to tell the world about it? Send email campaigns, push notifications, blog posts, announcements, press releases, rad release notes, and hit every channel possible. Beat it to death. Make it exciting. Be creative. This will attract new users but also keep existing ones engaged and the next time they use your app they will have the knowledge of the existence of the feature. Effective marketing isn’t enough though. Only a small portion of users will actually head straight over to your app and try out a new feature because they received an email informing them about it. Some will forget and some will get distracted once they arrive in your app. They need a reminder.

Onboarding

Once a user finds themself using your product you need a place for them to land on solid ground where you can then direct them towards the newest feature. If your feature is not woefully obvious the second a customer uses your product, it probably won’t be a home run without effective onboarding. The majority of users will find themselves using your product for their normal use cases. They will use the same flows they always use and will be blind to anything in the peripheral unless otherwise nudged towards it. Use bread crumbs, badges, or arrows to point them to the feature. Use subtle animations to draw a user’s eyes to somewhere they normally wouldn't be focusing. Use banners, change log popups, or marketing / learning resources to explicitly inform them of the feature and deep link to it. Consider offering incentives for trying new features. Notion, for example, offers credits for trying out new features. The particular type of onboarding you choose will largely depend on the feature at hand.

And that’ll just about wrap it up. Make the necessary changes to prevent features from flopping at any organization you’re a part of. Learn how to recognize the signs that you may be headed towards a feature flop and take the steps to avoid them. Reevaluate your validation process, execution, marketing, and / or onboarding to reduce the risk of repeated flops. Get back to building and providing the most value to your customers. Thanks for reading. If you enjoyed, please give me a follow on Medium or Twitter.

‍