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:
- Internal meeting of the product team
- Technical meeting of the development team
- Alignment meeting with an external product owner
- Formal meeting with the client
- Initial workshop with subject matter experts
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.
Table of contents
Why should you do an initiative kickoff?
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:
Kickoff as an icebreaker
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 as an alignment meeting
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.
Learn more →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.
Kickoff as a starting point
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 preparation
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.
Subscribe to our product management newsletter
Get articles like this to your inbox
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:
- Go through all known documentation and resources
- List questions, doubts, and assumptions
- Meet key people before the meeting
Go through all known documentation and resources
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.
List questions, doubts, and assumptions
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 key people before the meeting
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.
Kickoff meeting agenda
During the kickoff, you should make sure you:
- Have an icebreaker
- Align understanding
- Define constraints
- Discuss risks
- Plan baseline processes and communication
- Plan the next steps
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.
Have an icebreaker
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.
Align understanding
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:
- What exactly do you want to achieve? What’s the end vision?
- Why do you want to achieve that?
- For whom do you do that? Which user persona/client?
- What are the criteria for success? How will you measure it?
- How was the idea born? In what context do you operate?
Define constraints
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:
Scope
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.
Time
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:
- Some dream dates set by the C-suite
- Time-limited market opportunity
- Regulatory or contract-related obligation
Budget
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.
Discuss risks
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.
Plan baseline processes and communication
A kickoff is an opportunity to set some cooperation basics. Some questions to answer here include:
- What framework do you plan to use to deliver the initiative?
- When do you want to meet for planning, refinements, and reviews?
- What communication channels do you plan to use?
- How do you intend to manage plans, roadmap, and budget?
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.
Plan the next steps
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:
- Update the initiative documentation
- Prepare for the refinement tomorrow
- Use the refinement outcome to make the first sprint planning the next day is good enough
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.
Wrap up
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 generates product insights that lead to meaningful action
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 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.
