Internal Developer Platforms can help you Own the WHOLE Product
How product engineering platforms can provide OODA loops to support ownership, or stewardship, and accountability of a product's functional and non-functional features
In my “Don’t Feed the Pigeons” series of talks this year (see below) the topic of how an internal product development platform can support owning the WHOLE product being developed is explored. It’s a simple idea: A successful product is owned, or stewarded, across all its features, both functional and those traditionally called “non-functional” or, often, “tech or platform’s problem”; a successful internal product development platform can help product owners/stewards embrace this WHOLE balanced product perspective when prioritising and evolving their products. No more “just tech’s problem”.
I’ll be giving my “Don’t Feed the Pigeons: Some Principles From Real World Internal Developer Platform Engineering” talk at:
Axon IQ Conference in Amsterdam 2024
Come and say hi if you can make it!
Being a product owner or product manager is hard. Balancing all the possibilities for a successful product into a cohesive and executable vision, roadmap and backlog, guiding experimentation towards product success, and building empathy, compassion and understanding of your users so the product can be improved is a lot of work. And we love it. Really. Absolutely love it.
But as a product owner, it’s tempting to think your job begins and ends with that product vision, mission and an experimentally exploitable roadmap. That you’re held accountable for the features of your product alone.
And that’s right! But the gamut of what are your whole product’s features are not just its user-facing functionality. Features matter, but not just “functional” features. What we’ve unfortunately referred to as “non functionals” (in the soon-to-be past?) are features too.
For example, “non functionals” such as reliability (including performance, resilience, recoverability), security, observability and cost optimisation are product features too. If you’re not owning and accountable for them, you’re only owning half the product. These features, just like user features, also drift into failure without your consistent and regular attention, prioritisation and investment. Without your ownership and care, your product will gradually become less reliable, secure, cost optimised etc over time. Even if you did nothing and just left the product running with no further investment and change, through the fact that the rest of the universe doesn’t sit still your product will degrade and drift.
And without investment in those non functionals, the functionals don’t work. Nothing is more functional than a non functional, which is why I really want the non functional term to retire.
As Technical Product Owners it’s our job to understand how to measure, maintain and improve our WHOLE product. If you don’t have access to measurements of how reliable, secure, observable or cost optimised your product is, you’re flying blind. You need those OODA loops to be able to make great product investment decisions.
Those OODA loops are one of the big value-adds that an internal platform team can help establish. They sit firmly in the middle sections of what I’m calling the internal developer platform’s “hierarchy of needs”—more on that hierarchy in a future article. Way beyond infrastructure, a great internal developer platform product can aim to give you the tools so that you as TPO can own and be accountable your whole product, and your stream-aligned engineering teams can be responsible for executing on your whole product balanced feature investment roadmap and backlogs.