Over eight years across fintech and edtech, I’ve worn many hats — Scrum Master, Agile Coach, Digital Transformation Lead. Small teams, large organizations, everything in between. The scale kept changing. The context kept changing. But one problem had a strange habit of showing up everywhere.
Teams could run excellent processes — and still fail to create real value.
That observation, eventually, reshaped everything about how I work.
When everything runs and nothing moves
There’s a tempting logic to having one person own the product thinking. Clear accountability, defined role. The PM thinks, the team builds.
Sounds sensible. In practice, it’s fragile.
I didn’t learn this from a book. Product thinking concentrated in a single person is a hidden point of failure for the entire system. That person goes on vacation, burns out, leaves — and suddenly it turns out that nobody else actually knows why the team is building what it’s building.
Product thinking is not a role. It’s a distributed capability.
What product thinking actually means
It’s not writing features. Not grooming a backlog. Not shuffling ticket priorities.
It’s the team’s ongoing ability to answer four questions:
When those answers live in one person’s head — that’s dependency. When the whole team can answer them — that’s capability.
Story one: the team was working, but didn’t know why
In one team I worked with, the Product Manager was the only person who truly understood the logic behind the roadmap. While she was around, things ran smoothly. When she went on a two-week vacation, the team kept closing tickets.
At the Sprint Review while touching the idea of moving towards our strategic goal, the team could not explain their result
Silence.
But the real damage wasn’t the awkward pause. Engineers didn’t understand how current work connected to future direction. Technical debt wasn’t mapped to product strategy. Decisions became fragmented. People quietly stopped proposing ideas because they couldn’t see the bigger picture.
The system was functioning. It just wasn’t aligned.
What we changed:
We introduced quarterly roadmap walkthroughs — co-presented by the PM and engineers. Every backlog item got a mandatory “Why this matters” section. Sprint Reviews were reframed around four things: the problem, the hypothesis, the increment, and early signals.
Within two months, engineers started challenging scope based on goal alignment. We cut unnecessary scope by around 15%. Stakeholders gained confidence because teams could now explain not just what they built — but why it mattered.
Dependency started to decline.
Story two: two teams, two time horizons
Discovery and delivery are different types of work. The trouble starts when they become different ownership domains.
In this case, the Product was operating on quarterly discovery goals. Engineering was running on weekly sprint commitments. They rarely intersected. There was no shared moment of “we completed something valuable.”
The result was predictable: weak collaboration, blame when things broke, mid-sprint chaos whenever priorities shifted. They weren’t misaligned on values — they were living in completely different time horizons.
What we changed:
We introduced the concept of a Value Slice as the unit of commitment — aligning weekly planning to outcome slices rather than task volume. We defined an explicit “success of this week” metric and created shared moments of value completion.
Predictability improved. Mid-sprint disruptions dropped. Tension between Product and Engineering eased.
More importantly, decision cycles shortened. Discovery and delivery stopped competing for ownership — and when value became shared, accountability followed naturally.
What distributed product thinking looks like in practice
Let me give you a real example.
We were building a new checkout flow. The setup was classic: PM arrived with a detailed spec, engineers were there to implement it.
During refinement, one engineer asked: “Why are we rebuilding the whole flow now? What problem are we actually solving?”
The PM explained: stakeholders wanted cleaner UX and fewer steps.
Another engineer pushed back: “Our data shows 30% drop-off on the payment screen. The issue might not be visual complexity — it might be trust, or friction around entering card details.”
The room split. The PM was worried about the delay. Engineers were worried we’d solve the wrong problem. Stakeholders expected visible progress.
Under the old model, the PM would decide and the team would execute. Instead, we reframed the conversation around three questions:
We ran an A/B test instead of a full redesign — a simplified one-click option for returning users, and clearer trust signals near the payment step.
Drop-off decreased by 10%. We avoided a six-week redesign. The team gained real confidence in data-informed decisions.
But the deeper shift was systemic. Engineers stopped waiting for specs. The PM stopped being the sole product thinker. Improvements became iterative experiments rather than large, risky launches.
That’s distributed product thinking.
The Agile patterns that quietly kill product thinking
Some teams follow every ritual — and still erode their product capability without noticing. A few patterns I’ve seen again and again:
Proxy voting in refinement. The PO scores everything alone. The team never learns to weigh value against effort.
Siloed ceremonies. Standups become status reports instead of decision forums.
Feature-factory backlogs. Tickets with no user impact metrics. Just output, on a treadmill.
Handover-heavy processes. Design gets thrown over the wall. Dev implements without ever co-owning the problem.
These patterns look efficient. They’re quietly trapping product thinking in a single role.
What a Scrum Master can actually do about this
It took me years to articulate this, but Scrum Masters hold unique leverage here. And I say this from personal experience — I never had a pure product role. I started in facilitation, process health, and team dynamics. But I kept running into the same uncomfortable truth: if product thinking stays centralized, clean ceremonies won’t make the system resilient.
So I started expanding — not abandoning Scrum foundations, but building on top of them.
Rewire the ceremonies, don’t add new ones. Every refinement I ran started with the same questions: What behavior are we trying to change? How will we know it worked? What assumption are we making? What’s the smallest slice to test? I rotated who answered first. For the first few weeks — silence. Three months later — engineers were challenging hypotheses before I even asked.
Use a simple mental model: Delivery, Outcome, Uncertainty.
Applied to a real story, it might look like: Delivery: new login button. Outcome: 20% faster access. Uncertainty: does color contrast affect trust perception? Once teams started mapping DOU themselves, I knew the thinking had transferred.
Run impact mapping workshops together. Instead of the PM presenting the roadmap, we’d work through it as a group — user behavior, desired impact, possible interventions. Engineers saw strategic connections. The PM stopped being the sole narrative owner.
Measure the signals, not the compliance. I tracked the percentage of stories with team-written success criteria, cross-role participation in prioritization, and the ratio of experiments to fixed-scope deliveries. Not to control — to see whether the dependency was actually declining.
What happened when it worked
As product ownership distributed across the team, something shifted in the whole system.
Decision latency dropped. Product managers carried significantly less cognitive load once teams started participating in hypothesis framing. Stakeholder trust increased — because teams could explain both what they were building and what they were learning.
Most importantly, the organization became less dependent on individual product leaders. Product capability stopped being a trait of specific people and started being a property of the system itself.
Engineering-driven product ideas started appearing more often. That, to me, was the clearest signal: product thinking was no longer someone’s job title. It had become how the team worked.
What this changed for me
Looking back across nine years and a lot of different organizations, the pattern I kept seeing was surprisingly consistent.
Teams could have excellent Agile practices — structured backlogs, regular ceremonies, healthy delivery cadence — and still struggle to create meaningful product impact. The issue almost never came down to discipline or process quality. It was structural. Product thinking had been concentrated, sometimes intentionally, sometimes just by habit.
The most effective changes I witnessed never came from adding new frameworks or tightening the ceremonies. They came from gradually distributing product thinking across the team — making problem framing, hypothesis testing, and outcome evaluation shared activities rather than one person’s responsibility.
When that happens, engineers stop waiting for specifications. Product managers gain space to think strategically. Decisions move closer to the actual work.
And product capability stops being someone’s job — and becomes the way the organization thinks.
Facilitating processes matters. But designing systems where teams can think about the product together — that’s what makes the processes worth anything at all.
