Software and Product teams often get stuck in a feature factory where they constantly build new things and churn out features, without really knowing if those features are adding value to the customer and achieving their product or business goals.
Businesses often fail to differentiate between roadmaps and release plans. Release plans list all planned features and the dates they will be built and released. The features are typically shown on a timeline, named as a roadmap, and shared with customers. The problem here is that customers and clients often take these timelines as commitments and promises, which means there is external pressure to deliver on that list, even if the features turn out to be un-important. Essentially, they can force teams to deliver feature after feature even if the strategy, user needs, or behaviour has changed.
Release plans fail to explain why things are being built, why things have been prioritised, and what the end result or outcome should be. A roadmap should communicate the strategic direction of the product, including goals, outcomes, and how to add value to the user. You need to stop thinking features and start thinking problems.
Most companies only really have a release plan, not a roadmap. So, whilst there is a plan for when to release features that teams can aim for, the true impact of those features is rarely measured.
So, what is the way forward?
Ask yourself what success looks like to your business. Consider how you want your users to feel and what you want them to be able to do. Over a given time period, the team should commit to one particular outcome. This outcome must be measurable and should be something that is valuable to the customer and the business. It needs to be specific and relevant. An example could be “users should be able to register in half the time.”
All goals require a number of steps and milestones to achieve them, but those individual steps aren’t objectives in themselves. This outcome may be reliant on a number of features and will encourage the whole team to take ownership over the outcome and the steps needed to get there. The team will know the outcome has been accomplished when the registration time is halved, not just when something specific is released.
Additionally, this approach prevents products becoming heavy with features that users don’t want. Instead, the goal is to add value to the user, and this can be accomplished by improving and building upon existing features or addressing problems in a non-technical way.
As Bruce McCarthy, Founder of Product Culture, states “a good roadmap is a strategic communications tool, a statement of intent and direction, and, done well, a way of rallying the whole organization around the key problems that must be solved to achieve your product vision.”
Building your Outcome Driven Product Roadmap
Your vision is the overarching goal you are aiming for, and the strategy is the plan to bring that vision into reality. The objectives are clear, measurable goals which align with outcomes you are striving to achieve for your users, product, and business.
When creating your vision and strategy you should consider things such as market and technological trends, competitive intelligence, the company’s business model, unique differentiators, data insights, (prospects, colleagues, customers), and what you want to achieve in the near-, mid-, and long-term. Once all of this has been considered and crafted into the vision and strategy you need to set your objectives. The objectives should be specific, but also high level.
Use insights from users, prospective users, and colleagues, market segments, capacity planning, and date-based milestones such as industry events, to prioritise the products and features you will include on your roadmap. It’s very likely that you’ll be managing huge amounts of data and ideas from different parts of the business but sitting down and prioritising the urgent and important things is fundamental to a clear, well-structured plan.
Finding a product prioritisation framework that works for your business can be really helpful in organising all of your insights and tasks.
Create a working draft of your roadmap which includes a timeline, solutions, and strategic context, which when combined deliver an informative and easy-to-understand plan of what you are releasing, when they are being released, and why they are being released at that time.
Internally you need to communicate the roadmap clearly in order to empower and excite everyone so that they rally around the projects, and to keep up the momentum, you should be touching base regularly, either with email updates or catch-up calls. Everyone involved in the product lifecycle should be provided with a copy of the up-to-date roadmap and should always be notified when changes are made.
Stakeholders should also have access to the product roadmap, but what is different here is that it can be really useful to tailor product roadmaps to each stakeholder so that they really illustrate relevant values.
Moving towards an outcome-based approach to roadmapping allows teams to focus on end results instead of specific deliverables. It also encourages a shift in mindset, so that team members stop believing that feature delivery is more important than outcome delivery.
Essentially by shifting towards an outcome-based product roadmap, you usually end up delivering a more valuable product to the user, rather than a product that is laden with too many features which aren’t needed.
I’m keen to hear from you about the approach you take to product strategy. Get in touch to discuss this further!
For support accessing exclusive top tech Product talent for your business, get in touch via email@example.com.