Understanding What Software Product Roadmaps Should Look Like

Product roadmaps for software solutions document show where you want to go. So it's essential to design them correctly

by Rod Dunne on February 18, 2011

in Biz Dev, Entrepreneurial, Innovation

Defining a product roadmap has some additional steps in comparison to more tangible products. In this article I’ll show you what the basic process is in creating software roadmaps and where the changes can occur.

The goal of a product roadmap is to clarify which features and product lines the company should be working on over the next 12 to 18 months. These features are aligned with growth & innovation strategy plans and specific market research which has identified key customer segments or markets that the company should be pursuing.

With this definition in mind (and the needs/activities it implies), the standard process for creating a software product roadmap is:

  1. Collaborate with your CTO, architectural board, engineering leads, QA leads, customer support and marketing team to define as many ideas as possible for new product features and new product lines.
  2. The Product Manager should collate these ideas and try to categorize them based on specific markets. It s possible to use commercial product roadmap software to compile this list, but it is often easier to simply use a spreadsheet instead.
  3. The Product Manager then researches each of these markets to establish how easy it would be to enter this market (i.e. level of competition) as well as the market potential (volume of customers, potential ROI, etc.). This research should finish up by identifying some highly desirable market sectors.
  4. Review the short list of desirable market sectors with your executive board. The company’s own business growth strategies will have a bearing on which markets are going to be pursued. Gain consensus on which sectors to focus on (usually one or two).
  5. The Product Manager then works with the CTO to define product lines or components consisting of the ideas identified for specific markets. The CTO should also be considering what architectural decisions can be made to facilitate using product components in a wider range of product lines. In a software product roadmap this would be referred to as componentization, foundational components or frameworks.
  6. The Product Manager then writes up the software product roadmap detailing (i) timelines, (ii) the initial product lines for the next 18 months, (iii) long-term product lines and (iv) any additional information to justify product line decisions such as market research/ROI.
  7. Distribute this document for review to internal stakeholders. This will need to go through many drafts before an initial version is established.

It is important to also note that the software product roadmap will iteratively change over time quite rapidly as new marketing opportunities arise, innovation strategy plans change and the competitive market alters. When writing a basic product roadmap plan, always make sure to keep archives of older versions.

This is standard practice and the Product Manager should always make sure that updates to the document are communicated to all interested parties promptly.

Author Rod Dunne...

Blog owner and sole writer Rod DunneI am the owner and sole writer on Product-ivity.com. This is my personal blog detailing troubleshooting tips for small businesses. Posts are based upon 2 decades in consultancy & innovation management within startups/maturing companies.

Get Email Updates (it’s Free)

Comments on this entry are closed.