> Platform teams are engineering-led rather than product-led. There is almost never a product manager handing you a roadmap, no revenue line to follow, and no market to lose.
It's precisely because of this framing and mentality that platform teams don't actually serve people well and are usually highly dysfunctional towers of people inventing work.
The fix for having no market is to act like the teams you serve could leave. This whole article lists signals, and none of them is that. Being captive does not mean the users or internal teams don't have other options and don't notice. Being product-led means caring about your users. A platform teams should be product-led, not engineering-led in that very narrow meaning. Otherwise you invent work as this article so wonderfully exposes.
>It's precisely because of this framing and mentality that platform teams don't actually serve people well and are usually highly dysfunctional towers of people inventing work.
Spot on, I've worked in multiple small, medium and large companies. And these internal platforms almost always turn into ivory towers of useless churn.
Even if being forced to use it internally, in a lot of cases the projects ended up buying the same solution (or a working version of it) from an outside vendor when it came to fulfill actual customers needs on the outside.
If that wasn't possible we built what we needed ourselves.
If you have internal customers, I still believe you need internal incentive alignment. Otherwise what the platform builds and what is actually used and needed drift apart.
And you need at least one real customer project to dogfood the platform initially. Because most platforms start out way too generic with pure architecture astronauts [0] at the helm.
If you don't have a project-0 to test those assumptions against, you don't need to start that platform.
> And you need at least one real customer project to dogfood the platform initially. Because most platforms start out way too generic with pure architecture astronauts [0] at the helm.
The Rule of Three in Refactoring applies to this scale, too. If you are building a "platform" for one customer project, that's a one-off and quite possibly YAGNI. If you are building a "platform" for two customer projects, that's likely coincidence and still possibly doesn't show company-wide need. If you can build for at least three customer projects, that is a pattern, that provides real guidance on exactly how generic things need to be and better ideas how to abstract it.
Yeah, 1 is always better than 0, just that reminder that real "product focus" happens when you have multiple customers, not just doing one-offs for one or two customers.
dabedee · · focus · HN ↗
It's precisely because of this framing and mentality that platform teams don't actually serve people well and are usually highly dysfunctional towers of people inventing work.
The fix for having no market is to act like the teams you serve could leave. This whole article lists signals, and none of them is that. Being captive does not mean the users or internal teams don't have other options and don't notice. Being product-led means caring about your users. A platform teams should be product-led, not engineering-led in that very narrow meaning. Otherwise you invent work as this article so wonderfully exposes.
carlmr · · focus · HN ↗
Spot on, I've worked in multiple small, medium and large companies. And these internal platforms almost always turn into ivory towers of useless churn.
Even if being forced to use it internally, in a lot of cases the projects ended up buying the same solution (or a working version of it) from an outside vendor when it came to fulfill actual customers needs on the outside.
If that wasn't possible we built what we needed ourselves.
If you have internal customers, I still believe you need internal incentive alignment. Otherwise what the platform builds and what is actually used and needed drift apart.
And you need at least one real customer project to dogfood the platform initially. Because most platforms start out way too generic with pure architecture astronauts [0] at the helm.
If you don't have a project-0 to test those assumptions against, you don't need to start that platform.
[0] <a href="https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/" rel="nofollow">https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
WorldMaker · · focus · HN ↗
The Rule of Three in Refactoring applies to this scale, too. If you are building a "platform" for one customer project, that's a one-off and quite possibly YAGNI. If you are building a "platform" for two customer projects, that's likely coincidence and still possibly doesn't show company-wide need. If you can build for at least three customer projects, that is a pattern, that provides real guidance on exactly how generic things need to be and better ideas how to abstract it.
carlmr · · focus · HN ↗
The more dogfooding projects the better. And yes, rule of three applies.
WorldMaker · · focus · HN ↗