The New Hire Test for Success

What would success look like if we had to explain it to a new hire?

When someone new joins the team, they often ask deceptively simple questions.
“How do we know if we’re doing well?”

On the surface, that question is about clarity.
At a deeper level, it’s about coherence.

Having a new team member is a quiet forcing function that you can use to accelerate the team’s coherence. New hires don’t know your history, and they don’t know your internal shorthand. But maybe most importantly here, they don’t know which metrics are sacred and which are ceremonial. 

John Cutler often critiques “success theater”, where vanity metrics or dashboards look like they are creating signal, but actually generate noise. A new team member won’t know the difference right away. They’ll take what we present at face value.

Many teams can list metrics. Fewer can describe what winning actually feels like. And if explaining success requires a 40 slide deck, or a dozen KPIs and OKRs layered together, that’s a signal worth noticing. As Richard Rumelt has written, “Good strategy is simple enough to explain, but disciplined enough to execute.” If you can’t explain success simply, there’s a good chance your strategy is either fragmented or overly abstract.

---

STAND-UP EXERCISE

Use the idea of a new team member as a diagnostic lens.

Take a few moments asynchronously to write down how you would explain success of the team to a fictional new hire. Don’t just think about metrics, but also the meaning. What would you have them pay attention to? What matters most?

Then bring those explanations together and look for themes. Did different practice areas have distinct definitions? Did folks with varied lengths of tenure on the team explain it differently?

This exercise isn’t just about onboarding; it is about potential misalignment within the team. The places where definitions diverge are often the places where tension quietly lives. Use this to come together on a shared definition of success for your team and for your product. If success can’t be explained coherently, it can’t be protected intentionally.

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.