The Two Types of Product Teams

There are two types of product teams - the slow-learning and the fast-learning.

The slow-learning team wants to deliver. They manage projects, write tickets, attend internal meetings and ask colleagues for design feedback. They mostly care about delivery and managing expectations.

The fast-learning team wants to learn. They talk to customers, read market news, push hacky code to production, and sometimes break things. They embrace ambiguity, but they learn fast.

The difference? The slow-learning team builds products for their bosses, and the fast-learning team builds products customers actually need.

Shift your focus. The best products come from deep insight, not just efficient delivery.

Framing is Everything

Recently I wrote about the most important skill for Product Managers.

Regardless of whether you are a Product Manager or not, the communication will help you with all aspects of your career. If you want to manage or be a leader, you have to be a good communicator. Specifically, you need to get better at framing.

What’s your goal? Are you looking for feedback, sharing information, wanting to influence, asking for approval or something else entirely?

What are you sharing? Is it a problem? Maybe a solution? A vision? Or a mix?

How much detail are you planning to share? Is this a helicopter or detailed view? Or perhapse, both?

Who’s your audience? Your team, the entire organisation or the executive group?

Your communication needs to be adjusted depending on the answers.

Early in your career, you use the same message no matter the context.

To grow, you need to get better at tailoring your message - what you say, how you say it and when to say it.

The Cost of Indecision

Misaligned leadership hurts teams. It's unintentional though. But still when leaders can’t align or make the call ("disagree and commit"), their teams suffer. The damage is often invisible to leadership but felt deeply by those executing.

It’s not disagreement that breaks teams. It’s hesitation.

Make the fucking decision!

Trust breaks when promises break

Trust breaks when promises break. People notice, even in silence and they remember. Honour commitments - trust depends on it.

Empowering Without Overdirecting

This afternoon I spoke with the team about the challenges for any leader and their team in finding the balance between telling them what/how to do (Directive Leadership) and letting the team figure it out themselves, make some mistakes and learn (Empowering Leadership).

The balance is hard.

You definitely wouldn't want to over-index on either side. So you’ve got to find a sweet spot.

But it also could be multidimensional, and the balance might shift depending on the area.

For example, you might want to give more direction in terms of the problem the team is solving compared to how the problem is solved. Or you might want to give less direction in the team's communication style but more direction in terms of the standards of produced work.

Regardless, it might be helpful to be open about that balance and have a regular conversation about it.

Because that balance isn't static either. As the team gets better and better, it requires you to adjust the balance.

Hack Constraints

When your team isn’t experimenting enough, it's most likely due to experiments taking too long to build, track and measure.

But every missed experiment is a missed opportunity. Insights go untapped. Ideas remain untested. Innovation stalls.

If the bottleneck is tech, hack it. Find workarounds even at the cost of degrading user experience but push forward.

Constraints spark the best solutions.

Tough Love, Strong Teams

Currently refreshing my memory on Radical Candor by Kim Scott. These quotes are amazing:

The best way to keep superstars happy is to challenge them and make sure they are constantly learning.

As you probably know, for every piece of subpar work you accept, for every missed deadline you let slip, you begin to feel resentment and then anger. You no longer just think the work is bad: you think the person is bad. This makes it harder to have an even-keeled conversation. You start to avoid talking to the person at all.

Trust Over Control

Most people think leadership is about control. They assume great leaders are the ones who tell people what to do, make all the calls and keep everyone in line.

That’s outdated thinking.

The best leaders don’t control. They share context & intent, inspire, empower and trust their teams to make mistakes.

Control stifles. Trust unleashes potential.

Impact Over Firefighting

Bad leaders like convenience over value.

They push those who make their lives easier - small tasks, fire drills and ego bosts. Problem solvers, whose work eliminates chaos, go unnoticed because their success erases the memory of the problem itself.

Leaders fear losing their “firefighters” more than those who ensure a fire never starts. The latter rarely gets rewarded.

The title "Product Owner" shouldn't exist

Product Managers own the full lifecycle - strategy, discovery and delivery. Product Owners focus narrowly on Agile delivery. Splitting these roles fragments accountability and muddies product development.

True impact comes from roles with full ownership.

Clarity Over Complexity

A strategy isn’t about looking smart. It’s about making sure everyone understands it.

Clarity beats complexity in any organisation. A strategy packed with jargon or overblown ideas creates confusion, not action. The goal is alignment - getting everyone moving in the same direction with confidence.

Simple, clear strategies win because they get executed.

You join a team meeting and just listen.

The team is in control - they cover the options, ask thoughtful questions and share feedback.
You watch them gelling, getting in the flow.
They are considering all the right angles: customer, business and tech.
The conversation moves naturally. They are calm and focused.

They don’t even need you there and it feels amazing!

The Tech Debt Spiral

Customers Aren’t Always Right - Their Problems Are

Prioritising customer requests purely by volume is a flawed strategy.

Volume doesn't guarantee the best solution. And it doesn’t address whether this is the right problem to solve.

But it still blinds teams.

Yes, customer feedback is great for spotting patterns and surfacing needs. But raw demands don't point to the best answer. Building features based solely on who shouts loudest will result in bloated products or patchwork fixes that don't scale.

A client might demand Feature X but their request likely reflects a deeper pain point solvable in a more elegant, cheaper, faster and more beneficial way.

Strong product teams distil customer insights. Instead of asking: "What do customers want?" ask: "What problem are they trying to solve?".

Your customer problems are your problems.

Clear Problems, Focused Teams

Engineers love clarity. The most important problem defines the mission.

A disjointed list of tickets signals confusion, while a vague objective offers no direction. Great work emerges when the goal is clear, focused and free of jargon.

When the problem is precise, teams know exactly where to aim.

Deciding If Your Team Needs a PM

Not every team needs a dedicated PM. Someone is already handling the PM work informally. It’s not complex.

Eventually, though, clear ownership becomes unavoidable. Is an individual contributor juggling alignment, communication and strategy alongside their core work? Or is it time to delegate those responsibilities to someone focused entirely on them?

The decision shapes how the team prioritises and executes.

Strategies evolve in action

Strategies evolve in action. You draw a map—rough and incomplete. You outline your destinations—the vision—and major obstacles—the business challenges. But many details remain unclear. It's foggy.

As teams move forward, challenges emerge, like hidden lakes on a foggy path. These pivots aren’t failures—that's what happens when you start moving towards the vision.

Each obstacle sharpens the strategy, revealing smarter routes and better decisions. Writing a strategy sets the course, but executing it unlocks clarity.

Teams that are comfortable with ambiguity and change, refining their plans as new insights appear, turn uncertainty into progress.

New Year, Who Dis?

Everyone talks about ‘hitting the ground running’ after the Christmas break.

Let’s be honest, no one feels like sprinting straight away at this time of the year.

Some are still catching up on sleep, recovering from all the desserts they've eaten, wrapping their heads around what day it is and trying not to fail one of their New Year's resolutions in the first week of the year.

Forcing yourself into work mode overnight is hard.

I’d rather ease into it. Spend the first day reconnecting with your team, archiving all the emails from last year and marking all Slack messages as read. Oh, that feels great.

By the second day, you’re already feeling more in control.

Side projects teach product management faster than any course.

Finding a problem, crafting a solution and marketing it sharpen critical skills. You learn to balance creativity with practicality and adapt to real-world feedback.

Hands-on experience builds stronger product managers.

Leadership Doesn’t Need an App

You don't need a fancy tool to manage your team.

Complex software won’t fix miscommunication or misalignment. Tools often distract, leading to over-documentation, micromanagement and wasted focus on processes over outcomes.

Management is clarity. Set expectations, align on what's important and build trust with open, honest conversations. Keep the focus where it belongs—on the work itself.