Product planning meetings are one of the most important meetings in a product’s lifecycle so we decided to take you inside a product planning meeting at Atlassian by filming the latest Portfolio for Jira planning meeting (filming the planning meeting of a planning tool seemed only fitting). These product planning meetings tend to happen quarterly and last about four hours (don’t worry – we time-lapsed it for you of course!).
We also interviewed the participants, Martin Suntinger, Principal Product Manager for Portfolio for Jira, and Hannes Obweger, Development Manager for Portfolio for Jira, to get the specifics on how they run their product planning meetings. So check out the time-lapse and the walk-through guide for having a successful planning meeting, and if you have any tips of your own, share them in the comments section.
The planning meeting, a time-lapse
The planning meeting, a guide
The start: homework, objective, agenda
While there are no formal objectives for the Portfolio for Jira planning meeting (nothing on paper at least), both Martin and Hannes are clear on what they want to leave the room with: “A realistic roadmap so we are on the same page of what we can ship and when we can ship it.” For them, this generally translates to two to three big milestones with a rough time frame to “deliver awesome software.” The agenda of the meeting is pretty straightforward: they both bring their backlog to the table and then open the current plan in Portfolio for Jira and get planning. Neither party leaves the room until a roadmap is agreed on.
The goal of a planning meeting is a realistic roadmap so the team is on the same page of what and when to ship.
To make sure the agenda stays on course, the product manager and development manager should have a rough idea of the scope they want to plan before coming to the meeting. Sometimes Martin may bring in some customer-facing information that Hannes hasn’t heard yet and this is the meeting where this new information is brought to the table. To put it into perspective, Martin receives up to five feedback and suggestion tickets each day from current users. Hannes adds technical or architectural challenges to be addressed and ideas for functional improvements that may have surfaced while building out the product. Coming prepared ensures that no time is wasted trying to brainstorm product direction or new ideas (this should be a different meeting altogether); the focus is on planning the next three to six months.
The middle: scoping, estimating, planning
The first step in the planning meeting is collecting, double-checking, and prioritizing the backlog, which is done entirely in Portfolio for Jira. The backlog is entered as initiatives (“big chunks of work” that span multiple epics) so Martin and Hannes can get a big picture view of all the things that need to be done in the next planning cycle. The meeting is entirely scope driven “based on these 15 high-level features in the backlog, we are going to focus on x, y, and z.”
As a development manager, it’s Hannes’ role to make realistic commitments on behalf of his team. The crux here is: how to get realistic estimates, particularly for work that might not have been broken down in detail and spec’d out. Currently, Hannes does most of the estimation himself, relying on experience, looking at similar efforts done in the past, considering roughly what a story or entire epic will involve.
Martin says that as a Product Manager, he isn’t in a position to come up with estimates, but he will question if a number seems high – Can we do parts of it? Can we do it in a different way? Some estimates are more like time budgets if details are unknown – how much time are we ready to put into this, and do we think we can build something of reasonable value within that time, deferring the actual details to when it comes to implementation.
Aimie: Any thoughts on what you could do to make estimations more realistic? Hannes: The more time we invest in breaking things down and discussing it upfront with the whole team, the more accurate estimates will get. However, time is valuable and should rather be spent on building stuff, so bringing the whole team to each planning meeting would be impractical. A feasible approach would be to bring in people for short time periods to answer specific questions that help with estimation. Martin: Another option might be to get the team to estimate one roadmap backlog item each sprint, so by the time a planning meeting rolls around, we have a backlog that is already estimated. The other aspect to this is: It's all about what you do with the outcomes - in some situations a +/-100% estimate is accurate enough to make a general go/no-go decision, in other cases we might need to align closely with a deadline, a planned launch or event, and every day counts. It comes down to being conscious about what you know and what is uncertain - we've fallen into this trap before when we roughly estimated, and then a few weeks later we started taking that rough value for granted and 100% accurate.
Once the rough scope and estimates are in place, they double-check the team capacity in Portfolio for Jira (it’s linked to the team’s Jira Software board) and if it’s all good, they press calculate. This gives them a first schedule based on all of the estimated scope in the backlog, combined with the team’s velocity (and usually an “oh sh*t” moment when they want to do everything but they’ll be doing everything for the next three years). This is when they get to defining releases: splitting up overall backlog into releases that make sense. Releases are driven entirely by the scope rather than a strict cut-off date, as it has to make sense as a package to give value to customers.
To get to an MVP, they work down the backlog list, answering questions like “is it a must have?” and “what do we need to make sure the internal dogfooding happens?” Once they have a few defined releases – think internal dogfooding, MVP, Beta, Launch – they calculate each of the end dates for each of these releases. The meeting ends when both Martin and Hannes have “sliced and diced every possible way and both are happy with the schedule.”
The end: shake hands and share the plan
Hopefully after a few hours and two to three roadmap milestones later, a product manager and development manager can leave a room with a good handle on the future of a product. Not only in theory, but also in a tangible way that can be shared with the development team.
One thing that Martin and Hannes stressed in their interviews was the importance of making the team aware of roadmap changes ASAP. To do so, after a planning meeting, Martin and Hannes share the roadmap with the team the next time the whole team is together (e.g. the next stand-up). In this meeting, they’ll give a short overview of the roadmap – super high level – and then the team goes away to look at the plan on their own. The development team will then talk about the plan in more detail at the next sprint planning meeting, where they’ll have a discussion and ask questions. Once everyone is aligned to the plan, they’ll execute on it.
It became clear through interviewing each stakeholder, Martin and Hannes, that different roles have different goals walking into a product planning meeting. The product manager is the voice of the customer and typically walks into the meeting full of ideas, features, and updates to help increase customer value. The development manager comes into the meeting prepared to run numbers and make sure that any commitments made on behalf of the development team are realistic. Despite these differences, these meetings are key to keep a product, its roadmap, and releases on track.
Happy planning! 🙂