Some values can only shift through lived experience
I spent a month in Barcelona, and I couldn’t stop fighting the schedule.
Breakfast is small. Lunch happens around 2pm and might stretch two hours. Dinner at 9pm is perfectly normal—restaurants stay packed until 11. The whole city operates on this rhythm, sleeping past sunrise and staying up late into the night.
I can physically do all of this. My body is capable of eating dinner at 9pm. But emotionally, I’m in rebellion. Every morning I wake up around 8, then don’t get out of the house until 10 or 11 after getting the kids ready. The shutters stay closed, the rooms stay dark, and I feel like I’m wasting the day before it even starts.
Here’s what I realized: my resistance isn’t about logistics. It’s about a core belief. I believe daylight is precious. Maybe it’s from past bouts of winter blues, maybe it’s American productivity culture, maybe I just love sunshine. But when I’m not up with the sun, something feels fundamentally wrong.
The Spanish schedule expresses different values—quality time with others, communal meals, building relationships. Neither set of values is “wrong.” But knowing that doesn’t help. I still can’t relax into it.
But my resistance wasn’t just about conflicting values. Even if I’d wanted to adopt the Spanish approach, I couldn’t have. Here’s why: I was essentially a tourist in Barcelona. I didn’t have a community there. To truly understand the value of a two-hour meal with friends, you need friends to share it with. To appreciate staying up until midnight talking, you need people worth staying up for. The Spanish cultural values around connection and community? I never had the context to experience what made them valuable in the first place.
I couldn’t think my way into understanding—I would have needed to live my way into it. And without the social infrastructure that makes those values meaningful, no amount of intellectual understanding would help me adapt.
This is exactly what happens when we try to change product culture.
We introduce a new process. People can technically follow it. But they fight it anyway—not because they can’t adapt, but because we’re asking them to change what they believe, not just what they do. And until we address those beliefs, the change won’t stick.
The same pattern shows up in product management
The same pattern shows up in our work lives. Early in my PM career, a lead engineer taught me that every ticket I write is a contract. Any ambiguity or confusion wasn’t the engineer’s problem – it meant I hadn’t been clear enough. I came to believe that my core responsibility as a PM was to provide perfect clarity and control every detail.
Years later, at a different company, I was spending hours writing exhaustive tickets when an engineer suggested a different approach. He wanted the engineering team to take the lead on tickets while I spent more time talking to customers. A more collaborative model where we’d figure out details together.
I said I’d try it. I could physically do it – nothing stopped me from writing shorter tickets. But emotionally? I was in rebellion. After a few days, I had what felt like an allergic reaction. Just like those Barcelona mornings, I felt like I was doing something fundamentally wrong. I was still going back to expand and edit the engineers’ tickets, creating more work for everyone.
The engineer was asking me to trust that collaboration would create clarity. But I’d never experienced that version of product management. I had no evidence that his approach could protect what I valued. Just like with Barcelona – I couldn’t adopt values I’d never experienced in action.
I brought an underlying belief – that ambiguous tickets meant I was failing as a PM. He was asking me to value collaboration and shared understanding over my need for control and clarity. Neither value is wrong, but until that belief shifted, I couldn’t change how I worked.
Culture is downstream of beliefs—and some beliefs require experience
Culture isn’t just “we do things this way.” It’s “we do things this way because we believe this matters.” And some beliefs can only shift when you’re embedded in the conditions that make them meaningful. You can’t think your way into them – you have to live your way into them.
In Barcelona, I valued daylight. Spaniards valued connection. Neither is wrong—but they lead to completely different daily rhythms. In my PM role, I valued clarity and control. The engineer valued collaboration and shared ownership. Again, neither is wrong—but they produce incompatible ways of working.
The behaviors we see are downstream of beliefs we often don’t articulate. And you can’t durably change the behavior without shifting the belief.
What this means for product transformation
This is why product transformation is so hard. You’re not just asking people to follow a new process—you’re asking them to believe different things about what good work looks like.
When someone resists a change you’re introducing, the instinct is to push harder or explain better. But if the resistance is rooted in values, more explanation won’t help. They’re not confused about what you’re asking. They’re protecting something they believe matters.
The next time you hit a wall of resistance, pause before assuming it’s a process problem. Ask yourself: what value is this person protecting? Until you address that, the behavior won’t change—or it will change temporarily and snap back the moment pressure lets up.
How to shift values: a three-step approach
When you’re hitting resistance, you need to work at the level of beliefs, not just behaviors. This requires a progression—each step building on the last.
First: Surface the protected value
In my ticket story, the engineer asked me to change my behavior without understanding what I was protecting. He saw inefficiency; I saw the only way I knew to be a good PM.
What if he’d asked: “What are you worried will happen if we write shorter tickets?” That question would have surfaced my real concern—that ambiguity meant failure. From there, we could have explored how collaboration might actually reduce ambiguity, not increase it.
Before pushing a process change, ask people what they’re afraid of losing. Not “what’s your concern with this new process” (which invites logistical objections), but “what feels at risk if we do this?” Once you understand the protected value, you can show how the new approach serves that same concern differently.
This step is necessary, but it’s not always sufficient. Sometimes awareness alone can shift behavior—people realize their fear is unfounded, or they see how the new approach protects what they value. But often, surfacing the belief reveals a deeper problem: the person has never experienced what would make the new way of working feel safe or valuable.
Then: Recognize when experiential conditions are missing
Some values can’t be argued into existence. Before moving to implementation, ask yourself: Has this person ever experienced what makes this new approach valuable?
In my ticket example, I’d never experienced collaborative product management done well. I had no evidence that lighter documentation could work. The engineer was asking me to trust something I’d never seen succeed.
This is the critical diagnostic moment. If someone hasn’t experienced the value you’re asking them to adopt, they’re missing the prerequisite for change. You can’t skip this step—you have to build it.
Finally: Build the experiential conditions
I couldn’t embrace Spanish dining culture from the outside. Reading about the value of two-hour meals didn’t help. To understand why late dinners matter, I needed friends worth staying up for. The value only makes sense inside the experience.
The same is true for product transformation. Running a three-day experiment with skeptical participants won’t reveal the value of a new way of working. Trying shared ticket ownership with an engineer you barely know isn’t the same as doing it for three months with a tight-knit team.
The distinction matters: attending one Spanish dinner ≠ having friends worth staying up for. A pilot project ≠ being embedded in a thriving practice. When values require lived experience, you need sustained exposure to the conditions that make them meaningful, not brief exposure to the mechanics.
When introducing a significant change, ask yourself: Have we built the conditions for people to actually experience what makes this valuable? If the answer is no, the pilot will fail—not because the change is wrong, but because the context isn’t there to make it work.
Context isn’t optional for culture change
I never adapted to the Barcelona schedule. Even on my last day, I woke up feeling like I was wasting daylight (and my son fell asleep at the dinner table that night). But this wasn’t a failure of understanding or effort—it was proof of the thesis. I was missing the prerequisite for that culture change. Without a community there, no amount of intellectual appreciation for Spanish values would help me adopt them. Context isn’t optional when you’re trying to shift deeply held beliefs.
This is what makes organizational culture change so difficult. We often ask people to adopt new values without building the conditions that would make those values meaningful. We run workshops, write memos, and explain the “why” behind changes. But if people haven’t experienced what makes the new way valuable, they’re working without the foundation they need.
The next time someone on your team resists a change, don’t just push harder or explain better. Ask what they’re protecting. Then ask whether they’ve experienced what they might gain. And most critically, ask yourself: have we built the conditions—the relationships, the safety, the sustained practice—that would let them experience it?
Culture change requires more than understanding. It requires living it. And that means creating the context where new values can take root.