Boston Product Breakfast May 2017:
How to avoiding pigeonholing your roadmap with small, iterative changes
This month’s Boston Product Breakfast was hosted by Jake, Alex and the growing product management team at Klaviyo. Klaviyo (hint: it’s pronounced “CLAY-vee-oh”) makes powerful, data-driven tools to help ecommerce marketers target, personalize, measure and optimize their email and Facebook campaigns. We were excited to check out Klaviyo’s gorgeous new office space in a high-rise in the Financial District, and we had a lively discussion about the various tactics that we use, as product managers, to plan, discuss and communicate our Product Roadmaps. Here’s a summary of the main points of discussion for those that couldn’t make it!
Delivery v.s. Discovery Roadmaps
Adaora, a Senior PM at a FinTech startup, kicks off the discussion by sharing that she is not a big fan of traditional “delivery” roadmaps. Instead, she recommends using a discovery roadmap, focusing on the why over the what as much as possible. This sentiment is met with vigorous agreement from the other PMs in attendance, although we are curious about how to practically implement this model in the world of stakeholder and customer demands.
In the past, Adaora has used ProdPad for the discovery roadmap and Jira for the delivery roadmap. Ideas can be submitted into ProdPad either by employees or by customers directly. Once these ideas have been vetted and prioritised by a PM, they are then graduated into Jira.
Although there is some effort required by the PM to maintain the idea backlog, Adaora reports that this roadmap duality has worked very well. ProdPad, which integrates smoothly with Jira, acts as an innovation funnel, allowing ideas and suggestions to flow in from all parts of the company and giving stakeholders a place to voice their input. ProdPad allows you to visualise the effort v.s. value of each idea to help with prioritisation (other product managers recommend checking out receptive.io for similar functionality). The engineering team benefits from having Jira focused only on planned work and work in progress.
Roadmap Timespan and Release Cadence
It’s important that your roadmap doesn’t get stale too quickly. You should therefore take your release cadence into account while deciding the timeline to be covered by your roadmap. Too far out, and the roadmap is more of a hindrance than help as customer needs change.
The frequency at which new features are released varies a lot from one company to the next. Some engineering teams push their code live as soon as work is complete, while others cannot release as soon as a new feature is built and must instead wait to join the release train. While in general, larger companies have less frequent releases (due to coordination and overhead) and smaller companies are more flexible and therefore can release much more often, there are many other influencing factors.
At Imprivata (healthcare security), the on-prem nature of our software means that we have just four planned releases per year, to minimise disruption to our customers. A product manager at Pearson’s online learning division pointed out that they can only receive feedback from real users during the school year. Another PM described how their app is only useful during football season:
“When the season is over, you have nine full months without regular users and therefore, without releases.”
Stephen from Intrepid points out the value of aligning release cadence with the school year, and advocates for setting larger, annual goals, to control strategic direction. For these bigger goals, it’s important to have more tangible milestones. At Intrepid, a manager is named responsible for each goal. Each quarter, this manager is in charge of presenting to the full team, and maps specific deliveries back to how they help reach these goals. This helps the rest of the team to understand how their personal contributions impact the annual plan.
Iterating based on feedback, post-release
Jake had a very specific question for the group around when and how to revisit a newly-released feature: “We try to be iterative, use data, mitigate risks, adjust etc.—however, we also have sprints. We have these two weeks of work, and what ends up happening is that you have already scheduled the work for the upcoming sprint before the current one ends. How do you allow time for iteration? There are so many variables you can’t control—how long it’ll take users to react, how much feedback you’ll get, and how much effort it will take to make changes based on that feedback. How do you move that quickly enough to get into the dev cycle?”
How do you move your [customer development] quickly enough to get into the dev cycle?
One suggestion is to have a standard length of time between release and re-visiting the feature to analyze usage and implement changes based on real user feedback. Another PM suggests using “placeholder” stories in the following sprint so that there is time set aside for iteration. Of course, this assumes that you’ve validated the need for your feature in the first place. “What really is important is how much customer feedback you’ve got to confirm that you should deliver.”
Anthony from TripAdvisor points out that it boils down to how you prioritise initially. “We use weighted scoring — how much will the feature cost, how much revenue will it generate.” If there are follow-up stories, these are weighed against the rest of the backlog according to the same priorities.
There is one sentiment on product roadmapping that we all agree on — and that is:
Product Management is an art; not a science
When it comes to developing your roadmap — identify and make note of the needs of your various stakeholders, go from there and adjust accordingly.
