Platform User Research
Treating engineers as users whose actual behaviour is observed rather than assumed, which is what separates a platform from a set of shared tools.
The claim that an internal platform is a product is easy to make and mostly unearned. The test is whether anyone does the thing products do: watch users, find out where they struggle, and build for the struggle rather than for the architecture diagram.
In practice this is unglamorous. Sit with a team onboarding a new service and time it. Read the questions in the support channel and categorise them — a platform's support channel is its usability test transcript. Look at where teams left the paved road and ask why, because every departure is either a missing capability or an abstraction that leaked.
What this consistently finds is that the platform team's model of the friction is wrong. The team believes the hard part is deployment configuration; the observed hard part is getting a test database with realistic data, or working out which of four similarly named dashboards is the right one. Building the second is worth more than perfecting the first, and no amount of internal reasoning reveals which is which.