Data Product Management Maturity Model (v. 0.5)

I've been thinking about a maturity model for data product management for enterprise data science and analytics teams doing "offensive" data product work and wanted to share a pre-1.0 version as soon as possible. After all, that's the producty way!

Before we go on, you should be aware of my definition of data products.

Who is this maturity model for?

In my head, I designed this primarily for internal data teams supporting enterprise businesses indirectly; in other words, the org's primary business is not selling digital data products via software. They sell other products or services, and ML and analytics enhances those services. However, they may also offer some commercial data products whereby insights/information are exposed via monetized software, for example.

Question: does your org feel unnecessarily excluded by this scoping? If so, let me know at the bottom of the article.

Who is this not for?

Because of my definition of "data products," this assessment likely will not make sense or be relevant to you if data products mainly means something data-meshy to you, about containers, reusable data assets, or other solutions that do not include a complete "end to end" delivery model.

This is not a judgement of other data product definitions, and it's not to say that you cannot use product-driven methods to build things like "internal data platforms." It's more to say that for me, data products are more about the verb than the noun. In other words, it is about "doing it the producty way"— a way of working—that is focused on the creation of benefits and value—and not technology outputs.

The Maturity Model (v. 0.5)

This is rough, and it's v1 -- mostly based on qual data I capture through conversations, the Data Product Leadership Community, my podcast interviews, and 12 recent interviews completed as part of a research study informing a new Group Coaching offering I am offering in 2024.  Almost all of these Coaching interviews were with individuals in middle to senior management, with teams [direct report headcounts] of ~5-50 each. Some teams reported into larger orgs; several are mid-journey (no AI pun!) in migrating to a product-driven operating model or changing their behavior.

I would guess that we have a lot of 2s and some 3s if I surveyed the DPLC Community if this model is "right"—but more on that below.

Here's the 4-part model as it stands right now:

Level I: Unaware:

The data-drive through. "Customers" (internal stakeholders) place orders. Team does their best to fulfill the order as instructed, providing an output that matches "spec." BAU....but definitely feeling like an "order taker" team, fulfilling JIRA tickets, and wondering "why doesn't anyone use these solutions we make? We could be doing X!" They're starting to hear about "data products"...but it may feel buzzwordy at best..or a total mess since there are so many definitions out there.

Level 2: Emerging:

Aware of the need to produce value/benefits from the ML/analytics solutions, however the value is often opaque or hard to define. Focus is more on solving the end users' needs/pains....but despite seeing increases in usage, the value to the end users' own management or other stakeholders may not evident. Primarily measures adoption through analytics (sessions/page views/counting). Likely has no dedicated design/UX resources; the DPMs (data product managers) are wearing a ton of hats and spread thin. There may be a mandate/goal from the CDO or another CxO to "work the producty way," but it is not entirely clear what that means...and the DPMs in middle management are largely the ones figuring it out as they go. They're optimistic...but sometimes feel "alone" in their journey towards a producty way of working. They may have a uphill battle even with their own team who may mostly if not entirely care about tools-n-tech....not providing "value" (whatever the hell that means).  They are starting to see some light as they dig more into the unarticulated needs of stakeholders (why-questioning) as well as getting more access to real end users. However, a lot of effort is still spent on building out tech; resources for non-technical work are slim.

Level III: Maturing

Has some "wins" on the board; both stakeholders and end users can see benefits. Stakeholders see financial and/or other gains; end users feel benefits as well (time saved, empowerment, easier work, competitive edge). The DP leaders are able to measure both end-user value and financial value.  May have more of consultative role inside the business, and it's possible some stakeholders see the ML/analytics group as a strategic ally. May have influence drive where resources are deployed and to what problems (i.e. not just receiving mandates of what to create for the org, but highlights opportunities for ML/analytics to help the org achieve strategic goals.) Still has a hard time measuring benefits to the biz and users, but getting better at it and likely can quantify the value of specific in-production DPs. Very aware of how PM/UX Design compliment engineering and data science/analytics and may have in-house UX research and/or designers on staff...or available when needed. "Change management" is starting to become "old thinking" (i.e. you design the DPs in such a way that the issues that traditionally require change management are baked in "as a feature.") Has some regular exposure to actual end users and is used to involving stakeholders and users in the design/development stages. Has some power to "push back" on requests that don't make sense or won't be "winners." Starting to connect the dots to "paying customers" -- i.e. not just helping the business "save money" and "make money," but is thinking about the actual customers that fund the business and perhaps adjusting solutions to balance their needs, the stakeholder needs, and the end [internal user] needs. Starting to "own the problems" and not just the solutions. Manages a portfolio of data products and there is at least one if not more strong voices for data products/DPM in the team who has a strategy and is in the midst of executing it.

Level IV: Mature

Regularly deploys high-value products for which end users and org stakeholders see value; has a strategic voice at the table particularly about ML/AI and how it can be used in the org to further the mission. Unlike "maturing," these teams are very aware of "value" as it relates to the entire chain of humans in the loop: paying customers, internal users, stakeholders, vendors, affected third parties, etc. This org knows how to work cross-functionally and not get wrapped up in fiefdom and credibility issues. After all, the DP team owns the stakeholder problem, and there is clear alignment on what the benefits are that need to be created. Exposure to end users and stakeholders is routine and a regular part of the culture. Very aware of how UX design and research affect the usability, utility, and value of data products—and as such, these are seen as "essential" vs "nice-to-have" resources because the cost of low or no adoption is firmly understood by all parties. Likely has clearly defined "4-legged-stool" data product squads (i.e. PM, tech lead, UX/design lead, and data science/analytics lead).  May be thinking about or producing directly-monetizable data products or ways the business can innovate through new products/services or changing existing ones. Able to quantify economic and other forms of value easily, and place informed bets about where to put resources for the most gain. Essentially functions as a mature commercial software team that is "empowered" (to use Marty Cagan's language).

Next steps?

I may be turning this into an assessment for organizations if there is sufficient interest. Interested? Let me know below by submitting your feedback.

Conclusions: Wrong, but Useful?

"All models are wrong, but some are useful."
—Blair Enns (who maybe heard that elsewhere)

My data product management maturity model is likely wrong, but the question is: is it useful enough to provide insight on what to do next. After all, that's often the game of analytics and data, right?

Submit Your Feedback

To send your replies, comments and feedback, please email me at brian@designingforanalytics.com.

Array
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

More Free Insights: