The Incentive Map Every Data Platform PM Should Draw
Revealing the Invisible Layer That Powers (or Blocks) Platform Success
About Our Contributing Expert
Anna Bergevin | Sr. Manager Data & AI Product Management
Anna Bergevin is a data and AI product leader currently serving as Sr. Manager of Data & AI Product Management at Children’s Mercy. She leads platform product strategy focused on enabling secure, compliant, and scalable data systems that power analytics and AI across the enterprise.
Previously, she led global Data & AI platform product initiatives at ResMed, guiding roadmap and governance strategy for a distributed engineering organization supporting business teams in over 140 countries. Her work centers on semantic modeling, metric standardization, metadata-driven governance, and designing data products that balance regulatory rigor with innovation.
Anna writes and speaks about data product management, sociotechnical AI adoption, and the discipline required to build enterprise data systems that scale on When Data Met Product. She believes the future of AI depends less on model sophistication and more on clear definitions, strong governance, and product-led stewardship of data infrastructure. We’re thrilled to feature her unique insights on Modern Data 101!
We actively collaborate with data experts to bring the best resources to a 15,000+ strong community of data leaders and practitioners. If you have something to share, reach out!
🫴🏻 Share your ideas and work: community@moderndata101.com
*Note: Opinions expressed in contributions are not our own and are only curated by us for broader access and discussion. All submissions are vetted for quality & relevance. We keep it information-first and do not support any promotions, paid or otherwise.
Let’s Dive In
Data platform product managers have an impossible job: drive adoption and impact without formal authority over the teams they serve.
To succeed, you need to think like a game theorist. Game theory, the study of strategic decision-making, assumes people act rationally given their incentives and constraints. Behavior that may appear confusing on the surface makes sense if we dig deeper to understand the incentives that drive their behavior.
The problem isn’t that your stakeholders are irrational. It’s that you often don’t understand the games they’re playing.
🔖 Related Read
Software engineers aren’t ignoring your metadata standards because they’re lazy. They’re optimizing for velocity because that’s how they get promoted, and the standards require changes that feel burdensome to adopt.
Analysts aren’t creating warehouse chaos because they don’t care about governance. They’re solving today’s urgent business question because that’s what their VP is waiting for. They aren’t thinking about how their quick solutions create warehouse issues at scale.
Your stakeholders are rational, and you just need to understand their incentives better.
The Incentive Map is the invisible layer that powers organizational behavior.
Once you see it, your job as a platform PM gets infinitely easier. You stop fighting human nature and start designing with it. You build products that consider the needs of the diverse set of people engaging with the system, and not just the obvious users at the center.
Building this map? That requires systematic observation across four dimensions: structure, success metrics, systems, and people.
The Four Dimensions of Incentive Mapping
1. Structure
Data platform teams serve the entire company, which means understanding org structure across the business is critical. Organization structure reveals who sets incentives, how information flows, and what leadership believes about how teams should work together. It gives us clues about where collaboration will be easy or difficult.
When I join a new company (or hire someone onto my team), one of my first priorities is understanding the key people who surround my role. Eventually, as individuals, but first and foremost, the teams - who report into whom and how that intersects with my team.
“Ah, okay she works on DevX, which reports to the VP Eng Platform alongside the data platform. All up through the CIO, interesting.”
“Alright so this analyst is embedded in finance, but supply chain has their own finance analysts, what’s that dynamic?”
“He’s an architect on the software side….reports into a product leader….looks like we don’t have a CTO, okay so software eng is seen here as a function under CPO, okay.”
These mappings uncover how the organization thinks about each group. I’ve worked on data teams under both a CTO and a CIO. Under the CTO, all of engineering (software, enterprise applications, data) shared the same org and goals.
Under the CIO, we aligned with enterprise applications while the software engineers were being driven by goals set by the product leadership. That changed the collaboration dynamic significantly.
Organizational structure determines:
Who sets incentives, and what those incentives reward
How planning and prioritization happen
Where silos form and where context needs bridging
Whether cross-team dependencies are visible or hidden
Org design decisions and changes happen for many reasons: strategy shifts, layoffs, mergers, cost reduction. But regardless of the trigger, leaders are making choices about which teams sit together, who reports to whom, and how work should flow. Those choices reshape incentives and communication patterns, whether that’s the primary goal or a side effect.
2. Success Metrics
Understanding the org structure tells you who sets incentives. Understanding success metrics tells you what those incentives actually reward. What are the called-out KPIs for different teams? Is there clarity or ambiguity? Do some people feel pulled in conflicting directions? Are individual performance measures aligned with team goals, or are they at odds?
Once you understand how the company measures success, you can see why certain tensions exist.
Example: When I didn’t understand the success metrics
Early in my product platform career, I was PM-ing the communications platform supporting email, in-app notifications, and mobile push for all product development teams.
Very quickly, I discovered a tension between Marketing and Product around communications ownership.
Product felt they should own user engagement comms. Like many product orgs, they were measured by Monthly Active Users, and email was one of the only tools to re-engage dormant users.
Marketing also wanted to interact with individual users and drive engagement.
At first, I was perplexed. In a B2B SaaS company, why would Marketing care about individual user emails when buyers make the purchasing decisions?
Then I had a breakthrough. I realized marketing was being measured by account retention, which in our B2B edtech product was deeply tied to usage rates. Enterprise buyers purchased licenses, but renewals depended on whether people actually used the product.
Marketing didn’t just want to email buyers - they wanted leverage to drive individual usage. And frankly, it seemed like they didn’t trust Product to do comms as well as they could.
Once I realized this, I had a lot more empathy. Marketing’s success metric was hard to impact through buyer-only lifecycle emails. And they had a point: individual product teams were sending emails that were loose on branding, lacked a comms strategy, and had no coordination across teams. We were just giving them an API and letting them do whatever. I decided to change my strategy with marketing to see if we could collaborate more closely, improve brand alignment, utilize their expertise in comms strategy on critical emails, etc.
The lesson: Conflicting success metrics create predictable tensions.
The reality:
Companies are imperfect at measuring success. As data professionals, we know why: lack of skill at picking the right KPI, office politics driving selection, data quality or availability issues that make measuring what matters difficult.
Even as companies iterate on metrics over time, tensions will probably still exist. But once you understand the metrics, you can strategize and find common ground that lets both teams find success and helps the company reach its overall goals.
3. Systems
While structure and success metrics are slower-changing dimensions, organizations have many cycles that create pressure and shift priorities and incentives for our colleagues.
Cycles like planning, budgets, promotions, and performance reviews - these create unique pressures on individuals, and they aren’t uniform. A few examples to illustrate:
Planning
You learn once again that one of your analysts has created an expensive, monstrous ingest query into Tableau. Why do they keep doing this? Didn’t you just have a great meeting talking about investing in data products, shifting left, and maximizing efficiency for the company?
Well, yeah, you did, but what you didn’t learn is that leadership just pivoted strategy hard in the quarterly planning cycle, and your analyst had to start all over with the dashboard for their group.
The leaders are stressed and want metrics asap so they can see if the pivot is working or not. Your analyst can’t wait to build a curated model on this one; they just had to get it up and running as fast as possible.
Once you understand this, you can meet them where they are. Help them ship fast now, then collaborate on refactoring it into a proper data product next quarter. It’s not resistance to your platform strategy - they just had to deliver under pressure.
Product / Launch Cycle
You’ve been working for months on a new metadata as code project. You are super excited because you’ve been talking to a few teams and think you have a prototype that will work to let them push their metadata to you through a GitHub action, and you’ll validate it from there and push to the rest of the system.
But you approach one team, and they shut you down hard. It’s confusing, you thought they were on board, and other teams have been open to testing.
You ask your manager, and they remind you that the team owns the top priority feature that is launching at a user conference at the end of the quarter. They have zero margin for error. It has to be perfect and demo-able, without any embarrassing bugs. They just cannot take on something “extra” like a governance ask that feels like a distraction they can’t afford right now.
Work with other teams instead, wish them good luck, and circle back next quarter to celebrate their successful launch and bring up metadata as code again. By then, you might even have learned from the early adopters and have a second prototype for them to test.
Leadership Pushing AI Initiatives
Your leaders are bringing up AI across the board, and the pressure is intensifying. Even though you try to showcase progress and point to other work you’re juggling (cost savings, shipping important data pipelines, etc), they just keep coming back to “How are things going on the GenAI pilots?”
The tech is new, and everyone is learning, so progress is slow, and you are irritated - we’ll get there when we get there. Why is he being so intense about this?
What you aren’t seeing is that your leaders have a board meeting and budget cycle coming up. They are worried the board will ask hard questions, and they won’t have clear progress to show on an AI feature that resonates with that audience.
They don’t want a lukewarm update. They want a wow factor. Additionally, with the annual budgeting cycle, they need to justify renewal of that GenAI spending (or maybe an increase) and are worried lukewarm results will make that difficult.
If you understand the pressures from those board/budget cycles, the increasing AI pressure amid steady progress (but without a wow factor) makes sense. Maybe you can achieve something that feels more like a milestone they can run with?
In all these scenarios, the pattern is the same. Behavior that appears irrational, but suddenly comes into focus once you understand the pressure they’re under from these outside cycles. When you understand that, you can pivot your strategy: what you’re doing, the timeline, your priorities, etc and find a path forward.
4. People
The first three dimensions give you a systematic map of incentives: where people sit in the org, what they’re measured on, what cycles they’re navigating. But organizations aren’t just systems. They’re made up of humans with egos, ambitions, histories, and relationships that don’t show up on any org chart.
Some people are more influential than their title suggests. Others have reputations, deserved or not, that shape how their ideas are received. There are grudges from past projects, alliances between teams, and personalities that either smooth collaboration or create friction.
You can’t template this layer. What you can do is stay curious. Pay attention to who holds informal power, which relationships are strained, and where past conflicts still echo.
Your incentive map isn’t complete without accounting for the fact that people are people: complex, political, and rarely as rational as game theory would predict.
The Four Stakeholder Archetypes
The four dimensions reviewed above give you the structural foundation of your incentive map - how your organization is designed, what it rewards, the cycles that create pressure, and the people who have influence. But to make the map actionable, you need to understand the players navigating that structure.
While every individual is unique, I have found that certain roles share predictable incentives, constraints, and pain points that shape how they operate. The four stakeholder archetypes below will help you interpret the behavior of your colleagues: what they optimize for, what drains them, and what they commonly misunderstand about each other.
And at the end of your day, understanding your users deeply and empathizing with their pain points is what product is all about.
That’s how you design sticky products people love, by building solutions that work with human nature instead of against it.
1. Software Engineers: Optimizing for Velocity
This group includes software engineers, enterprise application engineers, solution architects, and other engineers outside the data team. For these users, the key is understanding that they are incentivized to ship business-prioritized features.
New work is seen as the most valuable, interesting, and engaging–while maintenance and tech debt are viewed as less desirable.
Software engineers value solving complex problems with autonomy, automation over manual processes, and minimizing context switching. They find many meetings burdensome, and processes a distraction; they’ll push back against unexpected pivots with no notice, and face invisible constraints (infosec, dev rules) that make “simple” requests more complex than one might think.
The common misunderstanding
Data platform PMs sometimes don’t realize that software engineers are blind to downstream data usage. They’re building for the application use case and are often not thinking of or even aware of data dependencies on their application data.
They don’t want to break dashboards or ML models, but they have no visibility into those dependencies. If you haven’t built data contracts integrated into their development lifecycle, you can’t really expect them to prevent breakage.
The design implication
Don’t create manual governance processes and expect compliance. Build automated tooling that fits their workflow: data contracts, metadata as code, and programmatic data access. Make the optimal path the easiest path, and you may be surprised by the uptake.
An example: For most businesses, one of the greatest barriers we face in getting value from data is a lack of context on the data. One of the most requested improvements nearly every stakeholder wants is better table and column level descriptions, richer metadata and more context overall.
The challenge data teams face? We don’t own that system, and when we contact the teams that do, we hear things like:
We have a Confluence page, but it’s out of date
Todd knows everything, so if you have questions, message Todd
Honestly, I don’t think it’s written down in any one place (implication: context lives in the code base comments, Jira tickets, and scattered resources).
So how do we overcome this?
In the short term, you can do what I call documentation sprints. You have them send you their messy docs, no matter the format, and you work on cleaning them up and validating them.
You interview Todd and write down his answers. You beg the tech lead to populate a spreadsheet. Even if you are successful, this only solves it for a single point in time; there’s still no plan for keeping it up to date.
But we had a hypothesis that if we made it easier to send us that metadata programmatically, through a standard format, that would be better received. We also thought that we’d make the update as simple as possible: follow the format, and we’ll manage validating it, handling versioning against prior metadata commits, and cascading it downstream to the warehouse and data catalog.
When we did user research with our software engineers, this idea was very sticky. So sticky that we were hit with comments like “Oh my gosh, this would replace our Confluence page, we could use this for our own documentation” and even “I love this, it would be even better if you could add [insert many feature requests].” Suddenly, our software engineers were engaged and eager to use this solution, because it was designed to match their incentives:
Solves a core problem they have for their application development work: documenting the system in a way that is more structured than a wiki; helping preserve official context to share across the team
Solves the problem in ways that make sense for their preferred workflow (sending us their metadata as a code file (yaml or json) via GitHub action that manages everything else. Minimizing the burden on them to learn a complex system, while delivering benefits for themselves and the business
Understanding software engineers’ unique incentives and pain points is critical to driving collaboration between source system owners and downstream data consumers.
Secondary data usage may not be their focus, but we can drive engagement by reducing barriers to entry and ensuring their efforts get visibility with leadership as critical enablers of analytics and ML development
2. Analysts: Balancing Speed and Precision
Analysts (and data scientists) are the core users of the data platform. They are the final mile that takes all the data work we’ve done and turns it into insights and AI models that have real business impact.
For these users, the key to understanding them is that they are incentivized to solve business problems quickly, but with precision. The business needs their deliverables quickly, and with their focus on precision, they will do whatever wrangling is needed in order to build what the business is asking for and hit a timeline.
They are the rare user who has a foot in both worlds: deeply engaged with the business and its problems, with a strong technical understanding of what it takes to build well with data.
Analysts value the puzzle of finding the right data to bring to the problem and finding the right model, visualization, metric, forecast, etc. They enjoy the process of exploring and uncovering value for the business and then returning to the business to share those assets to guide decisions, power products, and spark critical conversations.
They do not want to wait on the comparatively slow data platform team to build them pipelines, though if you have a curated, well-documented asset ready now, they are often excited to take the shortcut (if they can trust it).
The common misunderstanding
Data platform PMs sometimes don’t realize that data analysts often have no idea what the downstream implications are of their decisions. They don’t realize how the actions of many analysts compound to generate warehouse clutter, out-of-control query costs, and challenges with managing assets over their full lifecycle.
They are deep and narrow, focused on the problems within their remit and not thinking about the health of the ecosystem overall.
💡 Platform PMs think analysts should wait for “perfect golden data products” or that analysts don’t care about data quality.
Wrong on both counts. Analysts need speed, BUT they also care deeply about precision and quality. They may also feel threatened by self-service narratives that position their work as “almost automated.”
Particularly as AI demos show rapid-fire analysis and people declare the death of dashboards. Meanwhile, skilled analysts know that 80% of the work is just getting that dataset ready and knowing enough context to use it well, and we are far from being able to automate that aspect of their work.
The design implication
Plan for speed & scale. Acknowledge that analysts may need to curate just-in-time assets, AND they also need to realize that those curations need to be managed to keep the ecosystem healthy.
Build a platform that supports the curation spectrum: quick access for exploratory work PLUS a pathway to sustainable, scalable solutions (semantic layers, metrics views). Don’t force them to choose between speed and governance. And help them see career evolution, not job elimination.
Note: Data Scientists share many of the same incentives and needs as analysts - requiring speed, precision, and the ability to explore data iteratively. However, they have unique platform requirements around stability, pipeline reliability, and model deployment infrastructure that warrant additional consideration. More here.
3. Leadership: Proving ROI and Managing Risk
Leaders are optimizing for fundamentally different outcomes than individual contributors or middle managers. They’re thinking about margin, growth, and the long-term viability of the business. They answer to boards, investors, and their own bosses. To influence leadership, you need to understand what they’re being measured on and what keeps them up at night.
What are they worried about
Leaders face constant pressure around hard decisions: org design, layoffs, budget allocation, and strategic prioritization. They want to be data-driven, but they don’t understand the complexity.
In particular, right now they have a lot of uncertainty around AI - are they investing in the right areas, are we getting ROI, do we have the right talent for this next phase, when will our industry and market transform, and how?
In short, they need information and confidence, and in particular, they need to know that when it comes to data & AI, the business is moving in the right direction and allocating our scarce resources where needed. We need to provide reassurance that the data team can be:
An essential driver of innovation and operations, not just a service desk that builds nice-to-have reports
A strategic partner that helps leadership have the insights they need while finding the right opportunities to leverage data & AI to help the business and our customers
The critical misunderstanding
Data platform PMs often think too narrowly. They think it’s enough to say, “I’m delivering what your team asked for.” What they really need to think about is:
Am I adding strategic value to leaders in my org?
Am I making sure their most important initiatives are getting their data needs met - not just responding to requests, but proactively helping identify opportunities
Do they understand the full scope of what our team delivers for the business so that the timing of their request makes sense in the context of our overall capacity and demand on our team’s resources?
The design implication
Reserve capacity for comms and relationship building. Leadership doesn’t understand your world - you have to build that narrative. You have to connect platform work to business outcomes they care about (margin, growth, competitive advantage).
Communications from the data platform team are critical to the success of the team and your business. Make optimizing those communication channels a priority.
Business Stakeholders: To Each Their Own
Finally, general business stakeholders, though this isn’t really one archetype. The whole point is that each one is different, and you need to spend the time to build the relationship and deeply understand their pain points. What is each stakeholder optimizing for?
For sales, it’s all about closing deals and optimizing revenue.
For marketing, it’s about strategic growth levers and making sure we’re growing top of funnel and building brand presence.
For the product, it’s about making sure we’re shipping what our users need and understanding where we are getting traction and what’s not quite hitting the mark.
For finance, it’s about a multi-lens view of the business and the overall health, and making sure that those numbers are absolutely precise and can be trusted. And so on and so on for every different department.
You have to do the work to deeply understand your stakeholder’s department level strategy, their OKRs and KPIs, their foundational analytics gaps, and the opportunities AI brings and whether they are tackling them.
Think of yourself as a mini-data strategy consultant for each department, partnering with them to grow their vertical.
The critical misunderstanding
Data Platform PMs limit their impact when they treat business stakeholders as a homogeneous group or just respond to inbound requests. Wrong. Every meeting is a consulting engagement: get up to speed fast, find opportunities, solve together. Hear requests but also help them think bigger about data & AI’s role in their department.
The design implication
When you are staffing your data platform team and have multiple PMs, it may be tempting to align them to different platform features. And maybe some of your PMs can do that (at my last company, we had one PM over the AI platform feature set, for example), but when it comes to data products and engagement with the business, it is beneficial to align PMs to business departments for lasting relationships and deep domain knowledge.
You can’t be impactful without knowing them deeply. This isn’t scalable through templates and ticket queues. It requires dedicated relationship investment.
Influence Without Authority
Remember the opening premise: game theory assumes people act rationally given their incentives and constraints. The problem was never that your stakeholders were difficult or irrational. It was that you couldn’t see the games they were playing.
Once you have your incentive map, everything shifts. You stop being surprised when engineers resist governance or analysts bypass your platform. You understand why. And more importantly, you know how to design solutions that work with their incentives instead of against them.
Your core job as a product manager is to “influence without authority” and you can only do that if you empathize deeply with the humans you are working with.
The incentive map gives you that empathy at scale, helping you see patterns across individuals, anticipate resistance before it happens, and find the alignment points that let everyone succeed.
The map is never complete. It evolves as people change roles, structures shift, and strategies pivot. Your job is to keep updating it, stay curious about what motivates the people around you, and be the bridge-builder who sees all sides. That’s how platform PMs turn organizational complexity from an obstacle into an advantage.
MD101 Connect ☎️
If you have any queries about the piece, feel free to connect with the author(s). Or connect with the MD101 team directly at community@moderndata101.com 🧡
Author Connect
Connect with Anna Bergevin on LinkedIn 💬 | Or dive into her work on Substack:
From MD101 team 🧡
🧡 Join 2000+ on The State of Data Products
Introducing The Catalyst, a special edition of The State of Data Products that compiles insights around the ups and downs in the data and AI arena that fast-tracked change, innovation, and impact.
📘 The Catalyst, first release is our annual wrap-up that compiles the most interesting moments of the year in terms of developments in AI & data products, with expert insights from across the industry.
Some focal topics
The gap in AI readiness for enterprises
The shift towards context engineering
Addressing governance debt with a focus on lineage gaps
Revisiting fundamentals for better alignment b/w business vision and AI.
 | A guest post by
|
Congratulations on a well-written article that should be required reading for anyone who has been assigned a project management job, particularly when it's the first PM job he or she has been assigned to.
One area of the topic that might benefit from additional emphasis is the need for the PM to become highly proficient in time management. The project will have two key outputs - the product and the team that builds it. Each of these requires a great deal of attention. Each will encounter unexpected problems. Each will demand that the PM spend time that impacts the rest of the work the PM must perform.