Delivering the “right” 80/20: North Star Culture

Earlier, I introduced the concept of what I call the “right” 80/20 in software product management. Check out the first part here.

A wise product manager once said:

When development asks a product manager for more detailed requirements, she should give them deeper domain knowledge.

In the first part of this blog, I covered why it’s important to approach product development with that mindset. In this post, I’ll dive into how to get the development team on board with what I call the right 80/20.

Here’s a scenario: A well-intentioned product manager has researched, defined, and broken down the problem space. She brings her prioritized set of problems to the team and their first response is this:

“That sounds great. So, what do you want us to build? We need more detailed specs before we can get started.”

Most product leaders reading this are probably nodding knowingly. This scenario plays out the same way nearly every time a PM switches from breaking down the solution to breaking down the problem. As soon as the PM stops handing the team “solutions to build”, they feel lost.

To development, it can feel like the PM isn’t pulling her weight on the team. Development may even escalate the issue to management, complicating her situation even more.

Helping development gain a deeper domain knowledge, rather than a to-do list, is worth the hard work. One of the biggest payoffs is that they slowly stop asking “So, what do you want us to build?”. Instead, they’ll become more motivated to reach a deeper level of empathy for the real problems faced by users, which in turn results in generating solutions that address the real core problem.

In my experience, it often takes several months before product teams start to reap the rewards of this systematic hard work and persistence.

So, how can PMs change everyone’s mind? It’s not easy, and it requires the involvement of the whole team. Here are three key messages to continually reinforce with the team and with the broader organization:

• We’re all one team
• Our North Star guides us
• Everyone is a designer

We’re all one team

Let’s get down to the basics. Product teams are employed because customers pay money for their product (or for their data). This might seem like a redundant reminder, but it’s important to highlight that without our customers, product teams would be out of a job.

We’re all on the same team. The customer is the boss. Ultimately, the team “reports” to the customer.

Every product development team is cross-disciplinary at Roadmunk. This means we have a combination of product managers, designers, developers and test engineers on each team. Why? The same reason you wouldn’t assemble an entire soccer team of strikers: you’d give up way too many goals.

Let’s keep using the soccer analogy. The striker will have a tough time scoring if nobody passes them the ball and the team won’t be very effective at defending if that same striker phones it in on defence. In top-performing teams, it’s hard to find a player who doesn’t respect and appreciate what their teammates contribute to the team.

This is what team success looks like. So why is it so commonplace in software to point fingers, toss demands over the wall and say “that’s not my job”?

I’d say one of the most important aspects of being a product manager is to act as the team captain. If product managers aren’t…

• promoting collective ownership,
• encouraging team cohesion,
• And focusing the team on what’s best for the customer above all else,

…then they’re failing both the team and the users. Making a sustained and conscious effort towards becoming a “team captain” who promotes those things is the first step towards building a North Star culture.

When the individual members of a product team understand and appreciate how their efforts relate to one another, they’re more likely to be on track towards scoring those goals.

Our North Star guides us

So, how do we focus the team on what’s “best for the customer”? To answer that question, product managers can look to their North Star.

What’s a North Star? Simply put, it’s the reason the product team exists.

When you ask a team why they exist, some teams will respond with “to deliver feature x, y, z by Q3.” It’s true for a lot of teams (but not all of them): feature delivery is one way to measure success but it’s short-sighted.

Would you rather deliver 5 “okay” features this quarter or 2 “awesome” ones? Most (not all) executives would take the team that could deliver 2 awesome features every quarter and they’d aim to replicate that team’s magic on another team in order to deliver more.

The trouble is that, without an alternative definition of success, the only measure of progress teams have is the number of features they shipped.

With a good North Star definition, the product team will ensure that every feature they ship actually solves the problem it’s intended to. Sure, they may ship fewer features, but 80/20 is about delivering value not “stuff”.

How do I define my team’s North Star?

If a product team has a vision and mission defined, that’s a good start. But the best North Stars also include a single quantifiable metric that represents the success of their mission.

For example, Roadmunk’s North Star metric is “alignments”, which encapsulates how well we’re enabling our users to align their organizations to the roadmap. Our teams have individual supporting North Star metrics that ultimately contribute to the company’s high-level North Star.

In my soccer analogy, the team’s North Star is the scoreboard. Without it, product teams are just kicking the ball around.

It’s amazing how quickly toxic behaviour melts away when people rally around a common aspiration. The North Star is your team’s purpose.

Everyone is a Designer

Going all in on the soccer analogy, the team’s strikers are expected to score goals. After all, that’s what they’re great at. However, that doesn’t mean that a midfielder or a defender shouldn’t take a shot at a goal if they have an opportunity to score.

Given that your team’s objective is to deliver the best possible solution to users, it makes sense to leverage every resource at your disposal to figure out what “best” means. Everyone on any given team has a unique perspective. The best teams, defined as the most collaborative, take advantage of that.

One of the best feelings as a PM is when the quiet developer in the corner of the room pipes up and suggests a killer user interaction that nobody else even thought about because they assumed it was impossible, too difficult or too expensive to build. That level of collaboration only happens when discussions start with this user-centred question:

What is the experience we want to deliver?

Using every perspective to gain this deeper insight into what makes the “best” possible solution for users is at the core of collaborative frameworks like Design Thinking and empathy maps. These exercises don’t just exist to create a bunch of personas — they’re specific tools created with the purpose of aligning the way entire product teams empathize with the problems users face. And when product teams gain this level of self-awareness, they’ll always score their goals.

Thinking like a designer allows everyone to reach an agreement on what ideas should be prioritized based on a collective sense of human-centred/human-first empathy towards users. This understanding requires teamwork in the purest sense of the word: meet with the team and talk about how they define user problems, lead workshops, and learn to ask the right questions before a discussion.

And most importantly, remember this:

In the most successful product teams, everyone is a designer.