Hi all 👋, I work as a Product Manager for our internal developer platform. We’ve been transitioning from a more Ops-oriented way of working towards platform engineering for the last year or so. In some areas faster than in others 🙈. One of the topics we’re addressing is building a product catalog. We want to have a clear and attractive product catalog so our (internal) customers know for what they can come to us and how, and what the expectations and responsibilities are that are associated with the product. I can’t find much inspiration online that is tailored to platform teams, so I reach out to fellow PMs here. Do you folks have ideas, suggestions, links, examples, experiences, anything to share? Best! Roel

Sorry for not answering your question directly 🙂 I’ll start with thinking about

so our (internal) customers know for what they can come to us and how

and

what the expectations and responsibilities are that are associated with the product

In my experience, the first question can better be answered with the list of use cases rather than list of products. I would start with understanding what user journeys do you have and which of them are most popular. So the entry to your catalogue won’t be “Jenkins” but “How to build Java code”. And in those instructions you can link to internal documentation of Jenkins that will be answering more specific questions.

I agree with Aleksej on this, as this approach will be more customer centric linking platform capabilities to dev needs than the later. It may also drive adoption the more because you would be linking the user painpoints or usecases to the as-built capabilities and features, further using it as a knowledge sharing opportunity for your users. You could use a value proposition map for this.

Agree with the above, you probably have some common app types that have similar paths to production (e.g. cloud-ready java type stuff, heavy processing/data/AI, etc…). Defining those target markets (personas) and then creating a curated “path to production” for those user types will help a ton. By making “the easy way the right way” you’ll be able to steer app teams to your provided services. By building out this path to production, that capability becomes your “catalog” Other things that are helpful include: • Ensuring your platform has some high level documentation around your current capabilities • Creating and sharing your platform roadmap based on the needs of your users • Holding platform office hours

Thanks for your insights all. We are indeed working on multiple views on the same topic. So in addition to a product-centered approach we're also exploring a more persona and use case driven approach

Hi @Roel Kerkhofs Faced the same transition in my org. We started a simple product catalog on Confluence. We have a top-level page that list our products, grouped roughly by stage of the software lifecycle they cover (e.g. CI/CD, Observability, Infrastructure). This has a brief description of each product, a couple sentence at most, and a link to a dedicated section for each product. Each product has a 1-pager that answers these 3 questions: • What is it? • What Problem Does it Solve? (focus on pain points) • Why Use This Product? (focus on the benefits and advantages of using the product compared to alternative potential solutions)