How To Get Started Using Goal-Based Roadmaps
Goal-based roadmaps are widely regarded as best practice. So why aren’t more product teams doing it? Here I suggest a few reasons why and provides some practical ideas about where to start.
Goal-based working means you challenge your product teams with a clear goal, then give them time and resources to identify and deliver solutions to achieve it. It’s the opposite of a scope based approach where your team commit (usually months in advance) to a list of features in a roadmap, including dates.
An eCommerce product team might be set a goal to improve their site’s conversion rate - the percentage of visitors who become paying customers. The product team would study the problem and, through a discovery process, work out what changes or new features might help achieve that goal. Examples might include extending the payment methods you support; offering a money-off voucher scheme or reducing the personal data required to successfully checkout.
Firstly, it helps focus the team on an outcome. Over-focus on features and it’s easy to lose sight of the goal that feature is intended to achieve. The feature itself is a means to an end: shipping features is rarely the goal.
Good product people are problem solvers. Unfortunately, that can lead to rushing to a solution: they don’t spend sufficient time understanding the problem and exploring a diversity of possible solutions before narrowing down.
Finally, working towards a goal is empowering. As a team, you feel challenged and trusted. There’s a sense of mission and responsibility to deliver the right solution. It’s so much more motivating than being told what to deliver.
Many organisations are accustomed to approving projects, signing-off on the scope and awarding funding in return for delivering... stuff. Shifting an organisational mindset towards outcomes is hard if established governance and ways of working are set around approval of scope and features.
Goal-based working can feel risky to a business stakeholder. Agreeing outcomes and then stepping back and trusting the team to deliver them can feel uncomfortable for stakeholders or managers who are used to adding value by reviewing and specifying solutions.
The challenge may be within the team. Team members themselves may lack the skills, experience or necessary support to work this way - or feel they do. Goal-based working is empowering but without the confidence to deliver on a tough goal, it can feel scary.
Accept that you won’t flip all your work to being goal-based overnight. Instead, think of this way of working as the thin-end of an expanding wedge. Identify and agree a small but meaningful goal with the team or stakeholder group. Quantify that goal, at least in terms of what poor, average and great performance might look like.
Invest in understanding the problem. Push yourself and the team to really pick it apart. Generate multiple hypotheses, then think in terms of experiments: doing just enough to prove (or disprove) the idea. Running this discovery process effectively is a skill and there are many blogs and books on the topic: Teresa Torres’ work is a good starting point, as is the design sprint methodology pioneered by Google Ventures.
Done right, your roadmaps shift from describing solutions to describing challenges. Your work is visibly aligned to business goals. The team feels motivated. Stakeholders are happy. Things are getting shipped but they’re viewed as tools to achieve a goal, not goals in themselves.
Remember, you won’t perfect this new way of working overnight. Build, test and learn. Study your metrics. Iterate on your solutions. Work out how to refine and improve what you’ve done. Throw away the stuff that doesn’t work. Then use those metrics and learnings to help illustrate the benefits of goal-based working to the wider business. Accumulate some success, then start to embed it more widely.
To speak to AND Digital’s experts in product management, get in touch via [email protected].
Agile Vs Waterfall