What does it mean to own/support a product/platform?

In the ever-evolving tech landscape, owning a product or platform is a multifaceted responsibility, which requires oversight not just of the technology itself but of how it integrates into an organization’s broader objectives and needs. Unfortunately, at times the ownership of a product or platform is not something which is confined within a single team or group and gets distributed per the functional areas. For example- the engineering team might own the product code but Infrastructure might be a different team and operations might be managed by a different vertical altogether.

In my 18 years of IT leadership career, one of the reasons why engineers struggle is due to the fact that they don’t develop a 360 view of the entire product/platform and its ecosystem on the counts of "we don’t own that part". One of the things I have always stressed on is the fact that the only way to do a good job within your function is when you develop a sense of the entire lifecycle and ecosystem as that will help develop deeper insights and how everything impacts what you do end up owning.

Here is a quick checklist of what I have used in terms of- Every engineer should at least have a basic understanding of the following aspects of the product/platform you support in some shape or form:

1. Why is the product/platform needed within the organization to begin with i.e. what is the goal of having this and what business problem specifically it solves and for whom?

2. What are all the core functionalities and features of the same

3. Who are the users, how do they use it and what do they expect out of it for each of the user types

4. Knowledgeable about the technical underpinnings of the platform. This includes understanding how the system is built, what infrastructure supports it, and how scalable and flexible it is to meet current and future needs.

5. How do users get onboarded and offboarded?

6. What are different security and governance aspects i.e. how are the product, users, and data secured

7. Does the product have logging? If so what gets logged and where? Who reviews them? Do you have the knowledge and access to analyze them?

8. Are there monitors and alerts configured? If so what do they monitor and alert on? Who receives and acts on them?

9. If applicable- is a vendor involved with the product? If so, is a regular QBR(Quarterly business review) done?

10. What is the cost of the product and licenses? What is the frequency? How has cost changed or is it projected to change based on growth and scale

11. How often does the product or platform go through upgrades? Who monitors it and who manages the end-of-life cycles?

12. How and who manages the patching and security hardenings?

13. What is the current roadmap, tech debt, and 3-year vision of the product or platform and its features? i.e. will this continue, retire, or modernize at some point, etc.?

14. Do you have access to all the documentation including features, system admin guides, design, architecture, etc?

15. What are all upstream and downstream dependencies i.e. what other systems provide input and consumes output from this product or a platform

The above can be used not only as an onboarding guide but also as a gap identification checklist to shore up the aspects if they are not hardened as of today!