PM Health Scorecard — marianasg.com

Q1 of 15

How does your team stay close to what customers actually experience with your product?

We rely on support tickets and occasional feedback — there's no structured process for hearing from customers We do interviews or surveys occasionally — usually when there's a specific question or before a big launch We have a consistent cadence — regular customer conversations are part of how we work, not a special project

Q2 of 15

When it comes to understanding your customers, which best describes how your team uses qualitative and quantitative signals?

We rely mostly on one type — either we talk to customers or we look at analytics, but rarely both at once We use both, but separately — conversations and data don't usually inform each other in a structured way We actively triangulate — usage data tells us where to look, conversations tell us why, and we use both to challenge our assumptions

Q3 of 15

How do customer and user insights actually influence what gets prioritized?

Rarely — insights live in decks or docs that don't make it into product decisions in any traceable way Sometimes — insights shape some decisions, but the connection to what we build isn't explicit or consistent Consistently — there's a visible link between what we learn from customers and what ends up on the roadmap, and the team can articulate it

Q4 of 15

Before committing to build something — regardless of how it gets built — how does your team validate that it's solving the right business problem?

We move from idea to execution based on internal conviction — validation happens after the fact, if at all We discuss it internally and sometimes check with a few customers, but it's informal and inconsistent We make our assumptions about the problem explicit and test them — through conversations, prototypes, or experiments — before committing resources

Q5 of 15

Does your team maintain a documented list of the product and business assumptions you're currently operating on?

No — assumptions live in people's heads or are never made explicit Partially — some are documented but there's no consistent process to track, prioritize, or revisit them Yes — we have an active list of assumptions, ranked by risk and uncertainty, and we review them regularly as a team

Q6 of 15

What best describes how your team decides what to build next?

The loudest stakeholder or most recent customer request drives the agenda — it's hard to say no and priorities shift constantly We apply a prioritization framework (RICE, ICE, etc.) consistently — it brings structure but sometimes feels mechanical, disconnected from strategy We combine structured criteria with product judgment — frameworks inform the conversation, but the team can also articulate the strategic reasoning behind each call

Q7 of 15

When your team thinks about the roadmap, what's the primary lens?

Features and timelines — we think in terms of what ships and when A mix — we think about features but also try to connect them to user outcomes, though not always systematically We think about customer outcomes, not feature outputs — whether that means helping new users reach value faster, deepening engagement for existing ones, or protecting retention in a stable base. Our roadmap connects to a specific customer movement, not just a ship date

Q8 of 15

How does your team handle unplanned requests from sales, CS, or leadership that weren't on the roadmap?

They usually get added — the roadmap gets disrupted regularly and the team loses confidence in commitments We push back sometimes but don't have a clear process — the outcome depends on who's asking We have a defined intake process — requests are evaluated against clear criteria, decisions are communicated transparently, and the team understands why

Q9 of 15

When your team ships something new, how do you define what success looks like before it goes out?

We don't — success is usually "it shipped without breaking" and we move on to the next thing We have a general idea but it's not written down — we check a few metrics after launch but there's no pre-defined target Every initiative ships with explicit success metrics defined upfront — adoption, retention impact, or business outcome — and we measure them in the weeks after launch

Q10 of 15

How does product work with marketing, sales, and customer success when something new is about to launch?

We ship it and notify them — other teams find out when it's already live We share release notes in advance, but there's no coordinated enablement — each team figures out how to communicate it on their own Launches are coordinated — product prepares internal enablement, marketing has messaging ready, and CS knows how to explain it to customers before it goes live

Q11 of 15

After a feature launches, what does your team typically do with what it learns?

We move to the next thing — there's no structured review and lessons rarely get captured We discuss it informally but don't have a consistent way to feed those learnings back into the process Post-launch review is part of the cycle — we evaluate adoption data, iterate based on what we see, and document what we learned for the next initiative

Q12 of 15

How does the rest of the organization understand what product is building and why?

They mostly don't — the roadmap lives in product and other teams find out when things ship We share updates periodically, but other teams don't always understand the reasoning behind what's prioritized The roadmap and its rationale are visible to the organization — other teams understand not just what's coming, but why it matters for the business

Q13 of 15

How do teams like sales and customer success contribute to product discovery — not just the roadmap?

They send feature requests — product receives them but there's no structured way to turn those signals into insights We have some informal channels but the signal-to-noise ratio is low — it's hard to know what's a real pattern vs. a one-off request We have a process for capturing and synthesizing signals from customer-facing teams — they're active participants in discovery, not just a request queue

Q14 of 15

Does product have direct access to customers, or does it depend on other teams to mediate that relationship?

Product hears about customers indirectly — through CS summaries, sales notes, or leadership — but rarely talks to them directly We get access sometimes — usually when another team sets it up — but it's not systematic or regular Product has direct, ongoing access to customers — interviews, sessions, or usage observation are part of how we work, not a favor we ask for

Q15 of 15

When product decisions create friction with other teams — different priorities, resource constraints, competing timelines — how is that tension handled?

It escalates or gets avoided — there's no shared framework for resolving cross-functional conflict and it slows things down It gets handled case by case — there's goodwill but no clear process, so outcomes depend on the people involved We have shared decision frameworks and the psychological safety to surface disagreements early — tension is part of the process, not a problem to avoid

—

Score by dimension

Your top recommendations