I've been reflecting recently on the journey from infra/SRE to product/service owner, and my lessons - expected and not - along the way.
My initial anchor on product thinking was based on an effort Google had, originally called P2020, to do product development within SRE tailored to the needs of SREs and production. Many brilliant people were involved and it was a brave effort, but given what I've done over the past few years, I now see that work mostly on the tooling end of the tooling<->product spectrum.
There's a world of difference between them, even though they exist on a spectrum. Leaving aside every question of the mechanics of executing product well, the overall conceptual framework of product needs to sit around much wider considerations than writing a good tool does. Your tool can be appreciated by an engaged audience for a complex use-case and still not be a product, and a product can have a generally unengaged audience for a relatively simple problem and absolutely still be a product.
We spend a lot of time in product-world trying to figure out precisely what the user wants, what tasks they have (that they consider appropriate to accomplish with software), what they're willing to pay for or willing to do to accomplish those tasks, and how that fits in the wider cultural toolscape of the organisation or communities they fit within. Though there are 100% scientific aspects to product (indeed, I would say Google worked hard to obviate non-scientific aspects) there are also taste-based aspects, and in some sense those aspects can come to be more important than the ostensibly more deterministic process of figuring out what features the customers want and making them.
This is the paradox of tooling rather than product: because you're the user of the tool, your feedback loop is much shorter and more efficient, and you think that will make it all easier. Sadly, that's not true. You, as a user of your own thing have a huge efficiency bonus in a way, but it's a little like overfitting in ML - you anchor on your view of the world, and it's hard to escape that framing, even when you desperately need to. It's usually much harder to add a full customer/jobs-to-be-done audit/development process when you've already got an audience than when you're just starting out.
That's a relatively intuitive problem, but there's a few subtler ones: a tool developed with a user, or a small set of them, has much less chance of growing to an identity that survives a use case, and a tooling approach often strongly rewards more tactical approaches to solving a problem. Both are pernicious.
A tool invites the hand to use it according to its accustomed form, but the form is small and implies only things the assisted hand can do.
A product is an assembly of things working towards a much larger goal that even a multiplied hand could never do.
Finally, having been deeply influenced by the SRE experience at Google, where there was absolutely a lot of tooling, but also a ton of very successful infrastructure products (and that's really hard), I had expected that SREs would come to the world of product with two inbuilt advantages:
- They often have some developed taste-sense for infrastructure software. That's true, but it's one thing to have a taste for good cooking, and quite another thing to whip up an exquisite goulash.
- SREs are generally highly aware users exist and are both the source of motivation for a product, and a source of huge problems ;). Often they are more aware of this than product developers. But again, there is a fundamental creative act in deciding what the product does and why, which is not the same as supporting the existing set of critical user journeys.
Overall I would say this has been a significant learning journey for me, which I for one am still undergoing, and has caused me to look at the market for software in a very different way.
