How commercetools Roadmaps

How commercetools Roadmaps

A company’s roadmap is a reflection of its values constrained by its capabilities. For software vendors like commercetools, our quarterly roadmap is perhaps the most important document we have within the company. Roadmaps dictate what a bulk of the company’s people are working on at any given moment. Development, sales, marketing, professional services, and support are guided by our roadmap. 

Our guiding principles when defining the roadmap are:

• Focus on building a good product for our customers, our internal stakeholders and the larger market
• Stakeholders all feel as if their voices have been heard
• The process is transparent to all stakeholders
• There’s a broader understanding of the “why” behind the roadmap

Start With Why

Before we get too far, it’s important to go off on a quick tangent about the “why.” In Simon Sinek’s book, Start With Why, he outlines a simple but powerful concept called the “Golden Circle.” 

In this framework, Simon calls out the fundamental importance of starting with “Why.” At commercetools, we’re disrupting the enterprise commerce software market by fundamentally changing how commerce platforms are distributed, consumed, and customized. We start out every monthly all-hands meeting by reviewing the “why” behind what we do. All 150+ commercetools employees know why they show up to work motivated every morning. From the “why” follows from “how” — by leveraging APIs, microservices, and other cloud-native principles. The “what” follows from “how” — by offering a commerce platform that solves our customers business and technology needs through market-leading features.

We can articulate the “why” which is a prerequisite to successful roadmapping. Roadmapping without a common understanding of why your organization and product(s) exist is a waste of time. 

Set Annual Investment Priorities

Every year we have a two day off-site where define investment themes for the next year. Attendance is limited to our product owners, development managers, and a handful of C-level executives. The group size is kept small to facilitate trust and improve productivity. Big groups just don’t get much work done. 

We go off-site to minimize distractions and to facilitate trust amongst participants. Discussions can get intense and it’s important that everyone feel they’re able to contribute to the discussion from a trusted place. Having a small group that does some social activities together beforehand adheres the group and allows for better discussions.

Before the off-site, all participants are asked to contribute proposed investment themes for discussion. Investment themes are broad, often implemented over several quarters, often implemented using multiple teams, and not easily completed. Examples of investment themes at commercetools in 2017 included extensibility, developer experience and B2B. 

Investment themes come from many sources, including:

• What our current customers want
• What our prospective customers want
• What external thought leaders/analysts are talking about
• The collective experience of our staff
• Support inquiries
• Ideas from our own architects and developers
• Marketing
• What our external partners want — both SIs and ISVs
• Our own professional services

The investment themes for discussion are usually pretty self-evident to all participants. If you surveyed attendees of our last off-site, I bet everyone would have agreed on 75% of the investment themes before we started the meeting. 

The bulk of the off-site is then spent discussing the merits of investing in various themes. At our last off-site, we had 36 investment themes up for discussion. We ultimately decided on 11. Ideally, the number would be closer to six or eight. 

The decision whether to invest in a particular theme is not particularly scientific. Each of the investment themes are evaluated according to:

• Is it a market standard? Do our competitors all offer it? Do most of the RFPs we get list it as a feature?
• Is it something that will differentiate us? A product may tick all the checkboxes but if there’s nothing fundamentally differentiated nobody will buy it
• Is it non-functional but still required? For example, security, availability and performance are non-negotiables for us

These evaluation criteria ultimately get back to trying to quantify the business value. A lesson we’ve learned along the way is to avoid endless debates about trying to quantify value. The value of investing in a particular theme is inherently subjective and qualitative. Many things just have to be done and it’s clear to participants in the room based on their experience and what they’re seeing on a daily basis. If you’re building a car there’s no use in debating the business value of whether doors should be a standard feature. But there is use in debating whether satellite radio should be standard. 

If we were running a B2C SaaS business where we had millions of customers, it would be easier to quantify demand. But we’re a B2B product sold to large enterprises. We have far fewer and more varied customers. “I think customers X, Y and Z would use this feature” is hard to translate into a Net Promoter Score improvement or revenue gain. 

I listen to input from various stakeholders, review all quantifiable data, but ultimately I take a decision and move on. 

An ongoing topic of discussion we have is the time horizon for planning investment themes. While many would argue a year is too long of a time horizon to plan, we have ultimately settled on that time period because:

• Our customers need to know where to make investments. For example, a customer of ours needing B2B functionality shouldn’t invest in B2B if that’s an investment theme for us for the next year. Investment themes set quarterly don’t offer enough lead time to our customers
• Developers and other internal constituencies need stability. Developer productivity plummets when roadmaps are constantly changed. Marketing needs to know where to make investments. If we’re building a marketplace over the next year, marketing needs to plan events, campaigns, etc
• External stakeholders like analysts and prospective customers want to see we (roughly) know where we’re taking the product over a multi-quarter and often a multi-year time horizon. Strictly quarterly planning makes it look like we don’t know what we’re doing. “We’re agile” is not a solid defense against those (somewhat legitimate) claims

We may reduce the time horizon to nine months in the future, but for now a year seems to work for us. 

Define the Q1 Roadmap

Once we define our investment themes for the year, we then start to look at individual features. In contrast to investment themes, features are often implemented by one team over the course of a single quarter, and easily identifiable as being completed. Examples of features we’ve implemented include high precision pricing, a UI for processing exchanges, multi-factor authentication, sharding MongoDB, etc. 

We’ve found it’s best to gather all of the product owners together in a room within a few days of the off-site. We review the previously agreed-upon investment themes as a group to freshen memories. We then have the product owners take an hour and write out individual features related to their teams on individual post-it notes. There should be one feature per post-it note.

At the end of the hour, each person will have written down 25–50 different features. In total, we’ll have a few hundred individual post-it notes. 

Features come from the existing product backlogs, RFPs, input from support, input from professional services, and potentially dozens of other sources. Since we’re organized around vertical teams, our product owners know their respective domains extremely well. 

Then, using a big wall and some masking tape, we draw a grid similar to this:

Over the course of a few hours (and a case of Club Mate), we decide where to place each of the different features on the grid. 

We balance out the features according to:

• The capacity of each vertical team in each quarter
• Technical dependencies
• Alignment to investment themes
• Business value

This process is inherently a bit messy and subjective. We could use story points or some other metric to try to make the process a bit more quantitative, but we’ve found it’s best to just keep it more qualitative. Pragmatism is our guiding principle. It’s amazing how it all just “clicks” together by the end of the day. 

At this point, our Q1 is fairly clear. Q2 is a less clear, Q3 is even less, and Q4 is basically a guess. We’re OK with that. We want to avoid a waterfall-style roadmapping process where we have a year-long roadmap built out. That’s not agile enough. What matters is that we have a clear understanding of our investment themes for the year, a firm roadmap for the next quarter, and a rough list of individual features that need to be implemented over the course of the year. 

Q2 and Q3

Fast forward a few months and we’re now well into Q1 with Q2 just on the horizon. We’ve defined investment themes for the year and have a rough idea of what features are in each quarter. 

We then start building the Q2 roadmap by pulling the Q2 roadmap we defined at the beginning of Q1 off the shelf. Use that as the starting point, we adjust it for:

• Anything that wasn’t completed in the previous quarter
• Changes in team productivity
• Changes to investment themes or the priority of investment themes
• What we’re hearing from various internal and external stakeholders

We then send the roadmap to our head of professional services, head of support, head of marketing, head of partner training, a few architects, and a few developers for their input. Anyone else in the company is always free to review proposed roadmaps 1:1 with me or one of the product owners. 

We then repeat this process for Q3.

Q4

Q4 is the easiest quarterly roadmap to define because it’s mostly finishing up development from the previous year. We use this quarter to close off investment themes by implementing individual features that we haven’t had time to implement and servicing technical debt. It’s extremely important that we deliver on the commitments we’ve made so that we begin the next year’s product off-site with a clean slate. 

Voting

A few times we’ve held a blinded voting process for prioritization of features across quarters. In this exercise, we build a spreadsheet listing all of the features on the post-it notes, aligned to investment themes. For each feature, we list out the planned quarter, effort, who’s asking for it, associated Jira issues, and any relevant links. We provide as much data as possible so that voters can make an informed vote. 

We then send the spreadsheet individually to stakeholders across the company and ask them to vote. Each person should votes on his or her own, without seeing the votes of their colleagues in order to prevent undue influence. Then, we combine all of the votes into a single master spreadsheet.

Then we assign different weights to different voters (a company is not a democracy) and tally up the results. For example, we assign more weight to our CEO’s votes. 

We never build our roadmap solely off of a voting exercise like this, but we do use it as valuable input. 

Mid-quarter Roadmap Changes

Once a roadmap is set for the quarter, it’s considered “locked.” Development teams can’t execute on a roadmap that is constantly changing. 

The only exceptions we have for changing the roadmap are:

• If a high value customer has written it into their contract that we must deliver a feature in the current quarter
• If not doing something could cause security, availability or severe performance issues
• If the development team runs into serious issues

Short of those three considerations, we do not change our roadmap. We usually end up making one mid-quarter change every two quarters or so, but it really depends. It’s not a common occurrence by any means. 

I as Chief Product Officer am the only person in the company with permission to edit the roadmap. 

Measuring Development Progress

At the end of every quarter, we look back at the previous quarter and look at what we were able to deliver. We aim for 75% or more. Often we’re in the 80%+ range. When you include a four week delay, we’re usually in the 90%+ completion range for a quarter. 

Reporting these metrics to the entire company is extremely important. It motivates everybody to do better and it holds teams accountable.

We do not tie these metrics to pay or any other financial incentives because people would just commit to less until they’re able to always get 100% roadmap completion. Reporting these numbers to the rest of the company does create a small incentive to under-commit but there ultimately has to be some accountability. 

Measuring Investment Theme Progress

In addition to reporting development progress, we also report progress towards top-level investment themes at every monthly all-hands meeting and to external stakeholders when appropriate. This score card quickly gives internal and external stakeholders a view of how much progress we’re making towards the investment themes we’ve committed to for the year.

Red means we’re not going to complete the investment theme by the end of the quarter. Yellow means we’re making progress. Green means we will have successfully completed it. Remember that the time horizon here is an entire year. While earlier is better, each investment theme should progress from red to yellow to green over the course of the year.

Reporting to External Stakeholders

Every quarter we host an external call to update our customers and partners on what the next quarter’s roadmap looks like, how it aligns to our investment themes for the year, and how we’re making progress towards meeting our investment themes. 

These quarterly updates are important to all stakeholders. Our customers are running their businesses on us and it’s important that they understand where we’re taking the product. 

Conclusion

Hopefully you now have a solid understanding of how we roadmap. This is not a terribly scientific process and it’s always evolving as we learn. We approach it with flexibility and pragmatism and it has served us well.