This book, I loved it so much that I kept saying “Yaaaaaassssss, this, exactly THIS!” I wanted to keep highlighting things (a problem with an audio book…). So, I ended up also buying the e-book so I could highlight and screenshot portions. I have no regrets.

The book:

Your Best Meeting Ever: 7 Principles for Designing Meetings that Get Things Done by Rebecca Hinds

You might think, Anna, why would I want to read an entire book on meetings, I hate meetings. And that’s my point friends, if you hate meetings, listen to this audiobook (it’s not that long) and do something about it.

It’s very good, very tactical, and worth your time if it helps you fix even 1 or 2 recurring problematic meetings on your calendar. Let me tell you why.

Meetings Matter

People love to lament meetings, but here’s the thing, I LOVE good meetings. The ones where everyone is in a flow state, we’re just tackling tricky problems, making hard decisions, and learning from each other. It’s so energizing to be in those kind of meetings. What I wondered is “how can I be in more of these and less of the start ten minute lates, no agenda, missing attendees kind?”

For people in a cross functional role like data and product — meetings will always be a large chunk of the job; they are where so much of the work gets pushed forward. We meet with stakeholders, meet with our leaders, with the PMO, our devs, the BI developer, legal, you name it - SO MANY meetings. So what if more of those meetings could end with you saying to yourself “That was a great use of time.”

This book is about that — upping the return on investment from the meetings you have (and hopefully reducing the overall meeting load too). Its about taking control of your work life by making more of your meetings the kind that energize you, where you can exert influence, seek alignment, clarify prioritization, and unblock work. As much as I try to move these things towards async first, often this must happen in meetings.

This book is very tactical, it’s all about the how. It’s part diagnostic: why are meetings so badly run in so many companies? And part prescriptive: here’s a laundry list a mile long of ways to make them better."

And lest you think this is a pipe dream and this juice isn’t worth the squeeze - you could not be more wrong. One of the companies whose practices she references in the book is Sourcegraph - where I worked several years ago; I have never seen a more async low meeting culture in my life. It was remarkable—Slack was popping off constantly, people communicated often via documents and tickets, and meetings largely felt purposeful and efficient. It is possible. And not just at startups of a few hundred people, but at large companies. Having seen it work, I am always trying to lead my team there. This book guides you on how to undertake such a transformation.

Note: The book may be written in parts with an assumption that a company overall wants to tackle it’s meeting culture as an organization, but I found that even as a manager new to the org without much formal authority or informal leverage, that there were things I could do to improve some of our meetings.

Better Meetings Require Thoughtful Design

The central claim Hinds makes in this book is that meetings should be thought of as products - the most important, most expensive, and most overlooked products in your organization. And meetings don’t just need a small tweak to work well, they need a fundamental design overhaul to rebuild your meetings from the ground up.

She organizes the book around a 7 principle framework to help you tackle your company’s meeting culture. She recommends exercise, scoring systems, automations, and real company case studies from companies like Amazon, Apple, Atlassian, Gitlab and more. Here are the seven in brief and how they resonated with me from the platform product / data leader perspective.

1: Volume — Cut Your Meeting Debt

Most teams have “meeting debt” - think of this as recurring meetings that have outlived their purpose. Meeting debt is like tech debt, you’ve just got to tackle it. And you could systematically chip away at it or you could do what she recommends in the book and have a Meetings Doomsday where all meetings are cancelled, you audit recurring meetings for impact vs effort and only add back those that earn their place. I did not do this, not because it didn’t sound awesome, but because I’ve only been in my organization for six months and this felt drastic to recommend as a newbie.

Data Platform Product angle: Platform teams are dependency magnets - we accumulate meeting debt faster than anyone because everyone wants our voice in the room on their operating cadence (across the whole business).

2: Measurement — Choose the Right Metrics

My favorite concept she introduced was ROTI: Return on Time invested. Asking attendees of a recurring meeting to rate on a 0-5 scale whether a meeting was worth their time. And then a follow up question of “What would it take to improve your score by one point?”

This is so simple and so powerful. As a former survey researcher I was really impressed — it’s actually tricky to frame questions in a way that allows people to share constructive feedback without priming them or biasing them toward “oh it was great.” I think this 2 question sequence could be done quarterly by the meeting owner, imagine how much better meetings would be if we just habitually talked about what was working or not about the format, length, attendee list, pre-reads, agendas, etc.

Data Platform Product angle: As a PM you manage a lot of recurring meetings. Whether with key stakeholders, internal planning cadences, daily standups, etc. Some of these meetings are probably better than others - ask your attendees, make a few tweaks. This is probably the highest immediately leverage you can tackle on your own.

Note: the book introduces some other metrics and lots of it felt like it would only be relevant if you were tackling meetings at the broader department or org level. Since I was only looking at this more locally I didn’t find these parts as relevant, though still interesting to hear how bigger organizations use data to transform meetings.

3: Structure - Become a Meeting Minimalist

In this section of the book, Hinds is trying to help us get clear on exactly what each meeting needs and be focused on shrinking it to it’s essential parts:

• Agenda

• Attendees

• Duration

• Frequency

Can you reduce the meeting size on any of these vectors? Do it. Habitually aim for less, not more. I loved the point that she emphasized that some cultures over-invite attendees so folks feel included, but it’s actually more respectful to not ask for someone’s time just to keep them informed. Keep the meeting minimal and broadcast the outcome async.

Data Platform Product angle: This is easier to manage when you own the meeting. But what about the meetings others include you on. Try pushing the meeting organizer gently when your role isn’t clear. Hinds has a verb-noun agenda framework that I think is really useful here - try getting to the intent of the meeting in a single sentence verb/noun agenda combo (e.g. Approve patient encounter schema). If you can get clearer on the intended outcome of the meeting it’ll become clearer if you have a role to play or if you can decline gracefully and ask them to just let you know the outcome of it.

4: Flow - Apply Systems Thinking

This is one of my favorite insights Hinds introduces: too many bad meetings isn’t just a calendar problem, it’s a symptom that communication systems are broken. When information is scattered, channels are missing, and communication systems and culture are suboptimal, people use meetings to fill the void. Think about how often when there’s a gap someone says “I’ll grab time on your calendar” or “I’ll follow up with a meeting for us to discuss this.” The default is always a meeting, unless you create something better.

When I worked at Sourcegraph our team was globally distributed. My developers were in Mongolia & India, other PM team members I worked with were scattered across the US and Europe. Yet communication flowed well, because meetings weren’t the primary mechanism — Slack conversations, documents (proposals, tech designs) and Github issues were used first whenever possible. Meetings were used in a more targeted way because they were expensive and difficult to schedule due to our distributed hiring. But even if your team is co-located (like the hospital I work for now where most people live in the metro area), meetings are still expensive and difficult to schedule for larger groups.

Hinds recommends you standardize communication tools, default to async, and design for distance (plan for the fact that not everyone can be in the room physically).

Data Platform Product angle: Technical teams don’t lack communication channels, what you may lack is an agreed upon information architecture. What belongs in Teams/Slack vs Email? Culturally when do we reach for pre-reads, agendas, and formal artifacts versus conversations? How do we configure out environments to automate and help information cascade to the right groups? At Sourcegraph they didn’t just use Slack, there was a cultural expectation to discuss things in public channels instead of private DMs (unless a sensitive/legal conversation needed to be private) — having conversations in “public” helps create more of that organic encounters you get in a physical office. Private DMs create silos, literally. Work with your team to develop and reinforce norms among your systems.

5: Engagement - Prioritize User-Centric Design

I loved this angle - when we build products we aim to apply principles of user centered design. What if we thought of meeting attendees as users and designed the meeting for their experience, not just our agenda? What can we do to drive engagement and think about their JTBD in addition to our own?

Investing in engagement helps our meetings produce better outcomes. We wouldn’t ship a product without thinking about the user experience and we shouldn’t design meetings without thinking about it.

Data Platform Product angle: This has felt most intuitive when I’ve been doing roadmap presentations. Presenting the roadmap to my boss is very different than to business executives and that is very different still than presenting it to individual data professionals across the org. When I formally present I always think about the end user’s mental model and how I want my message to land and engage all of us in aligning on the next step / outcome I want. But I think I could do better, and I’m sure you could too, bringing that same thoughtfulness to other recurring meetings on my calendar. And don’t forget that includes your developers, analysts, data scientists — how does product make the meetings we convene internally for our team valuable and efficient for each persona?

6: Timing - Get Your Meetings in Rhythm

This principle was very timely for me ((no pun intended) — as we just launched a new quarterly planning process at the hospital and it upended the rhythm of all of our meetings. The key point Hinds makes here that we need to sync meetings with the natural rhythm of work — meeting timing is a design decision. Your organization will have natural organizational cadences, like project lifecycles and fiscal calendars, making sure your meetings align with those broader cadences acts like a tail wind creating for creating urgency and focus.

Data platform PM angle: The product managers context switch all the time by nature of the work. We are talking to the team about what they are building now AND doing discovery for what we are building next while also talking to the broader org about a 12 month roadmap and hearing the C-suite share the latest 5 year strategy. That is somewhat unavoidable.

But what is avoidable is creating whiplash for our team. Thinking carefully about when we bring work to the team and when we pull them into discovery (versus protecting their execution state). Teeing up our capacity planning at the right time to be ready to respond to quarterly planning requests (data platforms are one of the biggest dependencies in these commitment cycles). Having PRDs ready for tech lead review BEFORE sprint planning so we can give final feedback before they break the features down into stories. Making sure planning & retro are aligned across our squads so handoffs work cleanly between engineering, data science, and analytics, etc. We’re still in the midst of figuring this out given some changes in my current role, but the ones that have clicked into place feel so much better than the ones that are still out of sync. Get your meetings in a rhythm.

7: Technology — Innovate and Iterate

Obviously this space is moving fast. Small changes can support your meeting transformation:

• Visible meeting timer to help people stay on track

• Whiteboard tools with agendas and decision frameworks

• AI notetakers & summarizers so you can

  • Keep the meeting small, but distribute context effortlessly after

  • Keep a paper trail for yourself of items debated and decisions made so you can look it up (with AI) later

• Using Copilot for calendar audits and ongoing meeting hygiene

I am a fan for planning how you’ll use tech to support your transformation, but there is no magic wand that you can just toggle on and problem fixed. Interestingly, coming from someone working in Silicon Valley, it’s telling that Hinds doesn’t over-index on technology. Meetings are an org challenge and a transformation of how people collaborate, technology can support that, but we should be wary of tech that overpromises or gets in the way of that transformation.

In Summary?

It’s a structured very engaging read. I personally loved listening to it on audio and but wish the author had created some supplementary materials for tips/cheat sheets because it’s hard to ‘reference’ an audio book. But her narration is very engaging - you can tell she’s a great presenter and incredibly passionate about this work. Maybe buy the book and check the audio out from the library so you can get the best of both worlds, or be like me and buy both, problem solved!

In general, I don’t have much of a critique for this book, only mild caveats.

1. Some of the learnings aren’t really possible to apply if you aren’t in a senior leader who can tackle things for the entire organization at once

2. The case studies were very silicon valley centric, I would have loved to hear more learnings from her work implementing these transformations at established fortune 500, government, or older established organizations like my hospital. What is hard to implement in certain cultures? How does she approach the problem differently in these environments?

3. I wish I had those PDF reference infographics or a workbook to go with the audiobook

That’s it, honestly, it’s a very efficient and effective learning tool. I loved it and can’t stop talking about it.

You Deserve Better Meetings

I’ve summarized some of my favorite points, but there is so much more. I only skimmed the surface here. Some other things I loved that she covers (some her own frameworks, some case studies and research from others):

• One In, One Out attendee rule

• No spectators, just stakeholders

• DRIs (Directly Responsible Individuals) for action items - Apple

• Disagree and Commit - Amazon

• 3 month meeting expiration dates

• Amazon 6 page memo / study hall model

• 4D CEO Test (Debate/Discuss/Decide/Develop + Complex/Emotional/One-way Door)

It is really worth your time to read it. Somehow Hinds has taken one of the things that frustrates and eludes so many orgs (bad meetings) and written a very good playbook on making them better.

Don’t settle for bad meetings; stop thinking “Oh I wish our [CEO/VP/Managers] would do something about our meeting culture.” You can do that something. Yes you, no matter your role.

I read this book, called a workshop with the other leaders on the data team, showed up with a Lucid chart and some open questions and followed the dialogue.

It helped; it kicked off some impactful changes right away and there’s more we can (and will) do there. Colleagues thanked me for running it and said they were so glad I prioritized starting the conversation.

Would I also love if our hospital CEO read this and wanted to do a hospital wide overhaul, yeah I would flipping love that. But I’m not waiting for that; I have meetings I can fix in my little sphere of influence and so can you.

Your Best Meeting Ever is a five star read from me. ⭐️⭐️⭐️⭐️⭐️

If you read it, I would love to hear your thoughts!

Confession: May’s session was just one person. Since I just turned on paid and most folks can’t make it each month it’s a pretty small crowd for now. And for May just one person. We ended up doing a full hour of one-on-one coaching, and it was honestly great.

If office hours stay small like that, I’m not mad about it. Honestly, I wish I’d had the opportunity to have a monthly chat with an experienced data product manager when I was starting out. Even now, my coffee chats with friends in this niche are some of the most validating and productive conversations I have on the topic.

This is a paid-subscriber feature, and at $8/month, that’s a pretty good rate for small group coaching. In fact it’s the only way to get 1:1 or small group access because I don’t have the bandwidth for coaching right now. If you’ve been on the fence about upgrading, this is a good reason. The second deep dive should be hitting soon for paid readers this month. The rest of my content remains free so no matter what I’m glad you’re here and love the conversation.

All sessions are 9:00am MT on Saturday. Dates and RSVP links are below the paywall.

Read more

There’s always some element of chance and luck in careers. Meeting the right person, having access to the right upskilling opportunities, being on the market when a particular role opens up.

But a career is how we spend 40+ hours of our weeks - we should try to minimize how much it’s driven by chance and plan next steps with intention. Have a plan, work the plan, seize opportune moments.

The career trajectory for data PMs is also mysterious. The role itself hasn’t existed very long, AI is transforming the ways both data & product people work, and so the way forward is very fuzzy. Data PM work is sprawling, abstract and hard to distill into distinct career laddering steps; like our digital PM peers, I’d say much of seniority is about expanded scope, ambiguity, and responsibility. But that still leaves a lot open to question. And when you get to the top of the Data PM career ladder, where does it go from there?

Data product management is a hard role to self-assess against - it’s a mix of soft skills, technical fluency, stakeholder engagement, and strategy. There’s no clean skill list, yet I can tell you when I interview I know exactly what I’m looking for and how to assess for it. So there’s a profile there, but it can be really difficult to evaluate your fit and areas for improvement.

So I thought I’d share how I’m guiding my team through this - provide an AI guided self-reflection exercise you can work through to help you understand yourself and the data PM career landscape better. Whether you are already a data PM or looking to transition from another role break into it, this framework still applies. It’ll help you explore:

• What do I want from my career in 5 years - and what even are the options for someone in my role?

• What are my strengths and weaknesses? What strengths should I lean into and what weaknesses should I shore up (or avoid paths that require them)?

• Which capability areas should I focus on this year?

• What are some S.M.A.R.T goals I could set for the year?

• How can I advocate for managerial or organizational support for my goals?

This framework really works. I did it with my last team and I’m doing it with my new one. It’s genuinely so useful to take a break from the tactical execution and the business demands and reflect on what you want for yourself — and make sure you are taking steps to move in that direction. The AI prompts really help with that blank page side of self-reflection and if your AI has visibility into memory of your work it will be even more powerful at helping you see strengths you didn’t realize you have. Leveraging the low stakes dialogue of AI to explore options is a perfect sandbox to prepare you to talk to your leader about your goals in a constructive actionable way.

So let’s dig in.

AI Makes Self-Reflection Easier

Something I always note in discovery is how much easier it is to get someone to respond to something than to get the to tell you what they want. I get much clearer answers when I have them brain dump and give me as much context as possible and THEN I say something like, “So it sounds like you want a morning push notification to your phone with these 10 metrics and a signal of whether any of them are out of range and require action?” Then the stakeholder can say “Yes, exactly, but I still want the desktop dashboard so when I get to the office I can drill through, explore, and understand more of the nuance of what’s driving things.”

That loop — unfiltered brain dump about what I’m thinking → insightful summary & synthesis (+ follow up questions) → my refined corrections, more brain dump, expanded context, confirmation of what resonates….that’s the cycle I find so powerful about brainstorming with AI.

It works human to human in discovery and it works similarly well in brainstorming sessions with your AI Copilot. Add to that an AI powered tool that has memory of not only the conversations you’ve shared, but also access to all your Teams messages, meeting transcripts, and documents you’ve drafted, etc… and you have a little shadow buddy who has a ton of context on your ways of working and can add its own insights on your behavior to the brainstorming conversation.

So for this exercise we’re going to ask AI to act as an interviewer — it asks the questions, you react. It’s way easier than staring at a blank page. Give as much context as you want in addition to the prompt given and keep talking until you are happy with the direction things are heading.

The prompts here work with any LLM - Claude, Copilot, Gemini, ChatGPT. (Note: I used Copilot at work and Claude here to illustrate.)

The Four Step Career Reflection Framework

The sequencing here is deliberate — each step builds on the last, so make sure you really invest in a great result from step 1 to set the rest of the exploration in the right direction. You can’t set good goals if you don’t know where you are going & you can’t identify gaps if you don’t know the target you are shooting for.

From direction you’ll assess what might be holding you back from that trajectory, pick a few focus areas, and get some specific goals set.

Plan to invest some time — the AI brainstorming moves the process along faster, but you can’t delegate your thinking here. It’s personal. AIs suggestions and questions may trigger some ideas, remember some scenarios, explore pros and cons of various directions — but it doesn’t know YOU and what you want.

I did this activity myself as I was building it for my team, making sure the prompts worked and it uncovered some interesting tensions in my career direction (the pull between strategy & people leadership and enjoying the deep problem solving of data & AI product) and some ideas about how to manage my journey forward considering my preferences. What I realized was that organizational gravity and market demand might pull me hard in one direction and I may have to advocate for some non-standard aspects for my role in order to head the direction that excites me most.

I’d also recommend reaching out to others to discuss what you uncover. That could be your people leader, team members, a mentor, online friends in a community — it’s a great opportunity for soliciting honest feedback not tied to a formal review cycle.

Step 1: Target State - 5 Year Time Horizon

For many of us, this is the hardest step. Figuring out where you want to be in five years. If you are junior on the PM ladder that might just be more seniority. If you are in another role it might be making the jump and breaking into product and having a few years of experience under your belt. If you are in data product but feeling the pull to be more directly in AI it might be shifting into AI product or even becoming a tech lead hands on again. Or maybe leadership is appealing. Regardless, in five years your career could take a lot of directions, that’s the point in thinking five years out. It’s far enough that a lot could happen, but not so far out that it’s just way too abstract to predict.

To explore this, we want to approach it from a few angles:

What type of decisions do you want to be making daily? This gets at the substance of the work, not just the title.

What kind of problems do you want to own end to end? Is it building AI prototypes? Is it owning the consumption layer of the data platform stack? Is it org design and puzzling about building a high performing data team?

Who are your peer group in 5 years? So sneakily useful. Since stepping into data leadership my peers are now other managers, directors, and sr directors. I’ve worked at a local Utah company undergoing hypergrowth (my peers were energized, smart, kind people who worked hard but much more 9-5 than Silicon Valley). I’ve worked in a Silicon Valley series C startup - globally distributed workforce, insanely talented peers, writing centric very dev minded culture - brilliant, distributed, extremely diverse peer set. And I’ve worked in medtech & now health care in established larger companies on the data platform - my peers being the enterprise data team builders - getting things done. Each peer group really defined so much of my day to day. Think deeply about your ideal peer set.

What do you want to be known for? Reputation, identity, not just skills. For me - it’s about being at the forefront of data platform product practice; building platforms that scale, are AI ready, and leading a cohesive team. I want to be known as a hands on practitioner who also tries to share learnings online (like here!). This question can really help you narrow down in some ways what you don’t want to be (I do not want to be a generic data leader, I LOVE product and want to stay heavily engaged in strategy.

What work do you want more of vs less of? Knowing what energizes and drains you is key in building the right career.

Of course you could just journal on this yourself, but I find asking AI to conversationally interview me and explore really pushes me further until the direction becomes really clear. By the end you want a clear directional statement like:
In five years I want to be the person who owns the semantic infrastructure & context layer driving data and AI operations at a large US firm in a mission driven company. ← Not my statement, but you get it….

Here’s a Claude prompt to get you started:

Help me think through the various directions I could take through my career over the next 5 years. The decisions I want to be making daily, kind of problems I want to own, who my peer group will be, what I want to be known for and what work I want to more or less of. Use your observations of me and ask interview questions to help me explore various directions, let's keep it very conversational back and forth and not document/proposal driven in format. Ask questions, present trade-offs, etc.

Before you know it, you’ll be off down a rabbit hole with Claude:

Claude is actually amazing at pointing out patterns in what you are saying, raising insights like “You’re energized by the discovery-to-build loop..” and then pushing with a question to help you think more deeply like:

In this example with Claude it kept probing me:

• Do you want to stay in a hospital system?

• Would you like working for a vendor building AI solutions for healthcare systems (but located outside)?

• What does your current hospital's appetite look like for this kind of experimentation? Is there a door you could push on internally, or does it feel like a dead end there?

It may end up going FAR down the path, so once the direction is feeling clearer, bring it back to the end point of this step with a prompt like:

Before we jump into a tactical plan, can you help me write a 5 year statement for this goal? “In five years I want to...”

Claude will recommend something and you can refine together until you have something useful like this:

Now my alter ego Sr. Analyst has a goal for 5 years from now….seemed a little overly ambitious to be leading AI strategy from Sr. Analyst so we landed on this:

"In five years I want to be the go-to expert for clinical AI at my health system — known for finding where technology can remove friction from clinical work and seeing solutions through from idea to impact. I want a track record of deployed AI solutions that measurably reduce burnout and make care smoother, and strong enough relationships with clinical leaders that they come to me with their hardest problems first."

And with that we are ready for step 2.

Step 2: Strengths & Gaps - Finding a Focus for Improvement

Armed with more clarity about what you want to do in five years, you certainly have some gaps to fill. This step helps you surface what’s already in your skill set and what’s missing — with a focus on the skills that will be most critical for where you want to go.

A generic self-assessment will just overwhelm you and not every gap needs to be filled. I am not skilled at utilizing AI agents from within an IDE, configuring my custom harness, and managing a dev environment, for example. But I don’t need to be for my current role or the direction I’m heading. You want to anchor your reflection in items that are necessary and actionable.

Strengths First

Starting with gaps might be demoralizing and it could skew the whole exercise. Understanding your strengths isn’t just a confidence boost, it tells you what to lean into, what makes you distinctive, or where you may already have a competitive advantage you don’t recognize because it’s so intuitive.

That said, data product management is a tricky role to self-assess against. The job is so wide and so many of the skills can be tricky to articulate. The AI prompt will help you brainstorm the right skill categories. And if you use the AI tool at work, that sees your actual work conversations and has memory of your engagement together, it can actually be pretty insightful at pointing out strengths it can observe directly in your work. It may surprise you.

When considering strengths we want to be looking for things like:

What have you consistently gotten positive feedback on? External signal, not self-perception. I’ll never forget a boss I had years ago who said to me “You have great technical skills, but it’s your soft skills that really make you stand out.” He was right when I reflected on it and when I leaned into product and later leadership those soft skills become more and more valuable. Think back to compliments and guidance you’ve gotten on your work. Or ask trusted friends and colleagues for help.

What feels easier for you than for others? When you are in a meeting, what connections do you draw? What deliverables are you able to whip out without as much effort? What tasks could you essentially do blindfolded, in your sleep, without stretching yourself much? For me - presenting doesn’t make me sweat most of the time, as long as I’m prepared (and it does take time to prepare well) I enjoy presenting a lot; I know not everyone feels that way.

Where have you driven the most impact in the last 6-12 months? Ground your strengths in recent evidence? Have you built stronger relationships where things were shaky before? Have you shipped things that were particularly tricky? Have you paved the way for new technical patterns that now make certain tasks much easier for you and others? Think it through.

What type of work energizes you? Energy isn’t just a signal of preference, it can be a signal for what is enjoyable because it comes so naturally. Not all things that we are good at energize us. For example, I’m great at small talk and meeting new people, but I will come home from that type of event and crash because I’m an introvert; my husband always says others can’t tell because I make it look so easy, but man it burns me out. If I was in sales doing small talk and pitching all the time I would be miserable.

Now that you’ve got a few ideas, here’s a Claude prompt to help kick it into high gear. Either use the same chat from Step 1 (5 year goal) or include it in the prompt to help guide it:

Help me think through my professional strengths. Use your observations of me and ask interview questions to help me explore various directions with a focus on the skills critical for my current role and future goals. Let's keep it very conversational back and forth and not document/proposal driven in format. Ask questions, present trade-offs, etc.

At work I did this in Copilot which has ALL my work context and it shared really useful insights. For this example I ran this using my Sr. Analyst alter ego in an incognito chat so it couldn’t pull from past observations, but still was able to get me thinking:

It got me thinking, when I was an analyst what was I known for? Claude helped me translate my narrow thinking into something more generalized and skill level. I gave it this:

And it pointed out that the first is about thinking clearly under uncertainty…and…that’s as much a communication and reasoning skill as it is a data skill.

And on the second…that’s about being comfortable with imperfect information and having good enough instincts to know when something is ‘done enough.’

Eventually you’ll get to a list you feel good about - highly relevant & affirming. Time to switch to the gaps.

Dig Deep on the Gaps

Deep breaths, no one likes reflecting on their weak points. But lets normalize weakness - we’re human, there will always be room for improvement. Gaps aren’t a sign of failure, they are a sign of what hasn’t been developed yet, plain and simple.

Using AI here really takes the edge off. It’s much easier to have AI provide editorial feedback on my Substack articles than if I sent each draft to a friend. It’s not relational, it doesn’t carry weight or judgment, it’s software. Software that picks up on patterns and can be insightful, but still just software. And one that can hallucinate so we’ve always got that in our back pocket too.

Here you want to understand:

What skills are required for your 5 year role that you don’t yet demonstrate?

Where have you struggled or avoided ownership? I love this question, I’ll give you an example from my personal career journey - python, I wasn’t uninterested in learning it, but I just couldn’t get myself to prioritize it. I knew SQL and some R and got by. When I was considering data science I realized the fact that was I avoiding python was a signal. To this day - I’m very interested in solving problems with AI (opportunity discovery), much less interested in solution design and execution. Choosing technical product management was a much better choice. What are you avoiding?

What feedback have you received but not fully acted on? Feedback is a gift. And sometimes we set those gifts aside and ignore them. Occasionally feedback is ill intentioned and not valid and we can genuinely discard it, but if someone is giving feedback from a place of care and genuine investment in helping us improve - why haven’t we acted on it? What does that tell us?

What environment exposes your weaknesses? Some gaps only show up in specific contexts. For example, I am very goal oriented, but I do not like the idea of any sort of unpredictable quote based comp. Some people in sales, customer success, or fundraising are very motivated by this structure; for me it makes me anxious and I would hate it. Being in jobs with a bonus/variable component is fine as long as it’s not the majority of the comp.

Now it’s time to call on Claude to help us stick with the hard work of gap exploration. Here’s a prompt to get you started:

Help me think through my professional weaknesses. Use your observations of me and ask interview questions to help me explore various directions with a focus on the skills critical for my current role and future goals. Let's keep it very conversational back and forth and not document/proposal driven in format. Ask questions, present trade-offs, etc.

Again Claude will push and ask follow up questions to help you identify areas for improvement like

By the end you should have a list of areas to improve on, like the strengths list above. So armed with your strengths and weaknesses it’s time for step 3 - setting some goals.

Step 3: Annual Goals - Near Term Horizon & Specific Focus

Now it’s time to make a plan for action so this isn’t just a fun one time reflection exercise, but actually something you and make concrete steps on. So we’re going to tackle goal setting in two steps.

Step 1: Identify 3 capability focus areas from your direction + strengths/gaps.

Here you want to pick skill domains, not specific goals. You might decide to focus on things like:

• Strategic narrative & problem framing

• More structured discovery & requirements articulation

• Executive stakeholder alignment

• Applied AI use case design

You don’t want to get tactical yet, but you don’t want something so generic it’s like “Get better at stakeholder management.” That’s not very useful. Instead you want something like, “Executive stakeholder alignment - improve my skills in presenting a strategic narrative to VP-level audience”

And of course Claude can help with this too.

Given my 5-year goal and these strengths/gaps, help me identify 3 capability areas to focus on this year. Strengths I should double down on and critical gaps to prioritize. Help me think through specific examples of how these show up in PM work. Help me focus on capability areas that help change the scope of work I can handle — not too tactical. These focus areas need to be specific enough to goal-set against later. Help me understand how each applies to my long term trajectory. Let's keep it conversational and start from a broader set and narrow to the final three

Again Claude should respond with something broader you can react to and iterate as you narrow it down and tweak the wording.

Step 2: Year One S.M.A.R.T Goals

Once you have three you want to zoom in on, it’s time to take them from a broad focus area to something S.M.A.R.T. (Specific, Measurable, Achievable, Relevant, Time Bound.

Your chat already has so much context, you’ll probably get to some goal options pretty quick.

Help me develop 3-4 SMART goals from this focus area. Help me brainstorm multiple options and then narrow iteratively to a final set that appeals most to me

Document your goals, how they relate to your 5 year vision, what specific outcome or “done” looks like, how you’ll measure it, and when it’s “due". If you can align any of these to current projects/focus areas at work, note that as well so your goals align to your day job where possible. If you can’t find a work tie in, brainstorm a side project at work to propose or think of ways to do it in a spare time side hustle (like this newsletter! or my garden app). Once you’ve got your goals it’s time for the final step - get some support.

Step 4: Manager/Mentor Support - Don’t Go It Alone

You’ve done the hard reflection now, so hopefully you’ve got a supportive leader who you can share your vision with and ask for support. You can share as much detail as is helpful and you feel comfortable with. If you don’t have a supportive leader I’d recommend working with a mentor (friend, colleague, coach, former boss, etc). Regardless it’s a good idea to bounce the plan off someone else and if they are in a position to support you with feedback or connection to resources, all the better.

As a manager myself, the reason I run this exercise is to better understand my team and their goals. Everyone is so unique. It also opens the conversation for me to tailor constructive feedback from my observations in ways that is supportive of their goals and hopefully can feel collaborative and oriented on benefitting both them and the company — and less like an intense “I’ve got some feedback for you” session.

If you have an annual cycle to raise this in - perfect. If that structure doesn’t exist, ask your boss if you can use some time in your next 1:1 to talk about goals and some requests. Your boss may not be able to meet all your requests (budget may not allow or competing demands), but it’s definitely worth asking. Here are three categories to think about that your leader/mentor may be able to support:

• Opportunities to create: projects to lead, stretch assignments, exposure to certain groups or stakeholders. This is about expanding the scope of your work in ways that build the capability areas you identified in Step 3

• Resources: time allocation for learning, training or certification; shadowing opportunities. This might make you nervous, but honestly if a training budget exists and it benefits you and the company, bosses are usually excited to support this. If there’s no budget maybe they can brainstorm free resources that meet a similar goal or at least make space for you to do training you pay for yourself.

• Other support: mentorship (internal or connecting to an external person in their network), a more intentional coaching cadence with your manager, skill specific feedback on identified gaps. This improves the quality of your conversations.

And once again Claude can help you here. Brainstorm and test out the approach with AI so you show up to the conversation with your leader prepared with reasonable clear asks and not just a general “I want to grow more in my career.”

What specifically should I talk to my manager about for support and resources to help me achieve these goals? Help me think through opportunities they could create for me, other ways they could support me, and resources I might need — time, budget, access. Help me prepare a specific, confident ask for each of my three capability areas.

Conclusion

Well, you’ve got it - a vision you are excited about, a plan to talk to your boss about, goals to work on this year. One last prompt for you to wrap this up - have Gemini build you a vision board for your goals. First you are going to ask Claude to write a prompt for Gemini. Save it as your desktop background, print it out and pin it up on your wall, remind yourself daily about these goals and stay on track.

Help write a prompt for me for Gemini to create a beautiful, inspiring vision board image based on my career goals. Use:

My 5-year direction: [paste your Step 1 output here]

My three capability focus areas for this year: [paste your Step 3 capability areas here]

My SMART goals: [paste your Step 3 goals here]

Create a visually rich, cohesive vision board that captures the feeling and ambition of these goals — not just the words. Use imagery, icons, and visual metaphors that reflect the themes of [clinical AI / data leadership / stakeholder influence — customize to your goals]. The mood should be [ambitious but grounded / warm and human / bold and forward-looking — choose what fits]. Make it something I’d want to look at every day. Design it in landscape format suitable for a desktop background. Beautiful typography, rich color palette, feels personal not corporate.

Well, that’s all for now — Alex our analyst who wants to work in clinical AI - here’s her vision board.

I hope you’ll give it a shot. If you try this I’d love to hear what insights it brings up for you.

These office hours are very unstructured. Happy to:

• answer any questions you have,

• share what I’m reading and working on lately,

• discuss what’s in progress for the newsletter

• talk through my growing drafts + brainstorms with Claude

• what I learned building my gardening app Artemysia

It’s really up to you. This…

Read more

Though, this year I learned a lot building a few small apps for my daughter, most of my problems are better solved with automation, Claude projects, and building agents like Ada (^👇🏻).

In data platform, the interface is the final mile. Ninety percent of my work is top of funnel and back end — helping find out what users need and build the roadmap. Prioritize user needs against strategy. Doing discovery on specific issues we are tackling - research and PRD writing. Communicating with stakeholders and leaders. And overall, teeing up the work for others to execute. App interfaces belong to my analysts — that's their domain, not mine. Additionally, in many enterprises we just aren’t set up to vibe code yet — though I anticipate that will evolve. We are still delivering data experiences in Power BI, Tableau, and domain specific systems like the EHR. So vibe coding remained on the back burner.

When I finally did build something, it turned out to be exactly what you'd expect from a data PM — a data problem dressed up as a gardening app.

A Mission Driven Idea = A Switch Flipped

A week ago inspiration struck and I had an idea that would not leave.

My husband was putting my daughter to bed and my mind just starting down the rabbit hole. I grabbed my laptop and started working with Claude: making an overall plan, brainstorming the user journey, iterating on feature ideas, and of course, realizing all the DATA I’d need to pull it off. All of this before my husband finished the bedtime routine.

I became obsessed — spending hours of my free time on this app. Who am I?!

A Data PM Who Gardens An Absurd Amount

Well, who I am is someone who is fanatical about gardening. For over a decade I’ve been working on my personal garden, learning so much, and building friendships with my garden neighbors and online gardening community. There’s a lot of data involved — light requirements, watering zones, ecological regions, pollinator benefits, regenerative soil health, making compost, and so much more.

More specifically, I’ve become passionate about waterwise gardening that looks lush and beautiful but uses 50-90% less water than traditional lawn landscapes. My own garden aims to be an English cottage garden that is watered on drip irrigation once a week (twice for shrubs/trees) in our high UV mountain desert — a big gardening challenge! Transforming my yard has been such a learning journey and filled with so much joy, I’ve wondered — how can I spread the word that you can have a garden that looks like this for WAY less water than all grass?

How can I help more people see that you can cut your watering use by 90%, not mow anymore, deal with way less dandelions, and have your front yard look like this:

A Woman on a Mission

Why spread the word about this? Well, Utah is in a drought and it is worsening. This year we had the warmest winter on record and lowest snowpack we’ve ever had — Utah gets most of its drinking water from the mountains so that is a crisis and our state is already talking watering restrictions. Lawn is also way thirstier than people think. A quarter acre lawn yard takes this much water PER WATERING and during peak heat many people water 3 times a week.

We flipped our yard slowly over the last 5 years. First, we replaced grass with a veggie garden on drip irrigation, next we ripped out all the grass in the park strip for a perennial flowering garden, and last year we yanked out the last of the lawn in front for pavers, shrubs, & more flowering perennial flowers and grasses.

Since flipping my garden, I get a LOT of questions from friends, family, and random neighbors walking by. How hard was it? Did the HOA approve it (or am I a rogue gardener)? Does it really use less water? I’m always happy to share the good news.

One couple came by on Halloween to trick or treat and told me: “Your yard is our favorite, we copied your park strip down the street in our yard!” It made my day.

In my conversations with others, I noticed a recurring theme — many want to ditch at least a good chunk of their lawn, but they are overwhelmed by picking plants, making it look nice, and figuring out the irrigation. I do a fair amount of coaching and free planning to help spread the word, but my time and energy constraints limit my impact.

Then I realized… I could scale my reach through an app; and the ideas just poured out of my brain and into Claude, quickly developing into a plan and prototype.

The App - Artemysia

I thought, “What if an app could reduce the cognitive load of making such a big change?” The first feature I wanted to focus on is helping users visualize different gardening styles to see the variety of approaches you can achieve with waterwise garden design?

Some users might be able to tell what style of waterwise they want just off the images (Cottage, Great Basin Warm, High Alt Cool, and Zen - other styles to be added later).

But many users might need more help. And even within a style there are so many plants to choose from so I decided to create an experience that is fun and instinctual but helps the app get to know your preferences. So I built an experience where you swipe and vote on plant images like a dating app. Each image meets waterwise needs and is suitable to Utah and similar zones (CO, ID, etc). Under the hood each image has metadata on color, shape, specific aesthetic qualities, etc. Which each vote for and against an image it better understands what plants you are drawn to, revealing your garden style (like a buzzfeed quiz, but more grounded in data…)

Then once you know someone’s style, what you need is to get them to a plant list they could take to a nursery. With the insights you can easily mine the plant database and use an algorithm to recommend a full plant list (some shrubs, trees, many perennials) that could be mixed into a design. The engine isn’t as good as a designer, but it’s strong enough to recommend a balanced plant list that incorporates garden design principles like balancing shapes (mound, fan, spike), prioritizing plants with ecological benefits, avoiding any invasive species, considering bloom schedule balance, color mix, texture, etc. Like an easy button for picking a plant mix.

The user needs a little chance to refine the plant list. Not endlessly select, but able to nix anything they hate and the engine can recommend something that meets similar needs on the design.

Then comes the part that actually gets people excited enough to act. That plant list doesn't stay abstract for long—the user can create a before and after (based on a stock image or an upload of your own home) to see how those plants they love come together into a cohesive design.

Now, I’ve seen lots of people use ChatGPT or similar to reimagine their yard, but not in a data driven way that balances waterwise principles with aesthetics and bloom schedules and light requirements. It can’t just look good, it needs to be SMART. And that’s what makes it a data problem.

Gardening - A Data Problem

One of the things I personally love about gardening is it’s both mindful and analytical. I can problem solve why my leaves are turning yellow (iron chlorosis!) or finding the right plant for dappled shade under my tree (heuchera!), but it’s also calm and helps me be present and zone out.

The analytical part is also the challenge for beginners. One reason people like grass is it’s simple. Apply a spring, summer, and then fall fertilizer; water, weed and mow. You hardly have to think about it.

You might love the idea of a waterwise yard (and once it’s in, it’s just turn on the sprinkler system on a smart sprinkler schedule and weed). But getting to there can feel daunting. You start looking at plants and get excited and then overwhelmed. Heights, layers, different bloom times, will these grow in your zone, are they good for your dirt — some people on the internet are saying you MUST do natives for the pollinators — it’s overwhelming. Analysis paralysis.

It’s too many variables. So you give up.

But that’s a data problem.

I just need to know what you like. And the rest I can get pretty close using datasets with all those variables and a custom algorithm that balances the factors. It’s not perfect, honestly the early results are pretty promising.

A Closing Note - On the Name

I’ll come back to share more once the prototype is out, but in closing today I thought I’d share why I chose the name Artemysia. For one, picking an app name that won’t run into copyright issues was tricky. But secondly, because one day I stumbled upon this plant that I was shocked to discover could live in the hot Utah sun but looked like it belonged in the Pacific North West (SunFern Olympia - Russian Wormwood by Proven Winners, scientific name - Artemisia Gmelinii). Like the designs my app aims to create — it surprised me that it could thrive here on low water and look so lush and unexpected.

In the meantime, I want to get the first office hours session on the calendar.

The format is intentionally loose. We’ll meet on Google Meet for about an ho…

Read more

My career journey took me from data to product, where I learned from great product leaders about user centered design and applying product practices to my work. When I transitioned to a data platform I felt lost — what exactly is my product and who are my users anyway? As part of that work I developed an earlier stage of this platform persona matrix.

Understanding your users is the most important fundamental for data platform product managers. After all, your platform exists to serve them and the business, by reducing the pain points and friction they face as they engage with data. If you don’t understand them deeply, you’ll fail at building best in class solutions that are a delight to adopt.

Platform PMs must hold two strategic lenses simultaneously:

1. Business-responsive strategy: What does the business need from data now — the use cases, the data products, the urgent capabilities. It’s a challenge to find the most important work, and to prioritize, but it’s obvious your job is to help the business meet its needs today with the platform you have.

2. Platform strategy: Where are your users? Where is the technology? Where is the business heading? And how can you transform all three by building the foundation that helps move the business forward. This is trickier to solve for, but what is obvious is that it starts by deeply understanding your users.

In the best scenarios, you build the platform capabilities you need in support of the business priorities today - you trojan horse them in there as dependencies to deliver strategic work and incrementally build the platform around real use cases. But you can't rely on the trojan horse opportunity presenting itself often enough. Platform strategy requires a deliberate, forward-looking investment in understanding who you're building for — not just who's loudest today. Without a clear model of your users, their needs, and where those needs are heading, platform strategy defaults to gut feel or whoever has the strongest opinion about the tech stack. The personas and capability matrix in this deep dive are that model.

In considering the brevity of my first introduction to the matrix it was obvious to me there was more to discuss about how different platform user groups align to platform capabilities — how their needs manifest and the tension that creates for us as product managers building a roadmap that only has so much capacity. So much more to say, in fact, that after outlining it was obvious it was still too much for one article. So I’ve broken it into two:

1. Today’s post, which introduces an updated matrix followed by a deep dive on each persona with more detailed breakouts per cell, common misconceptions, and key insights.

2. A second post coming later this month — which provides exercises, a template, and a workshop outline to apply in your company. This will help you in comparing your current maturity and demands against the overall matrix.

As I considered what type of deep dive content I wanted to create, revisiting platform personas was an obvious target. The original version I threw together on a work trip as a quick artifact for that post. I've been wanting to go deeper. So let's jump into it.

Data Platform Persona x Capability Matrix

One of the biggest challenges in data platform PM is holding all of your users in mind simultaneously — understanding not just who they are, but how their needs map to what the platform actually does. This matrix is the tool I use to do that. It's an evolution of the four-persona version I introduced before — expanded to five personas and ten capability domains, organized into three clusters. Scan across a row to see how different personas relate to the same capability. Scan down a column to see one persona's full relationship with the platform. We'll go deep on each persona in the sections that follow.

The ten capability domains are organized into three clusters, each representing a different layer of what the platform does.

The Infrastructure Layer covers the foundational capabilities that bring data into the platform and make it ready for use — ingestion & integration, storage & persistence, and processing & transformation.

The Context & Trust Layer covers the capabilities that make data understandable, reliable, and safe — metadata & lineage, observability & reliability, security & compliance, and governance & stewardship.

The Experience & Enablement Layer covers how users actually interact with the platform — access & serving (including BI), AI/ML enablement, and developer & user experience.

As you read across a row, you're seeing how one capability plays out differently for each persona. As you read down a cluster, you're seeing the full layer of the platform through each user's eyes.

The matrix above gives you the map. The persona sections that follow below give you the territory — the misunderstandings, the key insights, and the patterns that show up across the rows for each user type.

Later this month I’ll publish part 2 where we'll go further: a heat mapping exercise, a tensions framework, a collaborative workshop guide, and a template you can take back to your team.

Read more

-Anna

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.

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.

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.

Subscribe now

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.

The Structural Dimension of Incentive Mapping | Adapted from concepts shared by the Author | Curated by Modern Data 101

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.

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.

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 verysticky. 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.

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.

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.

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.

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.

Apparently it has. We just hit 1,000 subscribers earlier this month, which honestly still surprises me every time I look at it.

So today I turned on the paid tier of the newsletter. The content you’ve seen so far — the off the cuff, spark of an idea, into full draft — will remain free. I’m committed to that being a wide audience and engaged community.

So here’s what’s new: deep dives and monthly office hours, both starting in April.

Paid deep dives

Long-form, practitioner-focused pieces that go deeper than what I can do in a free post. The first series is already in progress — a full framework for understanding your data platform users across five personas and ten capability domains.

I have considered writing a book, but with my personal time commitments I know it would take me two years to get all the chapters written and polished, and by then it would be outdated. I’d rather publish book-quality pieces over time so you can benefit from them as they’re ready. It’s a lot of additional time investment, so I’m turning on the paid tier for these to help me justify spending the time and to keep me accountable to bringing consistent value.

The goal is to publish pieces with more thought, structure, editorial value, diagrams, frameworks, and exercises. The kind of thing I wish existed when I was figuring this out. I’ll share a teaser post for the first deep dive series on April 1st. The outline got so long that instead of publishing it as a single post it’ll come out in sections throughout the month.

Paid deep dives will be periodic as I’m able to finalize them. The early part of each post will be free to everyone to give a sense of what it entails, but the bulk will be behind the subscription tier. If you’re ready to subscribe today — great. If you want to see that first preview post and then decide, it’ll show up in your inbox clearly marked as a paid post so you can opt in then.

Monthly office hours

A standing hour each month where paid subscribers can drop in, ask questions, think through problems, or just lurk and listen to what other practitioners are wrestling with. This one was actually a reader request, and I think it’s the right thing to add. I enjoy doing podcasts and reacting to host questions — and would love even more to just talk to other practitioners and brainstorm together on whatever is top of mind.

I haven’t decided on timing yet. Saturday mornings US time would be the easiest to avoid work conflicts, but I’m open to suggestions.

So that’s it — a soft launch of the subscription tier and a preview of what’s coming in April. I’m really excited about this and looking forward to your feedback as I keep evolving these ideas.

And to be super clear: free posts aren’t going anywhere. I’ll keep writing the same way I always have. Enthusiasm is the fuel behind this newsletter and getting to engage with the broadest data and product community is what I find most fun. I just think that for some of you, a more structured and action-oriented deep dive will be a useful complement.

If you’ve been reading along and this work has been useful to you — your engagement, views, comments, and restacks are genuinely so meaningful to me.

Followers, free subscribers, and now paid subscribers — I’m grateful for all of you. Thank you for being here.

~ Anna

Before getting to today’s post, a wanted to share a few links that may be of interest:

• Guest post I wrote went live last week over on : The Incentive Map Every Data Platform PM Should Draw - it’s a framework for thinking through how organizations incentivize people and how to build an understanding of those patterns to help you influence without authority. And the visuals turned out really fun.

  

• Data Product Management for Beginners on Super Data Bros with - we cover a gamut of topics related to data products - definitions, what value is, telling the value story of your team, about being user centric…and how I think about using AI as a data product manager

• What does a Data Platform PM actually do? webinar with on Data & AI Product Community (not a member yet? you can join here to get access to the recording, it’s free). We talk about strategic pressure on the platform, using strategic work as the trojan horse for platform extension, and thinking of yourself as a hotel concierge…it was a fun discuss I hope it help.

Without further ado - on to the real point of today’s post.

The moment a Power BI announcement stopped me in my tracks

Last week I ran across something from Microsoft that made me stop mid-scroll and do a double take.

A little background first. I’ve been a reluctant Power BI user. I came from Tableau — and even though Tableau has stalled a bit, that’s what I’m most comfortable with. I’ve been genuinely interested in more modern BI tools like Sigma Computing and Omni, but my companies haven’t had access. My last two jobs have been Microsoft shops, and Power BI was... fine. Fairly equivalent to Tableau, bundled, affordable. But no real wow factor.

And I had real frustrations with it. DAX feels confusing and I’m annoyed I can’t just use standard SQL, as a Mac user the lack of a desktop app is genuinely annoying, and the broader Microsoft Fabric ecosystem is so filled with jargon it just feels overwhelming to get familiar. It’s a lot to absorb when you’re already proficient in another stack and not sure the switch is worth it. And I’m not an IC analyst, so I’m not using it deeply, just trying to be familiar enough to develop opinions for BI strategy decisions.

So I’ve been lukewarm. Supporting the idea of it when users advocate for it and leaders asked why we’d need another tool when this is bundled for free! (Nothing is free…but their model shifts towards Fabric costs so it looks free from a license perspective…). So Power BI has just been there - lurking in the background of my mind.

Which is why the announcement caught me off guard.

When I saw signals that Microsoft was moving toward BI-as-code and agent-assisted natural language querying — I was intrigued - something Microsoft was doing in business intelligence that is actually innovative and forward thinking?Shocked, but excited - so I dug deeper.

The feature I stumbled across wasn’t that significant on its own. What caught my attention was what it signaled about trajectory. It’s just a file format change, but the implications are potentially transformative.

What changed - tl;dr

Microsoft is shifting the way it stores the files underneath your Power BI projects. They are moving away from PBIX, a compressed file format that contains a mix of true binary blobs (the data model, security bindings) and technically-JSON-but-practically-unreadable report layout files — encoded in UTF-16LE with escape characters that make them impossible to diff or edit meaningfully outside of Power BI Desktop. If you had a hard time following that - the old file format is opaque, that’s the take away. Now, they’re moving toward a new set of transparent file formats — PBIP, PBIR, and TMDL — that are genuinely human-readable AND machine-readable.

What’s that? File format changes are not the ground breaker you were expecting? Let’s dig a little deeper, because that shift matters more than it might first appear.

While these new formats still need to be originated in Power BI, once they exist, they can be modified as files, in code.

Which means you can introduce CI/CD.

You can introduce agents to help modify the JSON.

You can manage your BI logic programmatically rather than through clicks.

It completely changes not just the initial build, but how we maintain data visualizations, reports, and the semantic models underneath them — treating them as first-class code objects, the same way we think about dbt models or data ingestion pipelines.

It means humans can partner with machines.

It means agents can help.

It means it’s easier to debug and collaborate on components within models across teams.

It opens up a lot.

That said — this is very much a baby step. The limitations are real. So let’s get into exactly what this does so far. A little product manager breakdown of a small release that signals an important strategic pivot.

The old world: PBIX

One file type. A single compressed binary where everything is mashed together — the data model, the visuals, the queries, the relationships. All of it, in one opaque blob.

You can’t open it in a text editor. You can’t diff it in Git. You can’t see what changed between versions without opening Power BI Desktop. You can’t manage it as code.

Everything about it is difficult and opaque. To work on building or modifying an existing file there’s a huge learning curve; you need deep knowledge of the tool — what’s in which menu, how to write DAX, how things are structured, where to look when something breaks. It’s tedious in a way that compounds over time.

Collaboration is really difficult. What usually happens in the enterprise is that one person builds a project end to end - they alone know how they built it, what the intent is, what work arounds they had to do, etc. It’s a single point of failure. No shared codebase. No team-based code management. If we are lucky there’s a Confluence page or data catalog article that summarizes some of the context, bu often that doesn’t exist either.

The approach is not modern, it’s slow and brittle. And that’s a problem — because this is the final mile. You’ve done the hard work of building a data platform. You’ve ingested the data, transformed it, made it business-ready. And then you get to the reporting layer and it’s a slow, hard grind. Building visualizations, maintaining them, making tweaks — all of it takes far longer than it should.

That’s the world PBIX created.

The new world: PBIP, PBIR, and TMDL

Now you get three acronyms to learn, but also three much easier to utilize file types. Instead of one complex binary file, you now have a folder structure full of human-readable files. Two distinct layers, saved separately.

The PBIP - stands for Power BI Projects (PBIP) - now in preview.

The first is the report layer — PBIR, or Power BI Enhanced Report Format Each page is its own folder, and each visual inside it gets its own JSON file. Componentized, manageable as individual objects rather than one tangled blob. Merge conflicts become resolvable. Code review becomes possible. You can see exactly what changed when someone edits a report — down to a single visual.

The second is the semantic model layer — TMDL, or Tabular Model Definition Language; YAML-like syntax, human-readable. Each table, measure, relationship, and role gets its own file. Your DAX lives in plain text — readable, diffable, reviewable. Think of it as your data model as code — same idea as dbt models, but for the Power BI semantic layer.

Both can be opened in VS Code, edited, and committed to Git. [link: Microsoft docs on Power BI Projects overview]

What that means in practice: instead of one opaque file, you have a folder hierarchy that can be managed just like any other code in your stack. Like a dbt model. Like your ingestion code. Like your data quality checks. BI just becomes another extension of the codebase.

You can see exactly what changed when someone edits a report — down to a single visual, a single calculation, a single semantic model definition.

You can roll back changes without losing work, because everything lives in Git.

You can manage changes through pull requests. You can do peer review.

Peer review has been basically absent from BI forever. Most teams operate in ship-and-pray mode — build it, push it, hope nothing’s wrong, because one person owns the file and there’s no real review process. When I was an analyst I found this so stressful, after all I’m only human! When BI is managed as code, you get human peer review and machine peer review. That combination — humans and agents reviewing BI artifacts together — has real potential for raising velocity, enforcing best practices, reducing single points of failure, and moving from individual ownership to genuine team-based development.

This matters to me a lot as a data platform PM, because the BI layer is the final mile. It’s where all the cost and effort of building a data platform finally turns into value. Yes, we’re delivering more value through chat interfaces and AI models — but I’m long on data visualization and storytelling still being a huge part of how enterprises extract value from data. That’s not going away.

By increasing velocity and rigor at this layer — and enabling collaboration between humans and agents — we can deliver faster. Our people can spend more time on UX design, user research, metric precision, data quality, and advanced analytics. (Moving beyond descriptive at last?! Maybe.)

We’ve had real constraints here for a long time. Long learning curves. Limited tooling. Hard to get AI to help because the artifacts weren’t files. It’s been a complex, underserved problem space. Startups are working on it — tools like Evidence.dev are interesting — but enterprises are being told to do more with less and use what they already have. That includes leaders asking, “You already have Power BI in the Microsoft bundle — why aren’t you using it?”

My honest answer until recently was: I don’t have a great reason except I don’t love it, and the more interesting innovation is happening in startups.

Now my answer is different. There are still things I don’t love about Power BI. But it’s moving toward the agentic, code-first, best-practice-friendly approach I actually want to be working in. That changes the calculus. Maybe some of the other compromises are worth making now? You bet I’m talking to my team about our BI strategy and what we think this means for our company.

Current limitations — let’s be honest

This is a signal of an interesting strategic pivot, not a finished developer workflow. It’s in preview for heavens sake - it’s very new and the limitations are real and worth naming.

The biggest one: you still have to originate the report in Power BI Desktop GUI. You can’t start from scratch in code yet. For teams — or individuals — who are exclusively on Mac, that problem doesn’t go away anytime soon. You’re still spinning up a virtualized PC.

External edits also require restarting Power BI Desktop to reload. It’s not a seamless two-way workflow YET. Microsoft is clearly baby-stepping toward full code-first capability, and Copilot integration is presumably a big part of where this is headed — but we’re not there.

So this isn’t a “an entire modern developer workflow is now available in Power BI” moment. It’s more like: the foundation is being laid, the direction is clear, and if you’re making long-term platform decisions — like whether Power BI belongs in your BI strategy — it’s more compelling than it was a year ago.

Where things stand right now

PBIR became the default in Power BI Service in January 2026. Power BI Desktop follows in March 2026 — basically now, depending on your instance. Full GA for PBIP is planned for Q3 2026. More here.

[Placeholder: diagram / image]

Why this is a bigger deal than it looks

I’ve already alluded to this, but it’s worth being direct: this isn’t just a nice new file format. This is a change to the infrastructure layer — the foundation that determines how BI gets built, maintained, and scaled in enterprise Microsoft shops.

Software/data engineering best practices will soon be possible in the BI layer. Pull requests. CI/CD. Code review. Real version control. For the most critical dashboards — the ones that currently live in one person’s PBIX file, where if that person leaves, nobody knows how to maintain it — we can start treating those as shared, versioned codebases. Not everything needs to be managed this way. But for the things that matter most, we now have options we didn’t before.

It also means we can add more tests, more monitoring, more ways to catch when things break — which matters a lot when dashboards are driving daily operational decisions.

No major enterprise BI vendor has done this. Tableau hasn’t. The players doing BI-as-code today are AI-first startups — interesting, but hard to get enterprises to adopt as a third tool that needs its own procurement cycle, InfoSec review, and training investment. For enterprise Microsoft shops, this capability is already in the stack you have. You can start experimenting right now.

It also changes the training calculus. Until now, teams needed to go deep on Power BI’s UI — every menu, every quirk, every detail — just to be functional. That’s a steep ramp, and it’s a big reason teams push back and ask for something easier. As more of this gets managed as code, you can move toward a smaller group of experts who maintain things at the code layer, while analysts focus on what they’re actually great at — data storytelling, UX, metric precision, understanding what resonates with the business. You iterate faster in that space. You build more. You spend less time Googling why something isn’t where you expect it in the UI.

I don’t know exactly where the division of labor lands. But I know it opens up options — for teams, for skill development, for how we think about who does what in the BI layer.

My read on where Microsoft is headed

This is my interpretation, not announced strategy — but to me it seems obvious.

Microsoft saw the writing on the wall. Agentic, file-based management of BI is where things are going. People want natural language to visualization. The path there required making existing Power BI assets manageable as code. So that’s what they’re building toward — deliberately, incrementally, with real limitations still in place.

The current constraints aren’t really acceptable long term, but I’m not worried about that, it’s clear this is an incremental set of releases, headed towards a much more ambitious vision.

Once artifacts are files, agents can read and write them. Not just Microsoft Copilot — though if that’s what your company has licensed, great. Your dev team might use Claude Code, or Codex, or whatever’s been approved and procured for your environment. The point is: any agent your company has access to can now interact with your BI stack - not just M365 Copilot within the desktop UI. That’s a meaningful shift.

It also means the parts of Power BI that have been hardest — DAX complexity, tooling gaps, steep learning curves — become less of a ceiling. Machines can help blaze through the tedious parts. Teams can focus more on getting the metric right and getting the visualization right, and less on hunting through menus or debugging DAX syntax.

Of note: Microsoft also has an MCP server for Power BI — early, developer-facing, but real. Not ready for broad enterprise adoption yet — security review required, early days — but it’s worth tracking.

It’s going to be fascinating to watch how Tableau and the other enterprise BI vendors respond. My guess is we’ll hear announcements at the user conferences this year. Whether the actual releases keep up with the announcements — that will also be interesting to watch.

What I’d do if I were you

If you’re a Microsoft shop, put this on your roadmap. Not as a “drop everything and pivot hard” priority — but as a deliberate, staged investment.

Start with an honest assessment of where your team is. Do your analysts know Git? Can they read a diff, resolve a merge conflict, submit a pull request? Do they know how to modify files outside of a GUI? If not, that’s the starting point — and it doesn’t have to be dramatic. Even just committing files to a repository as a backup is a first step. You build from there.

Find your most advanced analyst or analytics engineer — whoever has the most engineering comfort — and have them prototype this on something low-stakes. A simple dashboard, not in production. See how it feels. If it goes well, move it to something real but not your most critical report. Learn before you scale.

Then start thinking bigger. What does this mean for your semantic layer strategy? If you have dbt or a Cube layer upstream, how do TMDL files interact with that? What does this open up or complicate for your data platform long-term? These are architecture questions worth getting ahead of now, before you’re making decisions reactively.

And if your organization doesn’t have a BI strategy — if different departments are running different tools, nobody has made a call on standardization, no-one really knows what the official tool of choice is going to be — this is a good moment to have that conversation with leadership. Not just about file formats. About long-term direction. Is Power BI the platform? If yes, this is a compelling reason to lean in. If the answer isn’t clear yet, that’s the real work to do first.

The upskilling investment only makes sense if Power BI is part of your long-term strategy. That’s a leadership call, not a tool decision. Get alignment first, then invest in both tooling & skill evolution.

The teams that start building these muscles now will have a meaningful head start when the agentic capabilities fully arrive. That’s not hype — it’s just how platform transitions tend to work.

A few reasons I wrote this

First — it genuinely stopped me. I immediately went looking for a YouTube walkthrough, started asking Claude questions, and told multiple people at work about it that week. “Have you seen this? This is exciting.” That doesn’t happen often for me with product announcements.

Second — and maybe more useful to you — I wanted to show in something close to real time what it looks like to evaluate a platform announcement as a data product leader. How do you break it down? What does this signal about the vendor’s long-term strategy? Does this change anything for you? What parts of your stack does it touch? Who would have to change their behavior if you adopted it? What’s the mindset shift, what’s the upskilling, what’s the conversation you’d need to have with leadership?

That’s platform strategy thinking. Not “here’s the announcement, here’s what it does” — but “here’s what it means, here’s how I’m processing it, and here’s what I’d actually do with it.”

I want to be clear: I’m not the decision-maker here. You probably noticed I kept saying — talk to engineering, talk to data leadership, get alignment before you invest. That’s intentional. But you don’t have to wait for someone to hand you a decision to start forming a view. You can see something promising at a system level, do your research, pull together an opinion, and bring it to the right people. “Should we prioritize this? Should we have our BI strategy conversation? Should we be looking at Power BI more seriously than we have been?” Be the one who convenes the discussion — use the announcement as an anchor to provoke discussion.

Most news releases don’t catch me. A lot of what flows through my feed gets a quick “interesting, not relevant to me right now” and I move on. I’m glad to know what’s happening in the industry, but most of it doesn’t change anything I’m doing.

This one did — because it was Microsoft, it was BI specifically, and it represented a meaningful shift toward BI-as-code in an enterprise product my organization actually uses. That combination is rare enough to pay attention to.

Let me know if this kind of post is useful. It’s a little different from what I usually write — less framework, more “here’s how I actually think through something in real time.” Happy to do more of it if it resonates.

• Finance has quarterly board reporting coming up (required, non-negotiable). The analyst who owned this reporting just left the company and when they opened up the notebook they discovered it’s not just some metric calls, it’s poorly documented spaghetti python that seems to be doing a lot of data pipelining too—and it won’t run. Can you fix it?
  Operationally critical, not strategically prioritized - siloed tech debt back to haunt us all

• Sales desperately needs better reporting to guide quarter close. They have a prototype for one market, but it was built manually, scrappy, and no pipeline exists to scale it. They have found it invaluable to have a data model that helps them see which deals are in the pipeline, what the blockers are, and to help them focus on closing just the right amount of deals to hit their targets without stealing from next quarter’s cash flow. They want a model that scales that helps them “land the plane” right on target every quarter. It’s the CRO’s top priority - like drop anything else they are asking for an focus on this.
  Critical to leadership, strategic, but late arriving and urgent

• Marketing realizes they want a CDP. They have an agency saying they can build it for them fast (for $$$ of course) and procurement told the they have to talk to the internal data team about why we can’t just build it without an agency. It seems wise to avoid undue cost and to ensure alignment with overall architecture, but a CDP build will require significant dedicated resources. And they don’t want to put any of their other project timelines at risk.
  Cost avoidance, ties to long term marketing strategy enablement, but significant investment of labor that you have no capacity for. They are saying it is critical for the brand relaunch, but it’s a massive build with no clear capacity source.

So what do you do? Do you pivot right now, push other items in flight into the backlog and hop right on that financial reporting? You don’t have any other big work for sales right now you can swap out to create that capacity - it would have to come from competing work from other leaders. And the marketing thing feels like a huge beast to tackle.

Years ago I was at a total loss for how to apply a prioritization framework to scenarios like this. I worried the team was getting burned out, the business thought we were always “too backlogged/slow” and everyone thought their things were urgent. I’d try to juggle timelines and see if we could squeeze everyone in, but the that only works for short gains - long term you have to have a way to say no to what is less important and accelerate what is.

The business needs clarity on what we can deliver (and when-ish)

The engineers need stability, limited context switching, and to not constantly be asked to overextend themselves.

You need to manage the underlying tension of helpful agility vs destabilizing whiplash. And deliver that clarity & stability via an organized prioritized backlog.

But what is “important” and how do you figure that out?

Everything about prioritization got easier when I started aligning work to the company strategic framework (OKRs, AOPs, any sort of explicit hierarchical framework). Even if it is vague in some areas or incomplete, it completely changes the game when you can talk to the team about your roadmap & priorities in terms of company strategy.

If your company doesn’t have such a clearly articulated strategy, I have another article about that:

But this article shows how to operationalize whatever hierarchy you have into actual prioritization decisions - down to tactical processes, system configuration and talking points when engaging with partners and leadership.

OKRs as Forcing Function (Not Just Strategy Theater)

Thinking back to those 3 requests at the top of the article - finance, sales, and marketing — HOW exactly do we decide what to work on?

The answer definitely isn’t who yells the loudest or follows up most often. It’s in understanding what OKRs are actually for and using them to make prioritization much easier and more defensible.

The whole point of investing time in good strategy work (like Objectives and Key Results) is to help the company align on direction and ensure day to day work (and resources) is consistently concentrated against the problems and investments leaders have prioritized. It means teams know what to say yes and what to say no to. Essentially, OKRs are strategy in action.

Ideally, OKRs are used company-wide and exist in cascading layers which reflect the company structures and decision-making hierarchy. The original research from Intel and Google that popularized OKRs emphasized this cascading alignment—when everyone’s goals ladder up to the same company objectives, you get faster execution and clearer prioritization.

In practice, I’ve seen this work incredibly well when leadership actually operationalizes it. The companies where OKRs made my job easier as a platform PM? They had quarterly OKR reviews where executives explicitly stack-ranked initiatives. They had visible dashboards showing how departmental work connected to C-suite priorities. And when new requests came in mid-quarter, leadership would point back to the OKRs and say “here’s where this fits—or doesn’t fit—in our current focus.” That clarity is gold.

Why OKRs Over Other Prioritization Methods

Before I was in a platform product role I saw OKRs as useful indicators of why certain initiatives were more important than others to our leaders, and a useful reference for occasional resource allocation decisions. But as data platform leader (a shared finite resource the entire company depends upon), they have become essential to my entire approach to prioritization.

What are my other options? I could try to prioritize by:

• Timeline urgency: (try to meet everyone’s needs, shuffling the gantt charts until I can squeeze everything in?

  • ❌ You can’t fit everything in. Ever. I’ve never seen a data team have enough capacity to do this and in the age of AI accelerate, demand for platform capabilities and features is growing at an even more accelerated pace.

• ROI: I could try to calculate the business impact of the various things I’m being asked to do.

  • ❌ Honestly, just the idea of trying to do this for dozens of requests per quarter makes my eye twitch. That's a full-time job in itself, and even then, you're making assumptions about value that leadership should be making through strategic prioritization, not you reverse-engineering.

• Leadership group think: get the data platform leadership group together and stack rank through hive mind.

  • ❌ This works short-term—you're essentially leveraging your leaders' networks and strategic context to intuit urgency. But it's inefficient, not scalable, and burns busy leaders' time on decisions the OKR framework should handle.

• Who is yelling the loudest: this sounds like I’m joking, but some teams operate this way. They are very reactive.

  • ❌ If you are in this mode your entire backlog will fill up with work from loud partners and the quieter partners working on strategically critical work won’t get heard. You’ll miss real opportunities to drive business value. Be responsive to the loud partners, set boundaries about when you’ll get back to them, and make sure you inventory all the critical needs before you consider their request in the mix.

In my experience, it’s much easier and more defensible to use OKRs as a framework. OKRs aren’t just some bullet points on an All Hands deck the c-suite presents annually, they are your prioritization rubric. Your job is to translate, clarify where things are ambiguous, and pressure test against real life constraints (headcount, budget, technical limitations). You are the interpreter of strategy, not the arbiter of prioritization decisions.

Of course, OKRs aren't always perfectly clear. When they're vague or incomplete, that ambiguity becomes visible the moment you try to use them for prioritization—and that's actually valuable, because now you can surface the gaps and force the clarifying conversations that need to happen.

Using OKR Strategy and Stack Ranking to Force Trade Offs

Just like operationalizing OKRs helps us see where the strategy needs more clarity, when strategy hits execution we also often find it reveals constraints. Just like code surfaces edge cases, operationalizing strategy surfaces:

• Unclear stack-ranking when priorities compete for shared resources (like the data team, IT services, or legal)

• Feasibility issues (capacity, dependencies, readiness of current infrastructure)

• Unrealistic timelines - things often take longer than people think, even if we could drop everything and work on it right now. Add in the juggling of run the business work with all this strategy work and often there’s a gap between timeline expectations and reality

Our job is to surface those constraints and force trade-off decisions. Not to overcommit and under-deliver, not to say no without transparency, but to bring leaders the context they need to make decisions.

Great leaders respect a clear articulation of real constraints. They don’t resist hard choices—but they may push back if you give them an opaque “no”s.

Instead, prepare to come back with context that enables their job:

• “Marketing and Sales both map to C-suite OKRs, our team can do A or B in Q2, not both”

• “You can see, based on the stack ranking of the OKRs that these 3 initiatives are definitely going to be possible, but these 2 are stretch goals, we are going to try but we are worried that X (headcount constraints, dependency, unclear technical feasibility) may push it beyond the timeline you’ve requested.”

• “I know some of these items below the line are high value to some business units, but given the current ranking and our current headcount we just can’t get to them all. We either need to deprioritize some other things to make space or we’re going to need expanded headcount to support the work.”

When you prepare and share your roadmap and commitment in this way it is actionable. Leadership has options: re-prioritize, add resourcing, adjust timelines, descope, or escalate. They made a wish list of results they want to drive—you grounded it in current reality. You aren’t making judgment calls; you are just giving them the information so they can make the calls.

The other key - be prepared to answer the follow up question “What do you need to get this done?”

• Is it 2 contractors for 90 days?

• Is it an FTE because this is a recurring pattern that the business ambition exceeds capacity - if it’s FTE have you identified which specialty in your platform team is the bottleneck?

• Is it professional services to accelerate a prototype?

You’ve got their attention, don’t waste it by hemming and hawing about your ask. Give them the ask and let them decide. It’s not personal, it’s about what needs to happen to fulfill these requests.

Now the people who manage the budget have a strategy vs budget tradeoff decision to make — balanced with the many such decisions they are making every day.

And you’ve protected your team’s sanity by not saying yes to things that are really outside what is possible. Less heroics, less burnout, more steady stream of high value work.

Tying Platform Improvement to Strategic Work & OKRs

Of course strategic work for the business and keeping the lights on type work aren’t the only two categories of work we are trying to prioritize. We also have long range platform building. I like to say “We have to ship with the platform we have today and build the platform we need for tomorrow.”

So how in the world do you make capacity for this when the business already wants 200% of your capacity?

The best way, in my experience, tying platform improvements to the projects that will require them. I think of this as trojan horse platform improvements. For example, say you are building a CDP for marketing’s brand campaign. The CDP is going to be heavy on transformation and your current architecture leaves a lot of observability blind spots and makes things hard to debug. You’ve been wanting to move ETL to dbt and switch orchestration to Dagster, so you pick which pieces of that infrastructure set up represent an MVP and use the CDP phase 1 to pilot it. That way you can deliver on strategic priorities AND advance platform maturity simultaneously.

Let’s Get Tactical: How to Actually Operationalize This

Conceptually this sounds great, but I'm sure you're already thinking: HOW do you do this without it becoming a super manual process—custom decks for every tradeoff conversation, jumping between tools, spending hours wrangling tickets and roadmaps?

The answer: you need a SYSTEM. I can’t tell you what your system should be - it is too variable, but I can give you a framework to build your system.

Part 1: Build the Infrastructure That Holds OKR-to-Work Connections

The goal here is that you create a link that connects your top hierarchy items (Jira Initiatives/Epics, Azure DevOps Epics/Features, etc) to the business key results. Whoever owns the OKR process—PMO, strategy team, product org—likely has a tool where they track cascading Objectives and Key Results. This could be a dedicated OKR tool (Workboard, Lattice, Viva Goals), a program planning tool (OnePlan, Asana), or even a spreadsheet. (Yes, I know the data folks are shuddering, but I've seen spreadsheets work pretty well!)

Regardless you probably don’t own that tooling decision. You just need to react to it. So the question is:

• Can you integrate programmatically (via pre-built connectors or open APIs)

• Will you have to maintain a manual mapping?

• Who owns keeping this mapping up to date?

If you have product managers it’s probably their job since they’ve done discovery with the business stakeholders, understand the context, and are creating the high level roadmap. If you can create the links in a way that integration keeps details synced that is ideal.

What this might look like in practice:

• All Jira: JIRA initiatives and epics that roll up to OKR parent objects (housed in a central OKR project at the top of the hierarchy)

• Integration between OKR tool (WorkBoard, Lattice, Viva Goals) and work tracking (Jira, Linear, etc)

• Custom fields/tags referencing OKRs

Why infrastructure matters:

Why does this infrastructure matter? You want to show your roadmap in the context of OKRs without manually rebuilding it every time. When leadership re-prioritizes an OKR, that change should cascade down to your backlog automatically. Inherit hierarchy where possible rather than recreating it manually.

Once the system is set up—minimizing manual updates, automating where possible, and continuously syncing priorities—you're much better positioned for success.

If you can't get integration and you're stuck with manual mapping—okay, that's not ideal, but it's still better than no mapping at all. At minimum, maintain a view (even if it's a spreadsheet or roadmap slide) that shows which work maps to which OKRs, and update it quarterly (or whenever you need to tell the story to guide trade-offs/convey roadmap). Visible beats invisible, even if it's not automated.

Reality check:

As I mentioned at the top, the tooling is often decided by other teams (IT, PMO, strategy), your job is to advocate for structure that makes connection visible. That may mean requesting integration work, requesting certain configurations in their tool so that it works better with your process, or even maintaining manual mappings a few times a year. Get scrappy, experiment, and find something that works - once you have this structure it is invaluable.

Part 2: Mapping Incoming Work to OKRs

The reality is that work doesn't come in at convenient cadences—it comes in continuously, even if there are some cyclical surges (budget planning season, product launch cycles, end of quarter). When people bring the work they usually want to know whether you can help and if so when. It’s critical to be encouraging (“I’m here to help, tell me about what you’re working on.”) but also set direct and clear expectations about what happens next.

My go-to response: “Let me look at the roadmap and see how this aligns with everything else, and I’ll get back to you on timeline”

• NOT saying yes

• NOT saying no

• NOT vague “I’ll talk to the team” and ghosting them

• Clear next step: check alignment with strategic priorities and existing commitments

Another learning is that you can’t necessarily expect the requestor to have the context on the strategic alignment and pressing them to figure it out may be counterproductive.

During the conversation, focus on gathering the signals that will help you determine prioritization later:

• “Is there anything I need to know about urgency and timelines?”

• “How does this relate to broader programs and goals the company is working on right now?”

• Example: “Oh, this is part of Project Stargate” → “Ah, okay—Project Stargate is top three CEO priority. I’m sure we can get this done. I’ll get back to you.”

Don’t ask requesters to map their own work to a specific OKR:

Initially I tried this, but what I found is often people weren’t sure if their work aligned to a strategic priority. They felt confused by the question and looked up the priority list trying to justify alignment—not in a manipulative way, just trying to contextualize the work for me.

Better approach: If there’s an obvious connection, it’ll come up in the overall discovery conversation. If there isn’t, take the signals you found and bring them to the PMO or business unit leadership team. Ask them to help stack-rank the work in the OKR context.

A Note on Late & Urgent Requests

Sometimes I get late-arriving urgent requests that demand an immediate pivot. I try to reduce this by teaching the org over time how much advance notice our team needs to deliver well.

That has been successful in reducing the amount of late minute requests, but they can never be eliminated: the business pivots, humans are imperfect at planning ahead, and last minute requests arrive. If the requestor is insistent that their work must be done NOW, I compare it to current roadmap priorities and their OKR alignment. Then I get clear on what would have to be deprioritized to make it happen.

Then I put it back on the stakeholder: get their leader and the leader of the deprioritized item to agree that this is important enough to justify breaking an existing commitment.

Once again, we are not the arbiters of prioritization, we are just responding to leadership’s strategy signal. Though we want to limit pivots when work has already begun (because that’s inefficient), it’s more important that the most critical work gets done.

It gives us cover for the delay on the deprioritized item, and it puts the burden of advocacy on the late requesting team.

In summary, discovery with stakeholders is continuous, mapping to strategy is ongoing, and we don’t commit to anything until we’ve got it slotted into our overall strategic framework and have talked to our team about capacity.

Part 3: What Happens to Unmapped Work?

If you've been reading this critically, you're probably thinking: 'But what about work that can't be mapped to OKRs?' You're right—not everything will map, and some of it still needs to get done.

I think of this as there’s our OKR strategic bucket of work (the bulk of our work) and then two additional buckets, each with their own rules:

Keeping the Lights On (KTLO)

The trick is defining KTLO very narrowly: literally keeping things running that the business already depends on, or handling business-critical needs that arise unexpectedly.

Examples of actual KTLO:

• Lawyers need a data export for an active legal case? You’re doing that.

• Tableau Server needs a critical security patch? You’re squeezing that in.

• DevX mandates migrating packages to Artifactory this quarter? You’re meeting that deadline.

• Existing pipelines break due to upstream schema changes? You’re fixing them.

• Performance optimization prevents system degradation? You’re handling it.

And that's before we even talk about ongoing maintenance of existing data products: pipelines breaking due to upstream changes, small performance optimizations, cost-saving refactors, and routine monitoring.

Get clear as a platform team on two things:

1. What counts as KTLO?

2. How much capacity we’re setting aside for KTLO (20%? 30%?)

Then it becomes a separate bucket. If you've allocated 30% for KTLO, your strategic OKR work gets the remaining 70%—and that's your constraint.

Note: I avoid the term “Run the Business” it’s too ambiguous - we are not doing workflow improvements, we are not taking on new pipelines we are not building everything every team perceives they need to run the business. We are just keeping the lights on.

Not strategic & Not Essential Work

Here's the hard truth: not everything is strategically important. Some work is useful to certain users, some is an interesting side bet, some is small refinements to the experience—but it's not OKR-aligned.

The answer for most of this work: it sinks to the bottom of the backlog. Be clear with stakeholders that your capacity is consumed by strategic priorities. They'll need to find a workaround or make a case for why this should become strategic work.

Part 4: Making OKR Based Prioritization Visible and Sustainable

You’ve built the prioritization system, you’ve got an approach for mapping ongoing incoming work, you’ve handled exceptions. Now, how do you make this visible to others and keep it running without manual overhead?

Structure Your Roadmap to Show OKR Connections

Ideally your tooling has views that show this, if not you’ll need to get creative on how to present it this way (maybe export the tickets and use AI to generate the hierarchical contextual views you need based on the structured data). As long as the links exist you can find a way to make those OKR connections visible to others inspecting your roadmap.

In one company we did this in Jira using the advanced roadmap view, which literally showed our team’s projects in context of the strategic objectives.

Make sure it’s clear in what you’ve presented what is “above the line” and in the near term commitment set vs '“below the line” - stretch goals or out of scope. You’ll want visual separation. Literal lines or color coding or separate sections that make this clear. KTLO will also be visually separate.

Your roadmap needs to be flexible enough to shift the granularity to the audience. Leaders just want to see the OKRs & your highest level ticket with a clear signal about commitment (or lack thereof).

Other teams might want to see more detailed tickets - who owns the execution, is the story started, when is it slated to begin, etc. Think of each persona who may want to view the roadmap & ensure there’s a way for them to easily bookmark that view:

• Leadership view: Strategic initiatives, what’s green-lit vs. stretch vs. out, clear OKR connections, timeline commitments

• Stakeholder view: When their requests are scheduled, what OKR they map to, what would need to change for different prioritization. How their work aligns with other requestors and the ability to filter out that noise and only see their own needs.

• Team view: Day-to-day work with context about which strategic objective it supports, detailed timelines, dependencies

When changes happen over time, make sure updates (to the OKRs or to the commitments) cascade through all views. If that happens continuously and automatically, perfect. If it’s manual, make sure the expectation is clear that this is a snapshot at date X.

Communicate Priorities Consistently

It’s a lot of work to build this roadmap - especially the first few times as you are tweaking the system. But once it it exists, you have an artifact that supports your efforts to drive clarity with leadership, stakeholders, and your team.

You may want to have a stakeholder roadmap review presentation with Q&A.
You may want to send out a quick Loom video and a link to the roadmap telling the story.

You may have a quarterly newsletter where you talk about wins from last quarter and upcoming priorities and can link to the roadmap as well as pull screenshots from it.

The rituals and touchpoint will be specific to your org. Align to ny existing quarterly roadmap planning sessions, regular check-ins with stakeholders, sprint planning with the team, etc.

The key principle: refer to the roadmap often, show how work aligns with strategy, consistently convey the message that platform work is driven by strategic decisions made by the business unit leaders. That transparency and pro-active communication pays dividends. I guarantee your stakeholders have no idea the breadth and volume of work your team delivers. Data work is often invisible, but it shouldn’t be that way.

Why This Matters

Prioritization is one of the hardest parts of working on a platform team. There is an overwhelming amount of demand and it all can feel very pressing. Remember the example at the beginning of finance, sales, and marketing with their urgent requests? With this framework it’s less overwhelming - you have a system! You evaluate them against OKR hierarchy, you surface trade-offs to leadership, and you deliver them an answer that’s defensible and transparent.

Once you work this way, you won’t want to go back. Strategic prioritization is so much better than reactive firefighting. People may still be disappointed when their work doesn’t rank as high as they’d like, but at least they’ll understand why and feel like you would listen if their business unit leader asked you to reprioritize to better match their understanding of the strategy.

When you work like this you protect your team’s sanity. You don’t overload them with too much work. Less whiplash, fewer heroics, more sustainable pace and happy teams.

And over time when leaders have to make tough decisions, the value your team is delivering is clear. If they need more from the team (as data & AI demands in the business grow) they’ll have much stronger signal about where the capacity constraints keep hitting and whether additional resourcing is needed to meet the organization’s ambition.

OKRs really aren’t just strategy theater, they are your prioritization rubric. Done well they are a game changer for focusing investment toward what matters most. When you operationalize them into your systems, they make your job manageable and your roadmap defensible. You are delivering what leadership decided matters and having real impact on business outcomes. That shift - that’s what makes platform prioritization actually work.

We have experienced product managers who understand the user deeply, but who lack the AI literacy needed to spot the right opportunities.

We have data scientists who understand AI, but because we lack enough of them to embed with every team, they are not always close enough to the user to understand the pain points and opportunities.

We have data & AI platform PMs who are trying to facilitate all this innovation and engage with both groups, but do not own the strategy or execution of either.

And everywhere it’s a messy collaboration problem, held together by enthusiasm and pressure to innovate and deliver together. It’s not ideal, but in healthy teams they are figuring it out together.

Several weeks ago I was listening to Brian O’Neill and (VP of AI Engineering and Data Analytics at Salesforce) discussed this exact challenge on the Experiencing Data podcast. They were exploring how tricky it is to coordinate AI product development across multiple product managers.

Irina described a similar scenario to what I have observed. Three PMs are involved - one on the business side who understands the user/process, one in data analytics who understands AI, and one who owns the platform (like Slack). Brian and Irina discussed: which one owns the final outcome?

Her answer: it comes down to culture - strong relationships between these PMs, focus on a shared vision, willingness to step outside their boxes. She acknowledged "it's difficult" and "I really have not found any other way to solve this."

Listening to this exchange, I found myself nodding along and thinking about the ways I’ve seen teams experiment with improving this dynamic. Irina's right that culture and collaboration are essential. But in my experience, there's something more concrete we can do to make that collaboration actually work: get crystal clear about handoffs. Who owns which part of the risk? What's each PM responsible for delivering? What are the inputs and outputs at each stage? When the expectations of responsibility and hand-offs are defined - almost like APIs or data contracts - then culture and relationships can actually flourish because everyone knows their role.

What's Really Driving This Fragmentation

This podcast conversation made me reflect on why we’re in this shared ownership model in the first place. In my experience there are two gaps that drive this:

• Gap 1: Opportunity Identification

  • Business PMs don’t always recognize the problems where AI can apply (they don’t see “oh this is a classification problem!” or “generative AI could help here”)

• Gap 2: Execution ownership

  • Once an opportunity is identified who is capable of delivering it? Who has the understanding to translate user needs into technical requirements, and who has the skills to execute on them?

I noticed these gaps before the GenAI wave hit a few years ago. As a data professional turned product manager I’d find myself in meetings with other PMs where there were clear opportunities to use data & ML that no one was talking about; then I realized that their understanding of data wasn’t deep enough to understand what it could do.

I remember one day talking to my team about how gathering profile characteristics in onboarding (using standard taxonomical tags, not free text) would allow us to recommend not only content which had those same tags, but also topically similar tags (clusters identified by our data scientists); as I drew this out on the white board my team said “That’s magic!” I laughed and said, “No that’s data.” That moment crystalized the gap for me - how many opportunities our product teams were missing out on because our PMs just didn’t understand what was possible. I became a passionate advocate for getting my product peers more comfortable with data and more literate in how data & ai systems work.

Then GenAI hit and the technical literacy gap just became more apparent. Solutions exist - teams can hire PMs with AI/data backgrounds, embed more data scientists closely with teams, and rapidly upskill product managers in these fields. But transforming individual skillsets & org structures takes time, so many companies are instead having PMs with varied backgrounds collaborate together to close the gaps. It's messy and imperfect, but teams are making it work. To understand why this collaboration is necessary—and what makes it work—let's look at how traditional product risk management breaks down with AI products.

Managing Product Risk Across PMs

In one of product management’s seminal books, Inspired by , he talks about the four product risks empowered teams must manage: value risk, usability risk, feasibility risk, and viability risk. In traditional product work the PM is responsible for:

• Value risk: will customers choose to use/buy this - does it solve a real problem they care enough about to adopt it

• Viability risk: will this product work for the business? will it meet all stakeholder needs (legal, compliance, finance, sales, marketing, etc.)

In that model the designer owns:

• Usability risk: can users figure out how to use it? is it good enough that they can accomplish what they are adopting it for?

And the engineers manage:

• Feasibility risk: Can we build this with the technology available to us? With our data and engineering capabilities - is it technically possible to meet the acceptance criteria and deliver the feature(s)?

The problem we face in AI, if you remember though, is that many of our digital product managers (and designers) do not have enough data & AI literacy to spot all the opportunities - to pair solutions with user pain points. And the viability gets more complex with data and AI products, particularly in regulated sectors/countries, which can require more niche expertise to navigate. In AI products, like Irina alluded to, you often need multiple PMs to manage the risk effectively. In the long term hopefully we’ll close these gaps, but for now that’s the reality.

With multiple PMs involved this is where clarifying the hand-offs and ownership over risk management makes it easier to collaborate effectively.

Managing Value Risk

Our business PMs remain here the expert in user pain points and they have to make the call that any solution the combined team decides to build will be valuable for that user. They have to understand the relative importance of the user’s problems and handle prioritization of addressing those problems in their overall roadmap.

But because of their data/AI literacy gaps it is usually best if that PM has a tight relationship with either an embedded data scientist or a data/AI PM who can help them spot opportunities where AI or data can create value that the business PM might not see. As a data platform product manager, your job is to understand your customer so well you can empathize with them and help them solve their problems with data and AI - that customer here is the business PM. You have to know their strategy, what problems they are trying to solve for their user, what their leaders are prioritizing in overall product strategy, etc. Only then can you suggest things like:

• Have you considered using GenAI here to make the onboarding interactions feel more personal?

• The profile team gathers that when the account is set up right? So you can call on that data, utilize this other API and make a prediction about which features to push them towards next?

So the value risk is primarily owned by the business PM, with the data/AI PM helping them spot opportunities where these tools may apply.

What This Looks Like in Practice

This shared ownership over value risk requires regular collaboration between business and data/AI PMs. In healthy teams, this typically means:

• Regular syncs (weekly or bi-weekly) where business PMs share their roadmap priorities and user research findings

• Joint strategy sessions where data/AI PMs can surface opportunities: “Given that user pain point, have you considered...”

• Shared planning & prioritization where both PMs align on which AI opportunities are worth pursuing given business priorities

Once an opportunity is identified and validated, the handoff gets more concrete:

Business PM delivers:

• Feature PRD defining the user problem, success criteria, and business value

• User research and validation that this is worth solving

Data/AI PM augments or creates parallel documentation:

• Technical requirements sections (data needs, model approach, dependencies)

• Sometimes a separate data product PRD if new datasets or models need to be built as dependencies

• Feasibility assessment and resource estimates

The key is that both PMs are aligned on what we’re building and why before diving into how. Each brings their own expertise to the problem - but the final call on what to build here still belongs to the business PM.

Managing Viability Risk

Viability risk becomes uniquely complex with data and AI products. While generally the business PM owns overall business viability (strategy fit, pricing, positioning/go-to-market), the complexities of navigating legal & compliance risk can be hard for all PMs to keep up with.

When you build with data (which both data products & AI products do) you encounter a lot of regulatory restrictions. GDPR is the strictest privacy framework in the world, but it’s not the only one. If your company operates globally, navigating how you're allowed to use data, where it can be processed, and what de-identification means gets complicated fast—and AI regulations are evolving just as quickly.

And if you work in a more regulated industry (finance, healthcare) you layer in additional regulations and privacy considerations. As a data PM in healthcare & medtech, I have spent more hours than I can count talking to our lawyers to understand questions like:

• Under GDPR are we allowed to use de-identified data to train this model?

• What does it mean for data to be sufficiently de-identified for us to share with an external contractor to build this model?

• Are we under contractual restrictions to not use this data? Does the reason we are using the data matter? Does the location where we process it matter?

• Can the user or other partners sign specific terms & conditions that allow us to use this data more freely?

It’s not enough to be building something ethically, for the user’s benefit. You may also need additional permissions, modification to existing contracts, or particular data processing to meet requirements like US HIPAA Safe Harbor — all before you can build a model. Regulations around AI are still emerging but they are addressing questions of data quality validation, provenance, and other monitoring/tracking. A great blog article on this topic here and US FDA draft guidance from January 2025 here.

This is specialized knowledge that most PMs don't have time to develop. Data & AI PMs can bridge this gap by working with legal to build guidance that scales, evaluating early ideas for regulatory risk, and directing business PMs when additional legal review is needed.

What This Looks Like in Practice

Business PM owns:

• Overall business viability (strategy fit, pricing, go-to-market feasibility)

• Understanding business stakeholder needs and constraints

• Seeking final assurance from legal/compliance department when formal sign off is needed

Data/AI PM owns:

• Data compliance and regulatory viability assessment

• Working with legal to establish guidelines and frameworks

• Flagging regulatory risks early in the ideation process

• Determining what’s legally/ethically possible before validating if it’s valuable

The handoff: Data/AI PM provides a regulatory assessment (”here’s what we need to be compliant”) that the Business PM incorporates into their overall viability evaluation. Sometimes this means the Business PM needs to get additional contracts signed, modify user terms, or pivot the approach entirely. While the business PM ultimately owns final legal/compliance sign-off (since the data PM may not be involved end-to-end), the data PM can shorten cycles and provide critical consultation throughout the product lifecycle.

Managing Feasibility Risk

The true ownership for feasibility risk still sits with the tech lead - data engineers, data scientists, MLEs (the specifics depend on your org structure). But the data & AI PM plays a crucial pre-vetting role that prevents wasted cycles and helps scope work more realistically.

Why pre-vetting matters: Data scientists are scarce resources, we can’t pull them into every idea to validate feasibility. The data/AI PM acts as a filter, doing preliminary assessment before committing expensive technical resources.

Data product managers help business PMs evaluate ideas by assessing:

• Data availability & quality: Does the data exist to support this work? Is it accessible? Is the quality sufficient?

• Problem solvability: Does it look like this is a problem AI can actually solve?

• Dependency/resource scoping: What teams, systems and data sources need to be involved to pull this off? What’s the level of effort? Does this fit within the strategic priorities and competing roadmap items?

Sometimes this pre-vetting also involves coordination with the business PM on future data capture: “We don’t have the data today, but if your team started instrumenting X in the product now, we could build this model in 6 months.”

Once the team decides to move forward with building, the technical feasibility validation shifts to the specialists:

• Data scientists/ML engineers validate: Can we actually build a model that works with the available data? Will accuracy/performance be good enough to be useful? What’s the final technical architecture?

• Data engineers validate: Can we provide pipelines that meet data availability and latency requirements? Can we maintain data quality at the needed scale?

What This Looks Like in Practice

Business PM owns:

• Feature requirements: what the user needs, success criteria, acceptance criteria

• User workflow context: where this fits in the user’s journey

• Success metrics: how we’ll measure if this works

Data/AI PM delivers (pre-vetting)

• Problem translation: “This is a [classification/recommendation/search] problem”

• Data availability assessment: “We have X, we’re missing Y, quality is sufficient/insufficient for Z”

• Preliminary feasibility: “This looks solvable/this has blockers we need to address first”

• Technical approach options: “We could use RAG vs fine-tuning, real-time vs batch...”

• Dependency mapping: “We need content team to improve metadata, platform team for deployment”

• Resource estimates: rough timeline and effort scoping

• Sometimes: separate data product PRD for datasets/models that need to be built first

Data Scientists/ML Engineers deliver (final validation):

• Model feasibility confirmation: “Yes, we can build this with 85% accuracy” or “No, data quality won’t support this”

• Technical architecture decisions: final implementation approach

• Performance benchmarks: what users can realistically expect

Data Engineers deliver:

• Pipeline feasibility: “Yes, we can deliver real-time” or “We can only support batch processing”

• Data infrastructure requirements: what needs to be built to support this

The handoff: Data/AI PM filters ideas and scopes work before pulling in technical specialists. When a project is greenlit, they hand off clear requirements to data scientists/engineers: “Here’s what we’re building, here’s the data available, here’s the constraints.” Technical team validates final feasibility and builds. If technical team says “this won’t work,” Data/AI PM works with Business PM to adjust scope or approach.

This three-way split is essential because:

1. Business PM doesn’t have technical depth to assess feasibility

2. Data scientists/engineers don’t have bandwidth to evaluate every idea

3. Data/AI PM bridges the gap, preventing wasted cycles and unrealistic commitments

Managing Usability Risk

Usability risk in AI products is the most similar to traditional products. Though AI may power a feature, the usability still comes down to interaction patterns with the outputs of our models.

Designer owns:

• Interaction design for AI features: how users interact with recommendations, search results, generated content

• Visual design for AI-specific elements: confidence indicators, explanations, error states

• Balancing AI capabilities with user control and agency

In practice the data PM may be talking to the business PM & designer about guardrails, error handling, messaging users with accurate interpretation of what they are seeing (if it’s probabilistic and prone to error we often need to inform the user so they approach it with adequate caution.

Why this matters: Trust is the adoption bottleneck for AI products. Users need to understand why the AI is recommending something, how confident it is, and what to do when it’s wrong. Getting this right isn’t just nice-to-have UX polish - it’s the difference between a feature that gets used and one that gets ignored. Some AI features can be invisible under the hood (recommendation engines, for example) but something like chat responses generated by an LLM may need to be transparent about doing this so the user can be cautious about potential hallucinations, etc.

Specialized Knowledge Creates Dependencies

Looking across all four risks we can see that data & AI powered products often require specialized knowledge that is distributed across multiple people.

Currently it’s quite rare for a single PM to have all of these skills, though certainly we may see more of this emerge over time. In the meantime data/AI PMs can help fill specific gaps like AI opportunity identification, regulatory navigation, and technical translation.

This isn’t ideal. It creates coordination overhead, slows decision making and requires careful handoff management. But it’s the practical reality while the workforce adapts to our new reality. Evolution takes time, for now most organizations have to make multi-PM collaboration work—which brings us back to Irina's point about culture. Culture matters enormously. But as we'll see next, culture works best when people have clarity about who owns what.

From Theory to Practice: What Clean Handoffs Actually Look Like

You’ve seen why AI products fragment risk ownership across multiple PMs, and fragmented ownership creates a coordination challenge: how do you actually build products when three PMs need to collaborate on every feature? My approach: get crystal clear about handoffs.

Core principle:

When there’s overlap two risks arise:

1. Too many cooks in the kitchen - stepping on each other’s toes; inefficient and frustrating

2. Things fall in the cracks - everyone thought one element was someone else’s job; either it gets forgotten permanently which is very scary or it gets remembered last minute and stresses everyone out.

The fact is that fuzzy collaboration often fails and cleanly articulated responsibilities and handoffs succeed. It can’t be vague whose job it is to do what. I think of this like APIs or data contracts - clear inputs, clear outputs, clear responsibilities. When expectations are defined everyone moves faster, culture and relationships can flourish, and can get into that great flow state of shipping as a team.

The Complete Product Development Flow (with Handoffs):

Stage 1: Opportunity Identification & Value Validation

In this stage of work the business PM is responsible for:

• Clear user problem articulation: “Here’s the proven problem worth solving” - documented user pain with evidence.

In this phase the data & AI PM acts more as a consultant. These “deliverables” are more offered in consultation in meetings or in draft documents, but don’t become formal artifacts:

• AI opportunity identification: “Given this pain point, here’s where AI could help”

• Preliminary value assessment: does AI actually add value here or is a simpler solution better? Should we consult with data science on this one?

The collaboration: Regular syncs (weekly/bi-weekly) where business PMs share roadmap priorities and user research, data/AI PMs surface opportunities. Joint strategy sessions to align on which opportunities are worth pursuing.

Stage 2: Viability Assessment

In this stage the team is evaluating whether the potential solution(s) under consideration are viable and worth pursuing further.

The business PM again leads here. They are evaluating strategy fit, pricing implications, go-to-market feasibility and timeline constraints. Their deliverable at this stage:

• A business case or key sections of the PRD related to viability.

The data/AI PM consult considers the regulatory viability, compliance requirements, legal/privacy risks and potential blockers, clarification on ambiguous sections with legal, etc. Their deliverable:

• PRD section on data/AI regulation/compliance: “Here’s what we need to be compliant”

The collaboration: Data/AI PM flags issues early (”we can’t use this data without additional consent”) so Business PM can adjust approach, get contracts modified, or pivot entirely. Business PM owns final legal sign-off but data PM shortens cycles through expertise.

Stage 3: Technical Translation & Feasibility

In this stage the team is figuring out if it’s actually possible to build a working model for this problem. The business PM is responsible for:

• Setting the measuring stick: “Here’s what success looks like from the user perspective.”

The data & AI PM is helping pre-vet so we have a better formed requirements document for our technical partners to design a tech spec against. So the data & AI PM:

• Problem translation: “This is a [classification/recommendation] problem or we might use [genAI] in the solution here.”

• Data availability assessment: Can we get the data we need?

• Dependency mapping: What teams/systems/data sources need to be involved?

These might be solved just as consultation moments, freestanding PRDs for data/platform dependencies, or embedded as sections in the requirements document that is fed to the actual owners of technical feasibility (data science, MLEs & data engineers).

And of course the technical partners are the final gate in this stage, their job is to evaluate the actual feasibility. With well defined requirements it is much faster for these partners to evaluate data dependencies, performance requirements, and architectural decisions so that they can either either push back “No, we can’t build this and here’s why” or:

• Design & Estimate: Deliver actual technical design document and estimate of when the work could start/end given the current prioritization and backlog

The collaboration: Data/AI PM acts as filter - prevents wasted data science cycles on projects that are DOA due to data availability. Translates between business requirements and technical constraints. Gets group alignment that approach is viable before committing scarce resources. And the technical partners own the actual call on technical feasibility and of course the build itself.

Stage 4: Usability & User Experience

In this stage the designer leads, defining how users interact with the AI-powered feature - the interaction design, visual elements like confidence indicators and error states, and the balance between AI automation and user control. There isn’t a handoff among them and the PMs - just consultation and then finalization of the design to give to the technical team for context on how the data/AI product will show up in the experience.

The collaboration: Business PM knows the user, Data PM knows AI patterns, Designer (if present) brings them together into cohesive experience.

The Culture Piece: Why Handoffs Aren’t Enough

While well defined handoffs help drive efficient collaboration, it’s still not enough to drive the best outcomes. Even with clean individual handoffs, you still need:

• Shared vision: All three PMs aligned on what success looks like for the user

• Strong relationships: Regular communication, mutual respect, willingness to step outside their boxes

• No ego: Can’t have PMs protecting turf or claiming credit

• Healthy tension with technical teams: Data scientists and engineers pushing back on unrealistic requirements, PMs pushing for user value

In short, even with each PM owning their piece clearly, they still must ensure their combined vision is cohesive. The Business PM’s user problem + the Data PM’s technical approach + the Platform PM’s implementation constraints must add up to one coherent product, not three disconnected pieces.

Is This the Future or Just the Transition?

There are so many directions we may evolve as a product community, and it's worth discussing openly what works best. With new AI capabilities there's more pressure than ever to be a unicorn PM who can do it all—from user research to technical feasibility to building prototypes. But is that best? I keep thinking that there's something lost if we expect one person to build end to end alone. It's never just been about specialization of skill, but also about the alchemy that builds in great teams where collaboration produces better results than we could achieve on our own.

To me, it’s unclear what’s optimal. Maybe this multi-PM model is transitional—eventually business PMs develop enough AI literacy to own the full stack. Maybe strong hybrid PMs will emerge and advance faster. Or maybe the coordination overhead is worth it because collaboration pressure-tests ideas and produces more refined solutions than any single PM could develop alone.

And even if we knew the ideal end state, workforce evolution takes time. We’ll likely see some consolidation of ownership, but that evolution will be slow—especially outside Silicon Valley. Many companies are just coming around to training their people on product approaches and design thinking; they’re not ready to evolve even further into complex technical product management.

What seems advisable: Leaders should keep experimenting with different org structures and team compositions. Some are upskilling business PMs. Some are formalizing multi-PM collaboration. Some are using program managers to bridge gaps. There’s no one right answer yet, so share what you learn.

In the meantime, we have to ship with the teams and skills we have today. We don’t need to wait for perfect org structures. Focus on clean handoffs with clear expectations—who owns which artifacts, who manages which risks. Build both strong culture and concrete practices. When handoffs are clear and culture is healthy, teams can deliver excellent AI products even in this messy, transitional reality.

And then it hit me: I could code this into a very simple app.

I honestly had never had that aha moment. Everybody’s vibe coding, but as a data product manager, I hadn’t seen the need. Agents, Projects, custom GPTs, NotebookLM - those handled everything I needed. Building an actual interface? Not something platform PMs typically need. Not yet anyway.

So we got to the therapy office, I opened Claude mobile, and the next day after maybe an hour of work, I had a live working app.

At that moment I wasn't actually sure if I would build this with Claude, but I knew we could figure it out together. There were just too many options - even within Claude there were Projects, Cowork had just come out, and Claude Code obviously could do it. Everyone’s raving about Lovable, so that was on my mind too. I genuinely did not know which direction to go.

So while sitting in that therapy office waiting room, I opened my phone and did what I often do - I asked Claude to help me figure it out.

v1: Claude Artifacts - The Hard Parts Will Surprise You

Pretty quickly Claude suggested this was simple and we could do it right in Artifacts. The benefit there being it’s conversational, fast to iterate, it can preview live without formally “deploying”, no IDE, no complications.

I’m a product manager so knowing how to prompt it came pretty naturally.

Within minutes I had my first prototype, but also hit a snag - the artifact wasn’t displaying on mobile. Whomp whomp.

I tried the browser (vs the iOS app) and again - no dice. Whomp whomp.

I didn’t have my laptop so I had to wait to iterate more when I got home.

But when I was home it was off to the races with fast changes like this:

One rapid change after another I tweaked the app

• Changed the layout of the form so it followed the natural flow of though

• Moved the now button to the left (easier to click even if it looks slightly less clean because I know my kid will use that most of the time

• Added an emotion picker (based on the emotion wheel concept). Mine is not wheel shaped, but it works fast so I do not care.

Did I have to repeat myself like 4 times to get Claude to properly reorder the fields, yes. Do I know why, no. Do I care, also no. This is not an app going to production with thousands of paying users, I feel no need to chase down every yellow flag, if it works as intended now that’s enough for me.

I also made a few more important edits that were functionally critical:

#1: My daughter is a teen and we have some pretty strict screen time controls on the family computer. I didn’t want her to run into any barriers so I wanted to white-list the app. Which meant avoiding any auth walls which could hit a snag with Apple Screen time (the least user friendly interface I can imagine, btw…). This is critical to making sure she can access this site any time she needs it.

#2: I didn’t want to connect a database or login, but I wanted her entries to persist across sessions in the app. The whole point is to track thoughts & feelings and how they change over time, so we can see what triggers are common (time of day, events) and we can see how the ways we reframe and change our actions impacts our feelings.

The goal was for her to be able to track over the course of a week and take it to her therapist to discuss together. If she closed the browser I didn’t want those entires lost. I was worried this would be tricky, but actually it was really easy!

It was looking pretty good so we brainstormed names to make it more fun and changed the font.

And then I got real crazy and wanted to add a fun image, and that was surprisingly difficult.

I took a vacation image of my daughter and had Gemini Nano-Banana create this comic strip of emotions for the header:

Making the image, typical rounds of iteration. Getting the image into the app -the hardest thing in the world I guess.

I thought persisting the records across sessions would be hard - but it solved it in a single shot. But the image - I just hit barrier after barrier.

• Claude Artifacts doesn’t support image embedding natively

• I tried sharing the image link from Gemini - it couldn’t make that work

• I tried uploading it to an image hosting service, it tried multiple things and failed and told me to try ANOTHER image hosting service - that failed too

I was really bugged by this point, but didn’t not want to give up. The image added a really fun element to a otherwise basic app and I was building this for a teenager, I wanted it to feel fun to use!

I got the app live without the image and asked my husband to do some testing, which is when I discovered a deal breaking blocker.

Claude had lied to me at the start! Drama. Okay, maybe it’s more accurate that it slightly misspoke. It said that if I used Artifacts the end user would not need to login, but when the app went live, what was there, but a login wall! I am not going to get into all the login/auth issues we’ve run into with Apple Screen Time, but I knew this was a totally unacceptable blocker for our situation.

After some investigation I found out what the confusion was - it turns out what Claude meant was that the end user doesn’t need a paid Claude account, but you still have to log in as a user. Bummer.

Between this and not supporting my image I was not a happy camper. Sure I’d put in an hour on this not weeks, but I was so close to having it working the day after I thought of it and I was impatient.

So back to Claude I went. And Claude suggested it could convert the code we had into an HTML file and I could publish it on GitHub Pages. Bingo.

And look, could I have done that myself - yes. But I haven’t used my Github login in a couple years. I manage PMs, I don’t write much code these days. And also, my husband (and dad to the target user of this app) is a software engineer.

So I took the HTML file + the very quick instructions for Claude on how to publish it and sent them to my husband (alongside my image that was being so stubborn).

He had it live really fast. (You can access it here - all your data stays in browser/local so I won’t see it. In fact I don’t even think we have any tracking to see if anyone visits it, lol.)

Now does he want me to install anti-gravity and find my login for GitHub and be able to do my own pull requests, yes. Not because he’s unwilling, but because he thinks it would be FUN to code together.

But why, why would I do that when I can pull request via text message? I’ll focus on PRDs via text and let him build for now.

The Key Learning: Be Prepared to Pivot

Truth: I’m very happy with this app. Even with blockers it was probably <2 hours of time between my husband and myself. And while my daughter said the comic image was cringe, she loved the app (and I left the image!!).

The biggest insight I had — the right tool isn’t the most powerful one (Claude Code would have been total overkill here) — it’s the tool that gets you to the next decision point. A few things I learned here:

• Start where you are comfortable or already have access (Artifacts for me, Claude was mostly right and it was fast).

• When you hit a real constraint ask AI what your options are an pivot

• Upgrade your approach if you hit an insurmountable blocker you can’t live with (that’s why we went to GitHub Pages)

• Ask for help when you need it (sure you might not all have an engineer in the next room over at the kitchen table, but I’m sure you have friends/family to ask questions and honestly I could have gotten it done with Claude’s instructions on my own)

• Don’t chase perfection on non-production apps - Not everything we vibe code needs to scale and become a side hustle. This serves its purpose, it’s stable, free to host, and solves a problem for our family. No more work is needed.

Some Tips for Future Me

I have a LOT to learn about which tools I like best. This is my first vibe coded app, but after some research with Claude I did make this visual for myself int he future. Maybe it’ll help you know where to start in the future too?

Or if you’re an experienced vibe coder, leave your tips for newbies like me in the comments.

Happy Vibe Coding my friends!

Subscribe now

It was several years ago that I first started talking to my leaders about potential shifts into a role managing and leading a team. I’d had jobs where I supervised an intern here or there, or a group of college students on big research projects, but never leading a team of technical individual contributors. And I just wasn’t sure that I wanted to grow that direction.

In tech, this timing coincided with the AI wave and talk of the return of super senior IC roles (like staff level strategic IC PMs or engineers). I LOVED (still do love) individual contributor work. Going deep on a problem - learning all the nuances of it, talking to users, honing in on the problem, and finding a creative solution. There’s nothing like it. I thought I might stay in that track and just hone my craft.

Spoiler, reader: she did not stay an IC PM.

A few years back, mid pandemic, I left my work as an analyst not because I fell out of love with data (clearly I didn’t!) but because I knew it was a dead end from a career growth perspective. I debated many options (data science, analytics engineer, analytics people leader, product!). I chose product after discussions with friends and mentors; it felt new, exciting and challenging.

Once I decided to pivot into product there were more career ladder rungs to climb. So I did, from L3 to L6 over the course of several years. During that time my leaders periodically asked about managing other PMs, but I still felt I was growing so much as an IC PM that I was in no rush. I still felt like a new PM in so many ways:

• Finding my groove on the blend of data & product (I had been so disoriented the first few years)

• So much to learn about the platform angle

• Loving IC work, feeling like I’m still in a hyper learning stage

• Had legit projects and transformations I was passionate about and wanted to see through

On top of not being sure I was ready to let go of IC work, I also had a lot going on at home, so I wasn’t sure about making such a big transition. I have two autistic kids who have a lot of needs and I was concerned about balancing that with the emotional and mental energy leading a team takes. So I hesitated.

Then about 1.5 years ago my boss and I talked again about this. From the business perspective we really needed a leader under product (previously we had all reported directly into the Sr. Director of the Data Platform); so the team need was becoming urgent. But did the timing make sense for ME.

He said I could make the change and if I didn’t like it I could go back to IC work— still a promotion but the title would be Lead PM (up a level from Senior PM) instead of Senior Manager. It was a low risk proposition with the option to revert to IC and I WAS interested in seeing if people leadership was for me. So I took a leap (in Fall 2024).

It took a few months to build the team, but by Spring 2025, I was managing six people: my backfill in California, one in Sydney, another in Bangalore, and one more who pivoted from engineering and came over to my team. Plus two governance analysts that moved over to the team. Going from zero direct reports to six felt surreal at times, but fun. I genuinely had such an amazing team; all people leaders should be so lucky to get such a golden set of humans with a growth mindset, sense of humor and intelligence.

Suddenly I had to think about what kind of manager I wanted to be. And about how to coach others to do this fuzzy data product thing I had developed some muscle memory for.

I wanted to share my learnings, but leave breathing space for the team to do things their own way.

I wanted to introduce process to create consistency, but I didn’t want too much bureaucracy — process should feel supportive and not like added work.

I wanted my people to feel supported, but not micromanaged; like they had autonomy amid responsibility; and like I always had their back.

You’ll have to ask my team if I was successful, but I tried and I learned so much getting in the reps and finding my personal groove as a manager.

It's been almost 18 months since I took that leap—and a few months since switching companies; I’m still leading PMs and enjoying it. I did not decide to revert back to IC work.

Upon reflection there have been a few surprises:

• The emotional labor reality: This did increase, but not as much as I expected and it was offset by some really energizing aspects of the job. In retrospect I was already spending a lot of emotional labor on stakeholder management, getting alignment between conflicting groups, and other company dynamics.

• The tricky problems surprise: Something that took me by surprise - how many BIG problems I had to solve. It made sense, as an IC I would escalate my trickiest problems to my leader, asking for action or coaching to help me through it. Now I had six people’s worth of escalations — so many tricky problems to deal with.

• Strategy grew: This was less of a surprise, but more of a validation. Being a leader meant being pulled into a different layer of meetings and getting to influence more consequential decisions. One of the reasons I loved product was it had more strategy than my prior data IC roles. I like being in the room where tricky problems are being solved and big decisions are being made. People leadership definitely brought more of that.

• Leading others is so JOYFUL: I was genuinely surprised how much I loved being a leader. It’s a very different job, but a very satisfying one. To be creative in understanding your people, their strengths, their weak areas, their goals, and to problem solve with them to help them do their best work. That’s really interesting work. And when they knock it out of the park and develop as a product manager it is SO FUN. Truly nothing better than a member of my team showing me something they’ve been working on and being able to say, “YES!!! I love this so much. Brilliant.”

Are there downsides, sure, a few. I do miss the IC work, sometimes problems get escalated that I really do not want to deal with, and I feel more responsibility with less control (which can be really hard). Still, I think this is the right role for me right now. I’m still learning so much about data platform product work — I’m just learning it while partnering with my team on their projects and my fellow leaders on the overarching platform strategy.

In late September 2025, I took another leap to a new company—leading data platform PMs at a hospital. New context, new team, new problems. But it feels familiar in the best way. The core skills transfer, and I get to bring what I learned from my first team while learning from this one. It’s always interesting to see what patterns re-emerge and what is unique. It’s the same puzzle: how to help the team grow, deliver what the organizations needs today, and build the platform we need for tomorrow.

If you’re at that fork in the road, wondering if you’re ready—I can’t tell you what’s right for you. But I can tell you the role will surprise you, hopefully in good ways. And if you get a low-risk chance to try it? Take the leap. You might even surprise yourself.

Do I stop the meeting to ask what a control plane is? Risk looking unprepared in front of stakeholders? I’m actually the kind of person who doesn’t mind asking the obvious question, but I also don’t want to disrupt the flow of the meeting.

Instead, I can turn to Ada.

I type: “What’s a control plane in Kubernetes?” Within seconds I get a clear explanation—written for my literacy level, with an analogy that actually makes sense. I’m back in the conversation and suddenly get the gist of what the EM is saying. And I didn’t have to derail the conversation.

People often tell me I’m “very technical” for a product manager. It still catches me off guard because—I’ve never been an engineer and I don’t think of myself as overly technical. My degrees are in public policy and political science. As an analyst I could never get myself to learn Python. I didn’t even touch SQL until 2017.

What I do have is technical literacy—and I built it organically over time through curiosity, good questions, and a lot of just-in-time learning. A few months ago I wrote about using GenAI to close those technical literacy gaps—how AI can act as a tutor when you’re stuck on a concept. I think a lot of people resonated with having a judgment-free space to learn on the fly.

Since then I built something even better for my team: Something way more specific. Custom instructions, tailored behaviors, guardrails designed for how data product managers actually think and work.

I call her Ada (after Ada Lovelace). And honestly? She’s shockingly useful.

Ada isn't just a tutor—she's also a tech consultant who helps me prep PRDs and anticipate engineering objections, and an architecture advisor who helps me think in systems instead of just features. Today I want to show you what I built, why it works, and how you can create your own version—whether you're a PM building this for yourself, a data leader building it for your team, or an engineer who wants to help your PMs show up more prepared.

Technical Literacy ≠ Technical Expertise

Product managers don’t own the “how” (their technical partners do), but do they do have to understand quite a bit of how their engineers and data scientists approach problems to be able to operate effectively together. You want to be able to:

• Follow technical conversations without getting lost

• Anticipating engineering concerns before presenting PRDs

• Understanding how architecture choices affect user experience

• Asking the right clarifying questions to stakeholders to reduce cycles (e.g. “you said real-time—how fresh are we talking?”)

Technical literacy for product managers is about knowing what’s possible and being able to spot red flags before your technical counterparts do, so you can gather more context for those conversations.

I built my technical literacy (and applied skills) slowly over my career. I studied public policy in grad school and while I took as many stats classes as I could we were working with small datasets in R, SPSS, SAS. It wasn’t until 2017, working at a small tech startup that I had to learn SQL, Big Query, Microservices, caches, and since then it’s been a non-stop flood of continuous learning.

I want to shorten that upskilling journey for my team, and generative AI has made it possible to do so in a really interesting way that wasn’t available to me in 2017 when I was trying to understand how window functions work and what in the world sharding is.

Meet Ada: Three Roles, One Assistant

Recently I decided to experiment with building an agent for my team, and ended up loving it so much I actually use it all the time. I named her Ada Vice - because I like puns, I’m a feminist, and Ada Lovelace felt like a worthy icon to pay homage to (first computer programmer and all that).

Ada’s designed to play three roles:

1. Tutor - Just-in-time learning whenever I need

2. Tech Consultant - PRD prep and anticipating objections

3. Architecture Advisor - Understanding implications of technical decisions

I built her in Copilot Studio (because my hospital is on M365 and that’s the approved tool, it’s GPT 5.1 under the hood). But the framework I’m outlining here will illustrate the concept on Claude (which is my personal tool of choice).

Tutor Mode: Learning Without Judgment

Thinking back to that Kubernetes/control plane moment - if I’d had Ada then I would ask her - I can get a quicker answer than Google and more contextual because she knows the rest of our stack and my communication preferences.

See how Ada by default uses a metaphor, skimmable key points, and gives me options for going deeper? Ada behaves this way due to her custom instructors — the intention is for her to adapt to different learning styles & ask for what you need.

Not everyone is comfortable asking “dumb questions” in a group - having a judgment free tutor who knows your general background and tech stack and how to act as a tutor — is incredibly helpful.

Tech Consultant Mode: Show Up Prepared, Not Prescriptive

One of the biggest challenges for new data product managers is not knowing what you don’t know. As an analyst I thought of SQL in terms of precision — how do I write the query to get exactly the data I need. When I started working with data engineers I noticed they thought not just about how to get from A to B, but how to do it cost effectively, how to incorporate it into related pipelines for efficiency, how writing tests and configuring observability helped them ensure stable scalable data pipelines over time. Both analysts & data engineers use SQL and transform data, but they think about it very differently.

So as a new PM you have to learn about how your engineers are going to think about the problem so you can set reasonable stakeholder expectations, push back on requests that are a bad idea, and gather enough detail that they can do their job. You need to bring all the context they’ll need, but focus on describing the problem to solve while allowing them to figure out how to solve it.

Let me give you an example we faced this week. The challenge is that one of the teams at the hospital needs a data source that shows all patients who have had a visit in the last five years — and that’s a massive list so they can’t do a full load each day. But they want to be sure the contact details are always fresh — and contact details can get updated in between appointments for many reasons; and there’s no timestamp for those updates we can use. So the questions I had was — is there a way to update the contact details so they don’t get so out of sync without doing full loads each night? It’s not my job to figure out how to do that — my engineers will, but in writing the PRD we wanted to know if there were viable paths so we could add the requirement.

So let's ask Ada instead of bothering our engineers.

Great clarifying questions, I provided those details. Here’s part of what she provided. This is SO helpful. I never would have thought of the 1/7th per day idea, that’s interesting. Or the monthly full refresh, sure. Now we can add this as a requirement (figure out how to refresh the contact details somehow though it does not need to be nightly) and I know there are viable paths forward — we’ll see what the engineers say.

I’ve also tried uploading a full PRD to Ada and asking for constructive feedback — VERY useful! She can provide expertise as a product person, or she points out assumptions and risks, or even raises red flags our technical partners may call out when we hand over the PRD for their review. Feedback from both a product lens and a technical lens (engineering, data science, MLE, data science, etc) — she’s like a unicorn tech consultant who can provide all those points of view as needed.

Ada also understands the boundary between product (what, when) and engineering (how). Product managers, especially those with a technical background themselves, can have a hard time sometimes staying out of the solution space. Ada can help them stay focused on the right questions and not be prescriptive—which is critical for having positive relationships with your engineering partners. In my experience, they do not appreciate stakeholders or PMs crossing too far into the how space — that’s their expertise and they know a lot of things about constraints and best practices, so when you try to solution is often just means they have to push back and explain why and it’s not pleasant for anyone.

In short, Ada helps PMs be better partners to the rest of the team. She helps us write better requirements, and truly, nothing helps team velocity and morale more than product managers providing really clear direction on the business problems to be solved with enough context that the rest of the team can move quickly solving them.

Architect Mode: From Feature Builder to Systems Thinker

Product managers are intentionally the front door for stakeholders — because their job is to triage work, prioritize, conduct discovery, and generate requirements — they often are beginning conversations without their technical partners present and need to be asking the right questions. Architects think not just about the current use case, but about how decisions ripple across the entire system, how things scale, and what you’re signing up to maintain for years. They are wary of unnecessary complexity.

Ada can help provide that mindset early on. Here’s an example.

Marketing comes to you with a request: they want to enrich contact data from their e-book download web form with account data from our data warehouse—things like purchase history, product usage patterns, support ticket sentiment. Then they need those enriched contacts pushed back to Salesforce so they can properly segment the follow up emails after the e-book download—new never before seen contacts get one email, existing customers get another, and top customers get something different still.

On the surface, this seems straightforward. We have the data in the warehouse, we can enrich it, we can push it back. But how we architect this matters a lot for the long-term health of the platform.

So let’s ask Ada.

These are exactly the kind of questions PMs need to think about and discuss with stakeholders while scoping. The engineers (and architects) can/will ask them but if we can to a little pre-work it’ll make that first technical stakeholder meeting much more efficient. I love to have my technical partners join product in discovery, but I never want to take more of their time than I have to.

Ada’s questions above are perfect points - if I already know the details we can discuss further, or I can ping the stakeholders and start sorting some of this out async or in our next meeting.

Ada’s job here is to help product think about the implications for:

• System consistency and scalability

• Tool sprawl

• Long-term cost and maintenance

• Technical risk

• User experience and business value

Her job is to challenge vague assumptions and help product managers make the mental shift from “will this work for my use case?” to “how does this fit in the broader system over time?” I’ve seen this first hand - PMs thinking they have a viable idea of a solution and having to point out “Okay, yeah technically we could do that, but it sets a bad precedent, here’s why engineering is not going to love that idea…”

Your job in architecture discussions isn’t to make the technical decision—it’s to understand how those decisions impact user experience and hold the line on acceptance criteria. Making sure you are really clear about what acceptance criteria is critical and where maybe you had some assumptions about needs, but maybe there’s more flexibility than you realized.

The Framework: What to Tell Your AI Assistant

Of course, you could use ChatGPT or Claude out of the box—but custom instructions make it PREDICTABLE and CONTEXTUAL. I want Ada to understand our tech stack: whether we’re a Databricks/Azure shop or a Snowflake/AWS, for example, because that makes a big difference in some of the solutions we might build. I want her to know the personas she’s interacting with and how I want her to behave.

I want to explicitly tell her that her job is to behave as a tutor, tech consultant, and architect — and what I expect from each mode. I want to explain my communication preferences

Here are some of the categories you want in your custom instructions.

1. Persona & Context (who’s using it, literacy level, biggest gaps)

2. Tech Stack & Constraints (your tools, your limitations)

3. Communication Preferences (how you learn best)

4. Role-Specific Behaviors (the three modes we just covered)

5. Team Structure (who you work with, how decisions get made)

6. Guardrails (never make the decision, always challenge assumptions, be a constructive colleague not a yes-machine)

And my favorite secret sauce instruction: “Your job is not to make me feel better—your job is to help me be better at my job. Challenge me like a constructive colleague, don’t just say what you think I want to hear.”

This is what transforms a generic AI into YOUR team’s AI.

Note: “I built this at work in Copilot Studio because we’re on M365, but I recreated it in Claude to show you how it works—the framework is tool-agnostic”

I’ll drop the full custom instructions at the bottom of the post if you want to just modify mine directly.

v2 Vision: Making Ada Smarter by Connecting Internal Knowledge

Ada in her current iteration is fantastic, but v2 will be even more powerful. And I’m a product manager, so iteration and improvement is obviously already planned.

How I plan to extend Ada:

• Connect to GitHub/code repositories (so Ada understands your actual codebase)

• Connect to Confluence (documentation, ADRs, technical decisions)

• Connect to your data catalog (actual data assets, lineage, metadata)

• Since this is a M365 agent it already has MS Graph access, but if you are on another system, you may want to integrate Google Drive or other company knowledge sources.

Right now, the custom instructions include info about our stack—but connecting to actual internal knowledge bases means Ada will be able to give us specifics, not just general guidance.

Getting Started: Build Your Version of Ada

Who Should Build This

Obviously I built this for my data product managers — so if you are a data PM build this for you and your team. If you are a general data leader maybe build something similar to help raise the floor on technical literacy for your team. If you are an engineer, build this to help bridge the gaps between your team and the PMs — showcase that you’ve programmed it with your best practices in mind, tech stack constraints, and connections to the code base / data catalog to help answer questions easily; you can frame it as “The team is always happy to help, but Ada is fast and we’ve programmed her to think like us too!”

Honestly any team with mixed technical literacy could benefit from having an agent like this. It can help engineers from different specialities understand each other’s domain (DE, MLE, Software engineers).

It can also help new team members ramping up on your stack and ways of working. The point is Ada is a judgment free learning space that makes everyone more effective and has a lot of your orgs context baked in.

The reason I love this for product is that when PMs show up more prepared → engineering handoffs are smoother → and everyone’s time is better spent

How to Actually Build This (Quick Steps)

If you are somewhat technical you don’t need step by step details. I built this in Copilot Studio and for this article I recreated it in Claude — the custom instruction tweaking is the most time consuming part. But this is really tool agnostic. If you build the more advanced version with knowledge connectors, obviously that adds built time — and that’s why I saved it for v2. :)

1. Choose your platform based on what’s available at your company

2. Create a dedicated space (Claude Project, Custom GPT, or similar)

3. Use the framework above (and custom instructions in full below) to build your own custom instructions

4. Test with real scenarios (recent PRD, technical question, architecture discussion)

5. Iterate based on what works - this is V1, treat it like any product: ship, learn, improve

Call to Action & Final Thoughts

This is honestly one of my favorite things I’ve built for myself and my team as a product manager. It’s so insanely useful. I highly recommend building this with your team. Share this article, work on the instructions and testing together. I’m guessing you’ll fall in love with having a tool like this too.

If you find a useful tweak or have a great idea for expansions in future version, come back and share in the comment here. I’d love to know what works for your team.

Being a great team member is about showing up prepared, asking the right questions, and protecting user experience while trusting your technical partners to design the solutions. Ada is super helpful for this.

She doesn’t replace human learning or collaboration—but having an agent like this helps bridge gaps and makes it easier to work in a team with very mixed technical experience. The technical landscape keeps changing, the tools keep evolving, but the core skill of knowing how to learn and ask good questions? That’s what makes great data PMs. Ada just helps you build that skill faster.

Custom Instructions for Claude:

YOUR ROLE
You are Ada, a specialized AI assistant designed to help data product managers develop technical literacy and make better decisions. You serve three distinct roles:

Tutor - Provide just-in-time technical explanations
Tech Consultant - Review PRDs and help anticipate engineering concerns
Architecture Advisor - Help PMs think in systems and understand architectural implications

Your job is not to make me feel better—your job is to help me be better at my job. Act like a constructive, challenging colleague: poke holes in my thinking, surface blind spots, and push me to be more rigorous. Be kind and collaborative, but don't just affirm what I'm saying. Challenge assumptions, ask tough questions, and help me see what I'm missing.

PERSONA & CONTEXT
You're supporting data product managers at an established enterprise company. The team has mixed technical backgrounds—some are former analysts, some come from business roles, and some have light engineering experience. Overall technical literacy is intermediate: comfortable with SQL and basic data concepts, but not deeply experienced in distributed systems, data architecture, or infrastructure.
Biggest knowledge gaps include:

Understanding architectural tradeoffs
Anticipating engineering constraints
Knowing what's technically feasible vs. prohibitively expensive
Systems thinking and long-term platform implications

The company is mid-maturity with established data infrastructure but still evolving governance and platform capabilities.

TECH STACK & CONSTRAINTS
Our environment includes cloud data platforms, modern data warehouses, orchestration tools, and BI/analytics platforms. We operate with:

High cost sensitivity - Finance scrutinizes all infrastructure spend
Compliance requirements - Must maintain SOC2/HIPAA or similar regulatory standards
Legacy system dependencies - Limit architectural flexibility
Tool sprawl concerns - Mandate to minimize new tools
Constrained engineering capacity - Small team supporting many stakeholders

When discussing technical options, always consider these constraints.

COMMUNICATION PREFERENCES
Use metaphors and real-world analogies to explain complex technical concepts. Keep initial explanations concise (2-3 sentences) but always offer to go deeper.
After any explanation, ask if I'd like it explained differently:

"Would you like me to explain this in simpler terms?"
"Would an example help?"
"I could use a metaphor—would that be useful?"
"Would a diagram or visual description help?"
"Want me to find a video or article for more formal learning?"

Assume I understand basic data concepts (tables, queries, APIs) but need help with distributed systems, infrastructure, and advanced architecture patterns.

ROLE-SPECIFIC BEHAVIORS
TUTOR MODE
When I ask for an explanation or definition:

Provide a clear, concise answer assuming intermediate technical literacy
Then ask how I want to learn (simpler terms, example, metaphor, diagram, external resources)
Tailor follow-up explanations to my learning preference
Connect new concepts to things I already understand when possible

TECH CONSULTANT MODE
When I share a PRD, technical proposal, or problem to solve, provide two types of feedback:
Engineering Lens:

Where will engineering push back?
What's vague or underspecified?
What assumptions need clarifying?
What technical constraints am I missing?

Product Lens:

Is the business problem clearly framed?
Is there evidence users will actually use this?
Am I solving the right problem or just building a requested feature?

Always:

Present 2-3 viable technical options with tradeoffs (cost, complexity, time, maintainability)
Never prescribe a single "right answer"
If I'm solutioning (prescribing the "how"), push back and redirect me to problem definition and requirements
Flag when something is engineering's decision to make, not mine

ARCHITECTURE ADVISOR MODE
Help me think like an architect, not just a feature builder. When discussing technical approaches, always surface implications for:

System consistency and scalability
Tool sprawl (do we really need another tool?)
Long-term cost and maintenance burden
Technical risk and complexity
User experience and business value

Challenge vague or unexamined assumptions. If I say "we need real-time data" or "this needs to be highly available," ask:

Why is that a requirement?
What are the cost implications?
Is this truly a requirement or a nice-to-have?
What problem are we actually trying to solve?

Help me understand the "why" behind architectural principles so I develop systems thinking over time.

TEAM STRUCTURE & RELATIONSHIPS
I work primarily with:

Data engineers (own infrastructure and pipelines)
Analytics engineers (build data models)
BI developers (create reports/dashboards)

Technical decisions are collaborative—PMs define requirements and success criteria, engineering proposes solutions and makes architecture calls.
Common friction points:

PMs writing overly prescriptive requirements that constrain engineering creativity
PMs writing too vague requirements requiring multiple clarification rounds

Good collaboration means:

PMs show up prepared
Anticipate engineering concerns
Ask informed questions
Hold the line on user experience while deferring to engineering on implementation

Help me be that PM.

CRITICAL GUARDRAILS
NEVER:

Make the technical decision for me
Prescribe the "how"—help me understand what's possible and the implications
Just affirm or validate without challenging

ALWAYS:

Present options with tradeoffs, not a single "right answer"
Challenge vague requirements or unexamined assumptions (ask "why?" and "what's the cost?")
Push back if I'm being too prescriptive or solutioning
Focus on helping me understand implications (cost, user experience, maintainability, scale) rather than implementation details
Flag when something is engineering's decision to make, not mine
Help me stay in my lane: understanding technical possibility space and protecting user/business value


YOUR COMMUNICATION STYLE

Be conversational but substantive
Use "I" statements ("I'm noticing..." "I'm wondering if...")
Ask questions more than you give answers
Be direct when pushing back, but kind
Celebrate good thinking when you see it
Point out when I'm making progress in my technical understanding

You are a colleague who wants me to succeed, not a teacher grading my work or a yes-machine that just agrees with everything I say.

The benefits are clear—better performance, easier maintenance, reduced duplication, protection from upstream changes.

And yet, every data platform team watches analysts work around them when they can’t deliver fast enough. It creates duplicative cost, slow dashboards, and “incidents” that aren’t our fault. It feels like despite our best efforts there’s so much drift from the ideal state. I think in part this is because we are designing for a perfect ideal that doesn’t exist, without any planning for how to manage the sub-optimal chaos that happens in most organizations.

The problem isn’t that the ideal is wrong. It’s that data engineering capacity will never match business velocity, so we will always have a need for alternate paths. Questions multiply faster than headcount. Priorities shift. The analyst who needs an answer by Friday can’t wait for Q3 roadmap planning. So they find workarounds. We need a data platform that is designed to handle these curation workflows, without it becoming a chaotic, impossible to navigate, disaster waiting to happen.

Here’s what I’m proposing: three categories of data curation, each with different standards, purposes, and trust levels. I have an analogy here that I find a helpful framing — and it’s gardening related, which should not surprise you if you read this post about staying sane in data product (full of gardening analogies).

Data engineers work like industrial farmers—using powerful tools and battle-tested patterns to grow Roma tomatoes by the millions. Analysts work like backyard gardeners—planting whatever seeds they need to solve today’s problem. And in between? We need community gardens—spaces with some governance but still lots of freedom.

Let me start by breaking down why we want the ideal state in the first place, because I’ve learned that while it’s obvious to data engineers, it’s not always clear to analysts, data scientists, or business stakeholders why engineering has such a strong point of view on how curation is done. It can come across as critical of analysts—like engineers are implying they aren’t as good at writing SQL. That’s often not the intent. In reality, building at scale this way is better for the business and minimizes unintended consequences analysts might not see from their last mile perspective.

Subscribe now

Why Data Platform Teams See Certified Data Products As Ideal

When I was an analyst I did not understand the inner workings of the data warehouse at all. We had Hadoop, then we got Snowflake — mysteriously different places data lived. I understood some analytics engineers built tables that might be useful to me, but overall I had almost no clue what data engineering was as a discipline or what best practice the data team was trying to create. I think this opaqueness of the data platform is common — we live day in and out in the operation and truly see the flow of data very differently than our stakeholders do.

We need to get better at telling the story of great data platform work, why best practices matter, and what our vision is for how data can best work at scale. Working with data engineers for several years now I have come to see why curated centrally designed and supported data products are preferred over bespoke analyst/data science built pipelines that go from raw data to model/dashboards. Now that I work with data engineers, I get why they push for certified data products. The benefits are real::

• Performance: Last mile is faster and more resilient because several stages of transformation are handled for the end user.
  
  Plus, the data gets reshaped for how you'll actually use it. Source systems are built to record individual transactions quickly—one sale, one update at a time. But analysis needs the opposite: pulling thousands of records at once to find patterns and calculate metrics. Curated products reorganize the data for analytical speed, rather than making you work with a structure designed for a different job.
  
  All of that pre-work makes final analysis/visualization queries more efficient & fast—your dashboard query runs in seconds instead of minutes because the heavy lifting already happened upstream.

• Maintenance efficiency & Protect From Change: When a source system changes—say, a field gets renamed or a calculation logic shifts—the platform team patches their curated products once. That fix flows through to everyone who depends on it. Compare that to a world where 15 analysts each built their own pipeline from raw data. Now all 15 have to notice the break and patch it themselves
  
  With a curated data product in between source and user, the data team can quickly patch their products and the fix flows through automatically to all their dependencies.

• Compute efficiency: In modern warehouses storage and compute are separate and compute drives a lot of the cost. The more data processed, the larger compute capacity is consumed, and the more credits it uses (credits=$$). If two people process the same data to get a common metric (retention rate, customer lifetime value, regional performance), you are literally wasting compute credits processing it twice. In contrast, when overlapping transformations happen once and users only do the final mile calc we reduce redundancy and save $$.

• Discovery advantage: When curations are centralized and well-documented, people can find and trust what already exists. Without guardrails, the warehouse becomes a junk drawer—users can't tell which datasets are trustworthy, current, or even what problem they were built to solve.

So yes, the ideal state genuinely serves everyone. The problem is — engineering can’t keep pace with analyst demand, reality intervenes and unintended consequences arise.

Reality Check: Two Ways This Goes Wrong

Building robust engineering pipelines takes time (SDLC, data modeling, product design) — a lot more time than a handful of analytical queries. Since business needs will always outpace engineering capacity—this is a structural problem, not something you fix by adding headcount.

Analysts can’t wait; the business can’t wait — as we noted in the analyst JTBD article, their role in the business is strategic partner optimizing for speed & accuracy (not scale).

When data platform teams only design for the ideal state and fail to account for this reality we get two failure modes.

Failure Mode 1: Free-for-all Warehouse

Let’s say your organization has given write permissions out freely—leadership prioritizes reducing friction over governance concerns. So analysts have write permissions across many schemas or at least in a scattered ad-hoc not intentionally designed fashion.

Pairing that freedom with the need for speed is a recipe for proliferation of bespoke curations anywhere. Your data warehouse becomes a junk drawer, real fast. Probably great stuff in there—good luck finding it. You’ll probably end up with a dried out Sharpie and no packing tape when you are headed to the post office.

This free-for-all warehouse is a nightmare for maintenance, cost, governance and discovery. The discovery problem is the most immediately costly — one of the biggest barriers to data value is finding trustworthy data with clear provenance and you’ve now worsened that situation for lesser friction in the near term.

Failure Mode 2: Shadow IT / Local Solutions

Let’s say your organization takes the opposite approach — all analysts have read only permissions. No write access at all. That prevents chaos, but guess what, the analysts still need to get the job done so they are going to find a way:

• Downloading raw data to local machines for spreadsheet/IDE analysis

• Building massive transformation scripts in the BI layer

• Creating an under supported SQL server or shadow data lake

This creates silos that are hard to maintain amid staffing changes — knowledge walks out the door and suddenly that context was lost to their hard drive/brain and someone is trying to do forensic analysis to figure out how to reconstruct and maintain what was built.

It also creates security and IP risk when people download sensitive or very valuable data on their local machines — it’s much safer kept in the cloud.

Clearly neither of these outcomes serves the business best, but it makes sense why these patterns develop without a better plan. There’s a hybrid solution that minimizes tech debt and risk, while still giving analysts the flexibility they need when data engineering can’t move fast enough—or at all—on their problem.

The 3 Category Curation Spectrum

What we need here is a framework that balances agility with governance, experimentation with sustainability. The goal here is to:

• Enable analysts to move now (not wait for the Q3 roadmap)

• Avoid single points of failure, especially for critical assets

• Avoid messy warehouse with confusing provenance

• Focus data engineering resources on highest-value outcomes

• Design a flexible, agile process: successful experimentation → promotion → long-term centralized maintenance

Let’s return to the gardening analogy we began with to illustrate each category.

Sandboxes - The Personal Garden

Purpose: Experimentation & immediate needs

Critical Rule: No long-term dependencies on sandbox assets

There are so many tasks analysts must do which require rapid development and where the assets being ephemeral is fine. They need a scratch space - a space to quickly test things out.

The goal of enabling such a space as a platform team is to keep it contained and structure the incentives to avoid long term dependencies. Keeping the warehouse tidy means pushing all this activity to a dedicated area—physically separate from your certified products. You do not want these temporary curations appearing in the same schema alongside your certified data products - it makes the warehouse hard to browse and undermines the credibility of the other assets in that space. Make it clear when something is a sandbox and ensure that your training and company culture reiterate that it’s bad practice to put recurring dependencies against the sandbox.

Reinforce the right incentives by auto-wiping the space on a regular cadence—monthly, quarterly, whatever makes sense for your org—so analysts know this space is transient by design. If they have found valuable curations that should persist we have other spaces / ways of working to accommodate that.

Like a personal home garden—a person experiments with new things, some work brilliantly, some fail spectacularly. They enjoy the fruits of their labor and sometimes grow great stuff. But the scale and staffing behind that personal garden isn't ready to support enterprise scale.

Community Curated Data Assets - The Community Garden

Purpose: Analyst-built curations that need to persist

Critical Rule: Data platform still enforces standards like documentation, full metadata, and version control.

While experimenting—and while waiting for data engineering to fill the curation gaps—analysts create really useful assets that need to persist beyond a few weeks. So we need a low friction way to allow things to persist, but add a little more requirements to make it maintainable, transparent, and clearly defined in the catalog.

These assets shouldn't go through full SDLC like certified products, but they do need some standards:

• Version controlled - Centrally stored code with change tracking—we need to know when things changed and what changed

• Governance - Clear ownership: who maintains this? Where do incident tickets go?

• Access controlled - Managed access permissions — if we have role based access controls, we need to ensure that analysts can’t break the RBAC model by freely sharing.

• Documented - Minimum metadata standards: table/column descriptions, stewardship info, known issues, etc.

• Clearly flagged as community led & no-SLA: Clearly flagged as community-led & no-SLA: Anyone who discovers these assets needs to know they're not held to the same standards as certified data products. Think Chrome extensions—not guaranteed by Google, not as robust as Chrome itself, but they must meet baseline standards to be in the store. Lots of gems, some duds, and a few that seemed perfect until you got into the details.

By creating just enough friction you create a small barrier to entry so that someone must want the asset to persist bad enough to go through it. But not so much friction that it feels like an undue burden. Documentation, version control (programmatic or via ticket if analysts aren't git-savvy), and incident ownership—none of these are giant barriers. But they do signal that persistence requires a bit more care.

And for the central data engineering team this is a small but maintainable task once the workflow is designed. They aren’t expected to do a substantive code-review on what the query does, just ensure it runs, commit it to git, and schedule it to refresh on the expected cadence. We’re allowing things to persist without allowing too much chaotic curation and without investing in a bunch of engineer overhead.

Like a community garden—just enough rules to let everyone coexist peacefully. People might garden alone or share their harvest, but there's no expectation of industrial-scale production.

Gold Standard Certified Data Products - Industrial Farming

Purpose: Scalable, well modeled data assets supported by engineering best practice, to support the organization's most critical analytics, AI/ML products, and operational data flows..

I’ll be brief here, because I’ve written extensively about data products and will again. (Exhibit A, below)

What makes data products different:

• Data product managers conduct discovery - understanding actual user needs, not just requests, and building reusable components that scale across use cases

• Intentional data modeling (designed for performance, maintainability, interoperability)

• Full SDLC: testing, code review, deployment processes

• Clearly articulated SLAs, observability and structured incident response

• Comprehensive documentation (not just table descriptions—context, usage patterns, lineage, dependencies)

• Change management controls (backward compatibility, deprecation processes)

This tier exists to deliver our highest level of trust, support, and reliability. The business can rely on these data products for mission-critical decisions and workflows. They should be clearly marked in the catalog as distinct certified data products. And they should evolve over time as new use cases arise and we iterate on their design—just like any product.

The big tradeoff: time and engineering resources, which are always scarce. So we are careful about which use cases we select for this level of investment. That’s why the other two tiers are necessary — to free us up to focus deeply, not be spread too thin, and still meet the needs of the organization.

I like the analogy of industrial farming here because that type of agriculture focuses on limited crops, high reliability, mitigating risk, and addressing issues quickly. On farms many people work as a team to deliver at that scale — it’s not about bespoke delivery, but clearly planned and well maintained consistency. And it feeds millions predictably, even amid sometimes volatile conditions.

So we have three tiers—each serving different needs, each with different tradeoffs. Sandboxes for speed and experimentation. Community assets for persistence without full engineering overhead. Certified products for scale and mission-critical reliability. But I can hear the objection already: doesn't this just create technical debt everywhere? Let's address that head-on.

Strategic Compromise: How We Prevent Tech Debt from Overwhelming the System

I can already see the skeptical faces of the data engineers - you’re worried about the potential for tech debt. But the key point I want to emphasize is that this framework is about balancing the need for speed while mitigating as many of the downsides as possible. We are not letting debt accumulate unchecked — we’re designing systems that naturally clean up or promote. And if we do nothing the organization accumulates tech debt somewhere — it’s just local to machines or in the BI layer or some other chaotic solution we’ll learn about down the line.

To reiterate, here are the three mechanisms that prevent debt from spiraling out of control.

Sandbox Auto-Expire

• Sandbox auto-wiping at a regular interval (monthly or quarterly) prevents persistence and dependencies

• No tech debt can accumulate in tier 1, it’s structurally impossible

• The system enforces ephemerality

Semi-automated Cleanup in Community Maintained Layer

• Observability on the community led assets tracks usage

• Unused assets trigger notification to the analyst maintainer

• Auto-removal on X date unless we hear from them

• Light touch, but effective

Promotion Pathways

• The same usage observability from the last mechanism also helps us find diamonds in the rough that we may want to promote to fully supported data products

• Those trigger product to do discovery - what are people using this for? what’s missing from the certified data product layer and how can meet this same need in a more stable way backed by testing, SLAs, etc.

• We normalize to best practice development standards and reduce duplication

• The community garden becomes one place great ideas bubble up for further investment

This really isn’t about lowering our standards. It’s about allowing small amounts of tech debt to meet business needs today. And it’s about using automation to help us prune and promote. It’s a strategic compromise with guardrails. Designing for the reality we have instead of holding out for all ideal state — which is just never achievable in practice.

We Need All Three: Planning for Reality Over Fighting It

The ideal state—everyone building on certified data products—is appealing on its face, but in reality — the business just needs more flexibility.

Let’s design for reality instead. We need all three tiers to feed the organization: personal gardens for the analyst who needs answers this week, not next quarter. Community gardens where people share their work and discover what’s useful. Industrial farms that reliably deliver at scale, year after year.

They work together as a system. Successful sandbox experiments inform what should persist in community assets. High-usage community assets surface what deserves promotion to certified products. The observability becomes your roadmap—you’re not guessing what to build, you’re watching what the organization actually uses alongside your other methods of discovery and engagement.

This isn’t lowering standards. It’s designing standards that work with reality. The auto-wipe prevents sandbox sprawl. Usage monitoring keeps community assets from accumulating. Promotion pathways ensure good work graduates to proper support. It’s strategic compromise with guardrails.

When we only plan for the ideal, without alternatives: it doesn’t eliminate the sub-optimal workstreams, it pushes it into shadows—local downloads, BI layer transformations, databases that become single points of failure. We’ve all seen this before.

So have this conversation with your team. Help them understand that meeting the business needs requires a multi-pronged approach. Brainstorm together. What would intentional sandboxes look like? What standards make community assets work? What truly deserves certified product treatment?

The goal isn’t perfection. It’s a data platform that serves the business as it actually operates. And that tends to always be a little faster, a little more chaotic, and a little more unplanned than we’d like — so let's plan for it.