Initiative kickoff is a critical event in product development.
Do it well, and you’ll kickstart the whole process and increase the odds of succeeding. Do it poorly and, at the very best, you are off to a slow start.
There are many types of kickoffs. They are:
For the sake of this article, I’ll assume the most common type of a kickoff — one done with a product manager or a stakeholder/sponsor that’s external to the team.
I am a skeptic when it comes to meetings. Most product managers attend or organize too many of them when many of them are unnecessary.
But, initiative kickoff is not among them. The benefits of the meeting easily outweigh its costs.
A typical kickoff has three objectives:
If the whole team already knows each other and works together then that is great, but most teams don’t.
Different initiatives require different skills and expertise. Even if the majority of the team stays constant, a new stakeholder and a new subject matter expert are enough to change the team dynamics.
A kickoff meeting gives a formal opportunity for people to get to know each other, (re)define their work and communication style, and see how the new team setup performs together.
Kickoff is a great opportunity to get everyone on the same page.
You probably shared some documentation, business objectives, and proposed roadmap before the meeting. But, let’s be honest; most of the team either doesn’t read that or just skims through it briefly.
Even if they dig deeper into initiative details, they often have doubts, fill gaps with their assumptions, and might develop a perspective different from yours.
The kickoff meeting allows everyone to share their perspective, ask questions, and clarify all loose ends. Stakeholders can provide additional context and narrative, and everyone can clarify their doubts.
Everyone should be on the same page and clearly understand the “why” behind the initiative. Kickoff helps to do just that.
Starting is always the hardest. The backlog is empty, the scope isn’t refined, and the immediate next steps aren’t clear.
Kickoff helps to break through that.
One of the goals of the kickoff is to leave with a clearly defined list of next steps, which should lead to further next steps. It works as a spark that starts the fire.
Kickoff is often a meeting when people who don’t fully know each other come together to discuss an initiative they don’t fully understand.
To make sure it doesn’t turn into a disorganized, wasteful meeting, make sure to prepare. A 30-minute recap before the meeting is not enough.
There are a few areas you should focus on the most:
The whole team should try to get as much context as possible. It will allow them to ask better questions, participate in discussions, and understand various topics better. Without that, all you can do is a PPT explainer presentation, and that’s not a kickoff.
While going through all resources, you’ll probably have some doubts and questions. That is good; list them out, but don’t stop there. Spend some intentional time fishing for any gaps in your understanding or concept. The more you clarify on kickoff, the better.
Meet with the key stakeholders, your tech lead, and whoever takes a lead role in the initiative before the kickoff. Clarify the objectives of the meeting, and try to sort out any doubts they have. If you already have questions and doubts, share them with them. It’ll help them come better prepared for the meeting.
The better prepared you are, the more you’ll get out of the meeting.
During the kickoff, you should make sure you:
How much time to spend on each and whether the kickoff should last an hour or two days depends heavily on a specific context.
The more you prepare, the better you’ll know how much time to reserve for every section.
Make sure everyone in the room understands who is who. For new teams, I would even consider sticky notes with their roles or adding them as a nickname (e.g., “Bart – PM”). It helps put new knowledge in a better context.
When someone proposes an idea, flags a risk, or disagrees with someone, it’s easier to understand where they’re coming from or their way of thinking if you know what their role in this initiative is.
Also, accommodate some time for casual warm-up activities, such as Impromptu Networking. It’ll help people transition from other contexts, energize them, and help them get to know each other.
To have a fruitful discussion, you have to get everyone on the same page. Stay on a high level, though. It’s better to leave more detailed questions and discussions for later once everyone has the same final picture in mind.
The questions you should seek to answer include:
Now that you know the what, why, and how behind the initiative, let’s discuss the limitations. There are always some.
There are usually three types of limitations:
In an ideal scenario, a team should be able to define the initiative’s scope as they see fit to meet the expected outcome, but that is not always the case.
There might be a contract in place that makes some part of the scope fixed, or the security/privacy requirements might make some things not negotiable.
While having 100 percent of the scope fixed is an anti pattern leading to a feature factory, there’s rarely full flexibility too. Make sure you are all on the same page about what’s within the team’s capacity to define and what is non-negotiable.
Also, understand what would happen if you don’t deliver some part of the scope. It’ll help you manage risks better. Sometimes, not delivering a “must have” feature means a major client will join the service later. Sometimes, it makes the whole product not compliant with the law and renders it unusable. There’s a big difference in severity between these two.
How much time do you have to achieve the initial goal?
Try to understand when the initiative should be completed and, most importantly, why?
What would happen if you went over the timeline?
“Deadline” means an entirely different thing when talking about:
How flexible are you when it comes to resources?
Can you add new people if needed? Or outsource some part of the work?
Also, discuss the long-term maintenance costs. I know it’s hard to predict, but you need some baseline assumptions. The team will prioritize different solutions when they have to keep cloud costs below $500/month as opposed to when scalability is the top priority.
Now that you understand the big picture and constraints, it’s time to discuss risks. Some of them you probably spotted during the prep work, and some came from previous sections.
There are different ways to do risk prediction exercises. You could try a post-mortem, for example. Meaning that you imagine the initiative was a total failure and tried to list all the ways that contributed to that. It’s also a pretty fun exercise.
The goal is not to map all possible risks. Risk management is a continuous process. The objective is to identify the biggest ones that can break the whole initiative and should be monitored and tackled from day one.
A kickoff is an opportunity to set some cooperation basics. Some questions to answer here include:
Once again, the goal here is not to discover a perfect way of working. It takes months for a team to find out a system that works best for them.
The goal is to have enough basics in place to start.
You know your kickoff was great if people not only understand the initiative but also what they should do next.
It doesn’t have to be a very detailed or long-term plan. Next steps can be to, for example:
Keep in mind, it doesn’t have to be one meeting. It could be a series of smaller meetings.
You could align people in one meeting, then let them prepare to discuss risks and constraints in a second meeting, and then give them time to propose an action plan you’ll confirm on the third one.
If done well, a kickoff helps everyone be on the same page, understand the problem better, and kickstart their work in a good atmosphere.
It’s such a critical meeting that it deserves a lot of preparation from everyone. The effectiveness of the meeting depends on the quality of the preparation.
The goal of the kickoff is to break the ice, align everyone, discuss constraints, risks, processes, and expectations, and leave with clear next steps.
Don’t fret too much, though. Although some people treat kickoff as a super-formal, serious ceremony, it works best when held in a casual and friendly atmosphere. Think of it as just a bunch of colleagues chatting about a shared topic.
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.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Karen Letendre talks about how she helps her team advance in their careers via mentorship, upskilling programs, and more.
An IPT isn’t just another team; it’s a strategic approach that breaks down unnecessary communication blockades for open communication.