Master Outcome Success: Surpass 97% of Product Teams With 4 Simple Patterns

Why are so many unaware of these?

Last week, one of my teams, who is making the shift to outcome mastery, reminded me of how easy product work can be.

And how most product teams are struggling (unnecessarily).

• Struggling to know if they are producing valuable features.
• Struggling under long, uninspiring big-bang releases.
• Struggling to carry the weight of unfinished, risk-laden work.
• Struggling to deliver their piece of the puzzle in a vacuum.

Do you have any of these struggles? At least 97% of the product teams I start coaching suffer in the working-too-hard category. And they have little to show for it. Value is elusive for them.

• They don’t know their customer.
• They treat their product as all or nothing and knowable up-front.
• They don’t finish working, end-to-end product features.
• They work solo in silos.

This does not have to be your fate.

Over the past 15 years, I’ve worked to reverse this trend with 112 teams. The result?

• Early user outcomes and value harnessing.
• Rapid, emergent learning to arrive at the right product sooner.
• Frequent hits of dopamine from finishing what they start.
• The pride and increased decision quality benefits of teamwork.

I have curated four simple patterns you can use today to do the same for your team.

Let’s explore them now.

This year, I’ve committed my focus to a concept called Lean Leverage, as described in my inaugural 2024 post. Each article I craft this year, including this one (the 7th in the series), will focus on an aspect of Lean Leverage. Enjoy and stay tuned for many ways to do more with less.

---

The 4 Simple Patterns to Surpass 97% of Product Teams

Let’s imagine a better future.

I’ve found the best analogy for how these patterns work is a soccer (football) team. As a caution, all analogies are flawed. But some are useful, like this one.

The team arrives at the stadium.

Raging fans greet them. They prepare for the game in the locker room, have a team huddle, and enter the field.

The crowd goes wild.

The whistle blows and the team gets the ball. The members on the field can see their teammates. The players work together, sometimes in small groups, to move the ball down the field.

Winning is scoring the most goals as a team.

The team can see the score at all times and the time remaining. They hear the reaction of the crowd. And when the whistle blows, they can stop the game in an instant and regroup as a team.

This is a team working as a cohesive whole at peak performance.

What you don’t see:

• An empty, quiet stadium.
• Many balls on the field, in play at the same time by different members.
• Balls scattered around on the field, abandoned.
• The field divided into walled-off specialized team members.

Ready to dive into the patterns that mimic the high-performing soccer team? Let’s go.

Pattern 1: Engage directly with users and stakeholders.

Know your user and stakeholder to gain purpose and harness early value.

I commonly see three failure pathways that get in the way:

• Proxies sit between the team and its users and stakeholders.
• Separate teams feed “requirements” to product teams.
• Nobody talks to users and stakeholders (this is more common than you might think).

I am astonished we still do this, but we do.

So, how do we remedy this?

The solution is simple (not easy): remove the proxies and the separate research teams. Then, put the customers at the center of the product team, a driving force for all team action. Keeping users and stakeholder at arms length does not breed product team effectiveness.

Teams need to bring users and stakeholders along for the ride.

There are three ways I tend to do this.

1. Invite them to product strategy, roadmap, and feature refinement sessions.
2. Show and test the product with them as it evolves (before, during, and after development).
3. Gather evidence and feedback from them as the product is used in the wild.

High performing teams need to hear the crowd and be energized by it.

Pattern 2: Emerge and validate your product in thin, end-to-end slices.

The days of everything-at-once, big-bang releases should be long gone, but they aren’t.

Several contributing factors keep this risk-magnifying, late-learning approach alive:

• Pure pride in predictive, deterministic prowess and a lack of humility.
• Seeking comfort in planning details amid the uncertain complexity of modern product work.
• Keeping everyone busy in their specialty means doing work out of order and assembling at the end.

The time is up for this archaic “I know everything and can plan it all out upfront” model of product development.

So, how can we simplify this?

The easiest path to take is one of rapid learning velocity. We need a learning-forward approach to reveal early evidence on the efficacy of our work. In my experience, a solid evidence-driven approach has four distinct characteristics:

1. Admitting you don’t know up-front, and being curious.
2. Delivered in thin, end-to-end, working use cases.
3. Aimed at learning your way to earning.
4. Fueled by inexpensive, fast experiment loops.

Effective teams see the whole field and emerge the best path to score (over and over and unique every time).

The game is won by scoring the most goals, not by kicking the most balls.

Pattern 3: Finish one thing before starting another.

Starting does not equal progress, yet we continue to treat it this way.

Several influences keep our “starting” habit going strong:

• The desire to please stakeholders (“Your request has been started!”)
• Everything is high priority.
• You hit an obstacle, and start something else.
• Everyone is working on disconnected parts, so nothing gets finished in whole.

As I list these out, I am struck by how illogical they seem.

Agreed?

The simpler path requires a slight, yet powerful shift in perspective. We need to stop starting and start finishing. I’m sure you have heard this statement. Implementing it is not difficult. All it requires is atomic focus. Here’s how I coach product teams to do this:

1. Start and finish one thing at a time—one goal, one feature, one task.
2. If everything is top priority (unlikely), go back to step 1 and just pick one (randomly if necessary).
3. When you encounter an obstacle, stop and remove the obstacle.
4. Work as a cross-functional team to concentrate all hands and minds on the focus (see pattern 4).

This focus is atomic because it is both small and powerful.

Having one ball on the field channels the team energy. They move it swiftly downfield and into the goal. Obstacles are no problem—the team works around them or breaks through them.

Having balls scattered all over the field (whether in play or motionless) is not effective.

You want one ball. One focus.

Pattern 4: Work as a team, not a collection of individuals.

Working solo relies on the power of 1; teamwork is the might of many.

Yet, the vast majority of teams I encounter are acting like a collection of people, each working alone.

I see several contributing factors leading to this tendency.

• Managers trying to keep people busy (idle workers are the ultimate sin for them).
• Team members desiring to stay wrapped in their comforting lane of specialty.
• The perception that more than one person focused on a task is inefficient.
• The false belief that debate and discussion is wasteful.

These might have worked (debatable) in Taylor’s age of Scientific Management, but they don’t work today.

Product development is complex and uncertain. As such, we need all minds and hands focused on the same thing, at the same time. I’ve seen four ways you can do this.

1. Focus on idle work, not idle workers.
2. Step out of your specialty to help keep work flowing, even if you are simply observing and learning.
3. Avoid the trap of optimizing for “hands-on-keyboards” time.
4. Amplify decision quality with many minds and many perspectives.

There really is no “I” in “TEAM” after all.

Remove the silo barriers from your field of play.

And feel the power and flow of a team working collaboratively to move the ball downfield.

---

That’s it. I hope that helps your team on your product journey.

Be in the 3%.

---

---

References

Soccer analogy adapted from an excellent book:

Niklas Modig, Pär Åhlström, This is Lean: Resolving the Efficiency Paradox, 2012

---

---

Related Posts

You can read a sampling of my other posts on maximizing your value achievement below:

We Need One Complete Product Team

Too much specialization destroys your product team.

I can’t sell Agile to you. And nobody else can either.

21 Secrets the Scrum Guide Doesn’t Tell You