Before I even start introducing the subject of this article, I have to get this out of the way first: there is no single right way of doing a product launch.
If you came here looking for a silver bullet, sorry, there isn’t one. And whoever tells you they have the grail is lying. Product launches are usually messy and can be vastly different from each other, even if made by the same team. Easy lift-offs are often a sign that something is wrong — problems are either flying over your head, or everything is “perfect” because you spent too much time on what is now a project rather than a product.
With all that said, there are some best practices you can adopt to make the product launch journey less convoluted. Most importantly, I want to cover tools that will allow you to adapt to a naturally bumpy process.
The less beaten-up professionals who read this question might jump to the conclusion that “successful” here stands for “frictionless,” or “issues free.” Unfortunately, this is not true, as there is usually a lot to gain from a complicated product launch.
An operational team was oblivious to your launch, and the aftermath broke their main KPI? You just discovered an otherwise occult strategic misalignment. There is a feature-breaking bug in production? That sounds like an opportunity to revisit the established QA process. Adoption is below expected? Why is that? Did you target the wrong ideal client? Or perhaps your acquisition pipelines are poorly optimized?
Regardless of the problems you face when launching a new product, rest assured that failing might not look like a “success” at the moment, but it’s up to you to take a win out of it.
A successful product launch enables you to improve the product, even if it is unrelated to the feature release itself. Discovery is not a process — it’s an attitude and behavior, and it doesn’t stop when delivery is done. All the feedback you get, positive and negative, allows you to build on top of it and make a better value proposition for your users and your business.
But I’m not naïve, I know that there are failures and failures. Although not much can be generally applied to every spectrum of the product management rainbow, some considerations will save you some headaches in B2C, B2B, SaaS, hardware, or any other shade of digital product you can think of.
Not everyone in your organization cares if you learned something or not, which might create some “I want them fired” types of situations. Depending on the maturity of your organization, you are more or less exposed to this risk, but regardless, it’s never cool to cause a fire and then need to ask for help to put it out.
Both to increase your chances of learning something productive and to preserve your and your team’s jobs, make a checklist with the following items:
Yes, this item precedes the actual checklist. Your launch plan starts as early as your first refinement session, or maybe even further back when the idea is first discussed with you. To maximize your chances of getting the best possible outcome from a product launch, you must lead the entire process with the right mindset.
Have this checklist with you at all times and use it as a mantra rather than a plan to follow. Just as I’ve mentioned about discovery, putting things into production shouldn’t be an event, but rather a habit. Everything that follows applies at all times.
Don’t be arrogant, and don’t let stakeholders’ or managers’ ego trips lead you astray. You and your team won’t be able to solve everything with a single swing. The more you promise, the more points of potential failure you add to your launch later.
This works at every dimension of a delivery: scope, impact, and cost. Regardless of which of those you overshoot, the higher the chances you get people frustrated. Iterative thinking means solving the right problem at the right time, not all problems at once, that’s how you maximize value per effort.
Left alone, different people might have different conceptions of what success means. This is precisely why the “learning” success criteria won’t stick with everybody. Unless you can align expectations with everybody, there is a high chance that some will see failure as what is objectively a success, even by business standards.
Let your stakeholders, users, and clients know what to expect, what can go wrong, and how you will preserve them from harm in case things get off track. Clarify what is there to gain, both in terms of raw benefits, but also as more intangible ones, such as a better understanding of the marketplace, or forcing the limits of tech innovation.
One of the biggest gaps between junior and senior professionals is that the first thinks everything will be alright, while the second knows the headaches awaiting over the horizon. Being prepared to deal with the worst-case scenario can do no harm, and save you a lot of trouble if things do go south.
This is a more solid concept for designers and engineers: a design or code that thinks only about the happy path is doomed to failure. Preventive corner case identification and mitigation help products to be more reliable and to scale better. Your product launch should be the same — what happens if the team’s QA goes on PTO? What if there is a last-minute scope change? Can some key stakeholders have forgotten about the launch? Try and think of the worst that can happen and take precautions.
Documentation might not be the most exciting thing to work on, but it helps a lot both in preparing all the involved personnel for the launch and in helping you to backtrack in case of issues. Good documentation provides clarity and transparency, two of the things you should be outputting the most as a product manager.
Documentation can be as simple as a text doc or a sophisticated JIRA project full of epics and tasks. The form is not as relevant as comprehensiveness and ease of access. Keep track of decisions made over chat, email, and meetings. Take notes of ideas from informal discussions. Maintain the documentation as up-to-date as possible to avoid memory lapses. Make sure all impacted parties have access to the relevant documentation.
This is not a must for every launch. Some low-stakes deliveries are better released with a blast, but for those that introduce a high degree of change, have a high risk of breaking, or bring a high level of uncertainty to the business, it’s best to phase the rollout and adapt according to user feedback.
Phased rollouts are substantially more work, but they can avoid big crises when you, the team, or the organization feel insecure. Don’t get too attached to it, though. If you feel confident enough at the third step of your five-step rollout plan and you have buy-in from peers and stakeholders, it’s best to move faster than to cling to a slow process that has no more benefit to provide.
Going back to my opening statements, no amount of effort and preparation can eliminate the high risk of having some troubles during a launch. If you are prepared for the worst, as we’ve suggested already, you must have a pretty well-defined support line and escalation list.
Whenever something breaks in your house, you have readily available numbers to call and ask for support. The same should be true for your product, and nothing breaks as much as a new product. The escalation list, alternatively, allows for stakeholders to quickly find support, either by reaching out to someone who is on duty during off-hours or by calling senior management to rally resources around the fix.
The most asked question around product launches is, “What are the changes?” The second most asked question is, “What comes next?” Stakeholders, users, B2B clients, your teammates, other teams, and, well, everybody is full of expectations for your product. If you’ve fallen under the above guidelines up until here, people will be left longing for more.
Small promises, managing the meaning of success, and phased rollouts — all of those send a strong message of “not now,” and that’s the idea, actually. A product shouldn’t be a cannonball thrown at a wall, but a chisel chipping away user issues to reveal art. It’s your job as a product manager to convey this exact image, showing others the full picture, and how this and the next launches tie in together to build the perfect product.
You took all your precautions (or not) and your launch still looks like a bad nightmare. Your checklist failed and you have a hot mess in your hands. Take a deep breath, focus, and take the best out of this poor situation. As we mentioned in the beginning, there is a lot to be taken from painful releases in the format of valuable knowledge.
Postmortems are amazing tools for understanding the root cause of problems and establishing follow-up commitments to avoid the recurrence of said issues. Postmortems can capture technical problems, design shortsights, and even process optimization opportunities.
It’s impressive how data-driven and evidence-based people can be when they are looking for a culprit, and taking advantage of this hunter mentality can help you a lot to bring some hard facts to your product maturity.
Not every root cause is technical or processual, some issues might arise from more intangible complications, such as intra or extra-team relationships, upper-management meddling in the team’s affairs, or self-limitations if you have yourself as a product leader.
Retrospectives are standard scrum meetings that should happen after every sprint release to assess how things went and what could be done differently to improve the process. Even if you’re not managing a scrum team yourself, incorporating some practices specific to this right can help you iron out personal team limitations.
No amount of work can transform a bad idea into a good product. In the words of Peter Drucker, “There is nothing so useless as doing efficiently that which should not be done at all.”
A bad product launch might be a hint that the product as it is shouldn’t have been launched at all in the first place. A fatal flaw many organizations fall prey to when trying to innovate is to fall in love with the work done rather than with the expected result. A bad launch might provide all the reasons why you should pivot your value proposition entirely, and that alone is worth more than any consultancy agency or product blogger could tell you. Look at the data and user feedback to identify when a failure is in fact a response to something different.
Product launches are unpredictable all-in plays that put to the test all your team’s worth. There’s no foolproof formula, and that’s what makes our job as product managers so important. Success isn’t necessarily about flawless execution, but rather about moving the business forward in sync with users’ needs.
A “perfect” launch might mean you’ve played it too safe, and the problem with that is that your time to market might have come too late for it to make a dent in user behavior. Take calculated risks, test boundaries, and see everything as a discovery opportunity. It’s often in moments of uncertainty that innovation emerges.
At the end of the day, successful product management isn’t about ticking boxes or following a methodology — it’s about finding and shipping something that caters to actual market needs and moves the business pointer closer to scalable growth. A successful product launch might not lead to any, while a catastrophic one can show you the way toward both.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Phil Freo shares his experience scaling Close from its founding team to more than 100 people and transition to being a fully remote company.
Nick Fisk shares his experience leading transformations and transitioning companies to a product ownership model.
It’s easy to hide behind charts and justify decisions with shallow metrics. But great product teams resist that urge.
Tony Schumacher shares important lessons he learned and has taken with him from working under his former boss and mentor.
Learn more →
