How we manage the roadmap

In a previous blog post, we explained how we manage releases in Fluid Topics but it didn’t tell you much about how we decide what we put in these releases, how we make tradeoffs in the roadmap, and who makes the choices.

This is certainly the most strategic, interesting and yet frustrating exercise for a software vendor.

• It’s strategic because it shapes the product, defines our positioning, and enables (or hinders) go-to-market options.
• It’s interesting because it forces us to examine, sort, and articulate all the demands coming from the different stakeholders, whether internal or external (our clients, partners, prospects).
• It’s frustrating because, as Gide said, “to choose is to renounce”. We would dream of being able to develop all the requested improvements and new features right away, without having to postpone any. But our resources are limited, and we have to make choices. Not to mention some technical dependencies (feature A requires feature B to be implemented before).

Interestingly, each internal stakeholder —customer support, professional services, R&D, sales, product manager— represents a force driving the development of Fluid Topics, hence of the company, in one specific direction, and finding the right balance between these forces should propel us with optimized efficiency.

So how do we choose?

Because we develop Fluid Topics for you, we had to find a way for defining the short-term roadmap (3 to 5 months) that is applicable and explainable. We have opted for a game coming from agile methodology called “Buy a Feature”. Here is how it works. As said, we have 4 groups in the company representing different sets of stakeholders with different needs and expectations:

• The Support team represents existing customers and their demands for improvements (the so called “feature requests”).
• The Professional Services team represents the new customers and the on-going projects, focusing on features that are needed for the go-live.
• The Sales team dreams of functions that would ease the sales process, increase the ROI and unlock market segments.
• The Product team defends the long-term vision and the major innovations that nobody has (yet) asked for.

Before each session (2 to 3 times a year), each team proposes the list of features that it wants to be done in the next 4 to 6 months. The complexity of each feature is evaluated by the dev team so that it has a cost. As you can imagine the total workload of the 4 combined lists represents at least 3 times the capacity that we have.

Here starts the game

The teams gather and each is given the same amount of money. But the total sum of money distributed is far less than the sum of all the features, and slightly less the total number of development days available in the next 6 months (roughly 80%). With that money each team will buy features. Because a team doesn’t even have enough money to buy all its own proposed features (maybe 25% of them) it will have to negotiate and to join forces with other teams to buy features. It’s a very interesting moment and certainly one of the biggest benefit of the game because each team explains the value that a feature brings, thereby sharing its concerns and perspective. This helps aligning the vision and creates transparency and engagement.

Once the final list if settled, it is ordered according to technical, organizational and commercial constraints. We are then able to update the roadmap and to communicate it to our customers. We know some of them may be frustrated not seeing their request or suggestion scheduled, but since it’s impossible to satisfy everyone, at least we know that we have a method that is balanced, explainable and transparent.

So don’t hesitate to reach out to us to feed the roadmap and to help us develop and refine our vision. We cannot guarantee that every request will be done immediately, but we can promise that we will always listen and make our best to provide you with the best dynamic content delivery solution on the market.