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.

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.

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.

The Tech Debt Spiral

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.

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.

Big ideas need action to become real.

Break them into small, clear steps. Each win builds momentum and keeps you moving.

Perfection doesn’t matter - progress does. Test, learn, improve, repeat.

No one will remember your first crappy step but they will when you cross the finish line.

Create, Don’t Wait for Ideas

Great ideas are crafted, not found.

They come from clear problems, real insights, diverse perspectives and bold inspiration. Ideation sessions — prep, sketch and develop. Turn this mix into better solutions and stronger buy-in.

Prep sets the stage. Sketching sparks creativity. Development refines ideas into actionable next steps. Keep it sharp and ideas will shine.

Trim the Dead Weight

Removing a feature signals a mistake. Few people feel comfortable admitting that.

This hesitation keeps bad features alive. Teams cling to them, fearing the optics of walking back a decision. But doubling down on something that doesn't work costs more in the long run—time, energy and user trust. Recognising when something doesn’t fit and cutting it isn’t failure. It’s progress.

Users notice when products improve. Removing what's broken clears space for what works.

From Chaos to Clarity

The exec team was drifting, priorities misaligned, goals scattered. With OKRs, we trimmed 50 key results to 15, forcing clarity on what mattered most. The tough trade-off conversations exposed clashing perspectives but created alignment. Had to be done.

Fast Fades, Purpose Wins

In product management, it’s tempting to move fast and break things. Sometimes, that works.

But moving with purpose works better. It means focusing on what matters, making smart choices, and building something valuable. Speed without direction leads to wasted effort. Purposeful action builds progress that lasts.

Fast fades. Purpose wins.

Clearing Space with No

Saying no is a leadership skill.

It’s not about rejecting ideas, it’s about protecting focus. When everything feels important, nothing is. Saying no clears space for what truly matters—what drives impact, not just activity.

Yes, it will sting. People will take it personally. But prioritisation isn’t about popularity; it’s about progress.

Every “no” to distractions is a “yes” to momentum.

Push the Limits

Bold ideas unlock progress.

When crafting new products or features, it's easy to focus on safe, incremental improvements. These solutions feel achievable and practical but they rarely break new ground.

Adding a bold concept into the mix forces the team to think beyond limitations. Even if the daring idea doesn’t make it to launch, it creates a spark. It pushes boundaries, reshapes how problems are viewed and reveals opportunities overlooked in safer designs.

A bold solution isn’t just a backup plan. It’s a catalyst for better work.

Scaling with a Head of Product

Trust between a founder and their first Head of Product defines whether a startup scales or stalls.

Founders often start as the Head of Product, driving vision, roadmaps and hiring. But as a company grows, splitting attention across fundraising, culture, operations and strategy leaves product leadership exposed. Bringing in a Head of Product isn’t just inevitable—it’s essential. The challenge is doing it without breaking the momentum or diluting the founder’s vision.

Alignment is the foundation. A great Head of Product doesn’t just execute—they embody and challenge the founder’s instincts, building scalable systems around them.

When Teams Don’t Need a PM

A team doesn’t always need a dedicated product manager.

In startups, founders often take on this role naturally, using their deep understanding of the market and their vision for the product.

In larger companies, if the team already has a strong handle on strategy, data and market needs, they can absolutely operate without a formal PM. However, someone still needs to take charge of the product function - making prioritisation decisions clear and aligning the team around common goals.

More Than Just ICE

Feature prioritisation isn’t always about frameworks like ICE (Impact, Confidence, Effort), Kano or MoSCoW.

Sometimes, it’s about building momentum - creating buzz, lifting your team’s morale, staying ahead of competitors or even strengthening internal relationships.

The challenge is finding the balance between chasing these quick wins and staying true to your long-term vision.

Lead with Problems, Not Solutions

Sharing problems doesn’t mean solving them.

Early in a product management career, it’s tempting to package every problem with a solution. It feels efficient and helpful but it can limit your team’s creativity. Presenting ready-made answers shifts focus from understanding the problem to critiquing your idea. This shortcut skips the messy, collaborative process where the best solutions often emerge.

Teams thrive when they tackle challenges together. Give them the problem—leave space for their brilliance.

PMs, Step Back to Move Forward

When PMs and PDs overlap, clarity saves teams.

PMs and PDs often talk to customers, pitch ideas and think about UX. Overlap is natural but not all tasks require both voices. If PDs excel at crafting intuitive experiences, PMs should step back and refocus. Their time is better spent refining strategy and building cross-team alignment.

Stepping back isn’t losing control—it’s enabling brilliance.

QA Isn’t the Fix

Dedicated QA creates more problems than it solves.

When a dev team owns quality, accountability stays in the right hands. Bugs are fewer, fixes are faster and processes tighten.

Introducing dedicated QA shifts that balance.

Developers grow complacent, relying on testers to catch mistakes. Tools diverge, creating inefficiencies. QA often duplicates what devs should already handle.

Quality isn’t a separate role. It’s a shared responsibility embedded in every line of code.