Pick your best platform roadmap with the Mould Spore Chart

How we created a tool to visualise all potential roadmaps for our platform

Photo by Landsil on Unsplash

I had an experience recently that put me out of my comfort zone. I think this is common for product people, but somehow knowing that didn’t make it any easier. I discovered my product is a platform product, and it changed everything.

Good product theory tells you to focus on the user. To really understand their problems, and the desires and behaviours shaping those problems. Only after you’ve understood the problem do you start developing a solution (because everyone knows if you start with a solution you subject yourself to the evils of anchoring and confirmation bias).

But what happens when your users are other product teams, and their users have such a diverse array of potential problems that you couldn’t possibly give each problem the attention it deserves? How do you develop a set of APIs that deliver general value but solve specific problems as well? How do you balance long-term platform health with short-term customer value? What happens when all the tools you use no longer apply?

When we started this journey, we didn’t know what we didn’t know. But eventually, we managed to construct a tool that visualises all the possible roadmaps that could help us reach our Objectives and Key Results (OKRs). With this tool — which I’ve affectionately called the Mould Spore Chart* — we can see how long or complex a roadmap might be, and trade this off against the value it delivers (as measured by the impact on key results).

Seeing this in one place has helped us take a step back and see the forest for the trees, avoiding the short-term trap you can find yourself in if you’re a bit too Agile.

*It’s called a Mould Spore Chart because it looks like a network of mould spores spreading over a petri dish. Kinda gross, but I like it!

Hungry devs and an empty backlog

In what may be a familiar situation, we began with no validated opportunities and a team of three very talented developers itching to code. We had no idea what we were going to build, but we did know we had this highly strategic way of bringing value to almost every single product team in the business, and that we were going to deliver this value through APIs.

As a recent product owner, this was my worst nightmare: devs hungry for work and not enough refined tickets in the backlog to sustain them. I knew feeding them with poorly thought through opportunities just to keep them busy was a terrible idea. Sure, you might get lucky and customers might love your thing. But chances are you won’t, and that awful feature will live on as tech debt that slows the team down until you’re mature enough to admit you made a mistake and sunset it.

So, I thought, I should start with the customer! But that uncovered a new harrowing thought — who are our customers? We were building an API that exposed broadly useful functionality to any internal product teams that could benefit from its value. Each product team had their own customers, their own complex domain knowledge, and likely their own full-sized opportunity tree describing their problem and solution space.

My gut told me that we should get stuck in and deeply understand all of the domains, co-imagine with them the transformative impact our service could have on their product area, and talk to their customers with the new vision in mind. Only then, with these new opportunities, could we construct our own opportunity tree. But the task was daunting. There is barely enough time in the day for a product manager to master a single domain, let alone a few dozen.

And even if we went down this path, where would we start? We needed to decide whether we were going after short-term value or platform growth. We needed a platform strategy, and we needed it fast.

Starting with a platform strategy

We knew we could deliver ridiculous value on a large, self-fuelling platform. But we couldn’t get there unless we delivered short-term value to real customers while our platform was small. We codified this dilemma into a set of OKRs: one for the connectedness of our platform, another for the depth of our platform, and a third to track the short-term customer value we would deliver along the way.

What I really liked about these OKRs is that they gave the team direction without defining any initiatives. True outcome-based development fit for an autonomous team. This told the team that yes, we should deliver customer value, but not all customer value is equal to us. Let’s keep our eyes on the prize and follow opportunities that fundamentally take us closer towards our platform strategy.

In time, we would use our key results to directly and transparently prioritise every initiative we considered for further discovery. To make this really work, we needed to make sure our key results were realistic, measured true value to real customers, and were directly within the control of the product team.

Getting the ball rolling on discovery

Now that we had an initial strategy in place, we could start discovery proper. To begin, we sat down as a cross-functional team and brainstormed all of the things (yes, solutions) that we could think of to get us closer to our long-term OKRs. This gave the team an opportunity to share their brilliant ideas, so we had a complete snapshot of the whole team’s knowledge in this domain.

In my experience, most people think in solutions — solution ideation democratises the product process without placing too much emphasis on any single idea. It’s a great opportunity to engage stakeholders like go-to-market or customer experience teams too, as long as you’re transparent about the fact that this is just input to the process, and you’ll let them know how ideas will be prioritised.

We then used gut-feel estimates of OKR impact and effort/complexity to decide on the ‘best’ opportunity to start targeted discovery. Our targeted discovery process itself is pretty big — big enough for its own blog — but it involves two of my favourite things: Jeff Patton’s Learning Canvas* and Melissa Perri’s Product Kata. As we discovered more about the problems and solutions, we continuously adapted our snapshot with our new collective knowledge.

While we were kicking off discovery, we put the devs to work setting up the platform properly. This included giving some love to our non-functional requirements like CI/CD pipelines, authentication, OpenAPI specs and auto-generating SDKs. Stuff we knew we wanted to do and would set us up really well for the future, but didn’t require us knowing what we wanted to build.

We also started to drill down on customer opportunities, opting for a three-pronged approach:

1. Talking with other product managers and their designers to imagine and articulate the problems they faced that we could solve
2. Conducting a review of latent opportunities for our platform in past research studies across the business
3. Imagining experiences uniquely enabled by our API, and conducting generative and concept tests with end users, to identify opportunities that cut across the domains of many product teams

These three tasks gave our designer (yes, you totally need a designer in an API team!) enough work to occupy an entire team for a year. But the three-pronged approach meant that learnings came back at different cadences and drip-fed into our team’s collective understanding, as we navigated our massive problem and solution space.

*The Learning Canvas doesn’t seem to exist on the internet. Weird, since it’s so awesome! If you don’t want to follow a random Dropbox link, go to Jeff’s website, then click the link to his Dropbox > Quick Reference Guides > Learning Canvas.pptx

Creating a root structure for our opportunity tree

While we were sifting through the hundreds of solutions we could build that might advance our OKRs, we realised that many of them had common pieces of functionality. Sometimes this common functionality relied on other bits of common functionality being built first. It made it really hard to decide where we should focus our discovery, because everything seemed so interdependent.

We decided to map out these dependencies to help us decide what to build first. It took a long time, but once we did, we had a clear picture of all the work we could do across all of our OKRs, linked by their dependencies in a surprisingly simple dependency tree.

I love the idea of the ‘roots’ in the product tree prioritisation system. In the product tree, they are a very visual way to highlight areas of technical debt where core features of the product were ‘not supported’ by appropriate technical foundations. The concept of ‘roots’ seemed like a perfect analogy for the platform we were trying to build.

So we fashioned the platform dependency tree into a root structure for our opportunity tree (although in this case, the roots start in the ground and reach upwards to meet the leaves of an upside-down tree, which has its trunk in the air). This new pseudo-tree showed us every path from our platform to our OKRs. It was beautiful.

You can see an example root structure below for an imaginary social network. Disclaimer: I’ve never worked on a social network so the examples are illustrative nonsense.

How to create your own Mould Spore Chart

This was fine, but which path do you take on the dependency tree? We needed a way to visualise the priority. Enter the Mould Spore Chart. The Mould Spore Chart is a fairly standard value vs effort chart with ‘impact on key result’ on the Y axis, and ‘complexity’ on the X axis.

To make your own Mould Spore Chart:

1. Take every high-quality solution idea your team can come up with and roughly estimate its impact on your key results
2. Arrange the ideas in clusters which together are unlocked by a particular piece of platform functionality, as in the ‘roots’ of your opportunity tree
3. Place each cluster on a value/effort chart
   - The impact you assign is the sum of the impacts of all ideas in the cluster. Part of this is explicitly deciding the relative importance of your key results
   - The complexity you assign is the rough T-shirt-size of effort to build that piece of platform functionality
4. Finally, draw arrows between the clusters for each of the dependencies (from the opportunity tree’s roots) onto the Mould Spore Chart

You can see high-value platform functionality at the top, surrounded by your most impactful ideas. Then you can visualise the path your platform has to take to get to it. This will allow you to trade off executing a set of medium-value ‘quick wins’ against a bit of a slog through some lower-value pieces of work (but with a pot of gold at the end).

For example, in the above, do you try to hit the highest value item with the following, longer roadmap:

1. Create / get user
2. Search users
3. Connect users

Or do you instead take a shorter-term view and go for a low-effort path with this roadmap:

1. Create / get user
2. Create / get post
3. Like post

In any case, you know you’ve gotta build ‘create/get user’ first, so your team can deliver that initiative while you’re all shuffling the priorities of the next initiatives through targeted discovery.

Having everything laid out on the chart gives your devs a bit of a heads-up about the future when it comes to making architectural decisions. It also keeps you laser focused on ways you can deliver on your long-term strategy, while at the same time thinking about the short-term value you deliver along the way. We love it.

Key takeaways from our journey

I’m really proud of how willing our team was to engage in discovery. My lingering hunch is that if you want developers to buy into your process, that process must allow for their ideas to materially influence the roadmap. Objective rather than gut-feel prioritisation based on OKRs helps too, so people can not only contribute to decisions but understand how decisions are made.

Roadmap-making is harder and slower, but I think the quality of the roadmap you end up picking is higher. Plus, a higher level of engagement is better for team health, and the nuanced understanding your developers cultivate leads to better engineering decisions, both at a micro and macro level.

Here are some other key takeaways that I discovered during this process:

• Managing a platform product requires a deeper level of planning and analysis
• A systematic process of solution ideation and filtering helps you get buy-in and identify possible pathways through the opportunity space
• Design is key in platform teams to make sure APIs serve the end user
• Transparent prioritisation based on OKRs helps build an engaged, autonomous team
• Visualising the value and effort of platform functionality and their dependencies helps clarify a complex domain and allows you to make more strategic decisions on initiatives

Thanks for reading about this stage of my product journey. As always, I’d love to hear any feedback you might have, and keen to hear how you might have approached this challenge!