In a recent Product Excellence conversation, Maya explained her reasoning. It starts with a reality of the role: you have no direct authority over anyone on your team. Engineers and designers do not report to you. Their compensation is not tied to following your direction. You operate through influence and the quality of the environment you create around the work.

That framing changes what product manager responsibility means in practice. The PM is responsible for the conditions under which everyone else can do their best work. Those conditions determine whether a team moves with confidence, and no amount of roadmap precision can substitute for them.

What Empowerment Looks Like at the Task Level

Maya breaks empowerment into its operational components. Each one maps to a specific function the PM performs daily. Clearing up user stories and writing requirements so engineers can work without ambiguity. Making meetings less painful so the team’s calendar supports the work. Increasing transparency so every function can see what is happening across the team. Building communication rhythms that keep information flowing between functions. Conducting user research that grounds the team’s decisions in real customer behavior.

These activities accumulate into the infrastructure that determines whether a team can move or stays stuck. Maya’s framing puts the PM at the center of that infrastructure. The PM ensures that information flows and blockers get cleared. The team’s energy goes toward building.

The implication for how PMs spend their time is direct. Early in her career, Maya expected the role to center on building and shipping. She learned that the majority of PM time goes to supporting work. Researching. Scoping. Making sure every function understands the current state. The system-building work is where the leverage lives.

Alignment as the Measure of PM Effectiveness

Maya describes the end state: a team moving in the same direction, at the same pace, toward the same goal. That level of alignment does not happen by accident. It is the product of a PM who invested in the connective tissue between functions. Transparency mechanisms. Communication cadence. Clarity of requirements that let people move forward.

Her perspective reflects years of building these systems across environments ranging from a 12-person startup to Klaviyo. At the startup level, she built the team’s entire process from scratch. The principles hold across scale. The mechanisms change, but the PM’s responsibility remains the same: build the system, and the team will perform.

In the full Product Excellence interview, Maya walks through how she evolved her process as her team grew. She describes what she tells product managers who feel invisible despite doing the work that keeps everything moving.

Watch Maya’s full breakdown in the Product Excellence clip on YouTube. Subscribe to The Product Way for more conversations with award-winning product leaders.

Why Team Processes Go Stale

Processes tend to solidify quickly. A team tries something during its first few sprints, it works well enough, and it becomes the default. Over time, the team grows, the product changes, and the original conditions that made the process effective shift underneath it. The process stays because nobody has a strong enough reason to change it, and changing it feels like a bigger commitment than keeping it.

The result is that many teams are running on assumptions about their own workflows. Requirements might flow in one direction because that is how it was set up, not because the team tested alternatives. Standups might follow a format that made sense for a five-person team but creates friction for a team of twelve. The processes work well enough to avoid a crisis, which means they rarely get examined. Teams that start questioning their defaults, even informally, often find that the process they assumed was working was actually absorbing effort that could go elsewhere.

The Experiment Mindset

Merziyah’s approach reframes process improvement as something that can happen in small, reversible increments. Instead of overhauling a workflow after a retrospective, she identifies one variable, changes it for a fixed period, and lets the team evaluate the result together. The scope stays small enough that nobody is committing to a permanent change. A team that knows it can revert in two weeks will try things it would resist if the change felt permanent.

What makes this effective is the evaluation step. The team does not just try something new and let it drift into a default. There is a defined moment where everyone assesses whether the experiment improved things, made them worse, or produced no change. That structure turns a casual suggestion into a real test with a real conclusion.

What Changes When Teams Adopt This

Teams that experiment with their own processes start surfacing assumptions they carried for months. Communication patterns shift because people articulate things they previously absorbed in silence. The team builds a shared understanding of why their processes work, because they have tested the alternatives and seen the results. Even experiments that fail produce clarity. A team that tries a different approach and returns to the original now understands the original in a way it could not have before.

Merziyah walks through two specific experiments in her How I PM tip, each with a different outcome and a different lesson for the team.

“We were able to identify a lot of the misunderstandings because I was getting their explanation and not just my explanation.”

Merziyah Poonawala, Principal Product Manager, MFP Services

Connect with Merziyah: https://www.linkedin.com/in/merziyahpoonawala/

Jenna Gaudio, Co-President of Vydia / Gamma Distribution and Technology, built a sprint planning process that eliminates most of that friction. Her team arrives at planning day with the scope already negotiated, the architecture already discussed, and capacity already allocated across every part of the company. Planning becomes a confirmation step.

In this Product Excellence clip, Jenna walks through the full sprint cycle her team runs at Vydia, starting with how the backlog is organized and why that structure changes the entire dynamic of sprint planning.

The backlog is not a flat list. Her team categorizes incoming requests from customers, executives, and internal teams into a structured backlog with capacity reserved for each stakeholder group. That structural decision is what makes the pre-sprint negotiation with leadership possible, because every group already has a defined share before anyone sits down to plan.

What happens between that backlog structure and planning day is where the process gets specific. Jenna sequences multiple meetings across the days leading up to planning, each with a different purpose, so that by the time the team commits to a sprint, the unknowns have already been resolved.

The clip also covers how Jenna distributes project leadership during the sprint. On big features, developers and designers carry responsibility alongside the PM in a way that builds management experience into the daily work of the team.

Watch the clip to hear Jenna walk through each stage, including the pre-sprint negotiation sequence and how shared ownership works during execution.

Subscribe to The Product Way on YouTube for Product Excellence clips with product leaders walking through the systems they use to run their teams.

That moment, where a familiar number decouples from the outcome it was supposed to predict, is where most metric reform conversations begin. The latest Roadmap to Mastery article on The Product Way traces what happens next, and the three dynamics that determine whether the reform builds momentum or stalls.

The first is the activity-to-outcome transition, and it is harder than the principle suggests. Page views per session predicted purchase intent because browsing and buying were coupled in the original product design. That coupling was real, which is what made the metric feel trustworthy for two years. The complication is that product changes, market shifts, and changes in user population can break the coupling without breaking the metric. The number still moves. It just stops meaning what it used to. Teams that recognize the shift can recalibrate, and the recalibration requires judgment about which correlations still hold, which ones have weakened, and which leading indicators now predict the outcome more reliably. A metric like qualified lead velocity or repeat session depth may track conversion intent more accurately in the new product environment, and identifying that replacement before retiring the old metric gives leadership something meaningful to watch during the transition. The judgment call differs by product maturity: early-stage products where the original correlation was never rigorously validated need different leading indicators than mature products where a once-reliable correlation has started to decay.

The second dynamic is the political economy of measurement. Page views per session did not live on the dashboard alone. Marketing referenced it to demonstrate campaign effectiveness, product used it to justify feature investment, and the executive who presented it to the board built a quarterly growth narrative around it. Each of those stakeholders has a relationship with the metric that extends beyond its informational value, and proposing to retire it starts a conversation about visibility and contribution that goes well beyond data hygiene. The reform works when leaders can show each function that their contribution remains visible through the new measurement. Making that visibility explicit before proposing the change means the conversation becomes an evaluation of a trade where each team can see what they gain, and that framing is what moves the discussion forward.

The third is sequencing, and it determines whether political capital builds or exhausts across the reform effort. The first metric to retire should be the one with the weakest constituency, the number that appears in the fewest reports and that the fewest stakeholders would miss. Removing it generates the least resistance and produces the first evidence that the dashboard can function with fewer numbers. That evidence is the foundation for every subsequent conversation. The second round can target a more protected metric with credibility behind it, because the organization has already seen that removing a number did not create a blind spot. Each successful round expands the team’s ability to propose changes that would have been politically impossible at the start.

The thread connecting all three dynamics is that metric reform compounds. A successfully retired metric builds credibility for the next conversation. A transitional quarter where leadership tolerates a slow-moving outcome metric builds organizational patience for ambiguity. And the leading indicators that demonstrate a causal relationship to outcomes give the team a bridge between the old measurement system and the new one, which is what makes the patience sustainable over multiple quarters. The organizations that reach the other side of this process end up with dashboards where every number connects to a decision, and where the team’s time is spent interpreting signal that actually informs the work.

The March TPG Live roundtable surfaced these dynamics, and the Roadmap to Mastery article goes deeper into the organizational forces that determine whether each step succeeds: the specific conversations leaders need to have before proposing a change, how to identify which correlations have decayed, and what the transitional quarter looks like when it is managed well.

Watch the full March TPG Live roundtable replay: https://youtu.be/QXYf_HY8ZEo

For non-members: Join The Product Way to access the full article, the complete Roadmap to Mastery series, PM Select (curated introductions to trusted hiring managers), and weekly strategies: https://patreon.com/TheProductWay/membership

For existing members: Read the full article on Patreon: https://www.patreon.com/posts/patreon-why-your-155105157

#ProductManagement #ProductLeadership

The latest Roadmap to Mastery article on The Product Way examines this dynamic in depth. It traces how metrics acquire constituencies: the person who requested the number, the team that reports on it, the executive who references it in board presentations, the sales leader whose commission structure touches it. Each has a relationship with the metric that goes beyond its informational value, and proposing retirement starts a conversation about identity and visibility that most cleanup efforts underestimate.

The article also examines context collapse: what happens when a number is read without the conditions that give it meaning. An NPS score that tanks because the survey hit during billing friction tells a different story than the aggregate suggests. Engagement numbers that look like intent on a search platform may signal confusion or aspiration. The precision of the number creates confidence, and the missing context creates incompleteness. Teams making decisions from those numbers are often more sure than they should be.

The March TPG Live roundtable surfaced both patterns, and this article goes deeper into the forces that keep them in place: why “just in case” wins every metric retirement debate, why the people who feel dashboard weight most have the least organizational leverage to change it, and how the conversation about retiring a metric is always a conversation about something else. Leaders who see these dynamics clearly can work within them, and the article traces how incremental approaches build the credibility and evidence that make each subsequent cleanup conversation easier.

Watch the full March TPG Live roundtable replay: https://youtube.com/live/8BCNuOYk-y0

For non-members: Join The Product Way to access the full article, the complete Roadmap to Mastery series, PM Select (curated introductions to trusted hiring managers), and weekly strategies: https://patreon.com/TheProductWay/membership

For existing members: Read the full article on Patreon: https://www.patreon.com/posts/patreon-why-your-154517188

#ProductManagement #ProductLeadership

Garrett Lang, Founder and President of PlateRate, chose real restaurants. Over the past several months, he has run beta events where actual diners use PlateRate in actual dining environments. PlateRate is the only pickup/delivery app that credits diners for trying a restaurant’s highest-rated menu items. It won the TPMAS (The Product Management Awards) award for Visionary Product of the Year 2019, and Garrett has been building and iterating on it for over a decade.

The beta events confirmed that PlateRate solves the core problem Garrett set out to address. People could order food, manage their own checks, and handle tipping through the app. The product worked. And the feature that generated the strongest response from beta diners was the freedom of walking out.

Finish the meal, tip on the app, leave. No flagging down a server. No waiting for a credit card return. The restaurant gets notified that the diner has paid, so when someone walks out, it is expected.

Garrett describes it as freedom, and that word carries weight for anyone who has ever watched ten minutes tick by after a meal waiting for the check to arrive. Product validation through beta testing in a real environment gave Garrett signal that surveys, focus groups, and prototype demos would not have surfaced with the same clarity.

That signal tells Garrett where PlateRate’s pull actually lives. If walking out is the moment that creates the strongest positive reaction, that insight shapes how the onboarding communicates value, how the marketing positions the product, and how the development team prioritizes features.

Garrett is transparent about where PlateRate sits today. The beta is live, and the product works, but he has specific quality thresholds that need to be met before public marketing begins: user friendly, intuitive, bug free, and performant. The redesigned website is still in progress. He is building toward a product that is pixel perfect before he starts spending on acquisition.

That approach takes discipline. Validation confirms you are solving the right problem, and the temptation to market early is strong at that point. Garrett’s path is to let the beta testing continue shaping the product until the experience matches the quality bar he has set. When PlateRate goes to market publicly, the product will already have earned loyalty from the people who tested it.

Subscribe to The Product Way on YouTube for more conversations with product leaders about validation, product strategy, and building products that earn loyalty.

Watch the Episode Now:

#ProductManagement #ProductLeadership #CareerGrowth #ProductExcellence

About the Podcast:

Where Cross-Functional Ideas Come From

People rarely contribute outside their lane randomly. When a tester sketches a better user flow or a PM flags a metadata structuring issue, it means their proximity to the work has surfaced something the team’s default structure would miss. These contributions reflect experience accumulated across different disciplines, and they carry information the specialist in that domain may not have access to.

This is especially true for leaders who came to product management through non-traditional paths. Someone who has worked across research, operations, and technology sees the product through multiple lenses simultaneously. The connections they draw come from years of navigating different disciplines, and they surface patterns that a more linear career path would never produce. When teams create space for that range of observation, the product benefits from perspectives the org chart was never designed to capture.

What Changes When Teams Evaluate Ideas on Merit

The teams that genuinely break down role barriers in product teams change what happens to an idea after it’s raised. They evaluate the substance of the observation separately from the credentials of the person who offered it. When that separation becomes a real practice, something specific shifts: people start contributing their full range of thinking, because they’ve seen the team respond to the quality of the idea rather than the title behind it.

That shift compounds over time. A PM who regularly brings technical recommendations to the engineering table, and whose engineers take those recommendations seriously, builds a different kind of working relationship than one where contribution lanes are enforced. The products reflect it. The team culture reflects it. And the people on those teams carry a different level of investment in the outcome, because they know their observations will be heard.

How One Product Leader Practices This

Renata McCurley, Founder of Mariposa Insights and a product leader with over 20 years across consulting and enterprise delivery, has a specific approach to breaking down role barriers that starts with her own willingness to cross contribution lines. In this How I PM tip, she shares how she brings technical recommendations to her engineers and what that dynamic looks like when a team commits to evaluating ideas on merit.

“Don’t discount an idea just because of the source.” Renata McCurley, Founder, Mariposa Insights

Harpal Singh has answered that question more than a dozen times. Across 13+ interim CPO engagements at companies including Ada Health, Automata Robotics, and Selligent, he has led product organizations of 10 to 12 product managers where both sides understand the engagement has an end date. That constraint eliminates some of the most common tools managers use to build credibility: accumulated history, positional authority, and the slow demonstration of competence through long-term results.

What people-first leadership looks like under constraints

Harpal describes a specific trade-off that defines his approach: he would rather compromise the quality of the product than fail to give his people what they need to succeed. That statement sounds like the kind of thing leaders say without testing. In interim roles, it gets tested constantly.

When you enter a new team with limited time, every allocation decision reveals priorities. Time spent understanding what each person needs to grow is time that could have gone toward delivery. Choosing the person over the output has a visible cost. And that visibility is precisely what makes it work, because the team sees the choice being made in real time.

Why interim roles accelerate leadership development

Interim leadership compresses the feedback loop on management decisions. In a permanent role, the effects of management style play out over quarters or years. In an interim engagement lasting 9 to 10 months, the effects surface almost immediately. A team either responds to the leader’s approach or it does not, and there is limited time to course correct.

Harpal describes orienting every action around making the existing team successful. The reasoning is direct: because the engagement is temporary, the interim leader can only succeed if the team succeeds. That interdependence is always present in management, but interim roles make it impossible to ignore.

How teams evaluate authenticity

One of the most practical observations from this conversation is that teams can detect whether a leader’s stated investment in their growth matches their actual behavior. The gap between what a leader says and what a leader does is visible to the people being led, even when the leader believes it is hidden.

This applies well beyond interim roles. Any product leader managing a team is being evaluated on the consistency between their stated values and their daily decisions. The interim context makes the principle more visible, but the principle itself operates everywhere.

Harpal also shared how his approach to mentorship and hiring evolved across two decades of product leadership, and the specific moments that shaped his understanding of what people need from the person managing them.

Watch the full clip on YouTube and subscribe to The Product Way for more Product Excellence conversations.

Watch the Episode Now:

#ProductManagement #ProductLeadership #CareerGrowth #ProductExcellence

About the Podcast:

What became clear across the session is that the practices worth keeping share a characteristic: they survive honest evaluation. The ones that persist without evaluation are often protected by a specific dynamic. The person who would raise the question has less authority than the person who owns the practice. Once that pattern is visible, it changes how you look at everything on the calendar, the roadmap, and the team’s operating rhythm.

From the recap:

Product teams entering a new year face a specific kind of decision that rarely gets made explicitly. The practices that structured last year’s work are still running. Standups still happen at the same time. Backlogs still get groomed on the same cadence. Metrics still get reported in the same format. Most of these routines continue because stopping them would require a conversation nobody has scheduled.

The recap connects four themes into a system: retiring rituals, recognizing anti-patterns, adapting to AI-native product work, and building the environment that determines whether any of those changes hold. The Roadmap to Mastery series arriving over the coming weeks examines the organizational forces, political dynamics, and emotional costs that keep these patterns in place, and what experienced leaders do to change them.

• Read the full recap on Patreon → (for members)
• Join The Product Way to access the recap and the Roadmap to Mastery series → (for non-members)

The belief might have been about user behavior. It might have been about partner incentives. It might have been about which problem the market actually needed solved. Whatever it was, it felt true at the time. It was reasonable. It was shared. And it was wrong.

The cost is never just the work itself. It is the dependencies that formed around it. The commitments made to partners and customers. The organizational momentum that makes reversing feel more expensive than continuing. Teams end up defending a direction they no longer believe in because the cost of admitting the foundation was untested feels worse than the cost of building on it.

This is what it looks like when assumptions shape outcomes instead of evidence.

Why This Keeps Happening

Most product teams are rigorous about execution. They plan carefully. They measure outcomes. They run retros and adjust. The gap is upstream. The beliefs that justify the work in the first place rarely receive the same scrutiny as the work itself.

A roadmap item gets approved because it aligns with the strategy. The strategy rests on an assumption about user behavior. That assumption was formed months ago based on a handful of data points, a few customer conversations, and a lot of pattern matching. Nobody questions it because it feels like shared understanding. Everyone agrees. The belief sounds reasonable, and reasonable beliefs do not trigger scrutiny. But agreement is not evidence, and the assumption has never been tested.

This plays out in specific, recognizable ways. An integration gets prioritized because the team believes the partner’s users will adopt the product. The belief is reasonable, but the partner’s incentive structure actually discourages the adoption path the team designed for. A retention initiative ships because the team believes users drop off due to lack of features. The real issue is that users never understood the core workflow well enough to reach the features that exist. An onboarding improvement launches because the team believes the first session needs to be faster. The actual problem is that speed creates surface-level completion without building the understanding users need to return.

In each case, the work is well-executed. The assumption underneath it was never examined.

What Changes When Beliefs Become Visible

The strongest product organizations we see treat assumptions the way they treat any other strategic input. They name them. They write them down. They pressure test them before the organization builds around them. They sequence work so the most fragile beliefs are challenged first, while the cost of being wrong is still low.

These teams still move quickly. They invest their speed in the right order. They resolve the uncertainty that could invalidate a direction before they deepen commitment to it. The result is fewer late reversals, less wasted investment, and strategy that holds under pressure because it was built on beliefs that survived scrutiny.

The difference is visible in how these organizations handle roadmap reviews, partnership decisions, and scaling choices. The question they consistently ask is: what must be true for this to work, and have we tested it? That question, applied consistently, changes what gets funded, what gets sequenced first, and what gets held back until the foundation is stronger.

What We Built

Our latest deep dive translates this discipline into structured operating systems. The article provides methods for making the beliefs inside your roadmap visible and testable, for ordering work so the most consequential uncertainty is resolved before commitment deepens, and for connecting that evidence to real decisions about what to fund, what to sequence, and what to hold back.

It includes full implementation sequences, practical artifacts you can copy directly into your workflow, scoring rubrics, failure pattern guides with specific prevention methods, and role-specific advice structured from early PM through executive.

If your team has ever discovered too late that a major initiative was built on an untested belief, or if you are about to commit resources to a direction and need to know whether the foundation will hold, this is the system to answer that question before the cost of being wrong becomes the cost of continuing.

[Read the full article on Patreon.]