Table of Contents
Go for Launch
The Facebook mantra “move fast and break things” is a a cliché and sometimes misinterpreted way of saying “innovate quickly.” A better mantra is “release early and often.” Delivering something that isn’t useful is not the same as releasing early. Releasing early means solving a problem and immediately sharing it with customers. A product releasing often does not mean a product full of half-baked features. Releasing often means regularly and consistently increasing value for your users. If you want to create frequent marketing opportunities while iteratively building a better product, release early and often. Institutionalizing this practice will help you outstrip competing products in your market.
How Early Is Too Early?
“Minimal viable product” or MVP is another term bandied about in product development circles. The concept is sound, but most “MVPs” far exceed the concept of “minimal.” MVPs don’t win design awards. They probably don’t experiment with radical user experiences, unless that’s the innovation your product is targeting. MVPs rarely let users authenticate with Facebook. If you are working on a new product and it’s the most beautifully designed thing you’ve ever seen, you’re not building an MVP. Your MVP was done a long time ago.
Some product owners assert that first impressions are everything and your product won’t get a second chance. In their minds, your product will die if you release early. If that’s the case, perhaps your product isn’t solving an important problem.
So how do you identify that it’s time to release early? As soon as your product can demonstrate your core idea, it’s time to release. I’ll let you in on a little secret: as of this writing, Critic can’t accept payments! Isn’t that insane? I released Critic prior to having any automated way of accepting money. At this point, if you’re not leaving this page, you’re probably thinking “this guy is an idiot, I’ve got to watch this garbage fire play out.” So let’s keep reading.
Why Would You Do That?!
You see, I do not need to build a payment system to validate my idea. In fact, spending my days programming is detrimental to validating my idea. Marketing and talking to potential customers feels much more valuable than building a payment system for no one. To release early means to release as soon as the product is useful, and that’s exactly what I did. Of course, I do need to build a way to enable subscription payments in my product. But I did not need it to launch. Instead, I chose to punt on the work that might otherwise prevent me from releasing quickly.
I employed a common marketing tactic to give myself time to build out subscription functionality. Critic has a free 30-day trial. That means I have 30 days to integrate a payment system. Worst-case scenario, I can extend the trial or drop in a very basic payment feature to buy myself more time. I can even ask customers to send me money via PayPal if I absolutely have to. My worst-case scenario is building something no one wants to buy. Therefore, I attempted to address that problem first.
Hopefully this example clarifies how far you can go with an MVP when you wish to release early. If I can release without a payment system, you can release without fully implementing that fancy design. Test your core idea—a feature or two—with a few early adopters who have a definite need for your product. First and foremost, solve their problem. If you don’t solve a problem for at least one customer, you should re-evaluate your idea.
What Does "Often" Mean?
Once your initial product is released in the wild, you will find plenty of reasons to release updates. You will want to incorporate customer feedback, fix defective features, and test out new ideas. To meet these objectives, release as frequently as you can. Weekly, daily, intra-day. As quickly as you can introduce more value into your released product, do it. Traditional thinking indicates that every product release should be a Very Big Deal ™, accompanied by a flashy ad campaign. However, that does not have to be the case. By contrast, your users will feel update fatigue if you are notifying them of changes every day. This is one reason why so many companies release updates on an annual, quarterly, or monthly basis. They do not wish to nag their users with minor updates.
And you really shouldn’t, in terms of pushing information about updates directly to them. Email and push notifications are an invasion into your user’s day. If you are going to send an email or push notification, it should provide a clear benefit to most recipients. That means large updates—design changes, major releases, or critical updates—can be tied to more concentrated, less frequent marketing campaigns. However, posting more frequent and smaller updates on passive or informal channels is almost expected. Your company blog or social media accounts are generally considered fair game for daily updates. Your followers are choosing to have a deeper relationship than the average customer, so give it to them.
Continuously Release
This does not mean every single bug fix should be announced. Nor does it mean you should only push out a new release only once a week. It means that marketing does not have to tie back to a release. Announcements don’t have to be made when you push out a new version of your product, unless it makes sense. However, you should be capable of continuously releasing. With the appropriate processes and tools in place, product updates should go out the door every time a feature is completed.
This is especially true for web applications. Web application updates require no user notification or intervention; releasing quietly and frequently is expected. For mobile or desktop applications, establish a beta group so interested users can sign up for frequent releases. Generally, a weekly or monthly update for a mobile app will make the most sense for the majority of your users. Updating more frequently than weekly will result in notification fatigue.
Release Early and Often for Feedback
Every application update is an opportunity to re-engage existing users. When a user discovers a new feature, they are more likely to send feedback in the form of an app store review, social media interaction, or support request. If you are using an appropriate customer feedback tool such as Critic, you will turn those interactions into product improvements. User feedback should drive user experience improvements, stability, and robustness of product features. By taking this approach, you ensure you are building what your customers need and are willing to pay for.
Seek Opportunities to Iterate
Some users will explicitly outline what they want to see in terms of new features and improvements. This gives you an easy start to iterating on your initial product idea. However, good ideas come from examining user behavior as well. When you push out a new release, what percentage of users use the newly released features? How long are users taking to perform common tasks? Can you make common tasks easier or faster? What features are seeing less use over time? Are you losing customers to your competitors? Are customers leaving your product without seeking a competitor? Have you interviewed a few detractors to find out why they are abandoning your product?
Answering these questions help you understand what you’re doing well and what you’re doing poorly. Additionally, if you are losing customers to a competitor, detractors will help you identify what opportunities you are missing. Perhaps your user experience is poor and you should finally implement that beautiful new product design. Perhaps a competitor’s pricing model makes more sense for your target demographic and you should adapt. Maybe the nature of a business problem you solve has changed and your solution no longer meets customers’ needs appropriately. By frequently gaining insight into shifting user behavior, you will maintain your position as an innovative product that solves a real problem. Further, by releasing often, competitors will have a difficult time keeping up with your innovations.
Release Often to Increase Marketing Opportunities
When you release early, you establish a dynamic with customers that encourages follow-up marketing opportunities. You can already see this in Critic, starting with my introductory product release announcement. I mentioned a future release of the REST API, setting the expectation that a product update would come soon. Naturally, this release will be accompanied by an announcement describing the benefits of this new functionality. Additionally, I turned a newly released feature—multiple file attachments for Critic reports—into an opportunity to write about its potential use cases.
Iterative product development lends itself to great marketing. You will identify a constant stream of new marketing opportunities when you release early and often. In digital marketing, this is a goldmine. Every time you implement a feature worth releasing, write a blog post describing its utility. If your new feature isn’t worthy of a blog post, ask yourself if it’s worthy of being built. You may even begin feature development by writing an article about the feature’s benefits. Amazon uses this approach to great effect, creating press releases as internal pitches for new product ideas.
Consider the psychological impact to users of your product. As a user, do you want to see a single huge release, a one-time update that is hopefully great? Or do you want to see a steady stream of thoughtfully-created updates responding to your needs? I’d prefer the steady stream of updates. I want the product that improves, not the one that stagnates. Releasing early and often demonstratives your commitment to innovation.
I’ve mostly described the marketing opportunities of releasing early and often as feature-related blog posts. Though, blog posts are just the beginning. Notable feature releases can generate press releases, email campaigns, customer contests, and even new pricing models for existing products. You will improve your content marketing, brand loyalty, and revenue by viewing everything you do through the lens of a marketer.
What Are You Releasing?
At Inventiv, we love hearing what people are working on. Hearing from you gives us the opportunity to understand what product teams really need. The discussion enables us to trade notes on our product development tools and processes. Maybe it doesn’t feel right for you to release early and often. We’d love to help you validate (or invalidate!) the idea. Alternatively, we can help spread the word if you have an idea to share with other product teams.
Inventiv’s goal is to help teams build products that succeed faster. Perhaps you walk away from our conversation with more refined thoughts on where you want to take your product or idea. Or maybe you have ideas for what products and services we should create to better support products like yours. Whatever the case, we want to talk. Start a conversation with us!