Dimensions of Quality

Most product teams care deeply about quality. But when timelines tighten or pressure increases, quality often becomes a vague, emotionally loaded concept. One person worries we’re moving too fast. Another one worries we’re overthinking. Conversations stall because we’re using the same word to mean different things.

Quality isn’t a single standard you either meet or miss. It’s a set of attributes that compete for attention. And different moments in a product’s life put different kinds of quality at risk.

Quality Isn’t One Thing

One of the most useful ways to talk about quality comes from Ami Vora, who describes four distinct dimensions teams are constantly balancing:

• Performance — how fast, responsive, and reliable the product feels

• Bugs — correctness, stability, and freedom from defects

• Completeness — whether the solution actually solves the full problem

• Consistency — coherence across flows, surfaces, and behaviors

Every team makes tradeoffs across these dimensions. That’s not a failure; it’s reality. The problem arises when those tradeoffs are implicit. When no one names what’s most fragile, teams start talking past each other, and quality debates become personal instead of practical.

When quality discussions stay abstract, they tend to escalate quickly. Engineers may feel asked to cut corners. Designers may feel pressure to ship something unfinished. PMs may feel caught between speed and responsibility.

But when a team can say, “This quarter, completeness is the riskiest thing for us,” or “Performance is the edge we can’t afford to dull,” something shifts. The conversation becomes about judgment, not virtue. It frees you up to focus on intent, not blame. Naming risk creates shared context. It gives teams language to explain decisions and empathy for why others feel tension.

Where Quality Risk Shows Up

You can usually spot quality risk by paying attention to where friction accumulates.

• Where are we cutting scope, and what kind of quality does that affect? Are we creating an experience that feels partial or awkward to a user?

• Where are we deferring work, and what assumptions are we making about impact? Are our inconsistencies eroding trust with other teams?

• Where are customer complaints, internal friction, or workarounds starting to cluster? Are there bugs that felt acceptable individually but now feel risky in aggregate?

Each of these points to a different dimension of quality, and recognizing which one matters most at this moment is what enables better decisions. The goal isn’t to eliminate risk. It’s to make it visible. When teams agree on which kind of quality is most fragile, they can protect it more deliberately, communicate tradeoffs more clearly, and move faster with less friction.

---

STAND-UP EXERCISE
In your next stand-up, on a shared workspace ask the team to vote on one question:

Which quality dimension feels most at risk right now?
Performance · Bugs · Completeness · Consistency

Notice where there’s alignment, or surprise. Invite people to talk about why they voted the way they did. Listen for patterns across roles or perspectives. Engineers, designers, and PMs often see different risks, and all of them are valid signals.

Going forward for this sprint / quarter / release explicitly name which quality dimension you’re prioritizing, and which one you’re consciously putting at risk.

Uncovering and Challenging Our Hidden Assumptions

Product teams constantly make decisions rooted in beliefs about their users, market conditions, and solutions. The challenge emerges when these beliefs remain unexamined—when teams operate as if their assumptions are established facts. In Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value, Teresa Torres highlights how teams must actively identify and test the assumptions that drive their product decisions, particularly those tied to meaningful business outcomes.

The risk lies not in holding assumptions, but in failing to recognize them as such. Unacknowledged assumptions become invisible drivers of product direction, potentially leading teams to build solutions for non-existent problems or chase metrics that don't actually matter. When assumptions masquerade as certainties, teams lose their capacity for genuine learning and user-centered discovery.

Torres advocates for connecting discovery work directly to desired outcomes, but this connection only works when teams honestly surface what they're taking for granted. High-performing product teams distinguish themselves by making assumption identification a regular practice, transforming invisible beliefs into testable hypotheses. Testing your assumptions is a much quicker and more repeatable process than testing new features. To test an assumption, you are simply looking for confirming or disconfirming evidence to support or dispute, which can prevent continuing on an unadvisable path.

Torres groups assumptions into five categories: Desirability, Viability, Feasibility, Usability, and Ethical. Grouping assumptions can help you see where your blind spots are, or in what ways you might carry bias.

Consider a recent feature your team shipped or is currently building. Chances are, it's built on a foundation of assumptions about user behavior, business impact, technical feasibility, and competitive landscape. Some of these assumptions may be well-founded, others completely wrong. Without a deliberate practice of assumption identification and testing, you're essentially building blindfolded.

---

STAND-UP EXERCISE

Choose a current project, feature, or initiative your team is working on. As a group, spend 15-20 minutes identifying the assumptions underlying this work. Use these prompting questions:

User Assumptions:

• What do we assume about who will use this feature? Does anyone want it?

• What problem do we assume this solves for them? How prevalent is that problem?

• How do we assume users will discover and adopt this?

• Is there any potential harm to our users in building this? (Think about data storage, categorization, user habits / dark patterns, disruption, etc.)

Business Assumptions:

• What impact do we assume this will have on our key metrics? Or will it support our broader business goals?

• What do we assume about the competitive advantage this creates?

Technical Assumptions:

• What do we assume about the technical feasibility or complexity?

• Do we assume this passes our legal / security / compliance safe guards?

• What do we assume about performance, scalability, or maintenance?

Market Assumptions:

• What do we assume about timing—why now?

• What do we assume about our users' current alternatives?

After identifying 8-12 assumptions, categorize them:

• Validated: We have evidence supporting this assumption

• Testable: We could easily gather evidence for this assumption

• Risky: This assumption, if wrong, would significantly impact the project's success

Pick the 2-3 most risky assumptions and discuss: What's the smallest test we could run to validate or challenge this assumption? Could we test it through a customer interview, analytics review, prototype, or small experiment?

Remember: This exercise aims to illuminate assumptions, not eliminate them entirely—that would be impossible and counterproductive. The value lies in making hidden beliefs visible and focusing testing efforts on assumptions that could significantly impact your project's trajectory. Torres' approach to continuous discovery centers on weaving customer insights into everyday product decisions, and systematic assumption testing provides a concrete method for achieving this integration.

This exercise works best when teams approach it with curiosity rather than defensiveness. The assumptions you uncover aren't failures—they're opportunities to learn and build better products.

Technical Debt

It is a rare a product that does not carry some technical debt. Trade-offs and compromises are made - to meet deadlines or work within other constraints. Some of those decisions have consequences that do not age well over time, and that is technical debt - the implied cost of additional work caused by choosing an easy or limited solution (instead of the more desired approach that would take longer / cost more / use additional resources.) It is similar to financial debt - you take it on because the value of having the item now is more important than saving up to purchase it when you can afford it. Eventually the debt must be paid down, and similar to financial debt, sometimes that comes with interest owed.

Not all technical debt is bad. Product teams must balance the business goals and outcomes with technical solutioning and implementation decisions. The key is to take on the debt responsibly. Part of doing that is identifying when you are making a decision that is not ideal. Thinking through - or at least acknowledging - a future fix at the time it is implemented can be valuable.

Additionally, categorizing your debt can be a helpful exercise, to better understand the trade-offs on your product and to help in the debt remediation phases.

Some categories of technical debt are:

Secure Coding - issues or vulnerabilities discovered within the code, through audits such as OWASP Top 10
Accessibility - issues addressing digital accessibility, at a minimum meeting compliance with WCAG 2.1 level AA or AAA
Code Efficiency - Maintainability, testability, performance, and scalability of code
Architectural Integrity - Best practices for code, security, data, and architecture
Business Risk - Documentation, audit controls, SOX compliance, etc.
Up-to-Date Technology - Ensuring the latest versions of IDEs, frameworks, libraries, servers, databases
Automated Testing - Increase coverage, resolution, alignment, and optimization of automated testing framework

The best approaches to technical debt focus on thoughtful decisions about when to take on the debt, and careful tracking and planned remediation.

---

STAND-UP EXERCISE

As a product team, identify the categories of technical debt that your product does/could encounter. Is there a way to track these categories on your tickets / incidents? Discuss how the team could systematically remediate technical debt. Is it best to focus a percentage of every sprint’s points toward one or more of these categories? Is it better to use one or two sprints a quarter to completely dedicate toward eliminating debt? Is there a way to coordinate with other teams, if you have reliance or dependencies with them? Create a plan for your team, and revisit it - as well as your tracked metrics - on a regular basis as your team and product evolves.

Signaling Decisiveness

As a product leader, you’re often navigating a space where formal authority doesn’t exist. Your influence is built through relationships and the respect you earn from your team, stakeholders, and peers. In this dynamic, how you carry yourself—what Sylvia Ann Hewlett describes as "gravitas" in Executive Presence 2.0—plays a significant role in how others perceive and respond to you.

Hewlett breaks gravitas into four essential components:

1. Projecting intellectual horsepower.

2. Displaying confidence and credibility.

3. Signaling decisiveness.

4. Maintaining grace under fire.

I’ve explored the topic of projecting intellect and expertise before, but we’ll focus on a less-discussed aspect of executive presence: decisiveness.

Decisiveness in Product Management

As product managers, we make decisions daily—about priorities, feature trade-offs, user experiments, and future research. These decisions shape the product’s trajectory and, in turn, the success of the business. To confidently communicate these choices to stakeholders, we must have self-assurance not only in our judgment but also in our ability to make those decisions quickly and effectively.

We’ve all experienced the pitfalls of indecision. When we delay making a choice, the situation often forces a default outcome upon us—typically not the one we’d have chosen. Avoiding this requires mastering the ability to make swift, informed decisions.

Gaining Confidence Through Information

One key to fast, confident decision-making is having access to trusted information that you can quickly digest and apply. Everyone processes information differently, so finding your ideal method for gathering insights is critical.

Some ways to gather the necessary information to confidently decide your product’s next steps:

1. Qualitative User Feedback – Mine your existing user feedback or lean on your UX team’s insights. Understanding the real-life experiences of your users is vital to making informed choices.

2. Internal or Quantitative Data – Build a strong intuition around user behavior by analyzing the numbers. Metrics often reveal truths that anecdotes can’t.

3. Experience with the Product – Use your own product like a customer would. Understanding the user experience firsthand gives you an invaluable perspective.

4. External Market Trends – Keep an eye on competitors, industry shifts, and broader consumer patterns. This will help you predict what’s coming and position your product accordingly.

5. Financial Modeling – Work with your finance or business partners to evaluate how various decisions might impact the bottom line. Long-term success often hinges on understanding the financial ripple effects of today’s choices.

6. Prototyping – Create mockups, sandboxes, or prototypes. Experimenting with different solutions can help you see how they perform in practice and make more informed choices.

While it’s impossible to cover all of these areas for every decision, pulling information from a few can lead to a decision that’s "good enough" to move forward.

The Role of Intuition and Circumstance

Of course, decision-making isn’t purely an intellectual exercise. As product managers, we juggle competing priorities, unpredictable constraints, stakeholder politics, and shifting business goals. Sometimes, our choices are influenced by factors beyond the data—like gut feeling or external pressures.

Even so, when you’re grounded in reliable information, you can navigate those complex variables with greater confidence. Decisiveness becomes less about bold assertions and more about informed, thoughtful action.

Leading with Influence, Not Authority

At the core of product management is the need to lead through influence. You don’t have the luxury of positional power; your authority comes from the expertise and trust you cultivate. Decisiveness is a key part of that influence. When your team and stakeholders see you making informed, timely decisions, it builds confidence in your leadership.

---

STAND-UP EXERCISE

Discuss with your team how they typically make decisions, or how they might feel forced to make decisions. Of the methods discussed above, which ones are applicable to their learning style, the product, and the business. What other ways might they collect information to make better informed and quicker decisions?

Bonus: Learn about the framework of one-way door and two-way door decisions. Jeff Bezos explains the philosophy in this video.