Data Product Management x2, Columns as Contracts; ThDPTh #57

What: I was going to provide a resource for this, but turns out, all I found I did not like. So I’ll describe it to you instead. Keep in mind, if you search for “Specification by Example”, you will usually end up with a bunch of very narrow ideas on how this works, even though it could be a very broad technique.

My perspective: Specification by Example is a fun technique you can use in the phase of Discovery Planning & Framing. I use it from time to time as an alternative to User Story Mapping. It works in environments where the user flow is already well understood, but where we still deal with a lot of complexity because of the underlying domain. It works at feature-sized ideas. Not too small, not too big.

It helps to quickly identify possible challenges like: “are we even able to provide a solution?” Is it too big? Will it provide value? And plan the work accordingly.

Sounds like there is a need for additional data products around the north star metric. The outcome is pretty clear, we want other PMs to be able to understand how they can improve their products to drive up the north star metric.

So, we can set up a quick SpecByExample/Data session. We can invite one possible PM as a domain expert, or give it a go without him using the feedback we already got. We include the engineers the PM, and if we have one, the product designer.

We draw up a table:

Now we start iterating and filling up the table line by line. So what is a possible question a PM could have? How about “How does my product contribute to the north star metric”; What is the data this should be based on? “North Star metric, segmented by products”. Perfect. So what is the answer he would like to see? Draw up an actual (exemplary) table of the result! Then ask yourself, what is a possible decision based on this information.

If you cannot come up with a good one, then you are probably not yet at the right data product! Because every data product should help others make better decisions. So you need to drill deeper into these examples….

… You keep on iterating until you have a nice set of possible decisions with high value (!) and a decent set of questions together with the data. You can now pretty quickly decide which kind of medium fits best for these kinds of answers & decisions. Is it a report, dashboard, set of reports, some machine learning prediction system, or some notebook you run a longer analysis in?

And that’s all you need. I enjoy this technique for discovering things like this, well-understood feasibility and usability, but complex domains and thus hard to understand the value.

What: GitLab has an amazingly open culture about their very formal product discovery process (and everything else). The opportunity canvas is a simple product discovery framing technique. It contains a basic Google Docs template you can copy.

My perspective: I still feel like product management is underrated in the data space. I’ve enjoyed the opportunity canvas, especially for internal data product management, meaning products like company-internal prediction tools, BI systems, (sets of) dashboards, and the likes.

It’s a great tool for medium-sized, not-well understood ideas, like for features or sets of features. Bug fixes, well-understood features can usually be done with an even shorter version of this, and larger efforts require larger tooling. But since the majority of day-to-day work happens in the feature space, I really recommend this tool.

What: Emily Riederer, Capital One, gave a talk at coalesce 2021 about using column names as contracts. She explains how tables and columns can be used to form contracts between data producers and consumers.

My perspective: I like her lead-in. Tables are usually too “raw” to be considered interfaces, at least that will often be the perspective of the data producer. The data consumers however have a very different take on things. I enjoyed the talk.