Why X-as-a-Product Is a Useful Lie
If you have ever heard, "Treat your platform as a product," or, "Think of your API as a product," then you might be in the business of creating software! A danger with these kinds of shortcut phrases is that they can become common enough that they begin to lose their definition. So consider for a moment, what do they really mean?
At first, this may seem paradoxical. When someone says X-as-a-product, it implies that it is not one already. So what might be missing that is preventing it from being a complete product?
[For a more complete definition of "product" see Episode 3: Evolving API Product Thinking.]
A Potential Product
Let's start with the easiest case to consider — when something has potential to be a commercial product but hasn't yet reached that level of maturity. For example, consider an internal API that could be useful to external partners. Additional steps will be necessary before it is ready for external launch. Only then can this API begin to generate direct/indirect revenue.
For an example of platforms, Amazon Web Services (AWS) built internal tools to run their digital bookstore. When they later made them available to others, it started an entirely new line of business as a public cloud platform.
Both examples above represent commercial products growing out of internal assets. At earlier stages of maturity, they had not yet realized their commercial potential. But should each X-as-a-product necessarily aspire to that? Within this question are hints about the beginnings of the -as-a-product lie.
The Lie Begins
Some default assumptions haunt the word "product." Partly this comes from being associated with product successes like the iPhone. This anchoring effect can make it harder to recognize smaller products all around us.
When the "as-a-" gets added as a qualifier, then a broader view of "product" emerges. Within this newfound space, requirements like commercialization may then be de-emphasized. Ways this might manifest include:
Limited Addressable Market: An internal development platform's user base is naturally capped by the number of developers within the organization (a closed market). An API designed to meet a specific internal business need, such as an employee directory, has no viable audience outside the company.
Absence of Competitive Forces: When an API is designed to meet a specific internal business need, it is inefficient to build another similar service (that it happens and why is the subject of a future post). This means there is little opportunity for new entrants to compete, as would be found in a competitive, public market.
Similarly, a platform engineering team might choose to buy from vendors in a competitive space rather than build a custom solution. At other times though, it may make sense to build a fit-for-purpose custom solution. When that happens, challenges are likely to come from driving internal adoption rather than from competitors looking to win that share of an internal audience.Non-Monetary Value Exchange: When building an internal developer platform, it would be strange to consider usage-based or seat-based pricing. Instead, the value to the organization will manifest through enhanced productivity, improved consistency, and higher overall reliability. Even though these internal platforms are unlikely to ever evolve into fully commercial products themselves, they can benefit from adopting a product-centric perspective.
Why the Lie Is Useful
In brief, using X-as-a-product can relax the default assumptions that any "product" should aspire to become a commercialized product (or even that it could). Adding "-as-a-product" is a useful lie that invites us to treat the internal product more like a commercial one and then to leverage the techniques that help commercial products succeed. This framing can bring benefits when applied thoughtfully.
By seeing through the lens of a product, a team might:
Ease Adoption: Design and build self-service journeys that improve user acquisition and increase activation and engagement.
Iterate Through User Feedback: Gather qualitative feedback from users that will inform improvements across iterations.
Understand Non-Monetary Costs: Just because money isn't changing hands, users still incur costs. For example, they assume a dependency risk or investment of time and mental energy to understand the product.
Realize Value Creation: Again, while money isn't exchanging hands, value will also accumulate for the creators. This can manifest as organizational impact, enhanced developer productivity, or reduced software development costs over time.
Quantify Outcomes: Instrumenting with metrics can help gauge usage and measure organizational impact over time, which may bring new insights or support further investment in the effort.
While -as-a-product helps to apply product thinking to unblock engagement and growth, any cost of these approaches must be balanced against any expected gains.
In Summary
To be viable, a product must create more value than it consumes. The value it creates is then split, with some going to users, and the rest accruing to producers. This is true whether the product is internally or externally focused.
For commercialized products, money changes hands. For internal products money may not be changing hands, but developers using a technical product may be paying for it in other ways, such as with time, effort, and/or by assuming a dependency risk.
On the other side of the transaction, a platform team or API producer responsible for an internal product deserves credit for the impact of their work-product. For example, they have likely improved the organization's quality and/or realized efficiency gains.
Whether this offering is highly productized or not, better products generally come from empowered teams. The flip side of that equation means that these teams must also hold themselves accountable.
So the next time you hear (or say) API-as-a-product, platform-as-a-product, or similar, take a moment to think about what specific constraints are being relaxed and why!
Enjoy this? You might also like Episode 3: how simplistic API product thinking is holding back progress.
Did you enjoy this? If so, then you should subscribe to be sure you don't miss the next one (it is both free and low-traffic).
Nice post Marsh! -- I've always found this "lie" strange in another way when applied to internal APIs. it's that the API isn't actually the product, it's the thing underneath the API that is really the product. So if your API is a new (better!) way to access (for example) to retrieve data from the customer database, then the ability to make those queries is that "product". The API team then has to realize it is competing with all the "other" ways to do the same - from the BI tools, to a naked SQL query or whatever.
With discipline, you also have to shut down those routes you really want to stamp out and push them to the better API. Or simply be so much better + helpful to those who want to switch that everyone does stop using SQL queries.
So it's really the much-loved resource that is the product, and the API teams are the heroes, making it more accessible. If the API team focused on the API itself as the product, it's easy to care more about the interface than the system it makes accessible...