Product Driven Leadership

This post will be an overview of the main concepts of Product Driven Leadership and my personal opinions woven in. If you want to learn more, I'd recommend you pick up the book.

I've been reading a great book called Product Driven by Matt Watson - which has perfectly summarized thoughts I've had for the last couple of years. Software engineering is broken - we've pushed engineering so far away from the product they build.

A story from the author really hit home. They had been preparing for a product release for the last few sprints. It was time to push to production. They crossed their fingers as their application restarted. No errors, no urgent emails, no calls from support, no panicked messages from sales. Sounds like a success, right? It went smoothly from a technical perspective.

Wrong. That silence should have scared them more than any bug report ever could. They didn't know if anyone even saw the changes, they didn't know if it helped. They didn't know if it mattered.

Teams should be excited to tell customers about the work they did and confident that their code made a real difference. When engineers ship into silence, it's hard for them to feel connected to the work.

As a Product Manager, I am sometimes guilty of doing this. Just recently I was working on a feature with my product peers and UX Lead. We were spinning for a bit trying to land on a good solution. I then involved my Lead Engineer and it brought perspective that I a) hadn't considered and b) had brought experience from a previous job that was relevant. From there we had a clear way forward. Now am I a bad Product Manager for not thinking of this? No, but I should have involved them earlier. Product thinking isn't just for the Product Manager, it's a shared responsibility for the team.

How do we fix this? This is where the Product Driven model comes in.

What is the Product Driven Model?

The Product Driven Model is backed up by research that Google ran across 180 teams called Project Aristotle to understand why some teams are highly effective and some aren't.

Here are the key characteristics:

• Psychological safety: freedom to take risks, admit faults and speak openly
• Dependability: your teammates are reliable
• Structure and clarity: the team's roles and goals are well understood
• Meaning: people feel connected to the why
• Impact of work: people believe their work matters

The Product Driven Model maps exactly to these things that Google surfaced.

• Vision - make the vision real. Repeat it often. Tie every sprint back to the "why"
• Focus - Busyness isn't progress. Say no often and keep the team connected to customer value, not internal noise
• Clarity - Explain the why - give people the context they need to move with confidence
• Shared Ownership - don't hand off tasks, hand over direction. Let ownership live across the team, not just in one person
• Courage - model honesty. Reward openness. Create the kind of environment where teams speak up and lead

What You Can Do Right Now

You don't need a new job title or to reorganize the department. You just need to do some things differently that will snowball into substantial change.

Here are some practical things you could do.

Reconnect Engineers to the User

Nothing builds clarity and motivation like hearing a customer explain their problem and how to fix it. Do one or all of these things:

• Share a meeting recording with the engineers (and make sure they watch it)
• Schedule regular syncs with support and engineering. Not to dump tickets but to surface patterns
• Create a lightweight on-call support rotation. Get your team to do an afternoon of support. Let the team feel the friction
• Involve engineers earlier. Bring engineers into the customer conversations. Let them hear the problem, not just the feature request. Let them speak up and ask why and challenge assumptions. That context creates clarity

Choose One Ritual to Reinvent

Pick one ritual you already do: standup, sprint planning, retro etc. and change redefine how it works.

Ask yourself:

• Does the team understand the vision of what we are trying to accomplish?
• How can I ensure my team has the clarity they need?

Then change the questions you ask:

• Why are we doing this now?
• What's the problem we're solving for the user?
• How will we know this actually worked?

Ask Before You Answer

Ownership starts with a question and not just giving tasks to do. Before jumping into the next thing you need to fix, pause to ask:

• What do you think we should do?
• What are we missing?
• Does this feel like the right thing to do?

When you ask, you're not giving up leadership. You're giving others the space to thrive and contribute to team success.

Protect Yourself from Distraction

Look at your current roadmap or sprint plan and ask:

• What's the one thing that actually matters right now?
• What is distracting us from our goal?
• What is keeping us busy, but not actually moving us forward?

You don't need to cancel a whole swath of things, you just need to get hyper-clear on the one thing you are doing and focus on it.

My personal Product leadership win

When I joined this particular company, I was part of a huge greenfield program of work to build our new flagship product. I quickly realized that this was a technology-led program. They had all the new shiny technologies and were putting them into use.

Even though I had joined 1.5 years into the program, guess how many users they had talked to in that time? A big fat zero. The reasoning? It was a mix between "Oh we know our customers - it's the same as our legacy customers" or "we are seasoned industry experts so we don't need to."

I slowly set up user interviews and a good UX practice along with my UX lead. We started demoing some of our features we were building to our end users. Lo and behold, our users weren't really that thrilled. Yes, we had solved some big tech issues, but at the end of the day it didn't really move the needle on their day-to-day issues. In fact, we were missing features that the project had overlooked.

Fast forward a year and a half. I had secured a five-figure budget to invest in UX research tools and completely changed our process to a user-focused development approach where users were involved across our development cycle. This led to a better designed system, a more focused product where we could go-to-market quicker and more confidently, knowing that what we were building was sellable.

Healthy Skepticism

You might be reading this thinking "yeah, this is fine for the FAANGs of the world or companies with good product thinking but I couldn't do that at my job."

I sympathize and agree that not every company has the capacity or leadership to change their way of thinking. But nothing will change unless you start the conversation. You might be surprised with the outcome, or you might find out that they aren't interested and maybe there is another company that aligns closer to your work values.

I have worked across companies at each end of the product maturity scale, but there was always something (albeit small changes) that pushed our product maturity forward.