Product Operating Model Series: Trust over Control

Issue #235

Destare Foundation, Alex Dziewulska, Katarzyna Dahlke, and 3 others

Feb 03, 2026

∙ Paid

In today's edition, among other things:

💜 Editor’s Note: Your “Empowered” Teams Are Probably Miserable and Alex Confession on AI - MUST READ
💜 Product Operating Model Series: Trust over Control

Join Premium to get access to all content.
It will take you almost an hour to read this issue. Lots of content (or meat)! (For vegans - lots of tofu!).
Grab a notebook 📰 and your favorite beverage 🍵☕.
DeStaRe Foundation

Editor’s Note by Alex 💜

Your “Empowered” Teams Are Probably Miserable

Why the gap between empowerment rhetoric and reality is burning out product managers faster than honest command-and-control ever did.

A few months ago, I had a call with a CEO. He told me his two product teams are EMPOWERED. All capitals. He wanted me to know.

They’d done the training. Product operating model. Discovery workshops. Outcome-focused OKRs. They’d hired a product coach. Read the books. All the boxes checked. I was impressed. On paper, this was exactly what good looks like.

But something in my gut called bullshit.

I asked if I could observe a product demo. Just watch. Get a feel for the team dynamics. He was delighted to show off.

Here’s what I saw: The CEO called every shot. Not just priorities—task estimations. He decided how long things would take. The team sat there, nodding. Nobody proposed anything. Nobody pushed back. Nobody mentioned customers.

Except one person. A product manager who mentioned user interviews. Apparently users kept raising a specific problem—she’d heard it enough times to bring it up. Before she could finish her sentence, the marketing lead cut her off. “We already have a campaign about that.”

And that was that. Discovery shut down in real time. By a marketing campaign.

This company had done everything right. The vocabulary. The training. The operating model on paper. And underneath all of it: the same command-and-control architecture they’d always had, now wearing empowerment as a costume.

I’ve seen this pattern enough times to stop being surprised. But the damage it does still gets to me.

The timeline is clear. Cagan’s Empowered drops in 2020. The book articulates what the best companies already do: give teams problems to solve, not features to build. Make them accountable for outcomes, not output. Trust them with discovery, not just delivery.

The ideas spread. Conference talks proliferate. The terminology enters the water supply. Every company wants empowered teams now. It sounds better in investor decks. It attracts better candidates.

But most organizations adopted the language without the structural changes. They declared empowerment while keeping the CEOs in estimation meetings. They asked for outcomes while shushing anyone who mentioned actual user problems. They wanted missionaries but kept the mercenary architecture.

The damage runs along a specific psychological pathway.

Denise Rousseau’s psychological contract theory explains why this particular gap is so corrosive. When employees perceive a breach between what the organization promised and what it actually delivers, they don’t just get disappointed. They get cynical—a specific emotional state characterized by distrust, disillusionment, and diminished effort. Research published in the Journal of Organizational Behavior found that cynicism fully mediates the relationship between psychological contract breach and emotional exhaustion. The gap between empowerment rhetoric and command-and-control reality doesn’t just annoy people. It burns them out.

This wouldn’t matter if organizations simply never adopted empowerment language. Traditional command-and-control is honest. It says: here’s your roadmap, execute. The psychological contract is clear even if the work isn’t satisfying. There’s no gap between rhetoric and reality because there’s no rhetoric.

But “empowered” organizations promise something different. They promise autonomy, mastery, purpose—the three basic psychological needs that Deci and Ryan’s self-determination research identifies as essential for intrinsic motivation and wellbeing. When organizations invoke empowerment language and then deny actual autonomy, they’re not just failing to motivate. They’re creating a specific form of psychological harm. Need frustration doesn’t produce neutral disengagement. It produces burnout, cynicism, and counterproductive work behavior.

Nils Brunsson called this organizational hypocrisy. In his research on how organizations manage conflicting demands, he found that talk, decisions, and actions can systematically diverge—and sometimes this divergence serves the organization’s legitimacy even as it damages its effectiveness. Companies can talk empowerment to attract talent, decide on roadmaps to please stakeholders, and act on whatever the loudest executive demands. Each layer serves a different audience.

But Brunsson also documented what happens when employees notice the gap. The “organizational hypocrisy gap” widens until healthy skepticism becomes destructive cynicism. Employees start wondering what planet management lives on. Morale tanks. The word he used was “Dilbertism”—when management’s description of reality diverges so far from lived experience that the only sane response is irony.

That PM in the demo? The one who got shushed? She’s not going to mention user interviews again. She learned that discovery is theater in this company—something you do in workshops but not in actual product decisions. That’s not disengagement. That’s learned helplessness. And it’s happening in companies that genuinely believe they’re empowered.

Cagan himself has been explicit about this. In recent talks, he’s noted that most teams are still feature teams—cross-functional in name, executing roadmaps in practice. “If you have roadmaps and OKRs,” he’s said, “that doesn’t really make sense. Roadmaps mean feature teams. OKRs end up being just theatre and meaningless.” The language migrated. The operating model didn’t.

The data reflects it. Mind the Product found that over 80% of product managers have experienced or are currently experiencing burnout. Gallup reports that global employee engagement fell in 2024—only the second decline in twelve years, matching the drop during COVID lockdowns. Manager engagement fell even harder, down three percentage points. These are people being asked to deliver empowerment they don’t actually have authority to provide.

Now, the strongest case for fake empowerment is pragmatic: organizations can’t flip a switch. Genuine empowerment requires leaders who trust teams, teams that have earned trust, and business context that supports experimentation. Maybe the rhetoric has to run ahead of reality to create pull toward change. Maybe saying “empowered” enough times eventually makes it true.

I understand the appeal. Change is hard. Language shifts faster than structure. Some organizations really are on a journey, and the language is aspirational rather than deceptive.

But here’s where this breaks down: the psychological contract research shows that gaps between promises and reality don’t create positive tension toward change. They create cynicism. And cynicism is corrosive to the very capabilities empowerment requires. Teams that feel betrayed by empowerment theater don’t become more motivated to develop competence. They become defensive. They stop proposing. They stop discovering. They start executing tasks and protecting themselves.

The companies that actually moved to empowered teams—Netflix, Spotify, Amazon—didn’t start with the language. They started with the structure: genuine accountability for outcomes, real authority over discovery, actual consequences when things work or don’t. The language followed the reality. In fake-empowered organizations, that sequence is reversed—and the psychological damage accumulates with every demo where the CEO calls the task estimations while the team stays silent.

So here’s what actually needs to change.

Stop using empowerment language if you’re not structurally empowered. It’s not inspiring. It’s gaslighting. If your teams execute roadmaps decided elsewhere, call them delivery teams. At least the psychological contract is honest.

If you want real empowerment, change the operating model before you change the talking points. That means problems, not features. Outcomes, not output. Discovery time protected in every sprint. PM authority over what gets built. CEO out of the estimation meetings. These are structural decisions, not motivational speeches.

Audit the gap. Ask your teams whether they feel empowered. Actually listen. If they laugh—or worse, if they go quiet—you have organizational hypocrisy. That’s not a training problem. That’s a burnout factory with good marketing.

I don’t have a tidy prescription for organizations caught in this gap. That would be dishonest. Moving from feature teams to empowered teams is genuinely hard—it requires leaders who’ll give up control, teams who’ll take accountability, and businesses willing to tolerate the uncertainty that comes with real discovery.

But I know what doesn’t work: pretending you’re already there. The rhetoric-reality gap doesn’t motivate change. It breeds the cynicism that makes change impossible.

That PM who got shushed? She’ll leave within eighteen months. She’ll find an organization where discovery actually matters—or she’ll burn out and leave the profession entirely. Either way, the CEO will wonder why he can’t retain good product people despite all the empowerment training he’s invested in.

Stop calling your teams empowered if they’re not. The psychological damage is worse than honest command-and-control ever was.

Alex AI Confession :D How I Actually Use AI to Write This Newsletter

Some of you wanted to know how the Product Art newsletter process works. Some to be mean and say it’s all AI. Some were genuinely curious. For all of you: here’s my process laid bare.

My team works differently. This is mine.

The Genuinely Human Part: Ideas

I never go to AI for ideas.

AI ideas are flat. Average. They feel like every other piece of content you’ve scrolled past this week. Smooth. Inoffensive. Optimized for engagement, not truth. The moment you let a machine generate what you’re going to think about, you’ve already lost the game. You’ve outsourced the only part that matters.

So what drives my ideas? Honestly? Rage.

I have this bottomless pit—or lake, whatever your imagination prefers—where all my 46 years of frustrations live. Endless meetings that could’ve been emails. Stupid bosses who confused confidence with competence. Politics that rewarded the loudest instead of the right. Inertia dressed up as risk management. Hopelessness that creeps in when you watch smart people do dumb things because the system rewards it.

You know this place. You probably have your own rage pits. Decades of accumulated what-the-fuck that you can’t quite let go of because it’s still happening, every day, in organizations that should know better.

But here’s the thing: part of me is all rainbows, unicorns, glitter, and hope. That’s not irony—it’s survival. I look at what frustrated me this week AND what inspired me. The constant human drive to be better. To do better. To strive for perfection and thrive in chaos—though that last part might just be my ADHD talking.

Is there a middle ground between rage and hope? Sure. But the middle ground is boring. Lukewarm takes nobody remembers. Safe observations that change nothing. I leave it to those who are afraid to speak. I don’t care for corporate bullshit dressed up as thought leadership.

Why I Write in English (Even Though I’m Polish)

Quick detour that matters more than you’d think.

I write in English because English has less negative affect. Polish is beautiful. Polish is precise. Polish is also, culturally, soaked in martyrology. We’re a nation that has survived being erased from maps, partitioned between empires, and occupied by everyone from Nazis to Soviets. That history lives in the language. It makes Polish incredibly rich for expressing suffering, endurance, and collective trauma. Less great for work that requires forward momentum.

In English, I can say: “I did it.”

In Polish, I would say: “Udało się.” Which translates literally to “it succeeded” or “it managed to happen”—the agency removed, the achievement made passive, as if success happened to me rather than because of me.

English also has words that Polish simply doesn’t. “Shipping.” “Deliverable.” “Commit.” “Scope.” The entire vocabulary of modern product management exists in English because that’s where it was invented. When I write in Polish, I’m constantly translating concepts that lose something in the process. When I write in English, I’m thinking in the native language of the work.

No offense to my country. I’m a patriot. I pay my taxes. I vote. I love the food and the complaining and the dark humor that gets us through everything. But for work that needs momentum, optimism, and precision—English lets me think differently.

My Knowledge Engines

NotebookLM: The Hallucination Shield

I keep 89 notebooks there. Sources I’ve verified and trust. Books. Research papers. Frameworks that actually hold up under scrutiny. Primary sources I’ve fact-checked against other primary sources.

I use it as a recognition machine. When I’m looking for a concept, a quotation, something I know I’ve read but can’t place—NotebookLM doesn’t hallucinate. It either finds it in my corpus or it doesn’t. That binary certainty is worth everything when you’re building arguments that need to stand up to skeptical readers.

AI hallucinates. It’s not a bug, it’s a feature of how these systems work—they predict plausible next tokens, and sometimes plausible isn’t true. NotebookLM constrains the search space to things that are actually in my documents. If Kahneman said something about prospect theory, NotebookLM will find the quote. If Kahneman didn’t say it, NotebookLM won’t invent it.

Claude Projects: Where the Work Lives

All my work lives in projects. 234 of them at last count. Rare chats stay separate, but everything meaningful is organized.

Every project has my profile—there’s a Claude skill I called “Klaudiusz” (yes, we agreed on the name, and yes, it’s the Polish version of Claude, and yes, I find that funny). It contains my human profile, product profile, expert profile. Generated as a context file for every project. I hate repeating tasks. So AI does that for me.

I feed projects with files, ideas, concepts, materials. But here’s what matters: every project has a second skill that works as a learning loop. Any time I learn something that should improve the project instructions, I log it. The system tracks changes, errors, things that didn’t work. After five logged items, it prompts an instruction rewrite. With feedback, the project remembers what went wrong and stops doing it. Novel concept, I know.

Another skill that never leaves me: the notetaker. I say “book it” and it logs my ideas, concepts, revelations to a file I can check later. It’s also a project file, so Claude can help me find ideas I’ve already booked. The number of times I’ve had a brilliant thought at 3am and forgotten it by morning—now there’s a system that catches what my memory drops.

The Multi-Tool Reality

I pay for Claude Max—the $200/month tier with 20x more usage. That sounds like a lot until you realize I’d spend more on a single consulting hour. The ROI isn’t even close.

I also have pro edu subscriptions to Gemini and ChatGPT. Why both? Partly because I can’t let go. Partly because different models have different strengths. ChatGPT does wicked corpo talk—that smooth, professional, slightly soulless language that enterprise clients expect. I need it for pitches sometimes. Gemini has interesting multimodal capabilities. Claude thinks more like I do.

I use other tools too—Gamma for presentations, Lovable for prototypes and many more—but that’s not what this post is about.

Tip: You can connect NotebookLM with Claude to limit hallucination further. Look for “notebook-mcp”—it’s an open-source Model Context Protocol connector that lets Claude query your verified notebooks directly. Technical setup required (you’ll need to be comfortable with command line and API keys), but worth it if you’re building knowledge-intensive workflows where accuracy matters more than speed.

The Research Engine

I have several Claude skills just for research. Deep research. Verifying claims. Finding scientific studies. Checking data against primary sources.

I use it to support myself with actual arguments for my thinking. Not to generate the thinking. To support it. The distinction matters. I arrive at a position through experience and pattern recognition. Then I find out whether the evidence backs me up or proves me wrong. Sometimes it proves me wrong. That’s valuable too.

I no longer use Perplexity. Claude does a better job in my opinion—deeper reasoning, better synthesis, fewer hallucinations when properly constrained.

I have a script for extending Claude’s limits on deep research. Claude can now use extended thinking mode—basically, it can spend more time reasoning through complex problems before answering, up to 128,000 tokens of internal deliberation. Combined with web search and tool use, you get research that actually thinks rather than just retrieves.

The output structure matters more than the research itself.

I don’t use traditional deep research templates. The generic “Background → Findings → Methodology → Conclusion” format is useless. It’s structured for the AI, not for the work.

Research output needs to match what I’m actually doing with it:

When I need to stress-test my own thinking:

"Here's my argument: [Argument]

What am I assuming that I haven't stated?
- Empirical assumptions (things I assume are true about the world)
- Logical assumptions (inferential steps I'm skipping)
- Value assumptions (things I assume readers care about)
- Audience assumptions (what I assume they already know/believe)

Which assumptions are most vulnerable?"

The research serves Claude as much as it serves me. We’re collaborating. So I tell Claude what format works for both of us—what I need to make decisions, what Claude needs to build on the work later. Research without the right structure is just noise I have to re-process. And I’m lazy, I don’t want to redo the work.

The Fight Engine

This is where it gets interesting.

I use Claude as a sparring partner. Finding counterarguments. Playing devil’s advocate. We both take that role—sometimes I argue my position and Claude attacks it, sometimes Claude argues a position and I attack it. Looking to see how the other side looks.

Usually I do this with my team. We have people who love to argue, which is exactly what you want when you’re trying to stress-test ideas. But Claude is never tired. Never busy. Never needs context you’ve already given three times. Always ready to go at 2am when the coffee hits and the argument won’t let you sleep.

I value human thinking. Humans bring intuition, lived experience, emotional intelligence that AI can’t replicate. But humans aren’t always available. Claude is.

Some examples of how we actually think together:

“What if our entire premise about PM skill development is backwards? What if deliberate practice isn’t the answer—what if the PMs who advance fastest are actually the ones who don’t overthink their craft?”

Claude came back with an argument about intuitive expertise vs. explicit skill-building. Cited Dreyfus’s model of skill acquisition—the five stages from novice to expert, and how experts often can’t articulate what they do because it’s become automatic. Made me realize I was conflating “deliberate practice” with “overthinking”—they’re not the same thing. Deliberate practice is focused and intentional; overthinking is anxiety dressed as preparation. Changed a whole section of an editorial.

The more unhinged one:

“What if the entire concept of ‘product-market fit’ is a psyop designed to make founders feel bad so VCs have leverage in funding negotiations?”

Absurd? Yes. But Claude played it straight. Built an argument about how PMF mythology creates learned helplessness. How the term was coined by Andy Rachleff in a specific fundraising context. How it’s become unfalsifiable—if you fail, you didn’t have PMF; if you succeed, you had it. How “searching for product-market fit” has become an excuse for VCs to delay commitment while founders burn runway. That conversation became a thread I’m still pulling on. Probably an editorial eventually.

The point isn’t that AI has answers. The point is that AI can hold a position I need to argue against without getting offended, without forgetting context I’ve already given, without getting tired, without needing to be managed.

The Rhythm: Flow Time, Not Clock Time

Quick note on when this actually happens.

I don’t work in days. I don’t have a morning routine. I don’t do “4 hours of deep work between 9am and 1pm” like the productivity bros recommend.

I work in sprints. Twenty hours of caffeine-induced focus, then I sleep. I don’t care if it’s morning or night when the sprint ends. Clock time is for people with commutes.

Night works better for certain things. No calls. No Slack messages demanding immediate attention. Just the quiet breath of loved ones—both human and furry—and the hum of the air cleaner. (The Mac is too quiet to hum. That’s not a flex, that’s a complaint. I miss the whir of fans that told you the machine was working.)

My life runs on flow time and rest time, not day and night. The AI tools are always available. That matches how I actually work better than any human collaborator could.

The Actual Human Part: Drafting

This is something I don’t allow AI to touch.

I write. Because I like my never-stopping train of thought. Seamlessly flowing. Multi-threaded. The way one idea leads to three others and you have to choose which to follow while keeping the others in peripheral vision.

My drafts look like spaghetti. No punctuation. Flow of thoughts. Not perfect structure. Literówki everywhere—that’s Polish for typos, though the word is more fun. To make it readable to actual humans, I use my structure engine.

The Structure Engine

It does exactly what it sounds like.

Takes my draft with a preserve condition: don’t you fucking dare change a word. Then it does nice structure with headers, proper paragraphs, and punctuation. It also verifies data claims I made in the draft one more time—every statistic gets checked against sources before publishing.

Structures according to Substack best practices. Formats for readability on mobile. Breaks up walls of text into something scannable.

And since I loathe SEO, it does a quick check for me. I refuse to write for algorithms. I refuse to stuff keywords into headlines because some tool said it would improve discoverability. I refuse to turn every post into a listicle because listicles perform well with the algorithm. That’s not writing—that’s content production. There’s a difference.

But I’ll let a machine make sure I’m not accidentally invisible. Basic SEO hygiene without compromising the work. That’s the deal.

Why I Hate SEO Content (And What That Has To Do With Anything)

Quick rant while we’re here.

Content created for SEO is artificial. Non-human. But it’s visible—that’s the whole point. It’s optimized to show up, not to matter.

It’s like Instagram influencers. You want to show something nice and valuable. But the algorithm loves AI ASMR, unboxing videos, rage bait, before-and-after transformations. So you either play the game or accept obscurity.

I choose obscurity over selling out. Not because I’m noble—because I literally cannot write that way without feeling my soul exit my body. Some people can optimize for engagement. I optimize for saying things that are true, that matter, that might piss someone off because they needed to hear it.

The newsletter grows slower than it would if I played the algorithm game. I can live with that.

The Disclaimer

Editorials and LinkedIn posts are done by me completely. With research and all.

I need the output for my writing needs. The drafting, the messy first version, the finding out what I actually think by seeing what I write—that’s the part I can’t outsource. So editorials and LinkedIn are a little messier. That’s the point—some things need to come from the chaos, not the structure.

Here you have it. Alex and her AI. Groundbreaking collaboration for the ages. Truly unprecedented in human history. Someone call the Nobel committee.

Or AI police, whichever works for you.

Love, Alex 💜

📝 Product Operating Model Series

Trust over Control: Reference Guide

Product Operating Model Principle 18 — Quick Reference

Core Principle

“Moving from the command-and-control model to the product model is not only a change in competencies and concepts, but it represents a fundamental cultural change. It is a model that depends on trust rather than control.” — Marty Cagan, Transformed

What It Means

FROM (Control) TO (Trust) Stakeholders provide prioritized feature lists Teams empowered with problems to solve Hands-on micromanagement Servant leadership with active coaching Approvals, sign-offs, permission Context: strategy, assumptions, objectives, constraints Leaders make decisions Leaders remove obstacles and provide context Compliance with process Judgment within principles Teams execute instructions Teams own discovery AND delivery

The Evidence Base

Key Research Findings

Source Finding Impact Google Project Aristotle Psychological safety #1 predictor of

Continue reading this post for free, courtesy of Destare Foundation.

Or purchase a paid subscription.

💜 PRODUCT ART 💜