The Product Launch ProcessLaunches Product Launches Process
"Process clears the path to more creativity”
If you’re lucky, you’ll get to launch dozens or hundreds of new products and features during your career, and with the right planning, each launch will go very smoothly.
In this post, I’ll touch on how to successfully launch a new product. This will include several topics and the success or pitfalls that I’ve experienced over my career. It’s not possible to encompass everything that your team might need, so take this list as a starting point, use and the concepts edit as you go along.
What is a Product Launch?
When I say “product launch” I’m talking about these types of activities:
An entirely new product, ranging from a new SKU to a new feature
Updates to a product's features or benefits
Re-positioning an existing product
Internal changes, such as a new CRM or backend tool
Common Characteristics include:
Externally, there is a change for customers
- UI/UX changes
- Pricing changes
Internally, education is needed to understand explain or understand the change
- Tool changes or updates
- Starting or stopping a process
If you can envision writing a press release, or receiving questions about it from customers, or needing to train team members, I would treat it as a product launch and it should be carefully executed.
"By failing to prepare, you are preparing to fail”
It’s vital to scope out the degree of change that you’re facing so that you know upfront how much effort you need to allocate to the launch. I recommend creating a list of questions to use for each launch, and you can add/subtract depending on your experiences.
Have we, or will we, do other launches like this one?
- At Wild Alaskan, we continually launched new products (seafood SKUs) to our customers, such as Red King Crab, so our internal and external product launch process had predictable steps
- If it’s a unique launch, it will require more coordination to create the launch plan, such as a one-time pricing change
How many of our customers will this impact?
- Create rough %-based buckets to identify the scope, and be honest with yourself. Saying that it COULD impact 100% of customers is a much different motion than saying it WILL impact 100% of customers.
- An example is a pricing change for everyone (core pricing increase), or a pricing change only a few customers will face (less used feature).
What type of change is this?
- Amazon and Jeff Bezos famously talk about Type 1 & Type 2 decisions
- Type 1 decisions are not reversible, and you have to be very careful when making them.
- Type 2 decisions are like walking through a door — if you don't like the decision, you can always go back.
- A good rule of thumb is that you’ll need more effort and planning to execute a Type 1 decision where there’s no going back than you will on a Type 2 decision which you can easily reverse. That said, treat Type 2 decisions just as seriously when launching.
- Amazon and Jeff Bezos famously talk about Type 1 & Type 2 decisions
How do we think customers will react?
- Generally speaking, the more objections that you anticipate the more effort the launch will take. Mainly this is true because it will require internal education and preparation for the launch.
- If there are fewer objections, but high technical complexity, it could also take a long time. Figure out what you’re dealing with and plan accordingly
What processes are vital to get right?
- This is where cross-functional teams need to come together. Each team is responsible for deliverables or project management.
There are many, many more tailored questions that you should ask in this process.
Before a go-live, each team involved in the launch process should sign off that they’re ready. This isn’t a formality, and any team should be able to stop a launch if they’re not ready. To make this a reality takes a big commitment to project management. You’ll need to create many milestones for your launch, checking in with each function early and often.
If you’re facing an upcoming product change, I would recommend taking 10-20 minutes right now and writing down your list of questions that you must answer to be ready for launch. You can do this to plan ahead for the next launch, or as a retrospective from a past launch you wish had gone more smoothly. This preparation will help you drive change.
Introducing change at your company
It can be enormously complex to implement cross-functional processes like these are your company. Typically, change is welcomed as a result of many people routinely feeling a lot of pain, so unfortunately, change might be hard to come by. Here are ideas on how to gain buy-in for these processes:
Start at the beginning - if your company is just launching, or you don’t have any
baggagehistory, then begin by using a launch process and never look back
Identify the pain - talk with your peers and team to find out how current product launches are going for them. Pain can be expressed in many ways:
- Wasted time
- Lower conversion
- Duplicate efforts
- Low CSAT
Calculate the cost of the pain - There are always trade-offs, so find the value in a process like this, or calculate the costs of pain. The costs could be a drop in CSAT, too many FAQs from customers, broken or inefficient processes, etc.
Cross-functional is where it’s at - The success of these processes rests upon getting buy-in across the company.
- In my experience, many CX teams are frequently left out of launch processes. It’s as bad as leaving out marketing or sales, so if this happens….
Start With Why
All good change management and leadership start with “why” you are doing something and then talks about “what/how” you’ll execute. At times when we might feel that our autonomy is under pressure from all angles, it is vital to explain the purpose of adding something new, which generates buy-in, and ownership of the processes, yielding much better results. I’ve found that if you’re able to articulate the pain through the lens of the customer, peers such as product managers frequently respond quickly and positively to change.
A word of caution: Don’t become a roadblock to moving quickly. There’s a difference between rapid iteration and being left out of the planning. If the launch timeline makes you uncomfortable, figure out how to prioritize and get it done. Working with fewer resources (time, people, money, etc.) is the name of the game. If you feel like something significant, that you can quantify, is being sacrificed by a rapid timeline, then raise the issue. As always, if you’re really stumped, or routinely left out, it’s a great time to leverage your manager for extra help.
The scope of the change will dictate how much time is required to communicate the why. Additionally, when you introduce the topic to your team they will inevitably have questions that no one else thought of. It is vital to log these questions, prioritize them, and get answers for your team in a timely manner. This is tied to Project Management.
You may have read or heard of the book called The Checklist Manifesto by Atul Gawande. As you can guess from the title, Dr. Gawande is a huge proponent of using checklists to save lives and improve outcomes. He writes about:
“a distinction between errors of ignorance (mistakes we make because we don’t know enough), and errors of ineptitude (mistakes we made because we don’t make proper use of what we know).” [^1]
In other words, use the project management tools that you inevitably have at your disposal or face the consequences. Most of our jobs are (luckily) not life or death, but why not just make it easier and use a tool like Asana?
In my experiences with bigger launches, the best way to utilize a tool is to run a process with steps similar to these:
Kickoff call with all constituents
Generating a project plan, it will be fleshed out more as you go along, but the group can get started and identify big items.
Introduce the list of questions you generated earlier, and edit them based on the specific launch.
Establish a routine and a way to regroup. Here are a few examples:
- Utilize cross-functional (daily) standups for rapid iteration and communication
- Ad-hoc meetings with small groups to answer specific questions or make specific decisions
Create a calendar of events or milestones for the launch - work backward from there and make sure it’s achievable
Post-launch monitoring process - think about what you want to measure or know after the launch and plan for it by creating dashboards or meetings to check-in
Ongoing maintenance and reporting - most launches do not end, instead, they become ongoing processes
When you’re organizing your check-ins, here are some simple buckets you can use:
New / to discuss
- These are items that arise in the day-to-day
- They’re cross-functional and warrant a group or team discussion
Assigned / In-progress
- Items that have an owner and due date
- Bring them back to the To Discuss column if blockers come up
- Get that endorphin rush and check off items as you go.
- The more granular the tracking, the better you’ll be able to estimate the time spent on the launch
Just like with OKRs, the progress and blockers should be public and visible to anyone involved in the launch. This helps create accountability, and as I like to say: you’ll know who deserves a promotion because they did stellar work. Consider the alternative: If you do not address blockers, then team members are working (very) inefficiently because you’ll eventually need to answer that same question with a lot more at stake. It’s much better to answer most questions pre-launch than it is to wait and hope. Afterall:
Image Source: http://lathamconsulting.com/wp-content/uploads/2015/04/Hope-Is-Not-A-Strategy.jpg
Project plan tooling is also a great place for Q&A: Having a clear way to ask and answer questions will make everyone’s life easier.
The most challenging part of project management in a complicated launch is making sure each team is ready. It helps tremendously to have someone responsible for project management. If you don’t have dedicated project managers, then the person responsible needs a lighter load in other areas because they will have a lot of ad-hoc tasks to keep the launch running smoothly. As with OKRs, it’s easy to create clutter in your project management tool. For your centralized project tracking, think about only adding the big rocks vs each smaller task. The smaller tasks can be tracked on individual team boards.
Here’s a visualization of how to cascade tasks from the project level to departments, and finally to individuals.
When you’re launching something brand new, it is imperative to generate staffing estimates. This gets to the heart of how you’ll support and engage with customers. If you get it wrong, you’ll either be underwater and scrambling to hire more or overpaying for too large of a team. Make sure to communicate how a launch impacts your staffing and budget. I’m sorry to say that if you get it right, you won’t be rewarded, so my recommendation is to make this part of your personal accomplishments for the year and brag about it to your boss. To do that, show your work and process.
A word of caution based on my experiences. If your company is taking a big bet on new technology, as DigitalOcean did with our managed Kubernetes offering, the way to earn board-level approval is to attach a big revenue target. Naturally, it’s easy to get caught up by that target and assume that it will happen from day one. In most cases, this is not the case, and you’ll need to spend time with your peers to get the estimates correct. Alternatively, if you’re lucky enough to work at a rapidly scaling company, like when Robinhood launched crypto trading, then you might need to 5x the estimates. As always, YMMV.
When you’re doing something new, the only way to get good at it is to practice. How much development time you spend on training is usually related to the scope of the change. A minor update might deserve a small update to onboarding and a quick update in a weekly meeting. A major change will require major updates and lots of practice because it’s sometimes harder to unlearn something than to learn it in the first place.
If your team is multi-channel, take the time to practice phone calls, and testing tough and likely customer conversations. Just like with employee onboarding, it’s a big time investment upfront but pays back in customer satisfaction and loyalty. Build this time into the full launch plan and budget accordingly.
Part of the launch will be seeing how your team handles customer questions/objections. It’s important to take a proactive approach to assess quality during the launch, update training in real time, and make sure you’re getting it right. This is especially important because it’s impossible to predict every question your customers will ask.
The more you openly talk about customer inquiries, or friction that you’re seeing, the easier it is to understand. At times like this, QA scores don’t matter and it’s all about learning and improving. Take time to identify how to deliver for your customers and train your team to deliver.
In the past, I’ve personally read over hundreds of emails and chats during a product launch and often spoken directly with customers. It’s very important to trust and verify the reports you’re receiving from the front lines. It’s also important to listen to phone calls because you’ll get a better sense of a customer’s tone. There’s a huge difference between the following phrase if it’s said with anger or just disappointment: “I’m not happy with the pricing change”
Everyone will want to know how the launch is going, so prepare to answer that question. Set expectations ahead of time about when and how you’ll report out. If your reporting system isn’t real-time, then plan on ways to get updates manually. This can also be accomplished through QA and extracting anecdotes from conversations. If you have automated reporting, plan ahead and create a product launch dashboard.
Share recaps of the data, representative quotes from customers, call recordings, and anything else that will accurately convey customer feedback. If you’re sharing an extreme example, make sure to convey that, so your peers don’t generate a false impression of the overall feedback. All-in-all, reporting is a great way to show what the CX is like during a product launch.
Coming back around to introducing change, is a great time to talk about changes you want to make, such as being more rigorous in the planning. As I mentioned earlier, it’s hard to introduce change without pain, so a post-mortem is a great place to identify the pain and suggest process updates. Once you go through enough launches, the post-mortems will identify fewer and fewer process gaps and will focus heavily on optimization and getting creative.
I’ll say it a different way: Process clears the path to more creativity. How’s that? If I have 10 units of energy to put into a product launch, and I don’t need to spend any units thinking about what else there is to do, then I have all of my energy focused on how to do my job better and better. This will inevitably lead to more creative solutions and positive iterations.
TLDR for Executives
New Product Launch Process…
Start with why. Taking the time to explain this clearly will empower your team to move faster later.
The launch doesn’t end the moment it goes live. In some cases, the launch is just the start and it will run forever, so staff/resource your CX team appropriately
Good things are not free and your team won’t magically get more efficient. Allocate budget for CX headcount and/or tooling.
Be an agent of change for your company - effectively launching products is an up-front investment, and if you support the investment, then the team will put the effort in
TLDR for Operators
New Product Launch Process…
Understand the why, and push back if it's not clear. You’re on the hook for explaining this to the team
Having a product launch process isn’t an excuse to slow the company down, figure out how to cut the fat and move quickly
Take a realistic approach to budgets and staffing, but make sure to advocate for what your team needs
This process will never be perfect, but with effort, it will feel better every time