For June’s ProductTank London, Simon Cast (@simoncast) brought us experts on the topic of product roadmapping, prioritisation and portfolio management:
Michelle You (@wreckingball37), Co-founder and Chief Product Officer of Songkick
Janna Bastow (@simplybastow), Co-founder of ProdPad, and of Mind The Product
Lee Wilkinson (@ProdDev_LeeW), Director of Product at Hearst Magazine
Prioritisation
Co-founder and CPO of Songkick Michelle You (@wreckingball37) took the stage first to describe how her teams prioritised their work. She opened by talking about how the method of prioritisation will differ depending on what mode you’re in.
You could be improving specific aspects of an existing product, or perhaps working towards a “big bang” feature release for a certain date, or still be early in the process of discovery, when you know nothing as yet about who your customer is nor have even a minimum viable product. For this talk, Michelle focused on the first case: product optimisation.
The trick to prioritisation is to break down big, hairy goals (the key performance indicators, or KPIs) into smaller, well-defined and more easily achieved sub-goals. You then group these into themes and measure them with their own metrics. These themes could correspond to Dave McClure’s famous pirate metrics (acquisition, activation, retention, etc.) or aspects of the product such as the sign-up process or search. You then figure out which levers to use to move the metrics as desired.
Songkick thinks this way about the difference between KPIs and metrics:
Losing a certain amount of weight over six months might be the long-term goal – the KPI – but you can only practically measure this on a monthly basis.
Metrics might include the calories consumed and the amount of exercise taken, and you can measure these every day to see how you’re doing.
Drawing heavily on Alistair Croll and Benjamin Yoskovitz’s book, Lean Analytics, Michelle described metrics as being:
Comparative – you can use the metric to compare different sets of users, or before and after
Understandable – because you want the team thinking about it all the time
Ideally a ratio or conversion rate to provide context
Actionable – can you do something in response now, rather than in a month’s time?
Before jumping straight into building features, Michelle’s cross-functional teams collaborate to generate and prioritise ideas that might help the product to achieve its KPI, using Gamestorming techniques such as impact (on the KPI) versus effort. This also gives the team a shared ownership and understanding of the space of ideas.
Each idea is then turned into a Trello card, assigned to a theme, and converted into a hypothesis to verify, for example:
If we show you recommended concerts based on your taste, then you’ll be more likely to buy a ticket, because you’ll see more relevant events.
They then run each hypothesis through quick, cheap tests ranging from A/B testing, to usability tests, to real-time click tracking in order to gather the feedback. While they’re running these tests, they measure their velocity and quantity of hypotheses tested to make sure they’re moving as quick as possible.
If something didn’t work, what did they learn from their test? It’s these learnings that are used to create new product features for the backlog – often many learnings for a single feature. It’s all about removing uncertainty, so that their time is spent building worthwhile things.
But there’s always other stuff to do, the “product hygiene” of fixing bugs, addressing technical debt and fighting the odd fire, so they manage it in a separate backlog to their metric-moving features, and devote 20 to 30 percent of their time in each sprint towards it.
The product manager, design and tech leads meet once a week to review the different backlogs and prioritise the work for next two weeks onto the main development board, the single board the rest of the team can see. They also review a daily metrics dashboard with the team every morning and report back to the company on the KPI each week.
Lastly they review the impact of individual features to inform their instincts for future tests about what’s a feasible and realistic amount by which metrics can be moved.
Parting Thoughts
Use the right prioritisation technique for your product’s current stage.
Break down big hairy goals (the KPI) into smaller, simpler and more specific sub-goals.
Group goals into themes relating to aspects of your product.
Identify metrics you can measure easily each day to check how you’re doing against the KPI.
Run quick, cheap tests on the hypotheses you believe will move your metrics, and learn from the tests.
Don’t neglect product hygiene – devote 20 to 30 percent of your development effort to it.
The Product Manager’s Guide to the Roadmap
Next up we had our very own Janna Bastow (@simplybastow), co-founder both of ProdPad and Mind The Product, to take us on a grand journey through the universe of product roadmapping.
A roadmap, Janna began, is an artefact that communicates the direction your product is going to take to fulfil the product vision. The vision is the key part, however. If you don’t know where you’re trying to get to, then you’ll never get there.
If you’ve not thought through your product vision, start there. Janna offered a way to articulate it:
WHAT:
Our product is the only …
HOW:
that … (does something)
WHO:
for … (people)
WHERE:
in …
WHY:
which … (solves their problem)
WHEN:
in an era of … (market opportunity, competition)
After defining your product vision, Janna went on, get the Board to sign it off, then align your product direction to it.
The next step might be to prune your product tree. Much like Michelle’s impact versus effort game, you would also collaborate with your cross-functional team to gather ideas and map their relationship to each other.
Your team would write down feature ideas on Post-It notes, then stick them onto the tree in different places:
the trunk for the core product (what you have in place today;
branches for different streams of work or new markets; and
the roots for the infrastructure needed to support the rest of the product.
In contrast with the product tree, which shows how products extend in different directions, a roadmap tries to put a product into a single stream. Roadmaps can take many visual forms, but there are essentials each must include.
Time horizons (over what period of time are we planning)
Scope (things nearer in time are better known)
Strategic initiatives (for the users, architecture, entering a new market etc.)
Product areas/components (which bits of the product will be affected)
One or many products (need a view of the all the product lines)
ProdPad‘s roadmap has all these elements, but omits specific dates. The problem is that, no matter how big a caveat you give that things in the future may change, people always take dates on roadmaps as the gospel truth and hold you to them.
Predictable dates are only possible when you have known resource, a very specific idea of what you’re going to do, and you’re not going to change direction along the way, as when building a skyscraper. However, by its nature, building software is less predicable and to an extent involves learning as you go, so flexibility in the roadmap is required to react to changes. Taking dates out of the roadmap shifts the conversation “when do we get there?” to “are we going in the right direction?”
A roadmap is therefore a very different artefact to a release plan and so the two should be kept separate. A roadmap will typically be looking at between the next nine months to five years, whereas a release plan is looking two to three sprints ahead (four to six weeks). You should be reasonably certain about what will be delivered in the next few sprints, so you can share this information to allow other departments to make the own plans accordingly.
If however your Board or senior managers still want to see dates, try to keep some flexibility by giving dates as broadly as possible, say to the nearest month or quarter, then reduce granularity as things get further out. If the dates are inflexible, then you’ll have to make your execs understand that they’ll have to compromise on feature scope to keep to time should delays occur.
Janna went on to consider the question of who should see your roadmap.
Different people will require different levels of detail and will find different aspects of your roadmap more relevant than others. There’s also the consideration of what to share internally and publicly. It’s healthy to share a public version of the roadmap with customers as this can be a great way to gather feedback, however you may need to keep certain details relating to your product’s “special sauce” that you may wish to keep private.
Janna mentioned that people are often concerned that competitors will copy their roadmap, but competitors are generally too busy to copy your stuff – you’re not Apple and reliant on hyped marketing reveals to launch your products after all. However, you can always mitigate this risk by being more general on detail in your public roadmaps.
Parting Thoughts
Define and agree your product vision with the Board before creating a product roadmap.
Ensure your roadmap covers the essentials, but avoid using specific dates to retain flexibility.
Keep your short-term release plan separate from your longer-term roadmap.
Consider relevance and the level of detail to show in your roadmap to different audiences.
Managing a Product Portfolio
Lee Wilkinson (@ProdDev_LeeW), director of product at Hearst Magazine rounded out the evening by talking about how to manage a complex portfolio of products and brands.
He opened by describing how product is at the heart of Hearst and that understanding their audience was critical in order to change the business from print to a multi-platform entertainment company. Product was the lens through which they could change the focus of the business.
Lee sees products as systems of interconnecting interactions and capabilities. For example, content is commissioned, journalists create it in a content management system (CMS), then that content is taken and rendered on multiple devices. User experience people interact with the rendered content, designers apply the brand to it, customer services need to work with it if it’s paid-for content, and store customer details in a customer relationship management (CRM) system, and so on. All these interactions form the product as a whole, but evolve at different rates.
In the case of the Times’s iPad app, it was created and rolled out so quickly that large parts of the organisation – including customer services – had not used or even seen it yet, and so needed to catch up.
As a framework for looking at products, Lee looks at features by corporate function, supply chain that makes the product happen. He then considers priorities over a broad timeline and asks how each product feature will affect different areas of the business. At one point, the only way Hearst’s iPad customers could communicate with them was via star ratings in the App Store. Hearst also wanted to be able to communicate back to their consumers, and this affected multiple parts of the organisation: marketing, customer services and editorial.
But how do you manage 22 brands, 88 products, 440 capabilities? It’s not practical to hire 22 or 88 product managers, so a different approach is needed.
So Lee first considered what was Hearst’s fundamental product, across all its different brands. The essential needs they fulfilled were to entertain consumers through content, and to connect advertisers with that audience of consumers. With that foundation, they could start to group common features together by corporate capability, and define audience segments and the sets of advertisers and customers that align to these segments (e.g. luxury, entertainment, lifestyle, health & well-being), then to classify them by business objective (more efficient infrastructure, managing churn, driving growth etc.).
With this structure, they then look at investment versus return. They use a Product Board ( a internal council of senior managers) to review and decide on product teams’ investment proposals and new product ideas. It reviews what the new feature will do, when it needs to happen, who it’s for, its return on investment (ROI) versus time versus resource (cost), what’s the goal (churn reduction, customer acquisition etc.) – even the passion of the people requesting the feature. The Product Board also reviews all existing products’ performance to determine whether to continue investing or to pull the plug.
But it’s not just about ROI – balance across the portfolio is also needed. Looking at the business as a whole, there’s always a particular objective in mind, whether it’s improving efficiency, stimulating growth, winding a business line down, or moving into a new market. Product initiatives need to align with the current business priorities, so this becomes another way of classifying product activities.
Lastly, it’s crucial to be able to communicate a roadmap effectively – people won’t buy in if they don’t understand it. Product teams must have the ability to articulate their roadmap and why it’s important, and to relate it to people in the right way. This could mean top-level detail in a slide deck all the way down to a detailed Kanban development board.
Parting Thoughts
Whatever you do, the roadmap’s got to be understandable.
Know your core product – cut through the blizzard of features and brands in your portfolio to the heart of what you do as a company.
Consider the investment versus return of roadmap items – understand the time, money and resource involved.
Balance the portfolio – understand where you are as a business. Too much maintenance when in growth can be bad, as can letting tech debt get out of control.
Communicate clearly to enable understanding and decision-making – have a communications plan and ensure the entire team can articulate the product strategy.
Thanks
We’re immensely grateful to Sky for sponsoring June’s ProductTank on roadmapping, prioritisation and portfolio management.
Do join us for our next ProductTank London at 6.30pm on Friday 25th July (note change from usual Wednesday slot) on product management case studies from change management. Tickets are available now (join the waitlist if none are currently available).
Tickets are also selling fast for 2014’s Mind The Product Conference on 11th / 12th September. Get yours now!
You can also get in touch with us if you’re interested in speaking at or curating a ProductTank, writing for our blog on Mind The Product, or sponsoring our events. See you soon!
The post Product Roadmapping, Prioritisation and Portfolio Management appeared first on MindTheProduct.