Goodbye features, hello goals
23 January 2019 |
Dan Griffiths | About a 4 minute read
Goal-based roadmaps are widely regarded as a best practice. So why aren’t more product teams doing it? Dan Griffiths suggests a few reasons why and provides some practical ideas of where to start.
What is a goal-based way of working?
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.
But what does this look like in practice?
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.
What are the benefits?
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.
Why isn’t everyone working this way?
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.
So how do you change to work this way?
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.Read More From This Author
AND Digital Places 23rd In eConsultancy’s Top 100 Digital Agencies Report
AND Digital’s Flagship Learning Conference Returns For Its Third Year
Waterfall Vs Agile: Which Methodology Is Right For Your Organisation?
React Native Engineer (London)
Champion software quality and technical vision for AND and our clients, work on large-scale projects and help junior and mid developers grow in their roles.
Technologies you will be using
Tech Lead (Reading)
Bring your expert tech knowledge to the table to influence the direction of projects, whilst coaching and your team through engineering best practices.I'm Interested
DevOps Lead (Reading)
Bring your delivery expertise to the table, leading the pack as ambassador on operational requirements, influencing and continuous development.I'm Interested