On why you probably don’t need to do a kickoff meeting.

I recently heard a podcast produced by a well known and respected hi-tech company about how to conduct a successful kickoff. Knowing my opinion about this topic – I decided to listen very carefully to this episode just to make sure I’m not missing anything when it comes to kickoffs.

So I listened very carefully… and… I must say that I couldn’t disagree more with what I’ve heard.

Look, if you are a hard fan of kickoffs then maybe this post is not for you. Or maybe on the contrary – you are open minded and would like to read it for the same reasons I listened to this podcast – to receive a different perspective on the topic.

You can already understand what’s my affinity towards the whole ‘kickoff’ concept. Yes… I’m not a fan.

And let me tell you why.

 

But first things first –

What is a kickoff meeting and what are its goals?

In the context of product management – a kickoff meeting is the first big meeting that takes place before starting to work on a feature or a project. The general goal of this meeting is to create alignment between all internal stakeholders as for what needs to be built and why.

At this stage – the product manager (hopefully) did a proper research as for the ‘why’ and can vaguely describe the ‘what’ as well. Hence, from the PM’s perspective the goals of the meetings are to:

• Declare the intent to work on this feature

1. Explain to all internal stakeholders why this feature should be work on and why now and get an alignment on that
2. Explain to all internal stakeholders what needs to be built (in general outline, the spec is most likely not ready at this stage) and get an alignment on that
3. Get validation and feedback from everyone about the why and the what.

Ok. That sounds useful. What’s wrong with that?

I will explain what’s wrong with that in a second. Before I do that I do want to emphasize something:

Kickoff meetings do make sense in some scenarios and configurations. I will detail those later down the post.

 

Now let’s get to what bothers me about this concept:

Most PMs I know have a dedicated group of developers and QA assigned to them. Most of the features the PM defines are executed by this group alone.

From time to time there are cross-teams features, but even for those – 80% will probably be performed by the developers assigned to you and the other teams will just be ‘closing the gaps’.

 

With this information in mind – let’s revisit the goals of this meeting:

A declaration of intent

You definitely need to do that. But what’s wrong with the quarterly planning you’re doing with your team? You have a list of candidates that you bring to the planning based on various signals received from the market. You go over the candidates with the biz team and dev team, prioritize it, estimate it, and see what can make it into the quarter. Eventually you have a plan for the quarter. (I’ve devoted this post to how to conduct quarterly planning in case you don’t understand what I’m talking about). Now, assuming you did such a planning – why each and every feature requires another introduction and a declaration of intent? I don’t get it.

 

Communicating the 3 W’ – the why, the what and the when

Again – very important. But this is 100% covered by the spec review which is performed right after writing the spec and before it’s handed over to the engineering. So – why do another similar meeting at the beginning of the process as well?

Again – I don’t get it.

Get validation and feedback

No doubt – very important.

But here the thing – only the market can provide you with validation on the ‘why’ and the ‘what’. You can get this feedback directly from your users and/or customers or indirectly from the biz team – sales, CS and support… OR from your data. Everything else – is just opinions. 

Why drag the engineering team, the UX/UI designers, the various managers and team leaders, the data analysts and so forth to a big meeting just to hear opinions?

Be efficient and be confident.

Be efficient – by entering into a ‘always listening’ mode. As noted above – the market sends you both direct and indirect signals all the time. If you are disciplined enough and you are properly documenting these signals – then you are always in a state of clarity as for what comes next and why it’s needed. For instance:

• Document all feature requests brought up during your meetings with your business colleagues (your weeklys or when they reach out to you directly to provide feedback). Document new requests and add ‘votes’ to existing feature requests.
• Stating the obvious – meet your customers and/or users on a regular basis. I assume you document these super important direct signals. Those are priceless.
• Constantly stay on top of the major KPIs and data points. Always measure the pulse of the business. Develop a daily 5 minutes routine to do so.

 

If you have a technical background and you know what ‘continuous integration’ means – then this is the mode I want you to be in. You should always have a ‘version’ (a plan) in your head as for what needs to be built next for the customer. You don’t need to start digging through backlogs when you are out of items to work on… because you already know how the next 4 months are going to look like.

Therefore, since you are constantly on top of the market signals – you can be confident as for the ‘why’. You don’t need to gather everyone inside a room and waste an hour of their time just to get opinions or facts that you already know. So be confident.

 

From time to time, though, you’ll be identifying a pain, but you won’t be sure your suggested feature is really addressing it. Even in such cases, instead of gathering everyone, I suggest crafting a ‘concept document’ – which includes only the ‘why’ and a vague outline of the what. Specifically I’m talking about a document that includes the overview, goals, success criteria and KPIs from the PRD/spec. You can find a template and a full spec in this series.

 

It’s practically writing the first half of the spec.

 

Once you have this ‘concept’ document – you are sending it only to the relevant business people and get their buy-in (or comments/feedback and correct from there).

 

From there – it’s easy to proceed to a full spec, without wasting everyone’s time.

 

So you see now why I don’t get this kickoff meeting concept. An ‘always listening’ mode + a spec review covers pretty much everything that is aimed to be achieved via a kickoff meeting.

 

Fine… but why are you making so much noise out of just one meeting?

Oh… don’t you start with me.

It’s not just ‘one meeting’. I’ve seen companies doing kickoffs for almost every feature they intend releasing.

If you read my post on how to manage your time more effectively (here) then you know I believe overflow of meetings is just a disease. You should avoid unnecessary meetings at almost all costs.

And to me – kickoffs definitely fall under the definition of an ‘unnecessary meeting’ which is wasting time for SO many people (with one disclaimer – see below).

When does a kickoff meeting make sense?

When it comes to cross-team’s effort, where each team is required to do a non-negligible part of the overall job – then a kickoff meeting suddenly makes sense.

Why? 

Because then two of the original goals are much easier to achieve by getting all the relevant people in the same room.

The first goal which is becoming much easier to achieve this way is the ‘declaration of intent’.

If you time the kickoff meeting BEFORE the quarterly planning of the teams which are not assigned to you – then this meeting can actually become the trigger for them to add this feature to their own quarterly planning (which is mostly out of your control otherwise). You are securing their efforts for the next quarter and get the alignment you need. An alternative scenario is that one or more of the teams will tell you that they have other priorities and it won’t fit within their planning. Disappointing as it may be – it’s still good to know, and you can ask them to secure the time in the following quarter if it makes sense.

 

The second goal that may be easier to achieve in such a constellation is feedback on the ‘what’. You can easily understand whether something is technically feasible on your side, by talking to the relevant team leader of the developers assigned to you directly.

However, when it comes to bigger projects – it’s very useful to get the engineering leaders of all relevant groups into the same room. They will spark the technical discussion in this kickoff meeting and all you need to do is to sit quietly, answer their questions and watch the discussion. At some point you’ll all either understand and agree on the outline of the ‘what’, or understand that there is a technical challenge here that warrants a separate, dedicated discussion. Good to know as well.

 

For these couple of reasons – I do recommend conducting kickoff meetings for large, cross-teams projects.

 

That wraps up the post for today.

If you found this post/series useful – feel free to ‘like’ it. If you think others can benefit from it – feel free to share it with them.

 

Thank you, and until next time 🙂