At Universal, I checked the app a few times a day to glance at wait times. Are the lines short enough to ride again? At Disney, I refreshed the app all day, trying to catch Lightning Lane availability before it disappeared. Lightning Lane availability pops up at unpredictable times throughout the day. If I missed the window, we missed the ride.

One park had us present with our kids, and the other had us managing a system.

The gap between a system that works for you and a system that asks you to work for it is a product design lesson that felt so obvious, I couldn’t ignore it.

Where we stayed changed everything else

We stayed at the Portofino Bay, which is one of Universal’s on-site resort hotels. That one decision of where to stay shaped our entire trip. Universal’s Express Unlimited pass was included with the room. It’s usually an upsell if you’re staying at a non-Universal property. Once you have the pass, there is no additional cognitive overhead of tier selection or budget math each morning. It was just there.

The boat ride to the parks from the hotel ran every few minutes. Security screening happened at the dock before we boarded, not at the park entrance with thousands of other guests. By the time we stepped off the boat, we walked straight to the park entrance.

At the turnstiles, Universal uses facial recognition for “photo validation.” We scanned our cards once each day to link our faces. After that, we just walked up to the express lanes. Our faces were the credentials, so no fumbling for phones, no scanning wristbands, no pulling up the app was required.

The pass, the transport, the security, the entry — all of it managed the complexity before we ever encountered it. Nobody at Universal had to rescue the experience for us. The system never created a moment that required a person to step in and explain something or fix something.

How often can we say that about the products we build? How often does one good upstream decision make everything downstream easier for our users?

The same ride, three times

Express Unlimited didn’t just save us time. It changed how we experienced the parks.

My kids are really into Harry Potter right now, so the rides were the ones we experienced the most. The first time through, they felt the thrill. The second time, they started catching story details, the portraits moving, the spells, and the characters. By the third ride, they were pointing things out to each other, fully absorbed in the world.

That only happened because Express Unlimited doesn’t limit you to one ride per attraction. We didn’t have to plan which rides to prioritize; we just followed whatever our kids were excited about.

Disney’s Lightning Lane works differently. One ride, one redemption. If you want to ride again, you’re back in standby or selecting/buying another pass, if it is available. It steers you toward breadth, so you see as many things as possible, rather than letting you go deep on the ones you love.

And it doesn’t just limit what you ride. It limits how your family moves through the day. One evening at Hollywood Studios, it was raining, and our Slinky Dog Dash Lightning Lane was booked for 7:30 pm. So instead of heading back to the hotel, we waited around in the rain because we’d lose the reservation if we left. The system was managing our evening, not us.

The way I see it, that’s a real design difference. Universal is built for the family that finds something they love and wants more of it. Disney built for the guest who needs to be moved through a sequence. And every time a system moves people through a sequence instead of letting them self-direct, it creates moments where someone has to pick up the slack. Those decisions come from the system, not from the people in it.

Disney knows how to remove friction

As a product person, this is what made the trip so interesting to me: Disney is clearly capable of designing for the guest. Their Imagineers are some of the most studied experience designers in the world.

The app’s integration with mobile food ordering works really well — pick a restaurant, order from the app, and show up when it’s ready. MagicBand handles payments, hotel room entry, and park access in one tap. Dining reservations are fully integrated into the app.

Disney knows how to make friction disappear. So when Lightning Lane is confusing, that’s not a capability gap. It’s a design choice.

And the numbers back it up. The predecessor to the Lightning Lane was Disney’s FastPass+ system, and it used to be free. It was included with park admission from 2013 until it was quietly discontinued during the COVID closure in 2020. It never came back.

What replaced it was Genie+, which launched in October 2021 at $15 per person per day. That became Lightning Lane Multi Pass, which now costs $24 to $45 per person per day, depending on the park and date. If you want to skip the line for a premium ride like Guardians of the Galaxy or Tron, you have to buy a separate Lightning Lane Single Pass — $7 to $25 per ride, per person. If you want everything included, then the Lightning Lane Premier Pass runs up to $449 per person for a single day at Magic Kingdom.

Disney’s leadership has been open about the strategy. On a 2022 earnings call, then-CEO Bob Chapek described the parks as playing a “yield game” — using dynamic pricing and reservation systems to “increase per-capita spending meaningfully.” Per-guest spending was up 40% compared to 2019. His successor called the pricing “alienating” — but kept the system in place.

What used to be included became a revenue layer. The tiers, the time windows, the daily purchase decisions, the pop-up availability you have to catch — that’s where the yield lives. And as a parent standing in the park with two kids, every moment of confusion that system creates is a moment someone has to deal with. Either I figure it out, or the person working the terminal does.

Who carries the friction?

Both parks had kind, pleasant staff. Nobody was rude to us at Universal. Nobody was unhelpful at Disney. The people at both parks were nice.

What was different was what each system asked of the people in it.

At Disney, the cast members are warm, well-trained, and helpful. They have to be — because the system keeps creating moments that need human recovery. A family whose Lightning Lane expired because a ride was closed during the window or while they were figuring out where to eat. A guest who bought a Multi Pass but didn’t realize the ride they wanted required a separate Single Pass purchase. A parent trying to understand why the pop-up availability they saw ten minutes ago is already gone.

None of those moments is the cast member’s fault. They’re the system’s. But the cast member is the one dealing with them a hundred times a day.

I see this in product work all the time. We offer 8 plan options with dynamic pricing, and sales reps have to untangle them for customers. We add complexity to the product and then add documentation to explain the complexity. The friction doesn’t go away — it just shifts to the people using the system and those operating it.

The way I see it, Universal didn’t build a system that requires its people to be exceptional. It built a system that lets them be human.

What are we asking of our people?

I came back from this trip thinking less about theme parks and more about the products and teams I’ve worked inside. At least Disney’s complexity is a deliberate revenue strategy. Most of our organizations don’t even benefit from the complexity we’ve created. We just live with it, ask people to work around it, and sometimes the system is generating the very problems we’re hiring people to solve.

I keep coming back to whether we’ve done the work of designing systems that don’t waste our team’s talents.

Universal didn’t get everything right. Their app is clunky and less integrated than Disney’s. The digital experience has real gaps. But they got the system right in the places that mattered most. We felt it in every ride, every entry, every moment we were with our kids instead of managing a product.

I’ve written before about structural courage — the idea that a well-designed system removes the need for individual heroism. That people shouldn’t have to be shock absorbers because the system should absorb it for them. I wrote that about organizations and teams. I didn’t expect to feel it so clearly on a family vacation. But walking through Universal with my kids, that’s exactly what it was. A system that had done the hard work so the people inside it didn’t have to.

That’s what good system design feels like. The people were just people — friendly, doing their jobs, not rescuing anyone from a broken process. And that was enough.

Outcome vs. impact

Where the outcome is the change in user behavior, impact examines whether the change mattered.

We changed the checkout flow, and users completed the purchase faster (behavior changed). Did the revenue go up? Did the support calls go down? Did customers come back?

Teams can drive behavior change that doesn’t produce value. More clicks, more time on page, more logins — none of that is impactful unless it connects to something that matters for the user, for the business, or both.

Benefit vs. impact

Benefits are the upside we expect. Impact is what actually happened, including the things we didn’t plan for.

Benefit is direct, intentional, and always positive. It’s the short-to-medium term upside we planned for.

Impact is wider, often systemic, and can be positive, negative, or neutral. It’s the longer-term effect of the change, planned or unplanned.

A feature that increases engagement but burns out the support team has a positive benefit on paper and a negative impact in practice.

Benefits are the result of the bets we placed and the value we delivered; impact is the effect of the change.

Why this matters

Teams that only measure benefits stop too early. We ship, the north star metric turned green, and we move on. Leaders who only ask for benefits get a filtered view of what the team intended, not what the product caused.

When we skip the impact question, we create a blind spot where negative consequences go unexamined. The checkout flow is faster, but did returns increase because users are buying impulsively? The platform migration sped up one team, but did it break three others?

These are uncomfortable questions. That’s the point. Benefits tell us what we hoped would happen. Impact tells us the full story.

In the f(Clarity) framework, purpose examines why, users look at who, and impact tells us whether any of it mattered.

If we stop at the benefit and don’t look at whether it mattered, we are only telling half the story. What’s something your team shipped recently where the benefit was clear but the impact wasn’t?

The charitable read is that writing good evals requires the same rigor as a good PRD — clear success criteria, edge cases, and user intent. If that’s the argument, I’m with it. Good evals are hard to write, and they force the same precision we should have been bringing to PRDs all along.

But that’s not what was said. The claim was that evals replace PRDs. And that’s where the framing falls apart.

These are not the same cognitive job

Evals measure model behavior against defined criteria. PRDs define the problem worth solving, who it’s for, and what success looks like for the user. Conflating them doesn’t elevate evals; it just misunderstands PRDs.

An eval can tell us whether the model’s response was accurate, concise, and free of hallucinations. It cannot tell us whether we’re solving a problem worth solving. It cannot tell us who the user is and what their struggling moment looks like. It cannot tell us whether the product should exist at all.

Last week, I wrote about product mindset as a function of clarity — clarity of purpose, users, and impact. Evals measure whether the thing we built is working. But they can’t do the upstream work of defining purpose or identifying users. If any of those are missing, it doesn’t matter how good the eval suite is; the product may still lack purpose or solve a problem for the wrong users.

I’ve built evals. They’re not the starting line.

We built a rubric to evaluate every conversation customers had with our chatbot — measuring accuracy, relevance, conciseness, hallucinations, and toxicity. As LLMs evolved, we updated the rubric based on how customers were interacting with the product, and then worked on automating the evaluation to review conversations at scale.

That eval work was valuable. But we could only write those evals because we had already done the harder work — defining what the chatbot was for, who it served, and what a good experience looked like for those users. The eval didn’t replace that thinking. It depended on it.

The real problem with “X is dead” framing

This is the same type of rhetoric that says PRDs are dead because you can show (not tell) your idea in Lovable. Or that product management itself is dead. These titles make good clickbait. But what are they telling the product management community? Your area of expertise is dead. Your artifacts are no longer needed.

AI has changed how we work and the artifacts we produce. We no longer need to spend hours on manual documentation. But the judgment underneath — what to build, for whom, and why — hasn’t been automated. The decisions we make from empathy for our customers, understanding of our cross-functional teams, and relationships with stakeholders are the PM job that will remain human. The documents were never the point; they were the output.

Evals are powerful. They’re not the starting line.

Evals belong in every AI PM’s toolkit. That’s how we validate that the product is doing what it’s supposed to do. But they sit downstream of the clarity work — the purpose, the users, the definition of impact. Just like documents, evals are output. The thinking is still the job. Without that, we’re measuring precisely and building aimlessly.

The silence is always longer than anyone expects.

These are experienced people. They are experts in their domain, their technology, and their stakeholders. They can tell me what they shipped last quarter and what’s coming next. But when the question is “why does your product exist?” the room gets quiet. And when I ask platform teams, “Who is your user?” — someone will (and did) say “everyone” and mean it.

I sit with that silence. The gap is not their knowledge or expertise. These teams could walk me through their architecture, recite their OKRs, and explain the roadmap. But none of that had ever been connected to the purpose of the company, their organization, their product, or their team.

We talk about product mindset constantly — in job descriptions, in leadership principles, in the training we send people to. There’s a whole market of courses now promising to teach product mindset with AI. But when asked to define it, most people default to surface-level descriptions of customer centricity and delivering business value.

The way I see it, product mindset is a function of clarity. And it has three parts.

The equation

Product Mindset = f(Clarity)
Where Clarity is the Clarity of Purpose × Clarity of Users × Clarity of Impact

Purpose — what problem does our product solve? Not the feature we’re building or the project we’re delivering. The product. Why does it exist?

Users — who are we solving for? A specific segment with a specific struggling moment, not “all American consumers” or “all developers.” When we say “everyone,” we’re saying we haven’t decided yet.

Impact — does it produce value? Did the product idea we built change behavior in a way that mattered — for the user, the business, or both? If we shipped it and nothing changed, we had activity, not impact.

The reason this is multiplication: if any factor is zero, the whole thing zeros out. Without clarity of purpose, we are solving the wrong problem. Without clarity of users, we are not sure whose problems we are solving. Without clarity of impact, we don’t know whether our most important metric moved. All three have to be present, and all three have to be re-examined regularly, because purpose shifts, users evolve, and what counted as impact last year may be a vanity metric this year.

The equation is not scientific. Purpose, users, and impact are each measurable, but with different metrics and at different altitudes. The multiplication framing matters for one reason: when any one of them is zero, the whole thing is zero.

Where it breaks down

1. Treating clarity of purpose, users, and impact as a one-time exercise. In practice, all three evolve as the product matures, as the team’s understanding deepens, and as the ecosystem around them changes. The equation is a starting point, not a finished answer.

2. Users default to “everyone.” This comes up constantly on platform teams, where the user is another internal team. They resist narrowing it down because they serve multiple consumers. But serving multiple consumers and being clear about each one’s struggling moment are two different things. “We serve five teams” is a starting point. “We serve everyone” means we haven’t done the work.

3. Impact gets confused with output. We shipped it. We hit the deadline. We completed the epic. But did the user’s experience change? Did we reduce calls to customer care? Did adoption go up? Impact asks the “so what” question we skip when we’re already planning the next sprint.

4. Clarity requires honest conversations that most teams avoid. Large enterprises may fill in the equation with comfortable answers, skip the difficult conversations, and call it clarity. A team can write a purpose statement, name their users, and pick a metric — and still have zero clarity. If the purpose is aspirational copy from three years ago, if the user segments haven’t been validated, if the metric sits on a dashboard nobody checks, the equation looks complete, but nothing in it is real.

5. Clarity decays without accountability. Having clarity and acting on it are not the same thing. A team can define its purpose, name its users, and pick an impact, but use none of it. The equation only works if someone is responsible for keeping it honest.

Product mindset is not what we do. It’s who we are

Product mindset isn’t a personality trait or a title. It’s how clear we are about why the product exists, who it serves, and whether it’s working. When the clarity is there, decisions get easier. When it’s missing, we fill the gap with process, meetings, and opinions, and then we wonder why we’re so busy without feeling like we’re making progress.

The same confusion came up last week during a workshop I was leading. Someone shared their OKR, and the room debated whether their objective was an outcome.

It’s OKR season for a lot of us right now. And when these terms are conflated, teams end up optimizing for the metric rather than the problem.

Outcome, Benefit, Objective — in that order

These aren’t synonyms and work in a sequence.

Outcome: The change in user behavior we’re trying to create.
A customer resolves a billing issue without calling.

Benefit: The business value that results from the outcome.
Reduced call volume, lower cost-to-serve.

Objective: The measurable target that tells us if we’re getting there.
Reduce billing-related calls by 20% in Q2.

When we start with the objective instead (”reduce calls by 20%”), our team might just make it harder to find the phone number. That hits the metric but misses the outcome entirely.

When we start with the outcome (”users resolve issues without calling”), we’re solving for the right thing.

Why this matters right now

The way I frame it: outcome first, then the benefit, then the objective. If I can trace the objective back to the outcome, the OKR measures something that matters. If I can’t, it might be a vanity metric.

What’s an OKR you’ve seen where the objective and the outcome got confused?

Each of these explored a different piece of the puzzle, but I kept landing on the same pattern: we keep asking individuals to be braver inside systems that reward complacency.

Individual Bravery vs. Structural Courage

We talk a lot about psychological safety, the idea that people should feel safe enough to speak up, take risks, and admit mistakes. It matters, and I believe in it. But I’ve been thinking about what it asks of people.

Think about what “feel safe to speak up” means in practice. Someone still has to go first. They have to raise their hand, say “I think we’re solving the wrong problem,” and override every instinct telling them to stay quiet. We promise we’ll support them when they do, but the system still requires them to be brave. And then sometimes we ignore that and ask them to build that feature anyway. Their individual courage now feels like wasted effort.

The way I see it, psychological safety addresses the fear, but it doesn’t address the structure that created the fear. So what would it look like to address the structure itself?

I’ve been calling the missing piece structural courage, the idea that the system removes the need for individual courage. That people don’t need to be shock absorbers because the system absorbs it.

Psychological safety puts the burden on people to be brave. Structural courage puts the burden on the system so that bravery is no longer needed to act on what you know matters. Once we can name that distinction, we can start designing for it.

Why Caution Is Rational

Before we can design for structural courage, it helps to understand why caution is so deeply embedded. Two forces are working against us, and they reinforce each other.

Inside us: uncertainty feels like weakness

I remember the last time I said “I don’t know” in front of senior leaders. I can tell you who was in the room and what was on the screen. I hung up and replayed the conversation in my head for an hour. What I should have said. How I should have framed it. Whether I came across as if I didn’t have a handle on things.

We are conditioned to know. People look to us for answers, and when we admit uncertainty, it doesn’t feel like intellectual honesty. It feels like a gap in our competence. The system rewards having the answer and having the plan ready. Saying “I’m not sure” in a room full of people who seem sure takes more energy than most of us realize.

Around us: the system makes risk-taking a bad bet

A few years ago, my team wasn’t meeting the say/do targets. Say/do ratios measure whether you did what you said you would do, but “what you said” is defined as features committed and delivered on time, not whether the feature delivered value.

My team was working differently from most teams around us. We were breaking work into smaller increments so we could test, learn, and move forward, and we were measuring ourselves on outcomes rather than the number of features completed.

I got my hand slapped by a senior leader. I was confused at first. I expected leaders at that level to understand that we were measuring outcomes and that breaking work into learning increments was deliberate. But the metric only measured one kind of work for all teams, and leaders, far from the day-to-day, assumed the process applied to everyone.

When you’re running smaller experiments and learning as you go, the ratio looks bad even when the work is good.

My team knew that working towards the outcomes got their leader reprimanded. The system sent a message that day, and it wasn’t “keep measuring outcomes.”

The incentives are asymmetric. You bear the risk, and the organization gets the reward, so we minimize risk. We hedge. “Let’s get more data.” “Let’s start small.” These aren’t failures of courage. They’re rational responses to a system that punishes being wrong more than it rewards being right.

The loop

We play it safe because the system rewards playing it safe. And the more we do it, the more the system reinforces it.

We keep telling people it’s safe to speak up, but the system still rewards staying quiet. Structural courage closes that gap.

Why Environment Wins

Here’s how I think about why structural courage matters so much. We assume that when we train people, they change their behavior. That behavior becomes identity. And identity eventually shifts the environment. That’s the path we invest in.

Training → Behavior → Identity → Environment: this path is slow, and it usually loses to the system.

The stronger loop runs the other direction.

Environment → Identity → Behavior

When the environment changes, people change with it. I’ve seen it. Same people, different environment, different questions get asked, work gets done differently. And when the environment reverts, so do they.

You do not rise to the level of your product mindset. You fall to the level of your environment.

Structural courage is what makes the environment hold. Without it, our investments in people, training, and frameworks wash out over time.

Building Structural Courage

If you’ve been reading along, you might recognize yourself in some of this. Maybe you’ve been the one shielding your team from a metric that didn’t fit how they worked. Or, pushing for smaller experiments when the system wanted big commitments. Or running a different process and absorbing the political cost so your team could focus on what mattered.

That kind of individual heroism is real, and it works for a while. But it’s exhausting, and it doesn’t survive you leaving. I’ve been that hero. When I left, the system won.

The way I see it, the fix is redesigning the system itself. I’ve been writing about what that looks like in my last few posts: changing the defaults so the right behavior is the easy one, encoding rules that shape outcomes rather than compliance, and closing the gap between the system we document and the system people follow in practice. Those are pieces of structural courage, and they’re designed to outlast any single leader.

What would you change if your team didn’t need a hero to focus on outcomes?

The Question Worth Asking

We keep investing in better training, frameworks, and more coaching to change behavior. These investments matter. But they’re working against a system that makes the safe choice obvious and the right choice risky.

The question I keep coming back to: are we changing the system, or is the system changing us?

Structural courage doesn’t mean we stop investing in people. It means we redesign the system so it supports what we’re asking of them, instead of working against it.

Where in your organization does doing what matters still require an act of courage, that the system should make unnecessary?

This happens everywhere, and I think we’ve stopped noticing it.

The Unofficial Game

I’ve been mapping how teams work across a large organization, comparing the documented process to what teams do in practice. The patterns are consistent. Every team has two sets of rules: the ones on paper and the ones they follow. Some modify the official process just enough to check the box. Others follow it to the letter. Most fall somewhere in between, bending things to fit their product, their customer, their technology.

We create elaborate processes and then modify them the moment they meet reality. We expect all teams, regardless of their customer, technology, or application context, to follow the same playbook. And when they don’t, we call it a compliance problem instead of a design problem.

Here’s the question that keeps coming up: if we are going to play by the unofficial rules anyway, why maintain the facade of official rules that we pretend to follow?

Where the Waste Lives

Think about how much energy goes into maintaining the gap between the system we document and the system we run.

Status reports are a good example. Teams assemble them weekly, formatting updates into a template that rolls up to a review no leader has time to read in full. The reports don’t change what gets built. They don’t surface risks or shift priorities. They don’t even get questioned. They exist so that someone, somewhere, can say visibility exists. The teams writing them know this. They write them anyway, because the process requires it. And then they go have the real conversation in meetings or a hallway.

Or look at how we handle operational metrics. Say/do ratios, feature completion rates, velocity, all of these get adjusted so the numbers look right at review time. Teams commit to less so the ratio stays high. Features get marked “done” before the outcome is measured. The metric becomes the goal instead of the proxy, and nobody asks whether the thing we shipped made any difference to the customer.

If the waste was justified because we solved customer problems, I could make peace with it. But most of this waste is bureaucracy, not outcome. It would be unacceptable in a market-driven culture, and yet we accept it because it’s how we’ve always operated.

People are working hard. People are often not the issue. The issue is how much of that effort goes into maintaining the gap between the official game and the unofficial one instead of into work that matters.

Why One Process Doesn’t Rule Them All

The instinct behind the standardized process makes sense. At scale, we need some shared way of working. We need to coordinate across teams, maintain dependencies, report progress, and allocate resources. Nobody was fired for wanting consistency.

But consistency of process and consistency of outcomes are different things. When we mandate the same ceremonies, the same templates, the same cadence for every team regardless of context, we’re optimizing for the ability to look across teams and see the same shape. Not for whether those teams are producing good outcomes.

A team building a billing infrastructure in a regulated environment works differently from a team iterating on a consumer app. A team managing a mature platform has different rhythms than a team exploring a new capability. Treating them the same doesn’t create alignment. It creates the appearance of alignment while each team quietly runs its own version underneath.

Consider The Alternative

It’s tempting to swing the other way and say let every team do whatever they want. That’s not the answer either. No shared structure at scale is chaos.

The way I think about it: instead of elaborate processes that no one fully follows, what if we designed a small number of rules that work across diverse teams? Rules that shape behavior without pretending every team is the same.

In my last post, I wrote about enabling constraints, the idea that a spine creates coherence without containing. A few consistent rules that channel behavior toward outcomes instead of compliance.

So what does that look like in practice?

Take a common one: “Every team runs two-week sprints and demos at the end of the sprint.” That standardizes activity. It tells teams when to work and when to present, regardless of whether that cadence fits their problem space. Now replace it with: “Every team can articulate who their customer is and what problem they’re solving this quarter.” That standardizes intent. A billing infrastructure team and a consumer app team would answer that question very differently, and they should. But both teams are forced to be clear about who they serve and why. The constraint doesn’t prescribe how they work. It makes sure the thinking happens.

Or this one: instead of “fill out the feature template before starting work,” try “demo what you learned before you demo the completed feature.” That single shift changes what teams optimize for. When leadership consistently asks “what did you learn?” instead of “what did you ship?”, teams start optimizing to answer those questions. They may run smaller experiments, talk to customers sooner, and bring real evidence to reviews instead of polished demos of features nobody validated. The constraint reshapes the incentive without adding a single new process.

These leave room for teams to figure out how to get there.

How We Got Here

The deeper issue is that most of our processes weren’t designed. They accumulated. Someone needed a template, so one got created. A review cadence made sense three years ago, so it became permanent. A governance step was added after something went wrong, and it never got removed after the risk passed.

Nobody sat down and asked: what are the fewest rules we need that still produce the outcomes we want? Instead, we kept adding. And now we have a system that nobody designed intentionally, that everybody modifies in practice, and that we spend collective energy maintaining the appearance of following.

That’s the real waste. Not that people bend the rules. That we built rules worth bending instead of rules worth keeping.

I’ve been gravitating toward enabling constraints because they offer something different: an intentionally designed set of rules that can apply to diverse teams and raise their capability without pretending they’re all the same.

We already have constraints. And the energy we spend maintaining the gap between official and unofficial could go somewhere more useful, like solving customer problems.

What’s one unofficial rule on your team that works better than the official process it replaced?

Thinking outside the box implies that there is a box. A box that represents limits. A constraint to overcome. But we rarely define the box itself. And what we get in return is scattered thinking.

If you’ve ever run an open brainstorm, you’ve seen this play out. A hundred ideas pointing in a hundred directions. Some brilliant, most disconnected from anything the business needs. Evaluating them becomes political instead of purposeful.

Defining the box may feel limiting, but it helps channel creativity.

In my last post, I asked how we can build operational autonomy that survives a leadership change.

The concept of enabling constraints clicked for me.

As John Cutler puts it, enabling constraints are the fewest consistent rules that allow you to operate effectively. Zero structure is chaos. Maximum governance is bureaucracy. The minimum creates clarity and loosely defines the box. I’ve been building these for years without labeling them, and I’ve finally found a way to describe the pattern.

The Six Thinking Hats workshop I ran last summer is an example. Each hat constrains the mode of thinking — “right now, we’re all thinking about risks.” The constraint kept the loudest voice from dominating. It channeled the room.

Pre-mortems do the same thing. “Imagine this has already failed — why?” That single constraint inverts the default from launch optimism to structured skepticism. Once the vocabulary exists, people use it without needing permission. The language becomes the constraint.

Exoskeleton vs. Endoskeleton

Dave Snowden, who built the Cynefin complexity framework, draws a distinction that sharpened this for me.

A governing constraint is like an exoskeleton. Think of an insect’s shell — rigid, containing. The structure defines the shape. Things may change within it, but the structure itself doesn’t flex. It protects by enclosing.

An enabling constraint is like an endoskeleton. A spine. It creates coherence — we can stand upright, we can move — but it doesn’t contain. There’s enormous variation possible around it.

The question isn’t more rules or fewer rules. It’s whether the rules we have shape the behavior we want.

Constraints That Already Exist

We already work in a constraint system. Not all of them work in favor of our goals.

PI planning is a constraint system. Definition of ready before epics enter the PI. Say/do ratios at the end. Close your completed features for leadership reporting. It’s structural. It survives leadership changes. It applies to every team.

But it’s an exoskeleton.

What does it produce? People gaming the say/do ratio, committing to less so the numbers look good. Checking boxes on the definition of ready because the system won’t let you proceed without it, not because the thinking is ready. Closing features for optics, not because the outcome was achieved.

The official game runs. And dozens of unofficial games run underneath it: keep my manager happy, don’t miss the PI objective, protect my headcount. Nobody designed the actual game intentionally. It got designed by accretion.

What Enabling Constraints Look Like

In 2023, Shopify deleted 12,000 recurring meetings from every calendar across the company. New rules: no meetings with three or more people unless justified. No meetings on Wednesdays. The default flipped, from “let’s schedule a meeting” to “do we need to meet?” They didn’t tell people to be more productive. They removed the lazy option. Time in meetings dropped 33%, and estimated project completion went up 25%.

When Steve Jobs returned to Apple in 1997, the company had 350+ products. Jobs drew a 2x2 grid on a whiteboard (Consumer/Pro on one axis, Desktop/Portable on the other) and said Apple would make exactly four products. Everything else was cut. The rule: “If it doesn’t fit in the grid, it doesn’t exist.” Engineering resources concentrated instead of scattered. Every product team knew their mandate. There was no ambiguity about what Apple was building.

Neither of these prescribed what to do. They changed the conditions under which decisions get made.

Here’s one I’d design. Same PI demo ceremony we already run, same cadence, same audience. But instead of asking “what did you ship?” ask “what did you learn?”

That single question, asked consistently by leadership, would reshape more behavior than any training program. The constraint changes what teams optimize for.

Not All Constraints Are Created Equal

A constraint can be well-intentioned and still produce the opposite of what’s desired.

A leader recently proposed a threshold: the team shouldn’t work on anything that doesn’t deliver at least $5 million in impact. That’s simple and easy to apply. I can see the value as it forces focus on high-impact work and eliminates small-ball thinking.

But it has a blind spot. Ten improvements worth $500K each that together compound to $5M would each get killed individually. The constraint optimizes for big visible bets and kills the small ones that add up. Without systems thinking alongside it, the constraint produces the opposite of what’s intended.

The question isn’t whether to have constraints. We already have them. The question is whether they’re the kind that enable the outcomes we want.

From Local to System

I’ve been building enabling constraints for years without knowing what they were. The workshops, the pre-mortems, the thinking frameworks, all worked in the room. But because I couldn’t name the pattern, I couldn’t design them to survive beyond the session.

The system-level constraints, PI planning, and say/do ratios persist because the organization enforces them. They survive leadership changes. They apply to everyone. When constraints are designed intentionally at the org level, cross-functional teams can move in the same direction without needing someone to hold it together.

Enabling constraints also apply to how we are adopting AI right now. Everyone is moving fast, speed is the only metric, and we are solving the wrong problems faster. That’s another post.

Whether AI or not, we need to build the right box. One that channels creativity and innovation without chaos. A spine, not a shell.

The constraints already exist. We can’t redesign the ones we can’t see. The question is whether we designed them, or they designed us.

A leader said this to me recently. That leader is not wrong. They experienced a real consequence of giving the team space, and it didn’t work out as hoped. The instinct to pull back control is completely rational.

Everyone talks about empowered teams. But empowerment is a leadership behavior, not a system property. Hire the right people, coach them, lead with strategic context. When that leader leaves, the system doesn’t carry it forward.

A while back, I ran a product mindset workshop with a large team. Two days of deep discussions on what it means to be a product team for product and engineering. On the last afternoon, an engineer told me, “No one has explained it this way before”. People were nodding. I left thinking things were about to shift. Perhaps it was my hubris.

It felt good for about a month.

Then, people returned to doing things as they had been doing them. PI planning pressure returned. Backlog grooming consumed the calendar. Feature factory resumed. Nothing seemed to have changed.

System: 1, Anu: 0.

In my last post, I wrote about why training doesn’t stick. Hint: the environment doesn’t support it. You give people the skills, but the system they return to makes those skills irrelevant. The training fades.

So if training isn’t the whole answer, what is? I’ve started calling it operational autonomy.

What Operational Autonomy Actually Looks Like

Permission Mode vs. Inform Mode

Here’s the sharpest way I can describe it:
Permission mode: Nothing happens unless someone (usually senior or a stakeholder) says yes. The default is inactivity.

Inform mode: Action happens unless someone stops you. The default is movement.

This is a structural shift. In permission mode, you wait. The leader holds the default. In inform mode, the team decides and acts.

Permission mode is the organizational default. It is often not designed intentionally. Inform mode requires redesigning the default, like switching from opt-in to opt-out. And behavioral psychology tells us that we rarely ever change the defaults. Teams revert because defaults are gravitational. The moment someone stops actively overriding the default, it snaps back.

We run in permission mode without even realizing it. It doesn’t show up as a policy. It shows up as behavior. Waiting for sign-off on decisions that shouldn’t need sign-off. Escalating because “I want to make sure leadership is aligned.” Accepting features like “add a button here” without asking why. Running things up the chain “just to be safe.”

Claire Hughes Johnson, former COO of Stripe, put it simply, if you’re not sure who the decision maker is, it’s probably you. Act that way rather than slowing the whole company down. That’s inform mode.

Two Teams, Same Environment

I work alongside a team that operates in inform mode. Here’s what’s different:

The team has clarity on their outcomes. Their goals don’t shift every sprint. They have shared ownership instead of rigid swim lanes where people only touch “their” work. When they meet stakeholders, they are ready with recommendations, not a blank sheet of paper. Their conversations are frank. No sugar-coating, no “managing up.” And when a process isn’t serving the outcome, they bend the process.

This is one of the strongest teams I’ve seen. They’re not ignoring the system. They’ve just figured out how to operate within it without asking permission for every decision along the way. “Here’s what we’re doing and why” instead of “can we try this?”

Now contrast that with permission mode. Every decision needs alignment across multiple layers. Engineers wait for the PO to write the story before they think about the problem. Recommendations get watered down to “options” by the time they reach leadership. Nobody makes a move until the next planning ceremony gives them cover to act.

Why This Is Structural, Not Motivational

You can’t motivate your way to operational autonomy; you have to redesign the default.

David Marquet took command of the USS Santa Fe, the worst-performing submarine in the Navy. Classic command-and-control: captain gives orders, crew executes. Marquet realized this produced passive obedience, not active thinking. So he stopped giving orders.

Instead of crew members saying “requesting permission to submerge,” they started saying “I intend to submerge.” That single change, from permission to intent, flipped the default. With permission, nothing happens unless the captain approves. With intent, action happens unless the captain vetoes. The Santa Fe went from worst to first.

Most retellings of this story focus on the empowerment. The deeper part is that Marquet didn’t just hand over authority and hope for the best. He built two things first:

• Competence. Instead of briefing the crew (here’s what we’re doing), he had the crew certify to him that they knew what they were doing. The burden of proof flipped — from “I told you” to “show me you know.”

• Clarity. The crew understood the mission well enough to make decisions aligned with it without asking.

Only after competence and clarity were in place did he push decisions down.

Competence plus clarity, not training and control. Without competence, you get bad outcomes. Without clarity, you get competent people optimizing for the wrong thing. Without control pushed down, you get competent, clear people still waiting for permission.

And here’s the cycle we’re stuck in: We invest in training and building competencies. But we don’t give people clarity on the purpose or the environment in which to apply it. And, when decisions go wrong, we pull control back. Which makes the training useless. Which confirms “we can’t trust them to decide.” And the cycle repeats.

After the workshop, I started to build operational autonomy on my team (although I didn’t call it that at the time). Clear product strategy, stakeholder-aligned objectives, continuous planning instead of PI planning, lightweight intake instead of the system’s default elaborate process, a space to think about problems, not just execute tickets. One-on-one coaching. Practices like pre-mortems and demo days.

It seemed to work — the team operated differently. They came with recommendations, questioned assumptions, and bent the process toward outcomes.

Then I moved to a new role. Within weeks, the team reverted. Output-based thinking. No strategic clarity. Reactive to whoever was loudest. The default game reasserted itself.

Here’s the admission that’s hard to write: I didn’t build operational autonomy. I was the operational autonomy. The system was tethered to my energy and my insistence on doing things differently. I didn’t encode it structurally. When I left, it left with me.

System: 2, Anu: 0.

The artifacts, documents, and rituals stay. But the behaviors conform to whoever holds the environment now.

So What’s Now?

The question I’ve been researching: how do you make operational autonomy survive without you?

I have some ideas. That’s next week.

The score isn’t final. I’m still in the game.

Maven instructors have made over $20M combined. Some earn $1M+ a year working 10-15 hours a week.

The course economy is booming. But here’s what I keep thinking about:

I’ve taken dozens of courses in my career. As a coach, I run workshops with teams on product strategy and mindset. And I’ve watched the same pattern play out over and over.

Years ago, my company brought in a well-known product consultant for a two-day workshop. Someone who literally wrote the book. The leadership team showed up. They participated. They asked good questions.

I left that hotel ballroom hopeful. They get it. We’re going to work differently.

A colleague talked about “delighters” for weeks. It felt like something had shifted.

Within the year, those same leaders introduced a heavyweight planning process. Quarterly ceremonies. Hardened commitments. The opposite of what we’d just learned.

I don’t think it was malicious. They genuinely believed they wanted transformation. But when transformation meant giving up control, they chose a framework that looked modern while keeping the old power dynamics.

They didn’t want product thinking. They wanted to have done product thinking.

In the courses I’ve taken and the ones I’ve led, one thing keeps happening: people show up, feel energized, and the trainer feels accomplished. Then nothing changes.

This is why I started one-on-one coaching. I kept seeing this pattern with my teams. The workshops were well received, but when people went back to their day jobs, nothing stuck. I have the advantage of being embedded with the teams I coach. I see what happens after. An outside consultant doesn’t have that view. They have to believe the training worked. I’m not sure how many go back to check.

So I’ve been thinking about why trainings don’t stick. That led me to some research.

The stat everyone cites

You’ve probably heard it: “Only 10% of training transfers to the job.”

It sounds rigorous. It gets cited everywhere. It makes you nod and think, yeah, that tracks.

Here’s the thing: no one can find where it came from. It’s been repeated so many times that everyone assumes it’s real. But the original source doesn’t exist.

For a field obsessed with data, we’ve been running transformations on vibes.

So what does the research actually say?

What the research says

In 1988, two researchers named Baldwin and Ford asked a simple question: Why doesn’t training transfer to the job?

They found three factors that matter:

1. Who’s in the room — trainee characteristics

2. How good the course is — training design

3. Whether you get to use it — work environment

All three matter. But the research found that one matters more than the others.

It’s not who’s in the room. It’s not how good the course is.

The biggest factor is whether your environment gives you the chance to apply what you learned.

Give someone a framework and no authority to use it, and you’ve wasted everyone’s time.

This isn’t just one study. In 2010, a meta-analysis of 89 studies confirmed the same thing: work environment and supervisor support are among the strongest predictors of whether training sticks.

Looking back at that workshop, I get it now. It was never going to stick. Not because the training was bad. Because we never created an environment for it to survive.

So what actually works?

1. Find other believers

One person modeling different behavior converts almost no one. Research suggests you need about 25% of a group to believe in something before it tips.

The question isn’t “how do I change the culture?” The question is “how do I get to 25%?”

You can’t do it alone.

2. Build operational autonomy

Psychological safety matters. But it’s not enough. Safety means you can speak up without fear. Autonomy means you can actually do something about it.

And here’s the harder truth: some leaders create the perception of psychological safety without the real thing. They say “my door is always open,” but punish the people who walk through it. They ask for feedback but get defensive when it comes. The language of safety without the behavior.

Even when safety is real, most orgs stop there. They think “we created a safe space” is the finish line. But if people can raise concerns but can’t act on them, you’ve given them a voice with no power.

Operational autonomy means: clear goals that don’t shift constantly. Outcomes-driven teams figure out how. Frank conversations tied to real goals. “Inform, don’t ask permission.” More on that in the next post.

But even structure is fragile. It needs density to be sticky, or it reverts.

3. Create artifacts that outlast you

When I say artifacts, I don’t mean posters with values on the wall.

I mean: What question gets asked in every meeting? What document is required before a decision?

Amazon’s 6-pager is a good example: a narrative memo, no bullet points. You can’t hide shallow thinking in prose. The format shapes the questions. Change the format, change what gets asked.

Decision logs. Pre-mortems. Rituals. These continue long after you’ve left the room.

The course wasn’t the variable

A colleague and I took the same course. Same content, same investment—$2,000 each. We both believed in it.

I applied the learnings immediately. It stuck.

My colleague couldn’t. Not because of their motivation. Because the system didn’t give them the chance. No space to experiment. No authority to change how decisions were made.

Same course. Same belief. Different environments. Different outcomes.

The course wasn’t the variable. The environment was.

You don’t rise to the level of your training. You fall to the level of your environment.

As product managers and leaders, we’ve all felt that drain, putting in more effort than we get back until the exchange feels completely one-sided.

Peter Kaufman calls this mirror reciprocation. You go first, give value, and the other person reciprocates. What you put out is what you get back. Kaufman argues the obstacle is loss aversion; we’re so afraid of a 2% chance of looking foolish that we forfeit the 98% upside. Go all in with kindness, trust, and respect, and the world reciprocates in kind. This is how we build relationships, rapport, and reputation.

But mirrored reciprocation assumes the other party can reciprocate. What happens when you go first, stay positive, stay constant, and the system structurally can’t mirror it back? Not because individuals are bad, but because the organizational structure absorbs your energy without returning it.

Bureaucracies aren’t individuals. They don’t feel kindness, gratitude, or respect. At the org level, this shows up as metrics that reward compliance, rotating stakeholders who inherit none of the relationship capital you spent months building, and approval chains where no single person owns the outcome.

At the individual level, it shows up as disconnection and burnout.

Here’s what worked for me:

1. Recognize the pattern. Look for signs you are in an energy-absorbing system. Meetings get rescheduled, then cancelled, with no outcome. Your product idea gets interest, but no commitment or funding. Ask yourself: how long do I keep going first? If the answer is ‘too long’, that’s data. It doesn’t mean that you quit; it means that you pause and recalibrate where you spend your energy.

2. Redirect to where reciprocation exists. Invest at the team level, build culture, processes, and tools that make daily work easier. Gently bend the rules of how you plan and deliver, instead of grinding against them. Don’t ask for commitment; create the options. Instead of ‘can you give me availability to meet?’, try ‘here are three windows that work, which one works better?’.

3. Find the reciprocating pockets. Individual allies you can share learnings with. Skip-level sponsors willing to mentor. Cross-functional peers who become your soundboard. Start by noticing who responds to your ideas and then ask, who among them can move things, not just commiserate? You need both.

4. Extract from asymmetric returns. The org may never reciprocate. What did you learn from this experience, regardless of the outcome? Document it. Lessons from hard systems are portable for whatever comes next, whether it’s a new role, a new approach, or a breakthrough where you are.

5. Build skills that stay with you. Don’t just extract from the past - invest in the future. Build capabilities that compound regardless of where you work, like building with AI tools or learning to navigate ambiguity. No one can take your growth.

The question isn’t whether to believe in mirror reciprocation. It’s whether the system you’re in deserves it, and where else that energy might actually pay back. And maybe there is another question: what if you changed how you lead, and the system started to shift with you? That is harder. But it is also where transformation begins.

I was invited to speak to my daughter’s 2nd-grade class about AI. As someone who talks about AI with the kids in my life, I’m always surprised by how they see and interpret the world.

Our Kids Are Digital Natives

We’ve had a Google Assistant in our kitchen for as long as I can remember. My kids have been giving voice commands since they learned to talk - asking about the weather, setting timers, or requesting songs. Early on, the assistant got things wrong because their words weren’t clear. But now they’re completely comfortable with voice AI, mostly using it to play KPOP Demon Hunters songs on repeat. The video recommendations from YouTube or Netflix seem so intuitive through their lens.

This fluency is remarkable, but it also raises the stakes. Because our kids are AI natives, they’re encountering these tools younger, more often, and with less hesitation than we did. That comfort can be a double-edged sword. Without guidance, they might share personal information with a chatbot the same way they’d tell a friend, or trust AI-generated content without questioning it. The very ease that makes them natural adopters also makes safety education essential.

As a mother, I naturally gravitate towards wanting to talk about AI safety with kids. With Claude Code, I put together a presentation deck for the class and a flyer for parents summarizing what I shared, along with additional safety tips.

Three Simple Rules I Shared With the Class

1. The Grown-Up Rule

   Always ask a parent or teacher before using AI, just like you’d ask before going to a new website or app.

2. The Privacy Rule

   Never tell AI your name, address, your school’s name, phone number, or passwords. AI doesn’t need to know these things about you.

3. The Truth Rule

   AI is really smart, but it can make mistakes. If AI tells you something that sounds wrong or confusing, ask a grown-up to help you check if it’s true.

I learned that kids are naturally curious, and they asked lots of good questions. They’re already intuitively using applications with built-in AI.

Everyday Teaching Moments

The best conversations about AI don’t need to be planned—they happen naturally.

My kids have heard me complain about AI-generated copycat songs that YouTube automatically plays in our car. What started as an annoyance has become a teaching moment. We now talk about the difference between original creators and AI replicas.

I’ve heard from several parents about creative ways they use AI at home. One example that comes up often: using ChatGPT as a bedtime story writer. Kids choose the topic, a princess and her unicorn on a rescue mission, a dinosaur detective etc., and AI generates a custom story every night.

It’s a creative use of the technology, but it also made me wonder: if we lean on AI for everyday creative tasks, what does that teach our kids about their own imagination? There’s probably a balance, mixing AI-generated stories with ones we make up together, or letting kids create their own endings.

How Parents Can Reinforce These Lessons

1. Model good AI usage by narrating when you’re using AI tools and why

2. Supervise AI interactions and set clear boundaries about when and how children can use AI

3. Discuss recommendations and why AI makes certain suggestions

4. Talk about the difference between AI assistance and human creativity and judgment

5. Encourage critical thinking by validating whether AI-generated answers make sense and exploring other sources (like books) to confirm

6. Preserve space for creativity by balancing AI-assisted activities with opportunities for kids to create, imagine, and problem-solve on their own

7. Be thoughtful about images. AI tools that edit or generate images often store and use photos in ways we don’t fully control. Think twice before uploading your child’s photos to AI applications

The Bottom Line

AI is a powerful tool, but it works best when paired with human wisdom, creativity, and critical thinking. Your guidance helps your child develop healthy digital citizenship skills for the future.

Have you talked to the kids in your life about AI? I’d love to hear what surprised you.

When days blur with back-to-back meetings and constant inputs, insights slip away before you can capture them. Without written data, there are no patterns to identify.

Why Reflection Matters

Daily reflection isn’t just about capturing thoughts. It’s about creating a feedback loop for your own growth. When you consistently document what you’re learning, struggling with, and noticing, you create a dataset about yourself. That dataset can reveal patterns: recurring friction points that need addressing, emerging interests worth pursuing, gaps between what you think matters and what actually moves you forward. Without this practice, you’re operating on gut feel and selective memory. With it, you have evidence to inform how you spend your time and energy.

Five days ago, I felt scattered. Still jetlagged, I felt ideas slipping away. Insights forgotten by the end of the day. So I created a system: six simple questions I’d answer at the end of each day, designed to capture both the learning moments and the friction points before they disappeared.

The six questions are:

1. What did I learn today? (personal growth)

2. What surprised me?

3. What’s one thing I am struggling with?

4. What are the insights from my work? (professional reflection)

5. What’s one question I am wrestling with?

6. What’s one insight from the books I am currently reading?

At first, I started to document my response to these questions at the end of each day in a Google Doc. Then I built a Reflection system in Claude code that integrates with Obsidian to capture my daily reflections. The creation of the system, integration with Obsidian, and the setup process were surprisingly easy and was up and running within 30 minutes.

For example, yesterday’s “What surprised me?” was realizing how much my perceived friction with Obsidian was mental rather than technical. That one observation led directly to taking action rather than continuing to avoid the tool.

After just five days of daily reflection, three patterns emerged:

1. My productivity depends on clarity. I’m consistently more productive on days when I’ve documented clear learning goals and targets.

2. Perceived friction is mostly mental. My hesitation to integrate Obsidian and Claude Code wasn’t technical—once I started, it took 30 minutes, and Claude Code basically did most of the heavy lifting.

3. You can’t find patterns in what you don’t capture. The act of documenting improves both retention and recall, creating a foundation for identifying where I’m actually heading.

Automation takes the heavy lifting out of the system. The Claude Code integration handles file creation and formatting, so I can focus on the thinking itself.

I built this in early January, riding the fresh start effect. But the system works because it’s simple enough to maintain beyond the initial motivation spike.

What system do you use to capture your thinking? Or are insights slipping away before you can act on them?

If you need a system, try mine. The six questions are a starting point. Alter them to fit what you’re actually trying to learn about yourself and your work.

Nine loads of laundry are piled in the basement. My kids are jet-lagged, confused about what day it is. My brain isn’t ready for anything that requires sharp thinking.

There are 200+ unread messages in my inbox. My LinkedIn feed is moving fast. AI agents. Agentic frameworks. New model releases. 2026 predictions. Think pieces about what I missed while I was gone. What our work will look like in 2026.

The FOMO hits immediately. But there’s something else sitting next to it. A dissonance I can’t shake.

Thailand didn’t care about AI.

The souvenir shops in Pa Tong don’t have apps. You can’t add items to a cart and check out. You walk in, find something you like, and negotiate face-to-face.

I tried this once. Picked up a small carved piece. Asked the price. The seller quoted me something. I countered lower. She said no, held firm. My kids were cranky. It was a hot day. I didn’t have the muscle for it anymore. I’m too used to paying sticker price. Too used to Amazon.

I left. Walked to an air-conditioned store down the street. Paid more for roughly the same thing.

The vendor I walked away from probably needed that sale more than the air-conditioned store did. But the friction was too much. I opted out.

The economy there runs on haggling, cash, and face-to-face trust.

Tuk-tuks are rickety and jazzed up at the same time. Drivers negotiate fares in real time based on distance, time of day, and how they read you. No apps. No surge pricing algorithms. Just humans making deals. Side note: We barely used the Grab app, and it was useful to overcome the language barrier to inform the cabbie where we were trying to go.

Shops charge 3% if you want to use a credit card. Most people pay cash. The system works.

Then I come home and open my feeds.

Every post is about AI. Every product update includes “AI-powered” in the announcement. Conferences, podcasts, newsletters—all racing to cover the latest model, the latest framework, the latest breakthrough.

But watching the hype cycle from the outside—even for just two weeks—made something clear.

Where AI matters deeply, in specific contexts

Knowledge workers in wealthy economies. People whose work happens on computers all day. Industries where labor costs are high enough that automation is relevant. Companies operating at scale where efficiency compounds.

That’s the echo chamber: a tight loop of people building AI, talking about AI, and worrying about AI—mostly with each other. We’re shipping AI products, writing about AI, and consuming content from others doing the same work. The discourse feels urgent because we’re all talking to each other about our own disruption.

And to be honest, not all of this is confusion or curiosity. Some teams are unclear about what to do. They’re avoiding hard prioritization decisions by hiding behind AI. Shipping “AI-powered” features is safer than saying no, cutting scope, or admitting a problem doesn’t need AI at all.

But most of the world’s economic activity doesn’t operate under these conditions. Cash transactions. Human relationships. Labor that’s affordable enough that replacing it with software simply doesn’t make sense.

AI’s impact is real. The discourse travels faster than its relevance. And being two weeks behind on the conversation doesn’t mean being behind on what matters.

How I’m Thinking About Re-Entry

I’m not ignoring AI. But I’m not diving in headfirst either.

I’m focusing on the problems I’m actually trying to solve, not the solutions being announced.

Before I chase the latest agentic framework, I want to know what user problem it solves that a simpler approach doesn’t. Before I add AI to a feature, I want to understand the cost—both to build and maintain—and whether it’s worth it.

This means understanding the mechanics. What it costs to run. Where it breaks. What value does it create for users versus what it signals to stakeholders.

What I’ve noticed is how quickly AI features turn into defaults instead of decisions. Summaries shipped everywhere because they were easy to justify, not because they were clearly valuable. Each subsequent layer: agents, orchestration, and multi-step reasoning, adds power, but also complexity and ambiguity.

Each progression feels less like “we solved the last problem” and more like “the technology advanced, so we’re finding new ways to solve the same problems.”

Are we solving user problems or solving our own anxiety about being left behind?

I don’t have a clean answer.

Some AI features are genuinely useful. Some solve real problems. But a lot of what’s being shipped feels like checkbox innovation. AI-powered features that exist so the company can say they have AI-powered features.

The Pa Tong vendor doesn’t think about optimization. She thinks about whether she’ll make enough today to cover costs. Whether the item she’s holding will sell. How to read the customer in front of her and find the right price.

Her solutions flow from her problems.

So that’s what I’m trying to do. Catch up strategically, not frantically. Read what’s relevant to the problems I’m actually working on. Ignore the rest—for now. Asking, does this need AI, or does a simpler solution work just as well?

It’s slower. Less flashy. But it feels right.

The world didn’t end while I was offline.

Thailand keeps running without AI. The big AI breakthroughs I “missed” will still be there when I’m ready to learn about them.

If you just got back from a break and your feeds feel overwhelming, you’re not behind. The discourse moved. That’s not the same thing as progress.

AI’s impact is real for some problems. Not all problems. The work is knowing which problems deserve your attention and which don’t.

In the meantime, I’m still doing laundry. Still jet-lagged. Still figuring it out.

But I’m not racing to catch up anymore. I’m choosing what to catch up to.

That feels like the right place to start.

We change product titles to signal progress. A Business Analyst (BA) becomes a Product Manager (PM). A Product Owner (PO) becomes PM.

On paper, it looks like a step toward transformation. In practice, that’s often where it stops. Very little actually changes.

When this happens, people are not just unclear about expectations. They are placed into the role without the structure, authority, or support needed to succeed.

It’s worth saying why this keeps happening.

Changing titles is fast, visible, and feels like progress. It signals transformation without requiring hard trade-offs. Bigger changes like how decisions are actually made, changing incentives, slowing delivery to learn, and coaching people through ambiguity take time and political capital. Under pressure to show momentum, leaders gravitate toward the thing that’s easiest to do.

The problem is that signaling change isn’t the same as enabling it.

But what actually happens when we change the title without changing the system around it?

I was talking to a PM this week who reflected that the hardest part isn’t the title change itself.

It’s being expected to do a job they were never taught how to do.

This comes up a lot in enterprises when BA or PO titles are changed to PM.

We change the title.
We don’t reset expectations.
We don’t coach people on what the role actually means in this context.
We expect behavior to change overnight.

Then we act surprised when it doesn’t.

People are suddenly asked to think in outcomes, look at data, run experiments, and talk to users. But they don’t have a well-defined product strategy. They don’t have access to data. They don’t have access to users or the right tools. And they’re not coached on how to frame problems or make decisions differently.

No one who finds themselves in this new role wants to raise their hand and say, “I don’t actually know how to do this.” So they fall back to what feels safe and what’s still rewarded: tracking deliverables, writing stories, waiting for requirements from business.

Not because they’re incapable. Because that’s what the system still asks them to do.

Later, this same behavior is used as evidence that:
“This isn’t the PM role we want.”
“This doesn’t align with the Marty Cagan model.”

What often goes unsaid is that we never built the conditions that the model assumes: clarity on ownership and influence in decisions, access to strategic context, real problems to solve, users to validate with, room to learn, and leadership support when trade-offs get uncomfortable.

The role doesn’t fail. The system sets it up to.

I’ve seen this pattern repeat over and over.

We bring in great thinkers. We run workshops (I’ve run more than a few myself). People leave energized.

And then nothing changes.

Titles change.
Processes stay the same.
Incentives stay the same.
Decision-making stays top-down.

Despite calling people PMs, the organization becomes more delivery-focused, not less.

In many organizations, “PM” quietly becomes the role where ambiguity is dumped without authority to resolve it.

There’s another dynamic at play here that’s harder to name.

In many enterprises, decisions don’t flow through roles. They flow through influence. The loudest or most politically powerful stakeholder still shapes what gets worked on, how urgently, and with what constraints. Leaders often inherit those priorities and pass them down, sometimes without realizing they’ve undercut the very PM role they’re trying to establish.

PMs see this quickly. They learn where real power sits. They learn which decisions are already made before a problem ever reaches the team. And they adjust their behavior accordingly—out of self-preservation.

The only time I’ve seen behavior truly shift is when the system around the role changes:

• How work enters the team

• How planning happens

• How success is defined and reviewed

• Where PMs are expected to lead decisions vs. collaborate or influence, and

• When PMs are coached over time, in context, while doing the work

In a follow-up post, I’ll plan to share what actually changed in the few cases where this worked and what it took to sustain those changes over time.

Workshops alone don’t change behavior. Training without system change creates frustration. Judgment is built through practice, feedback, and support—not through title changes.

That said, this isn’t just a leadership responsibility.

When PMs find themselves in this situation, there’s also a responsibility to actively upskill through coaching, courses, reading, and learning how strong product work actually looks in practice.

And when systems don’t change, PMs can’t wait passively. They have to identify the gaps.
Name where clarity around decisions is missing. Surface where success is still measured on output instead of outcomes. Create clarity bottom-up when it doesn’t exist top-down.

This is as much about managing up as it is managing down.

That’s hard work. And it requires courage, especially in environments that still reward compliance over judgment.

If you’re going to change the title, you have to be willing to: coach the role, change how work is taken on, redefine success, support validation and learning, and protect people while they build new skills.

Otherwise, the rename is cosmetic.

And if your PMs are acting like delivery leads, the real question isn’t whether they’re capable.

It’s what your system is actually rewarding them for.

If you’re a leader contemplating this change, ask yourself what else needs to change in the system for the transformation to actually be effective. If you’re a PM whose title has changed, ask how you’re actively upskilling so your actions can meet the expectations being placed on you.

In many large enterprises set up with these two layers of the product ecosystem, the discovery failures that show up in the flows often have a simple root cause: the early Product framing didn’t fully account for the systems, constraints, behaviors, or cross‑functional dynamics required to make the experience work end‑to‑end. It’s not that Market Product teams always do thorough discovery — it’s that whatever discovery is done rarely connects deeply enough to the realities of how the experience actually performs in the wild.

Authentication, Buy flow, Cart, Checkout, Search, Chat, Troubleshooting, Account Management, Billing and Payments, Support. The places where customers actually decide, act, and get help.

These are the Journey products — the systems and journeys that carry the weight of the customer experience but rarely get treated like real product work.

And here’s the uncomfortable truth: This is one of the places where companies lose the customer. Because the systems are not built to support the Market-facing products. We treat launches of a Market Product as a project with a set timeline and funding. Once the Product launches, then it’s up to the Journey product teams to manage it.

Let’s talk about why that happens.

Market Product discovery misses the reality of the user journey

Market Product teams usually believe they’ve done discovery. Hopefully, they’ve talked to users. They’ve aligned on goals. They’ve run competitive analysis. They’ve built the business case.

But discovery isn’t a deck. Discovery is understanding how customers think, behave, hesitate, or churn. Discovery is understanding how people buy and why they will be in a relationship with the company.

Most Market-facing discovery misses the reality of the user journey. It assumes the flow is a happy path - straight line, frictionless, and obedient.

It isn’t. It never is.

The “hidden discovery” problem

Even when Market-facing teams do some legitimate discovery, they rarely share it proactively.

And the Journey teams, the ones who own the flows, platform, systems, and experiences where the sale happens, are left trying to stitch together the basics:

• Why are we building this?

• Who is the target?

• How many people are expected to buy it?

• What problem does it solve?

• What outcome are we driving?

• What does a good flow look like for this customer?

When none of this context is shared, two things happen: (i) teams make assumptions. (ii) Then they get blamed when the metrics don’t move.

Discovery that isn’t shared = no discovery at all.

Requirements are locked before the problem is understood

This is the pattern across many enterprises:

1. Market-facing builds the business case.

2. Leadership locks the scope, the budget, and the launch date.

3. Requirements are handed down already baked.

4. Journey product teams inherit them as features to build, not problems to solve.

5. Discovery is now impossible because everything is predetermined.

In this model, you’re not building a product. You’re implementing a decision.

The Journey product teams don’t get to ask: “Does this solve a real customer problem?”

No time for that. Just build it.

This is how product discovery dies before it even starts.

Journey product teams are treated like IT, not product

This is the cultural root of the entire issue.

Journey product teams — Digital, Account Management, Site Search, Chatbots, Buy flows — are treated as an execution feature factory that delivers; order takers that are the last stop, not the first partner.

But these teams sit closest to the customer’s actual behavior. They see the drop-offs, retries, failed logins, broken steps, and contradictory flows.

In a healthy product culture, Journey teams develop a strong grasp of constraints, edge cases, and downstream impacts. But in many enterprises, they’ve been conditioned as executors — so the muscles needed for true discovery never get built.

The enterprise workaround that makes everything worse

Because Market-facing teams don’t bring Journey teams in early, they bring in enterprise solution architects instead.

Architects do what they are supposed to do: map systems, interfaces, dependencies, and integrations.

But here’s the failure mode: They design the integration. The customer journey gets left behind.

The project becomes a diagram, not a product.

When no one designs the journey, the product meets the integration requirements instead of the customer requirements, and the experience underperforms accordingly.

Misaligned Objectives

There’s another failure most leaders don’t see clearly:

Market-facing teams rarely think about how the customer will be supported after the sale.

They define what the product is, how it will be sold, and at what price point. But not how it’s supported.

Most assume the customer will call or visit a store if anything breaks.

This assumption is deeply out of sync with:

• Digital organizations trying to increase self-service

• Contact centers trying to reduce volume. Enterprise cost models that cannot sustain endless human support.

• Customer expectations shifting toward “I should be able to solve this myself”. A demographic that prefers digital-first, low-friction experiences

So the company ends up selling products with incomplete journeys. And the customer ends up paying the price - in time, frustration, and inconsistency.

Why Journey Product Strategy Needs to Exist

Journey products aren’t just delivery mechanisms. They are real products with their own constraints, user problems, and long‑term evolution. Yet most enterprises never articulate a Journey Product Strategy, leaving these teams reactive, dependent, and constantly context‑switching to support Market-facing launches.

A strong Journey Product Strategy clarifies:

• The role of each Experience product in the ecosystem

• The end-to-end user problems the team owns

• The capabilities it must maintain and improve

• The constraints it must work within

• The metrics that define its health

• The investments and bet areas for the next 12–18 months

Without this strategy, Journey teams become the organization’s fallback — responsible for making everything work, but rarely given the authority, clarity, or room to shape the future.

With a strategy in place, they become focused, equal partners. Not downstream executors, but owners of the experience layer, where customer trust is won or lost.

What Experience discovery actually looks like

The strength of Journey teams’ discovery skills depends on how they’ve been positioned, enabled, and involved over time. Some have become exceptionally strong because they work closest to real user signals; others haven’t had the opportunities, expectations, or support to develop the same depth.

Over time, they can understand:

• User behavioral signals

• How customers phrase their problems

• Where friction accumulates in flows

• What causes drop-offs, retries, and abandonment

• The invisible rules and constraints of the ecosystem

• The micro-decisions customers make along the way

• What journeys must do to actually support the product

This is why discovery for flows is critical — and why it shouldn’t be done by people who never touch them.

The minimum viable fix: collaborate from day one

This is the simplest intervention with the highest return:

Market-facing and Journey teams must collaborate from the moment the problem is defined.

Even if the Experience side has only one strong IC PM, involve that person immediately.
They bring the constraints and the reality of the ecosystem.
They know what is possible, what is risky, and what will cause downstream pain.

Early collaboration prevents months of churn, misalignment, and rework.
It also creates better products.

How to transition

Here are three shifts that would materially improve how Market-facing and Journey teams work together:

1. Treat Journey teams as product partners, not IT executors.

2. Don’t lock requirements before you understand the user journey.

3. Validate the user problem before you design anything.
   
   Market insight ≠ user insight.
   Business goals ≠ customer needs.
   Discovery ≠ stakeholder alignment.

Bottomline

Many enterprise product failures aren’t caused by engineering, design, or testing. They start much earlier — with unclear problem framing, siloed discovery, and misalignment between Market-facing and Journey product teams.

Fix that, and most things get easier: clearer experiences, higher conversion, lower support volume, faster delivery, fewer surprises, and teams that can do their best work — and customers who don’t have to navigate broken or inconsistent journeys.

This is what discovery for Journey products is actually about.

Not frameworks.
Not ceremonies.
Not templates.

When we write generic appreciation notes, some times we say very little. We thank people for “hard work,” “collaboration,” and “partnership,” but skip the part that actually matters: the invisible labor that holds product teams together.

Product work isn’t just powered by dashboards or roadmaps. It’s also powered by people doing the quiet, unglamorous, emotionally heavy work that makes meaningful progress possible. This is the invisible labor. If we’re going to talk about gratitude, it should recognize the work that rarely gets acknowledged but fundamentally shapes how teams show up.

Gratitude for Leaders Who Create Conditions, Not Just Direction

Product leadership isn’t just about directing activity. It’s about creating the psychological, political, and strategic conditions that allow real product thinking to survive.

The kind of product leaders who:

• Protect teams from noise just long enough so strategy can take shape.

• Hold the line when the organization drifts back into output-first thinking.

• Anchor conversations in customer problems rather than pet projects.

• Absorb organizational friction so teams can focus on the work.

This form of stewardship rarely gets celebrated, yet it enables everything else.

Gratitude for Teams Doing the Invisible Work

Product teams carry more emotional and cognitive weight than most people realize. The real “hard work” isn’t always what shows up in release notes.

The teams who:

• Reframe vague business requests into clear problem statements.

• Build alignment across stakeholders with competing incentives.

• Ask the inconvenient questions that prevent bigger issues later.

• Hold ambiguity while still pushing momentum forward.

• Challenge assumptions without escalating conflict.

• Navigate shifting priorities without losing the customer.

This work is often thankless, but it is essential.

Gratitude for Cross-Functional Partners Who Make the Work Better

Great product work is never the result of a single team. It’s a collective effort.

The cross-functional teams with:

• Designers who advocate for user truth even when timelines push back.

• Engineers who strengthen the product’s future, not just its present.

• Analytics partners who bring clarity instead of noise.

• Ops and frontline teams who surface reality, not filtered data.

• Business partners who choose clarity over urgency.

These contributions elevate the work in ways most people never see.

Gratitude for Healthy Tension

Healthy friction is often misunderstood as conflict. When handled well, it’s a source of strength.

The teams willing to debate tradeoffs honestly, challenge misaligned goals, push for better metrics, build time for discovery, and hold one another accountable for outcomes.

This tension improves products far more than any process or ritual.

Gratitude as a Cultural Signal

Appreciation isn’t a nicety. It’s a force that compounds. When people feel seen, they show up differently. Recognizing invisible labor strengthens trust, accelerates decisions, and reduces the pull toward feature-factory habits.

Gratitude reinforces the behaviors that produce real outcomes - honest, curiosity, courage, alignment, and focus.

Culture shifts through how people treat each other, not through frameworks.

--------

The coming year will demand more: more clarity, more prioritization, more strategic discipline, and more courage in uncertainty. The foundation for that work is built by people who carry the invisible load: people who choose care over speed, truth over convenience, and users over noise.

Thanksgiving is a moment for gratitude, not as performance, but as recognition for the collective effort that makes meaningful product work possible.

Here’s to the people doing the unseen work that shapes everything ahead.

Since the launch of Netflix’s KPop Demon Hunters this past summer, there have been no other songs playing (on repeat) in my car.
After watching the movie with my kids a few times, and building a custom Rumi Halloween outfit for my daughter, I started to notice how popular it had become through its songs and characters. The scale of its popularity was evident on Halloween night, with countless kids dressed as Rumi and other characters. The movie has clearly taken over elementary schools everywhere.

Parenting experts like Dr. Becky Kennedy have drawn out its themes of shame, authenticity, and belonging. Her takeaway that honesty builds connection mirrors exactly what product teams need to work with clarity and trust.

The themes in the movie and how Netflix rolled it out resonate with me as I think about building empowered product teams and resilient cultures.

Spoiler alert: If you haven’t seen the film and plan to, watch it before reading further.

“KPop Demon Hunters” is a story blending Korean mythology and K-pop culture, where a trio of idols use their music to fight demons and protect the world by creating a magical barrier called the Honmoon.

1. Story as System Design

KPop Demon Hunters works not just as a narrative but as an interconnected system. The music reinforces the mythology → mythology reinforces the emotional arc → emotional arc reinforces the character’s growth. Every subsystem strengthens the others, creating a cohesive world rather than a sequence of scenes.

This systems thinking is a core product skill. Great product teams design ecosystems the same way, thinking about the user journey end-to-end. Every touchpoint: onboarding, UX flows, data signals, brand moments, support interactions, reinforces the same core purpose. Nothing feels bolted on. Nothing contradicts the narrative. Everything compounds.

Lesson: The real skill is in designing systems where every part reinforces the “why.”

2. Collective empowerment over individual heroism

In the film, the trio only wins when they move as one. Rumi, the protagonist — who is part-demon herself — can’t hold the barrier alone; it takes their synchronized strength to protect their world.

In product work, alignment carries the same weight. When teams act as individuals chasing local goals, priorities get rehashed, and quality breaks down. When they operate from a shared mission and success metric, agility and progress follow naturally.

Lesson: Alignment is a force multiplier.

3. True ownership, even of our demons

Rumi is ashamed of her “demon” half, and keeps it a secret from her bandmates — until it affects her performance and she learns to own it in the end. That act of honesty flips the power dynamic: hiding weakens her; truth strengthens her.

Product teams do the same dance. When delivery pressure, ego, or fear of blame take over, people start hiding reality — risks, delays, and unclear decisions. And when they hide, trust erodes and the product suffers.

The fix isn’t more process; it’s courage. Courage to say we’re off track or we don’t yet know, followed by here’s what we’re doing to get back on track.

Lesson: Truth and ownership strengthen trust.

4. Leadership alignment and transparency

The barrier, called Honmoon, protects their world and needs constant care. If left neglected, demons leak through.

In organizations, that barrier represents alignment and transparency at the leadership level. When direction shifts weekly, decisions are made in a vacuum, or communication is filtered, teams lose clarity and confidence. Leaders who are consistent, transparent, and explicit about priorities build the foundation that keeps the entire system steady.

Lesson: Alignment from the top sustains trust and focus throughout the organization.

5. Momentum, not moments

Netflix didn’t drop KPop Demon Hunters and walk away. It released the movie, then the soundtrack, then the sing‑along events, and later localized experiences — each one a new entry point back into the world.

That’s how great products grow: thinking beyond features to building user experiences that people identify with, return to, and talk about.

Teams that measure success by the number of features shipped miss this energy. They deliver outputs, not outcomes.

The better question: what sequence of experiences will keep users coming back?

Lesson: Design the rhythm of engagement, not just the release date.

6. Depth > Breadth

The movie didn’t try to be “universal.” It stayed deeply rooted in Korean culture and mythology — a deliberate choice to go deep rather than wide, proving that depth of authenticity can drive global appeal more effectively than generic universality. The film’s success also reflects the fusion of art and algorithm, good human storytelling, and Netflix’s data-informed distribution.

In product, most PMs do the opposite. They try to build for everyone and end up resonating with no one. Building MVPs and solving one use case deeply for a real user problem in a real context before scaling.

Lesson: Building depth before breadth is how product teams learn and earn lasting resonance.

From fantasy to real‑world leadership

KPop Demon Hunters isn’t just a story about idols and demons. It’s a blueprint for collective courage. The film conveys messages about building emotional connections, community engagement, and storytelling that align well with product management strategies focusing on creating customer loyalty, brand identity, and user ecosystems. Popular culture sometimes surfaces truths about organizational behavior before business literature catches up.

The biggest demon in our organizations is the feature‑factory mindset. It is the trap where teams equate delivery speed with progress. The deeper cost is waste and solving the wrong problems.

The antidote is clarity of thought, courage to take ownership and be accountable, and thinking in systems.

That’s how product teams stop fighting the imaginary demons and start building the product barrier with shared rhythm, skill, and clarity under pressure.

These days, every company wants AI to make sense of its chaos.

We live in a world where AI tools pull from emails, chats, meetings, and documents to build a perfect map of how our business processes work and everything we’ve decided.

But most of what matters never makes it into those systems.

I’ve lost count of how many times a meeting has derailed with, “I thought we agreed on this last week.” We all pause—because no one actually remembers. The notes were never written, and the decision was never logged.

More than once, I’ve stopped mid-discussion to ask, “Is anyone taking notes?”

Silence.

So I share my screen, open a Loop page, and start documenting in real time—discussion points, trade-offs, outcomes. Everyone nods. The cycle repeats the next day or week.

We spend hours in meetings, yet very few of those hours turn into written memory.

We’re just speaking into the void. No synthesis. No record. No foresight.

📊 What the research shows

• 47% of employees spend between 1 and 5 hours a day searching for the information they need. (Cake)

• 54% of organizations rely on more than five different platforms to document or share knowledge. (Cake)

• Even when tools exist, adoption is low—only 45% of employees in large companies use their knowledge management systems. (IDC)

• Fragmented information directly reduces efficiency and process quality. (Han van der Aa, AMCIS study)

These numbers confirm what many of us see every day: teams lose time and judgment chasing information that should already be known.

I think better when I write.

Words on a page bring structure to chaos. They turn abstract ideas into something concrete enough to question, refine, and agree on. Clearly written words rarely lose context; they anchor the discussion.

Sometimes, when I want alignment, I’ll ask, “How would you phrase it? I want to capture it in your words.” That small act turns verbal agreement into shared understanding. It forces precision and creates ownership.

Years ago, in a previous role, I asked my team to keep our wiki up to date with priorities, the roadmap, the backlog, data, and key decisions.

It was a small team, which made setting expectations easier. To their credit, they followed through. Whenever someone asked for an update, we shared the wiki link instead of joining another meeting.

It saved us hours and taught others to find information on their own. That documentation became our single source of truth—a living record of our work, reasoning, and progress.

That discipline, though, fades quickly when people move on or when there is a change in leadership. Documentation starts to feel optional again. Context disappears. Teams begin rehashing the same things.

GenAI promises to stitch together information from everywhere.

The reality is that AI can’t synthesize what doesn’t exist. It can summarize, tag, and connect, but it can’t recover lost memory.

Most companies don’t have a reading or writing culture. Conversations live in chat threads, recordings, and hallway talks. Knowledge fragments and eventually vanish.

The real opportunity isn’t more tools, it’s rediscovering the discipline of writing things down. Writing is how teams think together.

AI will help us find and connect the written material. But it can’t fix what we don’t record.

Until we build cultures that value writing as much as talking, we’ll keep losing our most important work to the noise of our own conversations.

‌This reflection is part of an ongoing series on decision hygiene, knowledge flow, and product culture—how teams think, decide, and remember together.

Most product managers, especially in non-tech large enterprises, don’t work in ideal conditions. They operate within systems that are anything but simple: layers of governance, legacy platforms, fragmented data, and limited user access. Decisions are made with incomplete context, and priorities are often shaped by timelines rather than outcomes.

Early in my career as a product manager, I believed those constraints were the problem. They slowed us down, blurred focus, and made every choice feel like a compromise. Over time, I realized that constraints were also an opportunity to build product taste.

When we didn’t have perfect data, we learned to listen differently, not to confirm what we already knew, but to find signals in what others overlooked. When we couldn’t talk directly to customers, we looked at behaviors, support tickets, and the moments where users tried to work around us. When the roadmap was locked, we used small traffic ramps or experiments to test what mattered most.

Those moments taught me more about product judgment than any perfect process ever could. Because product taste doesn’t form in ideal conditions.

Product taste sharpens even in constraint — when you’re forced to make decisions before certainty, and learn to choose clarity anyway.

What Constraint Looks Like

Constraint doesn’t always look dramatic. Most of the time, it looks like trying to make thoughtful product decisions with half the picture.

It’s when a UX design review gets stuck in the compliance approval process. When you have data, but it’s directional enough to sense a pattern, but not to bet on it. When your only access to customers is through online user testing tools, not real conversations. When priorities shift because a senior leader made a promise you didn’t know about. When “agile” starts to feel like a waterfall with better branding.

These are the conditions most product managers quietly navigate every day. They don’t make the work impossible, but they do make it harder to stay grounded in the why. It’s easy to slip into output mode, to chase certainty through motion, and to measure progress by deliverables instead of understanding.

But these same environments are prime spaces to sharpen your instincts:

• Start noticing patterns that others miss in customer escalations, support tickets, and how internal teams describe recurring problems.

• Learn to extract signals from imperfect data, to make decisions without full validation, and to test your judgment against real outcomes once changes go live.

That’s what real product constraint looks like — not just a lack of resources or access, but the constant pressure to decide with limited clarity. And that’s where product taste earns its edge.

How Product Taste Develops Inside Constraints

In constrained environments, product taste isn’t built through perfect processes; it’s built through pattern recognition, curiosity, and the discipline of asking better questions.

When the data is limited, I’ve learned to triangulate. Insights come from multiple places: analytics, customer care logs, feedback from internal teams, and small experiments that reveal directional truth. Over time, patterns start to emerge between what users experience, what they share through testing tools, and what surfaces once changes go live.

When the roadmap is fixed, the focus shifts to what’s most worth validating, not what’s easiest to deliver. Sometimes that means reframing a feature request into a hypothesis — “If this change is solving the right problem, we should see fewer drop-offs or faster completion.” Even small tests create more signals than assumptions ever could.

When decisions are driven by timelines or executive pressure, clarity becomes the tool to push back. That clarity doesn’t come from hierarchy; it comes from understanding. We can’t always say “no,” but we can ask why now?, What’s the trade-off? Or how will we measure success? Those questions are how teams in constrained environments hold the line on quality.

You can tell when this kind of judgment starts to take root. Reviews shift from status updates to deeper discussions about intent. Engineers bring up user signals before PMs ask. Designers use data to challenge assumptions. Leaders ask about outcomes instead of dates. The team spends less time explaining the “what” and more time aligning on the “why.”

That’s what product taste looks like in motion — not a special skill or luxury, but a discipline that shapes every decision, even when the view is partial.

What Sharpens Taste Under Pressure

Over the years, I’ve noticed that PMs who develop strong product taste in constraint-heavy environments share a few traits. They stay curious when answers are vague. They show courage when priorities need to be challenged. They create clarity when the path forward is messy. And they stay consistent when progress feels slow.

Those four traits: curiosity, courage, clarity, and consistency, tend to separate teams that simply react from those that refine. They’re not frameworks or buzzwords. They’re the habits that shape better decisions, especially when conditions aren’t ideal.

Product Taste Compounds Over Time

Many teams act as if product taste can only develop in ideal conditions, when there’s clean data, direct user access, and clear executive support. But it’s usually the opposite.

Constraints force product managers to rely on judgment rather than process. It makes trade-offs visible. It pushes you to build alignment where there isn’t any, to define success before metrics exist, to keep your focus when everything around you feels urgent.

Product taste starts to take shape in the daily practice of thinking deeply when it would be easier not to, without waiting for perfect conditions.

And if you keep showing up with curiosity, courage, clarity, and consistency, product taste compounds. It becomes part of how you think, how you decide, and how you lead, even when the environment hasn’t caught up yet.