There’s a saying “If you build it, they will come”. But if you build an amazing product and no one uses it, is it actually that great? Too often, our products gather features like corners gather dust bunnies.
Adding product features is fun and addictive, and it’s how the product management lifecycle works in many companies. If you’re measured in velocity and burn-down rates, then you’re optimized to deliver features. But we know that a bunch of features doesn’t necessarily make the best product. There’s more to do once the last lines of code are pushed out and developers have closed that ticket in Jira.
Let’s look at the steps involved in launching a product feature, from release to post-launch, and at how feature flagging and feedback can maximize your chances of success.
Beta modes and the definition of Done
Development teams often refer to the “Definition of Done” to describe a completed piece of work. It might include unit tests, documentation, and any integration work that needs to happen. But although it’s done in development, that doesn’t mean it’s done. There’s a lot more to do before you can call the feature a success.
For example, you might want to manage the feature as part of a Beta test with a select group of customers. You can glean many insights in a relatively ‘safe’ space by releasing features behind a feature flag, and many product teams build this in as an essential ‘post-build’ stage in their product workflow.
Beta modes are a great way to test criteria for your product feature’s future greatness:
- Does your product feature work as expected? Do customers use it as expected?
Use Beta mode to check that customers use the feature as expected. Sometimes users have surprising workarounds or use your product in ways that you didn’t think about! You should also check that it functions as expected, from a customer’s first log-in to when they get the feature to work.
There’s no test quite like production, and it’s your chance to see how your new addition fits into the bigger picture.
- Can it be accessed as expected? Is it easy to navigate to and activate?
Features often flop because they’re not easily found. Launching a feature in Beta first allows you to see if users can find it in the product.
Don’t just rely on a marketing push to tell the world about your product feature. Marketing campaigns have time limits and may not hit your users at the right moment. Instead, the feature should be discoverable as part of a customer’s existing journey. If they skip over it, you should think about how to identify when the customer is likely to have the problem, and put access to the feature somewhere more obvious.
This doesn’t mean you put all your features at a user’s fingertips at all times. That would make for a hugely busy interface! Think about when the user is likely to need to use the new feature, and progressively disclose more functionality as they dive deeper.
- Does your feature solve the problem? Do users find it valuable?
Many teams use their Beta phase as a staging period, and not as a huge opportunity to dive into learning mode. Don’t waste your chance! Talk to customers to find out if they’re getting real value out of the product feature. Ask questions like ‘How would you feel if you could no longer use this feature?’ to figure out if there’s a fit.
Connect your Customer Feedback Portal to your product, and capture feedback on new features right where they sit in your app. It’s important to make this flow as smooth as possible so you don’t miss valuable insights.
Learn about what customers love, and what irks them. Your first try at a new feature won’t be perfect, so embrace the feedback and learn from it. If customers find it valuable, listen to how they describe it. This will be the baseline for your marketing material later.
If they don’t find it valuable, either iterate until they do, or kill the feature!
- Are you able to support it?
While developers might have a Definition of Done that includes technical documentation, a Beta phase will teach you what you need to do in order to support the feature.
If the feature turns out to be too complicated to support and maintain then be ready to turn it off. It’s a lot easier to determine and do this at this stage, rather than later.
- Are they willing to pay for it?
Most of the Beta programs I’ve seen involve the free use of the features in order to collect feedback and start to get customers on board.
But this doesn’t mean you can’t and shouldn’t ask questions about pricing. If customers find your product feature valuable, find out if they will pay for it, either as an add-on to your usual pricing or as part of a larger price increase that represents the growing value your product will soon provide.
Are there other business drivers that you can attribute to the new feature? Perhaps you can see research and usage data that indicates users will churn less, or that referrals will increase, as a result of your feature.
Compare your insights about the potential upside to the costs you’re also learning about, and paint a picture of whether this is a healthy feature to bring out of Beta and on to the next stage.
Beyond Beta is just the beginning…
Once you’ve thoroughly aired a feature in Beta, you must make the call on whether it lives or dies.
If it dies, record your decision and the insights that led to it in your ProdPad account. You never know when you’ll need to look back on these again. You can revisit the feature in the future or prove a point that something’s been tried before, so you don’t repeat your mistakes!
If it lives, it’s time to take it to your marketing team.
You can use the customer feedback which describes how the feature is valuable to craft a compelling story.
After all, the best way to speak to your customers is to use the voice of your customers.
Your launch material should cover things like:
- What is the feature?
- Who does it benefit?
- How will this make their lives easier, or better in some way?
- Why should they care about it now that you’ve built it for them? How do they start to use the new capability?
It’s no good making a great product that neatly solves a problem for users if no one knows about it. You should test and iterate on the marketing copy just as much as you do your features themselves.
Don’t worry if you have to iterate after your ‘big launch’. Any initial marketing will likely increase traffic over a couple of days, but the spike won’t last. The real value is in whether the feature continues to attract people to your product as a whole.
Your features aren’t there to drive spikes in your traffic, but to build the case for why your product is the right solution to your customers’ problem.
So use your launch-day data and beyond to measure how well your product feature is received and understood. Be ready to change your feature pages, on-boarding emails, and in-app guidance to reshape how you talk about the feature, so it has the best chance of living a long, healthy life.
We’ve all been there. We build a feature, launch it and forget about it because we’re too busy building more new features or tackling other marketing initiatives. Building is only the beginning. To succeed, you need to be able to iterate in both development and marketing.
That’s why it’s important to take time to consider how new features will fit into all aspects of your post-development workflow, including your beta phase and launch phases, before you release them. It means you can make sure every decision – from positioning and pricing through to customer on-boarding and user experience design – is in line with what customers want most from your company.
Want to get better outcomes for your feature launches? See how ProdPad can make sure your feature experiments come to life and provide you all the insights you need to continuously improve your products.
The post Don’t waste your new Product Feature – Tips for a Successful Launch appeared first on ProdPad | Product Management Software.
