If You Only Hold One Meeting Before You Start Building a Feature, Make It This One
A feature kickoff meeting is a time for the team to gather round the proverbial campfire and discuss what it is you’re about to build, why you’re building it, and how it will work. Once successfully adjourned, your team should be familiar with the new feature be and ready to get to work.
There are some potential pitfalls to look out for with kickoff meetings.
First, a poorly run meeting is going to be a waste of everyone’s time (as with most meetings).
Second, if you don’t have the meeting at all, then be prepared for a lot of back and forth and wasted time between the product, engineering , support teams.
Another challenge is that you may not always get total consensus in a feature kickoff meeting. Maybe some people don’t like the feature or disagree with how it’s being built. That’s your job as a PM is to try to build some kind of consensus around the product (and probably a bit out of scope for this article ;-) ).
A great kickoff meeting gets everyone ready to do their job
A good kick-off gets buy in, builds up excitement, and promotes why this new feature is so important.
It also helps get everyone on the same page and prevents a lot of the “but I didn’t know about that” that can sometimes happen if engineering & product start building in isolation.
Running the Meeting
Who to invite
You’re going to want to invite yourself (the product manager). You’re going to want to make sure your designer is there if you have one and/or your UI/UX person. You’ll definitely want to make sure an engineer is there and if possible, their engineering manager.
You’re going to also want to make sure you invite your product marketer so that they know what’s coming down the pipeline and how they’re going to market it once it’s released.
And don’t forget your customer support representative. They need to know how to plan and prepare for how to support users using this new feature.
There may be some more personalities you’ll need to invite that depend on how your particular team operates, but these are the core members.
When to have it
So you have all the right people in the room. When do you have it?
Well, you’re going to want to make sure it happens after you’ve put this feature on the roadmap and you know that this is something for sure that you want to build. Who wants to go to a feature kickoff meeting for something that’s never going to be built?! Not us!
You’ll also want to have it when the development phase is able to start soon. That way this feature and the conversation is fresh on everyone’s mind.
You also want to only have it after you’ve thought about this feature a bit.
No going cold turkey into this meeting! It is not a place for brainstorming and spitballing. You really want to make sure that you have a really clear idea of why it is that you need to build this thing. A rough spec is a good idea right now.
You also want to make sure that you’re having it before you actually put it in the backlog. Here we’re using the term backlog as a “real” backlog in the agile definition of the term - not in the proverbial backlog that’s actually better described as a black hole of potential features and ideas that most of us admittedly “manage”.
In summary, have it somewhere in the sweet spot of after you’ve thought it through a bit, before it goes into the backlog and before it actually begins work. You’ll probably be able to feel it out based on how your team feels and what your current workload is at the moment.
What to talk about
Now, what do you talk about in a feature kickoff meeting? Well, you’re going to run through that rough spec you’ve already put together.
You’re going to want to talk about
- what it is that you’re building
- why you’re building it
- who you’re building it for
- how you think it may work
- the user journey
- who is responsible for what
- dependencies, risks, and possible issues
Make sure everyone understands how the user is going to use this feature, when they’re going to use it and how you see them getting value out of it.
Once you run through the rough spec, the next thing to do is to get some feedback. See if your teammates have a different approach or even a better way of solving your user’s problems. This is also a great time to address any concerns about the feature.
And then once everyone knows what they’re building, why they’re building it, has had any of their feedback or questions addressed it’s time to get to work. All right.
We talked about…
- the challenges of feature kickoff meetings
- what can go well when you have a good feature kickoff meeting
- who to invite to feature kickoff meeting
- when to have it
- what to discuss
In the meantime, I hope you have a great feature kickoff meeting.