handbook: First iteration of product roadmap

[knolleary]

A first iteration at a product roadmap that looks over the next 3 years.

As expected with that sort of time duration, the detail gets less granular over time.

There's more to be done around scheduling all of the Yr1 work - but at this point, I need feedback.

In support of the roadmap, it also updates two other docs:

• Adds a 5th problem statement to the top level strategy doc. We had nothing in there that spoke to our govern pillar being a customer problem
• Updates the swimlane doc to list a more comprehensive list of swimlanes.

[netlify]

✅ Deploy Preview for flowforge-website ready!

Name	Link
🔨 Latest commit	c51061c
🔍 Latest deploy log	https://app.netlify.com/projects/flowforge-website/deploys/6a9149d302dce10008cdc22d
😎 Deploy Preview	https://deploy-preview-5659--flowforge-website.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 64 (🟢 up 12 from production) Accessibility: 96 (no change from production) Best Practices: 100 (no change from production) SEO: 85 (no change from production) PWA: - View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[ZJvandeWeg]

This seems to counter the "Industrial Application" narrative?

[knolleary]

What about:

FlowFuse provides the application platform for Industrial Applications. Applications that can access data from any machine or asset within the organization; applications that can provide meaningful visualizations where they are needed; applications that are infused with AI to bring greater insight and value. FlowFuse becomes the natural language interface to the whole industrial organization: MCP tooling, standardized data models, and custom skills combining so that anything FlowFuse can connect to can be asked a question.

[ZJvandeWeg]

9 lanes is too many, especially if you're against the KPI's per swimlane. Now it's hard to assess progress and great performance, or underperformance are both going to be hard to observe.

[knolleary]

I have been thinking about the lanes as a way to classify and organise the work so we can get a sense of whether we're covering all of the surface areas of the product. I wasn't framing it about each having a specific measurable deliverable, but I can understand the want of having more measurable outcomes against something.

Previously we had just three lanes - AI, Edge/Data, Platform Core (aka Everything Else). I didn't feel comfortable with the lack of granularity on the core side - it just became a catch-all bucket that equally didn't feel measurable.

I'm not sure where the right balance is.

[allthedoll]

The key distinction is that the lanes are a taxonomy of the product surface, not nine simultaneous priorities. They give us a consistent way to classify the work and see whether we’re covering the product appropriately (so we don't forget things as much as so we're noticing where we spend focused time).

For me, in product, the granularity matters here. To @knolleary's point, with the previous three lanes, core did turn into a junk drawer/catch-all for everything that wasn’t the other two things. Obv not effective. That also made it much harder to understand coverage because even though we had "lanes", they were essentially.... That made it harder to reason about coverage because fundamentally different areas of the product were being grouped together (we didn't have a place to put extra batteries, so they went into the junk drawer).

This should be three levels:

• Lanes = product taxonomy / coverage
  • The dimensions of the product we want to be able to identify and reason about independently
• Release focus = capacity allocation
  • We shouldn’t expect meaningful delivery in every lane every release ofc, any given release might heavily invest in 2–3 lanes, lightly touch others, and do nothing in the rest. That’s intentional prioritisation (from the intentional prioritisation region of France)
• KPIs = outcomes for the current focus
  • Every lane doesn’t need its own KPI every release. KPIs should measure the outcomes we’re trying to achieve in the lanes we’re actively prioritising (also from the intentional prioritisation region of France)

So nine lanes don’t make performance harder to assess. Nine simultaneous priorities would (these are NOT from the intentional prioritisation region of france). So again, the lanes give us the taxonomy to make the prioritisation explicit (no junk drawers / catch-alls): these are the areas we’re investing in, these are the areas we’re maintaining, and these aren’t getting capacity right now (intentionally 🍷).

For me, this preserves the visibility we’re missing from the three-lane model without creating an expectation that every lane has to produce measurable progress in every release.