2/ There are many ways in which your platform differs from AWS.
Firstly, AWS serves the median use-case whereas you are expected to serve the entire spectrum.
Secondly, you cater to captive audiences and you have no notion of revenue or metrics which serve as proxy for revenue.
3/ For captive audiences, solutions can not compete and better solutions cannot win. Like a command economy, platform products are designed rather than evolved. Design takes priority over market economy.
So why is design bad?
4/ For design to work, we need a software specification. Since we do not have metrics to guide our specifications, we rely on user-interviews to fill the gap.
This is an unreliable source since captive users do not know of the ideal state of abstractions that could be available.
5/ The only way to flip this situation is to let go of command-economy-style designed abstractions, and to let your platform self-organise along the principle of markets.
How does that look in practice?
7/ Secondly, look for overloaded use-cases are guides to unmet needs of the users.
Lastly, use user-interviews judiciously. They should not be the resort guiding every product decision.
Let me start with an assertion. Every platform engineering team 1 in every organisation aspires to be like AWS 2. To define a platform for the purposes of this post, I use Camille Fournier’s words: A platform is the software side of infrastructure. ↩ I use AWS throughout this article as a stand-in for a generic cloud provider. ↩