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.

Creating Space in the New Year

The beginning of a year often comes with pressure to add something new.
A new goal.
A new process.
A new initiative.

The reset of the calendar year can often correspond with the fiscal year for many businesses. This means a fresh start to many projects, KPIs, and the like. But sometimes the most meaningful way to start fresh isn’t always by committing to more. It’s by taking a careful look at what we’re already carrying.

Product teams accumulate habits the same way products accumulate features: gradually, often with good intent, and rarely with a clear moment of reevaluation. Meetings get added. Rituals repeat. Dashboards refresh. Decisions follow familiar paths. Over time, some of this work stops earning its keep, not because it’s wrong, but because the team has changed.

It might be a meeting that persists even though decisions now happen elsewhere.
A roadmap ritual that exists independently of strategy.
A metric that’s tracked faithfully but never referenced when choices are made.
A handoff or approval step that once mitigated risk, but now simply slows flow.

These aren’t failures. They’re signs of growth. Teams evolve faster than their systems, and that’s normal. What matters is whether we pause long enough to notice.

This year, thinking about peeling something back. Not as a resolution. Not as a critique. But as a moment of care for how the work actually happens.

Healthy teams don’t just build products thoughtfully; they tend their systems. They revisit how decisions are made, how time is spent, and which rituals still serve the work in front of them.

When teams don’t periodically reassess these defaults, they can create operational drag. The work gets heavier without becoming clearer. The calendar fills up without improving outcomes. And the team’s energy gets spread thinner than it needs to be. This idea shows up again and again in the work of Melissa Perri: outdated or inconsistent processes often slow teams more than a lack of tools or talent. The cost isn’t just inefficiency; it’s decision fatigue, misalignment, and lost momentum.

Starting the year by removing something unnecessary is a way of restoring intention.

---

STAND-UP EXERCISE

In your next stand-up create a whiteboard for people to share at least one recurring ritual, meeting, report, or decision pattern they participate in regularly. Talk through key points of that item:

• What decision does this help us make?

• Who uses the output?

• What would realistically happen if we paused this for a month (or 3 months)?

Listen for overlap, hesitation, the things no one quite knows how to justify anymore. You’re not looking to eliminate everything. You’re looking for one candidate — something that may have outlived its usefulness.

Then, remove one ritual. Don’t immediately replace it with something else. Let the absence do some work. This isn’t about optimization; it is about care and attention to the team’s energy and clarity. After a month, or a time interval that makes sense for the specific ritual, look back and assess. Did removing this create space for better work?

Storytelling via Roadmaps

Most roadmaps are timelines. Rows and boxes and dates. They’re useful, but they rarely tell the real story of why we’re building anything, or what our work means for the person on the other end of the screen.

Customer stories, on the other hand, create instant clarity. They show us the stakes. They reveal the make-or-break moments. And they help teams align on the problem long before we talk about solutions. Ali Maaxa calls this the core dilemma — the moment where a customer’s adrenaline spikes because something matters. When we understand that moment deeply, the roadmap becomes less about features, and more about resolution.

What if we took a step back from our timelines and asked a different question:
What single customer story would explain our roadmap better than our roadmap?

Not a persona. Not a workflow diagram. But a customer story about a moment when something shifts in their world and they have a need. You can usually find the story by tracing backward from urgency: an alert, a deadline, a mistake, a handoff, a moment of pain. Look for the core dilemma or the moment that carries emotional weight for the user. Is it confusion? Risk? Embarrassment? Desire? Compulsion?

Once you spot that moment, the rest of the story becomes easier to see: the environment they were in, the people involved, the tools around them, the friction they’ve learned to tolerate. Are there workarounds they are using? Do some tools help or get in the way? And then to project into the future, what does the user hope will happen if things go right? What’s at stake if it doesn’t?

These elements form the real narrative spine of your product, and if you follow it honestly, you’ll often find your roadmap sitting right inside it. Some roadmap items resolve the tension beautifully. Others don’t belong at all. And sometimes you realize you’re missing the one thing that would change the entire experience.

When a team aligns on a story, the roadmap stops being a list and becomes a sort of promise: we understand this user moment, and we’re building toward a better one. Stories give teams meaning. And meaning invites better decisions.

---

STAND-UP EXERCISE

In your next team meeting or retrospective, ask everyone to individually jot down:
What is one customer story that explains why this roadmap exists?

Encourage simplicity. Look for the core dilemma.

Then, share your stories. Instead of debating accuracy, listen for:

• patterns

• emotional moments

• stakes

• recurring characters

• recurring friction

Then see if you can coalesce around a story or two, and piece those into your roadmap.
If this story were our north star, what on the roadmap feels essential?
What feels optional?
What feels missing?

Continue to come back to your customer story during roadmap reviews and share-outs, and find and refine new ones over time.

A Gratitude Practice for Product Teams

We spend a lot of our time scanning for gaps - what’s missing, what’s broken, what needs to be better. It’s a big part of our job. But November is a good moment to pause and notice the scaffolding we don’t usually talk about: the customer behavior that reveals something meaningful, the constraint that sharpened our thinking, the teammate who quietly made things easier.

Gratitude in a product context isn’t fluff.
It’s a tool for clarity.
It can help us see where value actually comes from, and what enables good work to happen. It is worth taking some time to recognize the things we build on, not just the things we build next.

Teams that practice noticing what’s working (not just what’s missing) can make better contextual decisions. They communicate with more generosity. They can catch customer signals earlier. They avoid unnecessary tension. And they build more trust, which is the quiet backbone of any healthy product org.

Gratitude helps teams name the inputs worth protecting - the relationships, habits, and insights that give the work its sturdiness.

Where to look for gratitude in a product team setting:

1. Gratitude for Customers
   What’s something a customer did, said, or struggled with recently that made our product better? Think about the small moments like a surprising workaround, an offhand comment, a behavior that reframed your understanding.

2. Gratitude for Constraints
   What limitation (timeline, tech, scope, capacity) forced us to simplify or focus? Which constraint improved the outcome once the frustration faded?

3. Gratitude for the Team Behind the Scenes
   Who made your job easier this month in a way no dashboard captures? A clear diagram. A thoughtful question. A fast bug fix. A structured meeting.

4. Gratitude for Steady Systems
   What process, ritual, or tool quietly holds more weight than we acknowledge?Which of our habits would actually hurt if they disappeared?

5. Gratitude for Growth Moments
   What moment stretched you, and ultimately made you better? A tough conversation. A pointed critique. A tradeoff that clarified what mattered.

Teams often think their value is defined by velocity. But the real story is the network of relationships, insights, constraints, and micro-moments that support the work. Naming these things isn’t just “feel-good energy.” It strengthens alignment. It builds trust. And it reminds teams that progress is never a solo achievement; it’s collective.

Gratitude helps us understand what enables us, not just what we produce. As we move into the last stretch of the year, this practice helps teams end on steadiness, grounded, connected, and aware of the things that truly matter.

---

STAND-UP EXERCISE

Using the five prompts of where to look for gratitude (above), ask the team to individually finish this sentence:

“Our product is better because _________.”

You might set a specific time frame (last 2 quarters, last year) to help focus the exercise. Capture the responses as a type of retrospective and way to tell the story of your product and team.

Tooling (and AI, of course)

The market is overflowing with tools - AI assistants, collaboration platforms, analytics dashboards, niche SaaS products (with AI integrated!) for every imaginable workflow. It’s tempting to try them all. But tooling is not strategy. A good tool accelerates existing strengths; a poor one multiplies inefficiencies.

Some organizations love to collect tools like shiny objects. Every pain point comes with a new platform, subscription, or “quick fix.” And of course AI has entered the landscape by force, as chat but also wizards within other platforms. Some teams are being mandated to be using AI, so that the business is not “left behind”. The problem: tools don’t solve problems. People do. Tools only accelerate (or complicate) the work depending on how they’re introduced and adopted.

Effective teams treat tools as part of their operating model, not as shiny objects. They introduce them intentionally, guided by a few questions:

1. Fit — Does the tool align with the way people already work? If it requires people to constantly context-switch or feels like extra work, adoption will die fast. Tools should dissolve into existing habits, not demand entirely new ones.

2. Friction — Does it remove barriers or add new ones? Does it work for everyone on the team or just a subset of folks?

3. Focus — Is it solving the right problem, or just a problem? Does this distract from what we should be actually working on?

4. Flexibility — What’s the plan if the tool doesn’t work out? Too often, teams get stuck with tools that don’t scale or can’t integrate. Part of “trying something new” should always include the question: If this doesn’t work, how do we exit?
   

Organizations that answer these questions up front could save themselves months of rework and resistance.

Too often, teams focus on what tools to use instead of how to use tools well. A team that doesn’t know how to run effective meetings won’t suddenly become effective with an AI note-taker. A company that avoids tough prioritization decisions won’t magically improve by adding another project management suite.

The tools that truly stick for your team might not be the buzzy ones. FigJam for collaboration. Miro for brainstorming. ContentSquare for understanding behavior. Yes, ChatGPT for drafting and discovery. But sometimes a shared doc and a standing meeting are still the most powerful tools you can have.

The best teams don’t chase every new tool. They learn how to audit, experiment, and fold the right ones into their culture. That’s how tools stop being shiny objects and start being leverage.

---

STAND-UP EXERCISE

At your next team stand-up, run a quick tooling audit together:

• List the top 3–5 tools your team uses daily.

• For each tool, ask:

  • How does this fit into our flow of work?

  • What friction does it remove? What friction does it add?

  • Are we using it to solve the right problems?

• Choose one tool to experiment with improving. Compare notes on how each other uses it. Does someone need more training? Are there ways to be using it more effectively? Simplifying? Or a need to sunset it or an overlapping tool?

The goal isn’t to chase the next new platform. It’s to ensure the tools in use are actually serving the team, the process, and the outcomes.