As the top-priority objectives become clear you can assign them to teams and consider what might be tackled in parallel (or by the same team sequentially in time). Typically, teams focus on one product objective at a time. Of course, what can get accomplished in any time period depends on team capacity. Multi-team planning & dependency tracking When we decide which objectives to tackle next, we plan backwards from these time-based milestones and consider what would be most important to accomplish by then.
(Note: We still recommend only making such commitments with extreme caution.) That’s where planning objectives on a timeline roadmap is useful.
There are Gartner analyst briefings to consider, industry conferences, multi-pronged marketing launches, and the occasional commitment to a strategic partner or major customer. Often, time becomes a key input in these decisions. Now-next-later roadmaps provide a basic overview of your priorities, helping stakeholder understand at the highest level what’s coming when.īut for larger organizations and those working in more complex environments, there comes a time when product leaders must plan at a higher-level - prioritizing not which features to build, but which objectives they should tackle. This is how many smaller organizations begin using roadmaps in Productboard, and to great effect! They provide the right level of granularity when communicating the plan to stakeholders and provide plenty of room for the team to adapt the plan as they go. Or they’ve planned discrete releases loosely associated with time that only extend a short way into the future (January release, February release, March release, Short term, Long term). These teams have often adopted a now-next-later approach to roadmapping, using high-level buckets to communicate what gets worked on when with an emphasis on the near-term. After all, they run empowered product teams, not feature factories ! They’re striving to bring about real-world outcomes and will happily continue iterating rather than ship the wrong thing on-time. When given the option, many modern product teams have cast off dates entirely. Let’s explore each of these scenarios, starting with the more detailed planning permitted by date-based timeline roadmaps. You can even abstract the specific dates on your timeline roadmaps to make them suitable for sharing with all your stakeholders! Later we’ll take a look at how Productboard’s time horizons functionality can help you do just that. And in the short run, they provide a more detailed view of what’s getting delivered when, which helps for coordinating launches and preparing customer-facing teams for product updates. They can help you see exactly what teams are working on, and identify cross-team dependencies early to avoid costly delays. That comes with a steep cost: early convergence on a poorly-researched, non-optimal solution that won’t adequately address any real user need or business objective.Īnd yet, date-based roadmaps are entirely useful for modern Agile product teams! They help your product team carry out internal planning toward upcoming date-based milestones. Even when features are shipped on time, it may only be due to the premium placed on timely shipping. No one should be surprised, then, when date-based roadmaps lead to broken promises and false expectations - disappointed customers, lost deals, and distrusting colleagues who have been burned by the product team more times than they can count. Arbitrary, because not only are teams unclear on what form these forthcoming solutions will take, they often haven’t even uncovered the real user need they should be solving. At their worst, they are arbitrary mappings of the feature backlog onto a timeline, with no basis in any reliable estimation of effort. All too often, they’re treated as public commitments to ship future capabilities by unrealistic dates. Date-based or “timeline” product roadmapping has become a boogieman for modern product teams, and for good reason.
0 kommentar(er)
