A platform team abandoned their custom catalog build because high volatility in source systems and limited engineering bandwidth made it unfeasible. The product manager reframed the problem using jobs-to-be-done: the catalog needed to be a discovery plane, system-of-record for meaning, and governance platform. Even a minimum viable version would exceed their capacity, so they bought a vendor solution instead.
Chapters
Are we ready to maybe just, you know, do YAML and code and like do these things? Anyway, and her company decided they were ready. And so, they're building something custom. Her platform engineers are building this semantic context layer, whatever they're building, they're ditching the catalog completely. And our discussion at the hospital was like, we have too much volatility with this sort of huge source system change and our engineers need to focus on this core other stuff. And we do not have the bandwidth to build this, the functionality and the way I broke that down is we, I, I guess this gets back to more like a, how the product manager approaches this differently than maybe like an architect or an engineering leader would, which was what are the jobs to be done that we want from a catalog? What's our catalog currently serving? What's our ideal state of what a catalog would serve? And it's like, it's a discovery plane, it's a system of record for meaning. It is a governance platform for sign-offs and approvals. It like has these different functions. And then we looked at the various vendors and which of those features were jobs that we absolutely had to have done and which were nice to have. And what we kind of decided was to build the minimum viable functionality was more of a build than our team could do right now. There were parts that we could do, right? We could build the semantics, we could use Unity Catalog, we could use YAML and Git repos. There's things we could do, but it wouldn't cover enough of the jobs.
