APAC CIO Outlook
  • Home
  • CXO Insights
  • CIO Views
  • Vendors
  • News
  • Conferences
  • Whitepapers
  • Newsletter
  • About us
  • Awards
Apac
  • Agile

    AI Healthcare

    Artificial Intelligence

    Aviation

    Big Data

    Cloud

    Cyber Security

    Digital Infrastructure

    Digital Marketing

    Digital Transformation

    Digital Twin

    Drone

    Internet of Things

    Low Code No Code

    Networking

    Remote Work

    Startup

    Unified Communication

    Wireless

  • Bi and Analytics

    E-Commerce

    Education

    FinTech

    Healthcare

    Manufacturing

    Pharma and Life Science

    Retail

    Travel and Hospitality

  • Dell

    IBM

    Microsoft

    Salesforce

    SAP

  • Cognitive

    Compliance

    Contact Center

    Corporate Finance

    Data Center

    Data Integration

    Digital Asset Management

    Full Stack Development

    HR Technology

    IT Service Management

    Managed Services

    Procurement

    Proptech

    RegTech

Menu
    • Agile
    • IBM
    • Aviation
    • Data Center
    • Digital Infrastructure
    • Unified Communication
    • Retail
    • Salesforce
    • MORE
    #

    Apac CIO Outlook Weekly Brief

    ×

    Be first to read the latest tech news, Industry Leader's Insights, and CIO interviews of medium and large enterprises exclusively from Apac CIO Outlook

    Subscribe

    loading

    THANK YOU FOR SUBSCRIBING

    • Home
    • Agile
    Editor's Pick (1 - 4 of 8)
    left
    Agile Development in Large Companies

    Mario Magnanelli, Former CIO, Six Payment Services

    Optimized Networks for an Agile Workplace

    Steve Miller, CIO, Steelcase

    Cementing Position in the IT Driven World

    Mike Anderson, CIO, CROSSMARK

    Business Analysts: Delivering Client Strategy through Agile Consulting

    CEO

    The Unique Challenges of Being Agile In a Large Global Corporate

    Charles Thompson, Chief Information Officer, Vanguard Investments Australia

    Gaining Access to the Future with Machine Learning

    Hemal Shah, Executive Director, Product Delivery & Regional CIO APJ, DELL

    Harvest Innovation from Omni-Direction Technology Up Gradation

    Sanjeev Kumar, Chief Information Officer, ApON India

    Eight Years of Agile Journey in the Insurance Business in Indonesia

    David Bejar, Head of DevSecOps& Agile Practices,Allianz Indonesia

    right

    Product Roadmaps - In the Self-Driven Car Age

    Leandro Pinter, Head of Software Engineering, Tyro Payments

    Tweet
    content-image

    Leandro Pinter, Head of Software Engineering, Tyro Payments

    Where did Products Roadmaps come from?

    The first time the term Roadmap was used was back in 1890’s. At that time bicycles were the mains from of transportation between cities so in order to move from city to city people needed some sort of a map. The first Roadmap was then created to help people to move around New York.

    When using a Roadmap people always knew where they were (current location) and where they wanted to go (the destination). With a Roadmap in hands they could find different routes to get to their destination faster. “Product Roadmaps should work just like that, but they don’t”.

    It was in the 1980’s that organizations began using the term roadmap in the format we still see in use today. The roadmap was a tool used to align technology and product development efforts with the purpose to inform customers and stakeholders about releases of new products or enhancements of existing products.

    The main components of a Product Roadmap were and still are in most cases:

    • Deliverables – Features, Solutions, Hardware etc

    • Dates – normally months and quarters and in some cases very specific dates

    • Priorities – the order to which the deliverables would be released

    In essence, Product Roadmap became a tool to help organizations plan and communicate in advance, when they would be releasing new products or upgrades. It was also a way to ensure the team’s focus was on the highest business priorities and a way to track commitments.

    This model has worked well for about a decade when things started to change quite rapidly. The rise of the internet and the adoption of lean and agile practices along with the ever-increasing pace of change in technology have made the traditional roadmaps a cumbersome and inefficient tool in many, if not all circumstances. However, the way most companies still create Product Roadmaps haven’t changed.

    The annual cycle for Roadmap development started to clash with the rapid release cycle enabled by agile/lean development methods. (Figure 1)

    What is wrong with it?

    I have come up with a list of things that I believe to be the key problems with traditional product roadmaps:

    • Output focused

    • It implies certainty

    •Date seen as hard commitments

    • Misused as release plan

    • Tied to annual planning

    • It doesn’t embrace learning

    Most of the organizations are still developing roadmaps, focusing on the output they plan to deliver. Output takes the form of features, system implementation, activities planned; however, they are not in any way an indication of progress towards the company goals and vision

    Another key component of traditional product roadmaps is the dates. In my view, they are still one of the most misused components. Although they are not meant to demonstrate precision or hard commitment, they in most cases see just that.

    The fact that most Roadmaps are tied to companies’ annual planning cycle is also a fundamental problem. This assumes that companies know exactly everything they need to build in order to achieve its objectives and goals but this is in most cases not true. This premise has been proven wrong many times.

    Lastly, I would say the most important issue is how static roadmaps are. The fact they are built annually and rarely updated, reduce the chances of adapting and learning new things about the problems you are trying to solve, hence, its chances of success is reduced.

    All of this would not be a problem if we were living in the scientific management theory - Taylorism age (Frederick W. Taylor) where:

    • Senior Management of organizations knew what they need to build and how;

    • Measures of success were simply quantitative output such as efficiency - the more they produce, the better;

    • Management was responsible for measuring and improving the entire process;

    • The premise was that the workers knew and cared nothing about the organization, what it was doing or why.

    An alternative to traditional Product Roadmaps

    “A Product Roadmap describes how you intend to achieve your Product Vision”, is a definition from the book - Product Roadmaps Relaunched: How to Set Direction while Embracing Uncertainty.

    It focuses on the value you propose to deliver and is used to rally support and coordinate effort among stakeholders. It is more than a list of features with some dates.

    Vision, Goals and Themes

    Your company or product vision should always come first – is intended to be your high level, the ultimate view of where the company is going.

    Its primary purpose is to communicate this vision and inspire the teams and stakeholders to support and get behind it to make this vision a reality.

    Company or product vision should be more a long term view. If you are thinking somewhere around 3-5 years, you are probably in the right ballpark. They will normally set the leadership and the good ones are typically inspiring and ambitious.

    Next comes the goals. That should be the first business goal you have in order to achieve or get closer to your company vision. Here we have to start getting a bit more quantitative, and timeframe would be somewhere between 1-2 years. OKRs (Objectives and Key Results) are a great way of describing those types of goals with clear measurable outcomes.

    Finally, we have what I call themes. Themes are the key areas the teams decided to explore to achieve the Company Goals. This could be a specific customer problem, needs or jobs to be done.

    Two parts of the theme:

    Hypothesis/Problem Statement – it we solve this problem or prove this hypothesis we will be closer to achieving our company goals

    Outcomes – the key part of the roadmap – it describes quantitatively what we hope to achieve by solving this problem

    I find that a quarterly cadence works well for this level.

    Now - Next - Later

    Once you vision, goals and themes have been defined you can then start thinking about how you are going to communicate when things will be done.

    There are many ways to do this but my preferred option so far has been the “Now”, “Next” and “Later” format.

    At the same time this gives the information you need to align expectations with stakeholders and customers. It also leaves space for changes, particularly with things that are not yet started. I encourage the use of broader timeframe to avoid creating a false sense of certainty about dates at that stage.

    So when thinking about building a Roadmap for your organization I would recommend a few things:

    1. Always tie your product Roadmap to your company vision and goals

    2. Commit to outcomes rather than outputs

    3. Favor the use of broader timeframe over precise dates

    4. A product roadmap is not a project plan

    Weekly Brief

    loading
    Top 10 Agile Solution Companies - 2021
    ON THE DECK

    Agile 2021

    Top Vendors

    Agile 2020

    Top Vendors

    Agile 2019

    Top Vendors

    Agile 2018

    Top Vendors

    Agile 2017

    Top Vendors

    Agile 2016

    Top Vendors

    Previous Next

    I agree We use cookies on this website to enhance your user experience. By clicking any link on this page you are giving your consent for us to set cookies. More info

    Read Also

    ESG Performance - Why It's Crucial To Future Success

    ESG Performance - Why It's Crucial To Future Success

    Jo-Anne Ruhl, vice president and managing director, Workday Australia and New Zealand.
    Digital Acclerating Duke Energy's Transformation

    Digital Acclerating Duke Energy's Transformation

    Brian Savoy, Senior Vice President, Chief Transformation and Administrative Officer, Duke Energy Corporation
    Fear the cloud, or not, better yet don't fear...

    Fear the cloud, or not, better yet don't fear...

    Timothy Masey, VP, IT Infrastructure & Security Carhartt
    Beautifully Autistic - Enabled To Make A Difference What Did My Children Teach Me About Life, Business, And Innovation?

    Beautifully Autistic - Enabled To Make A Difference What Did My Children Teach Me About Life, Business, And Innovation?

    Ahmed Abukhater, CIO - Chief Innovation Office Boeing
    Enhancing POS Experience for Employee and Customer is the Key to Success

    Enhancing POS Experience for Employee and Customer is the Key to Success

    Christopher Davis, Chief Information Officer, the Tile Shop
    The Possibility of Scan-and-Go Pos Solutions

    The Possibility of Scan-and-Go Pos Solutions

    Rebecca Meyer, Director of it - Commerce Applications and Ecommerce, Kelly-Moore Paints
    Critical Elements of a Data Driven Product Organization in E-Commerce

    Critical Elements of a Data Driven Product Organization in E-Commerce

    Ankit Mangal, Director, Advanced Analytics and Insights, Wayfair
    The Intersection of Technology andTransportation: How an eCommerce Book Seller Became a Leader in Logistics

    The Intersection of Technology andTransportation: How an eCommerce Book Seller Became a Leader in Logistics

    Dave Bozeman, Vice President, Amazon Transportation Services
    Loading...

    Copyright © 2022 APAC CIOoutlook. All rights reserved. Registration on or use of this site constitutes acceptance of our Terms of Use and Privacy and Anti Spam Policy 

    |  Sitemap |  Subscribe

    follow on linkedinfollow on twitter follow on rss
    This content is copyright protected

    However, if you would like to share the information in this article, you may use the link below:

    https://agile.apacciooutlook.com/cxoinsights/product-roadmaps-in-the-selfdriven-car-age-nwid-5529.html