Shiv Wayal

Guardrail KPIs — Protecting What Matters Most

As product managers, we’re wired to chase metrics —availability, waste, profit, lead time reduction, CSAT — the north stars that define success. But there’s another side to the story that often gets overlooked: the guardrails that protect our product, customers, and long-term product vision.

That’s where Guardrail KPIs come in.

What are guardrail KPIs?

Guardrail KPIs are the metrics that help us avoid winning in one area while losing in another. They’re not about driving growth — they’re about protecting what matters along the way.

Think of it like this:

North Star KPI (Goal-Oriented)	Guardrail KPI (Protection-Oriented)
Drives product performance	Prevents negative side effects
Example: Availability > 99%	Example: Waste < 10%

Why they matter

In supply chain, we often adjust variables and pull levers to hit a specific target. But if we focus too narrowly on one objective, we risk tipping the balance — improving one metric while unintentionally hurting others. That’s where guardrail KPIs help us stay in control and avoid costly trade-offs.

Push availability too high? You risk overstocking, leading to waste and lower margins.
Cut waste too aggressively? You might understock, hurting availability and customer experience.

Guardrails help us balance speed with stability. They give us confidence to make trade-offs — knowing we’re not compromising long-term value for short-term wins.

How to define guardrail KPIs

Here’s a simple way to build them into your product thinking:

Start with your goal. What’s the primary KPI you’re chasing? (e.g., availability, waste, lead time)
Ask: “At what cost?” What could go wrong if we push too hard?
Quantify the risk. What metrics signal those risks?
Set thresholds. Define limits. If a guardrail dips below the line, it’s time to pause or pivot.

Final Takeaway

Guardrail KPIs aren’t just a nice-to-have, they’re a practical tool to help us avoid costly missteps. As you plan your next roadmap or adjust supply chain levers, make it a habit to ask:

What does success look like?
What could we unintentionally impact while chasing that success?

This kind of thinking helps us make well-balanced and well-informed product decisions.

January 13, 2026
0 Comments

R-P-P (Reality → Perception → Perspective) Mental Model

Mental Model

The Reality–Perception–Perspective (RPP) mental model will help distinguish objective facts from human experience and stakeholder interpretation, preventing confusion caused by mixing the three. By separating what is true, what is felt, and how it’s interpreted, RPP enables clearer thinking, faster alignment, and better decisions.

Think of it as a 3-layer stack or a 3-stage pipeline. Each layer answers a different question.

Separate facts, feelings, and viewpoints to gain clear, actionable insight.

The “Sorting Test”

When you hear a statement, classify it like this:

Is it about facts? → Reality
Is it about experience? → Perception
Is it about interpretation or judgment? → Perspective

Example: “The product is slow.”

Reality: “Median response time is 3.1 seconds.”
Perception: “Users feel it’s slow.”
Perspective: “As a PM, I think that’s unacceptable for onboarding.”

Why is this model powerful?

Prevent arguments caused by mixing layers (“You’re wrong” when you’re just in different layers).
Diagnose problems correctly (is this a real issue, a perception issue, or a framing issue?).
Communicate better (“Here’s the data, here’s what users feel, and here’s how each team sees it.”)

One-line memory hook

Reality is - what is.
Perception is - what’s noticed.
Perspective is - how it’s judged.

In short: Fact → Feeling → Frame

RPP lens for Product Manages:

1. Product Reality (Facts)

What is objectively true about the product. This is your instrumentation layer.

Includes:

Metrics (latency, uptime, conversion, retention, churn)
Usage data (DAU/MAU, funnels, cohorts)
System constraints (tech debt, cost, scalability)
Market facts (pricing, competition, regulation)

PM question: “What is actually happening in the product and market?”

Tools: Analytics, Logs, Experiments, Benchmarks

Failure mode: Building based on opinions instead of data.

2. User Perception (Experience)

How users experience and feel about the product. This is your empathy layer.

Includes:

User complaints
Reviews, NPS, CSAT
Support tickets
Usability findings

PM question: “How does it feel to use this product?”

Tools: Interviews, Usability tests, Surveys, Session recordings

Failure mode: Ignoring user pain because metrics look fine.

3. 3. Stakeholder Perspective (Interpretation)

How different stakeholders interpret the same reality and perception. This is your alignment layer.

Includes:

Engineering constraints (quality, complexity)
Leadership goals (growth, efficiency, strategy)
Legal/compliance risk
Marketing positioning

PM question:
“Why do different teams disagree about what to do?”

Tools: 1:1s, Roadmap reviews, Strategy docs, Incentive mapping

Failure mode: Roadmap becomes political instead of rational.

How PMs should use the model?

Step 1: Anchor on Reality - “What does the data say is happening?”

Step 2: Validate with Perception - “Do users experience this as a problem?”

Step 3: Resolve via Perspective - “Given our goals and constraints, what should we do?”

This prevents:

Data-only decisions that ignore humans.
Empathy-only decisions that ignore scale and cost.
Politics-only decisions that ignore truth and users.

Example: “Onboarding is broken.” Break it down:

Reality:

35% drop-off at step 2.
2.8s latency on first API call.

Perception:

Users say it feels “slow and confusing.”
Support tickets mention unclear error messages.

Perspective:

Sales: “We’re losing deals.”
Eng: “Fixing this risks destabilizing auth.”
Leadership: “Activation is a top OKR.”

The Product Manager Decision Filter

Before prioritizing anything, a PM should ask:

Is it real? (Data)
Is it felt? (Users care)
Is it aligned? (Business + team context)

Only when all three are “yes” should it rise to the top.

Product Manager mantra: Build on facts, design for feelings, decide through frames.

In Short: Measure → Empathize → Align → ActTop of Form

Bottom of Form

January 10, 2026
0 Comments

First Principles Thinking

Product Management

As product leaders, you’re constantly surrounded by playbooks, frameworks, and the comfort of “this is how it’s always been done.” It’s easy to fall into the habit of solving problems by following precedent.

That’s where First Principles Thinking really shines - it helps us strip away assumptions and rebuild our understanding from the ground up. I've seen this thinking in action among strategic leaders and critical thinkers.

What Is First Principles Thinking?

First Principles Thinking is a problem-solving approach that involves breaking down complex ideas into their most fundamental truths and reasoning up from there - rather than relying on assumptions, analogies, or conventional wisdom.

It asks:

“What do we know to be absolutely true?”
“What can we build from those truths?”

Why It Matters

When we reason from first principles, we:

Challenge assumptions - they might not hold up anymore.
Get creative - don’t let “how it’s usually done” limit your ideas.
Focus on core drivers - that’s where better decisions start.

First principles thinking is incredibly powerful in product management. At Starbucks, we often navigate misalignments, compounded risks, and tough product decisions. I’ve found that the most effective way forward is to challenge the problem as it's initially framed. By stripping it down to its bare essentials, there's a moment of clarity—and in that moment, it becomes unmistakably clear what we’re truly solving for.

Applying It at Work

Try this exercise:

Identify a problem you’re facing.
Break it down into its fundamental truths - facts that are undeniably true.
Rebuild your solution from the ground up, ignoring analogies and assumptions.

Say a project is running behind schedule. Instead of jumping to “we need more resources,” pause and ask: What’s really causing the delay? Is it a tech issue, a process bottleneck, or maybe team alignment? First principles thinking help you strip it down to the root cause. If you were starting from scratch, what would solving it look like? That’s where real clarity and better solutions begin.

Final Thought

First principles thinking isn’t about being contrarian - it’s about being curious. It’s about refusing to accept complexity at face value and daring to ask, “What is really true here?”

Let’s challenge ourselves to think deeper, question more, and build from the ground up.

January 06, 2026
0 Comments

Fall in love with Problem

Leadership

Product team is about building the right product. Technology is about building the product right.

But how do we know if we’re building the right product? Too often, we don’t. Intake requests, projects and business cases frequently arrive with solutions baked in. Sometimes, the “problem” is retrofitted to justify an idea someone loves - whether they invented it or saw it succeed elsewhere.

This is one of the biggest traps in product management: jumping to solutions before understanding the problem, or defining the pain. When the solution becomes the starting point, the risk isn’t misalignment, it’s irrelevance.

We lose sight of why we’re building, for whom, and what outcome we aim to change.

Why Problem-First Thinking Wins

A great discovery doesn’t begin with “What are we building?” but with “What must change?” If we begin by clarifying solutions disguised as requirements, we have already ceded the most important question.

A problem-first mindset pushes us to ask:

What is the core problem -and why is it worth solving?
Who feels the pain, and how will we know it’s gone?
What trade-offs does this decision demand?

These questions are how we avoid building something correct, but ultimately irrelevant.

How to Apply at Work

Before approving a requirement, shaping a story, or aligning stakeholders, pause and ask:

Are we validating the problem or just refining a solution?
Can we articulate the business value in one clear sentence?
Are we hearing the real customer, or a proxy with an opinion?

If we can’t answer these, we aren’t ready to build.

Closing Thought

A strong product manager is first and foremost a problem solver -which means the problem must be clearly articulated before anything else. Great product teams don’t romanticize solutions; they dig deep to uncover real pain points.

So, when someone brings you “the solution,” respond with curiosity, not acceptance.
Fall in love with the problem and the right solutions will follow.