Product Roadmap: Control Chaos During Development

Great. Now you’ve decided what idea you want to focus on and why it’s important to your consumers.

Next challenge: how do you start building your product?

You start with a grand vision statement of redefining an industry and changing people’s lives. Then you get to the tough part of figuring out how exactly you do that. Multiple opinions surface – Let’s build front-end first. Let’s build a scalable backend. Let’s go mobile first. No, no, web first. Is this a 1.0 or a 2.0 feature? Hey, we need marketing demo stuff ready quickly. What? Requirements changed again?

Arrghh!

Chaos is inherent in startups. Any team will have a lot of conflicting ideas on what needs to be done. Managing all the inputs can be difficult.

Independent teams in larger organizations struggle with similar issues. They don’t have a VC to convince, but often need enough of a story to sell-in to senior management. As the core team keeps context switching between strategy and execution, there are often fresh debates on strategy, on whether something is ‘not right’ and a lot of muttering beneath the breath.

Some of the larger companies adopt a process of having a marketing requirements document followed by a product requirements document. This might

seem like a lot of process overhead for a startup. But I recommend at least having a good product roadmap in place.Why a product roadmap helps

It’s easy to scoff at a product roadmap, saying we’re such a small team – we don’t need it. But, having a clear document reduces much grief along the way.

A product roadmap is a priority order of features that your team will work on. It is a document that everyone can reference (and challenge!). It reduces

communication challenges and costly misunderstandings. It may feel like process overhead, but it more than compensates for the chaos you have to bear

otherwise.

A good product roadmap is also a great way to identify dependencies, so that you sequence your work for maximum impact. If your company vision is the ideal state for you to reach, look at the roadmap as the set of steps that will get you there.

I have worked with multi-site teams with different sub-teams building product components as well as smaller teams based in one site. The level of detailing differs in the product roadmap – multi-site multi-component teams require more detailed plans, as there are more pieces that fit together. In both situations, having a clear product roadmap and priority list helped everyone stay on track, and plan items like dependency charts, product features and analytics we wanted to capture.

Some benefits of a good product roadmap are:

• Clear dependency gathering in product planning process
• Realistic market priorities. If market needs change, you can recast or reprioritize your product roadmap with an idea of what changes cost in time and effort
• Help in capturing atomic work details that can be reprioritized with clear impact analysis
• Have enough detail for different teams to plan their work
• Factor in customization and localization needs, in case your product is international

How do you build a product roadmap?

Product roadmaps help bring clarity to the vision, as well as give details to execution teams.

Typically, you’ll end up creating different versions of the same priority roadmap, with different objectives

• A high level ‘strategic’ one for discussion/marketing purposes
• A detailed one for execution

Strategic roadmap

This version contains lesser details, but lays out the story better. It is an important means of communication when you present your idea to management

or for funding. This is also the document that execution teams can periodically check against to see if they are on the right track. A typical version consists of customer needs, landscaping to see what solutions exist, identifying why your product will be important, and a high level feature list of your product.

A high-level product roadmap for the case discussed earlier could be:

• Stock collection unit (no data required)
• Stock collation backend
• Alert system on specific triggers
• Training/help module

…and so on.

Detailed roadmap

This is your execution list. I recommend adopting, or adapting, the SCRUM methodology. SCRUM involves building iterative and agile product, with teams focusing on potentially shippable increments of work. The link gives more information on the SCRUM process. The concept of user story from the SCRUM process is a great way of building your roadmap or backlog.

At its root, a user story consists of a user’s perspective and an expected outcome.

Some examples of user stories are:

• As a salesperson, I would like to capture details of stock at a shop without requiring data access.
• As a sales manager, I would like to see consolidated reports for stock in my territory.
• As a category manager, I would like to get a daily alert on my stock position in my area.

I recommend using the same approach to capture other stakeholder feedback:

As a business analyst, I would like to see details of what product features are used the most.

• As a marketing manager of the project, I would like to have a demo with xxx features.
• Try and make the user story list as exhaustive as possible. User stories should map to elements of the high-level priority list.

As the next step, you would then detail out these user stories with what exactly needs to be done to implement a user story, and which teams would be involved. In this method, the entire product backlog is built not in terms of independent tasks for backend, web, etc. but in terms of what needs to be achieved for the consumer. A user story becomes a common means of different teams talking through a consumer problem to target, implement and test.

With a good backlog, you would also identify which stories need to be done earlier. For example, the alert system might be in use for alerting category

manager, shopkeeper, sales manager, etc. and so may need to be implemented before the others. This level of detail helps different teams estimate effort for implementation. This can than be consolidated to see when a product launch is technically feasible.

Some benefits of having everything captured in the roadmap are:

• If your timing estimates are off, you will still have product components that may be shippable, or the base for future development
• Each team knows what others are working on, and there is a cadence to development process
• Marketing features are not neglected. Marketing and BD can bring back feedback from the market space
• Items like demo, support requirements and analytics get factored in the development process
• If there are delays to the project, you can figure out impact and shelve features lower in priority

Point to note: the product roadmap is usually a living document, and there will be changes to the plans after you start implementation. This approach helps understand impact and plan changes better.

What has your experience with building product roadmaps been? Post your comments on the topic below or reach out to me on Twitter at @shrinathv.

Note: these are personal views of the author.