We are right up in your launch business and looking under every nook and cranny to make next go round much easier. Last week we went over Launch Debrief Widgets, 3 areas and 12 points, we would analyze to improve our launch. Today, we are analyzing all 12 points and will quickly prioritize refinements and crucial areas of focus.

General Project Plan, including Pre-Live & LIVE strategy

Looking back at your calendar and dates, crossover work for Pre-live and Live, and functional areas and sprints. . . we are going to ask some important questions that help us with timing.

1. Did we have enough prep time?
2. Why did we have so many crossover tasks?
3. What could we have been working on well before we entered the pre-live stage or live stage? Note: Its ok and normal to have regular tasks crossover in the beginning of the pre-live stage BUT it is my ultimate rule of thumb that once we enter LIVE launch stage (specifically that sprint) we only work on the live launch. It is an ‘all hands on deck’ sprint.
4. What functional area took longer than expected? How many additional days or sprints did each functional area need?

FAQs How many sprints or time needed in pre-launch and live launch?

Typically the pre-live stage lasts 2-3 sprints (equivalent to 4 – 6 weeks), however this doesn’t necessarily include the audience priming if you are doing pre-sales or warming up your audience before open cart. It’s normal to have some regular task crossover at the beginning of the pre-live stage, but as you near last sprint of pre-live you want your team’s sole focus on be pre-live tasks. Rule of thumb is we carve out an entire sprint to LIVE launch stage because a 10-day cart period fits nice and tidy there. Even if you aren’t doing an open/close, the same perspective applies.

By tracking your sprints and functional time required, you will get better and better at assigning milestones and deadlines.

Team, Support, and Resource Management

The next set of questions will help you open your eyes to who’s doing what work and what’s getting done on time, as well as how to improve communication and collaboration within your team.

1. Did my team know exactly what to work on when?
2. Was each team member prepared to complete their piece of the pie?
3. Were there any tasks or functional areas that needed to be split between two people?
4. Did I/we have point of contact with each team member during the pre-live and live stage?
5. Did the team discuss and collaborate during each stage?
6. When could we have had better communication?
7. Who did what and when? Was their progress impeded by a deadline missed or blurry responsibilities?
8. Did we make it harder on ourselves by recreating the wheel? Where could we have repurposed existing content or frameworks?

FAQs: How much do you stay in contact with your team during pre-live and live launch stages?

In Pre-live sprints we normally have weekly checkins generated automatically in Slack, plus we are in constant contact with progress updates in project management software. During live launch stages, I strive to have daily checkins with each team member and at least 1 (if not 2) video calls to maintain ultimate collaboration. I love daily standups and it keeps us on task!

Tech

Chances are high, you know what tech worked or didn’t work- BUT we can always improve our tech support and training for launches.

1. Do we have actual documented workflows and updated video walkthroughs on tech we use during launch?
2. Are the listed tech platforms necessary? Are we using all the options or just a few of the features?Are there other alternatives?
3. If there were workarounds, how can we fix them officially? Was it a necessity or a bandaid until we made it through?
4. Did we give enough time to properly setup tech?
5. Did we have enough testing time assigned?
6. Do we have a running bug list?

FAQs: Who is responsible for tech setup and daily management/use? What kind of trainings does each team member need? What is a bug list?

While I don’t setup tech on a normal basis, I am very particular (as you should be too) on documenting workflows and video walkthroughs so IF I (or any other non-tech support needs to) knows what’s happening. This is especially crucial to tech used during launches because everyone is working together and that means tech is almost always involved. I also love and have newly implemented a running bug list that is beyond traditional website glitches but also platform and scenario specific.

Ok, phew! That was a lot of think about.

Critical Areas of Focus and Refinement Priorities

Now that you have asked yourself the hard questions. . . we need to focus on the most critical area to improve first!

Look over the 3 areas: General Plan, Team/Support/Resource Management, and Tech. What was the biggest pain in your behind that made this launch go awry? Was there an epicenter of things that started to fall off? That is where you start.

Once you’ve handled the critical areas of focus, you need to focus on refinement points. These things can be easy fixes or tasks that your team can collaborate on. It’s always a good idea to continue and break down your tasks into single level actionable tasks so that if one thing goes wild, you haven’t halted progress of an entire functional area. Doing this Launch Debrief right after launch and including your team in the collaboration helps because it is also fresh on their minds!

Launching is fun exciting and also a pain in the behind. Without this Launch Debrief, I can’t improve our operational strategy or the individual widgets that make all the things move.

Ya’ll we are just out of the season of launching #allthethings x 1M! I mean this was crazy town over here, we had launches and promos and flipping things to live going on all over the place. While I LOVE the exhilaration of a good launch and being in the trenches with my teams, I’ve had to spend the last couple of sprints (with at least one more) debriefing the launch and other operational aspects.

A Launch Debrief, what is that? Well a launch debrief is where myself and my lovely CEO clients pick apart the launch and refine so we can improve the launch’s operational elements. It’s very similar to a sprint review, but solely focused on the launch.

Over the course of this two parter blog series I’m going to walk you through Part I: Launch Debrief Widgets (the what and why) AND Part II: Launch Debrief Results (the how) .

It’s really important that you LD as separate to a sprint review because a significant launch is much different than analyzing your regular ‘ole “stuff”. You may be re-launching your thing later this year so you need to know how to improve and make it a littler easier to replicate. You may even be turning this into an evergreen launch, so you gotta get it right and transitioned correctly from live launch to evergreen. You may even (probably most of you) be using this launch as the framework and process of other launches in Q2-4. So you’ll need to nail and refine the workflows, stages, and resource management.

Sidenote: Now this is where my thinking differs between other operational integrators or strategists. We don’t actually look at results of the launch. Say what? Yup. That’s right. In the LD we don’t look at the results for an important reason. You can have the most sales or revenue brought in or smash your goals, with the crummiest most duct-taped and “wing it” operational plan there is. AND those results (while INCREDIBLY important to track and assess) can subjectively change how you look at your operational strategy.

Today, let’s focus on Part I: The Launch Debrief Widgets
What you’re looking for, why, and how to go about rounding up the info.

We analyze at 3 aspects of the launch:
1. General Project Plan, including Pre-Live & LIVE strategy
2. Team, Support, and Resource Management
3. Tech

These are the most important areas to have a handle on. We are rounding up info you probably have within a few clicks, so get ready to print reports or have your journal out to make additional assessments. For my whacky brain, I print everything, label, and color coordinate between the areas as I debrief. I keep the printouts and notes together in a regular old school file and also keep a digital version in Evernote or Google Doc (which then ends up refining our launch plan in Asana or Trello).

As we gather you probably have a good idea of what these areas will glean for you, but just spend a couple hours gathering the info and we will analyze all the areas as a whole after!

General Project Plan, including Pre-Live & LIVE strategy

Dates and Calendar Assessment | starting at your very first task prepping for the launch through your ‘live’ date. Note, some of these dates may have crossover with other tasks. See #2 and #3.
Pre-live crossover work | note any team member, times or tasks that were working on either launch prepwork or regular tasks during pre-live portion of launch
Live crossover work | note any team member, times or tasks that were working on either prepwork or future tasks during LIVE portion of launch
Functional Areas and Sprint Assessments | focus on the following for launch: content, marketing, tech setup and management, planning, team management, and testing.

Team, Support, and Resource Management

Team Coordination, Pre-Live | list dates, members present, and general topics of team calls and Slack checkins completed during Pre-live stage
Team Coordination, Live | list dates, members present, and general topics of team calls and Slack checkins completed during Live stage
Deadlines Assessment | list any missed or rescheduled deadlines and by whom
Repurpose Assessment | list any content, tech, or workflows repurposed to fit this launch
Team Management Assessment | gather hours logged, tasks delegated (if separate from your own assignments) during Pre-Live and Live stages

Tech

Tech Launch List | list all the tech used (email marketing, spreadsheets, project management, software, website platforms, revenue tech, etc)
Tech Mishap Assessment | list any problems (broken, workarounds, issues) with any of those listed in #1
Tech Help | list any video walkthroughs or documented workflows specific to tech used in this launch

As I am diving into this debrief, I also ask my clients to simply form a google doc or we do this during a separate debrief call, where they download and bullet out all the good/bad/ugly from the launch. It helps merge our perspectives, normally we see the same thing and just analyze it differently.

These 3 main areas with 12 points of analysis are what I gather for each LD, we will dive into the analysis in Part II. Also remember, there are many things you know right off the bat could be better, so it’s important you get it all out of your head and start listing out refinement points in a systematic way.

Why I like to round up the reports is because it helps remove my personal bias or subjectivity as I look at the black/white reports or notes. The data, calendar, and reports also give me actual evidence to support (or not) my gut instincts during the launch.