Product · TeamSystem · Platform · B2B SaaS
I'm Product Owner for shared platform capabilities used by several products — around company identity, product access and consumption. The interesting part isn't how the platform works inside: it's that every decision has to work for more than one product team at the same time.
At TeamSystem I'm Product Owner for shared platform capabilities used by several products. Instead of one product with its own users, I look after common services that other products rely on.
They cover two areas: company identity — one shared, consistent view of the companies our products work with — and product access and consumption, which is about what a customer can use and how that use is accounted for.
Each product could solve these things on its own. The point of a platform is that they don't have to.
When a capability is shared, a decision never belongs to one team.
The same choice has to work for products with different needs, different customers and different plans. It has to keep things consistent across all of them, and at the same time leave each product enough room to keep evolving at its own pace.
That tension — consistency for everyone, freedom for each — is the real product problem here, and it's what makes the work interesting.
I sit between the product areas that use these capabilities, engineering and the business side. Concretely:
A platform product is different because its users are often other product teams rather than end customers. That changes how the usual product work is done:
A platform team's roadmap is the intersection of other people's roadmaps.
01
When should something become a shared capability, and when should it stay specific to one product? Almost anything can be generalised — the useful question is whether a second product would really need the same thing, for the same reason.
02
Not every request has the same urgency or impact. A small piece of work that unblocks another team can matter more than a bigger one nobody is waiting on.
03
Some decisions have long-term consequences, because other teams build on them. Others can stay open until there's more information. Telling the two apart is a skill I'm still working on.
This is current work, so there's no neat ending — and most of the detail is internal, so this page describes the shape of the role rather than the results.
What I can say is that it's teaching me that Product Management is not only about deciding what to build. Sometimes it is about creating the conditions that allow other products to move faster and make better decisions.