Does Your Product Launch Strategy Include Retrospectives?

Congrats, you’ve shipped something! Maybe it was a minor feature release, perhaps it was a major enhancement, or it might have even been “version 1.0” or an MVP of the next big thing for your company. It’s been a long process that involved lots of people who have done everything from defining the features to creating the architecture to working out the UX kinks to fixing bugs to QAing it to pushing it out to messaging customers to creating a marketing plan and executing it.

It’s time to celebrate, whether that means cracking open some beers, getting a sheet cake from Costco or holding a team outing at the local bowling alley or go-kart track. Don’t get me wrong, I’m not trying to stop you from having a good time, but once you’ve recycled your microbrew bottles and returned your bowling shoes there’s still more work to be done on that now “old” release.“Many people don't do a debrief session because they are already busy working on the next project,” says Jason Womack, Founder of TimetoGetMomentum.com in a post on Entrepreneur, “The purpose of the debrief is to find better ways of doing things the next time by identifying mistakes and clarifying efficiencies.”While everyone will probably want to focus on the next set of challenges, there’s a lot that can be learned from taking a post-mortem moment or two to reflect on this past launch to see what can be incorporated going forward for even more success (which just might merit an even more lavish release party).

What Exactly is a Product Launch Retrospective?

“Companies must review their successes and failures, assess them systematically, and record the lessons in a form that employees find open and accessible.” (HBR.)

That’s not some newfangled wisdom from a Silicon Valley thought leader or a high-powered venture capitalist, it’s a 23-year-old quote from Harvard Business School professor David Garvin.For Product Managers on teams who’ve fully adopted and embraced Agile or SCRUM project management methodologies, the concept of a “project retrospective” is probably not a new one. A retrospective meeting is a chance for everyone involved in a particular release, cycle, or sprint, to get together and take a step back from production to focus on procedure. The goal of a retrospective is to get each party to share their experiences and feedback on the entire process.You want to walk away from a retrospective meeting with a list of things that worked well (particularly if they are not already part of your documented launch process) and a list of things that went wrong or could be improved. After a retrospective meeting, you may want to set aside more time (in a smaller setting) to assess whether your own processes need to be tweaked and figure out specifically what you’ll change.

What’s on the Agenda?

Questions you might want answered during a retrospective meeting might include:

• What was the goal of the project and did we achieve it?
• Were the requirements and expectations clear?
• Was the schedule reasonable?
• Were deadlines hit or missed (and why)?
• Did supporting teams know what they needed to know (and with enough time to do their parts)?
• Was the project on budget?
• If the deliverable has a cost, were the final COGS within range of the initial estimates?
• What were the surprises?
• Where were the bottlenecks?
• What worked better than expected?
• Is it selling as expected?
• What has been the initial customer feedback?
• Are there support issues or costs that have arisen since launch?

Why Bother with Launch Retrospectives?

George Satayana’s frequently quoted statement “Those who cannot remember the past are condemned to repeat it” is the guiding ethos for a retrospective. While planning, building, testing and getting the latest release out the door, people screw up, mistakes are made, opportunities are ignored, steps are skipped and things fall through the cracks.

It happens and it’s completely normal. The goal of your retrospective isn’t to lay blame for mistakes but to use the truth to inform your future projects and processes so everyone can achieve more success with less friction.As a product manager, you may be particularly interested in how other teams felt about communication during the process; did marketing have enough time and information to prepare collateral and other assets? Did support have sufficient training and documentation before launch? You’ll also be interested in what types of reactions, questions, and feedback customer-facing teams have received from users about the release.

Finally, one of the great things about retrospectives is that they give participants a chance to be heard across several departments. While you could simply use this opportunity for “The Airing of Grievances” and the catharsis that may bring, you should center this exercise around extracting some actionable learnings from the experiences of those involved.

Your learnings shouldn’t focus solely on what went wrong, either--you’ll want to highlight the things that went well to encourage do-overs in the future. Yes, a post-mortem review can be a great opportunity to recognize achievements and give credit where credit’s due.

Who Should Be Involved?

It can be very tempting to approach this as an engineering-centric exercise, but don’t fall into that trap. Limiting your invitation list to technical staff will also limit the amount you can learn from this process (although they are welcome to hold their own departmental retrospectives that focus on the nitty-gritty). Instead of taking the technical team approach, try to invite someone from every part of the company. Your organizational chart may vary, but an ideal guest list could look something like this:

• Product Manager
• Project Manager and/or Scrum Master
• Engineering Manager
• Lead Engineer
• QA Manager
• QA Lead
• Operations/Manufacturing Representative
• Customer Support/Service Representative
• Sales Representative
• Account Management Representative
• Marketing Representative

Does that list seem pretty broad? Good, it’s intentional. Evaluating the successes and failures of a launch requires input from everyone involved in birthing the baby and delivering it to the market. If marketing was totally unprepared, you’d want to know about it; if sales hadn’t been trained, you want that to come to light; if account management received feedback from customers, that’s important to include.If you’ve just released an entirely new product (or made a significant change to the current product line), you could also consider including:

• Sales Operations Representative
• Accounting Representative

Adding these folks into the mix can help you ensure the administrative processes required (e.g. adding SKUs, tweaking pricing, etc.) were also completed (or not) during the launch process.Nearly as important as who IS invited is who is NOT invited. You probably won’t want to invite every engineer or member of the QA team because you aren’t conducting an engineering review (although you might want to get yourself an invite to those).

You also should probably not worry about inviting a bunch of executives to your retrospective meeting since you want the working-level folks (or their direct managers) to be the ones present as they actually know what happened throughout the launch process. You can, of course share your findings with executives and others after the fact.

Finally, you’ll also need to decide who you’re going to invite to run the meeting. There’s a case to be made for the project manager or scrum master if you have one since they will have best idea of the end-to-end process, but there is also a case for running the show yourself because as a product manager you’re ultimately responsible for the product. However, in a perfect world an outside facilitator (or even a project manager from elsewhere in your company) might manage the agenda and run the meeting since they’ll have a more objective viewpoint of the release and process.