I work for the teams I lead.

I see digital product (and service) delivery as a collaborative endeavour. It requires Product Managers, Designers, Engineers, Researchers, Data Scientists, Domain Experts and Business Leaders to all work together to apply their individual expertise and experiences to solve problems.

My job as a Product Leader is to make sure everyone involved has everything they need to be able to do that well. Including (but not limited to):

• a clear understanding of what customer need they are trying to address
• what the business objectives for the product are and how the team’s goals align to the wider organisation’s vision and strategy
• an environment where collaboration between all team members works for the team.

How each of the above are delivered is dependent on the organisation and team makeup. All teams are different. Some naturally lean towards a customer centric approach, while others are more technology or solutions centric by nature. Some organisations are very adept at providing a clear and concise vision and strategy, others less so. Some teams are naturally better at collaborating than others.

My job as a Product Leader is to understand the organisation and team makeup and adapt my way of working to fit with how they do their best work. Always focused on delivering measurable outcomes, not just outputs, that improve the overall experience of customers using the product or service.

A lot of Product Managers see themselves as the people who shape the product, with their teams there to execute their vision. I don’t.

I believe it’s the team who shapes the product, my role is to shape the team and give them what they need to shape the product.

I can bring my experience as a UX consultant to the team, offering input on the usability, accessibility etc of the product’s design and implementation, but ultimately it’s the Designers and Engineers on the team who make the decisions about how a solution we work on is executed.

My job is to help them focus on the right problem to solve and make sure they have the information and tools they need to solve it by working together.

While the specifics are different for each team I work with, broadly speaking I like to follow the Inspired (Marty Cagan) approach to product management, splitting the team’s activities into two tracks:

1. Discovery work
2. Delivery work

Discovery work

Discovery work is focused on gaining insights about any problem or problems customers have and exploring different ways we could solve those issues with our product or service. This type of work calls for rapid iteration and exploration and involves a lot of prototyping, testing, trial and error, and learning.

Delivery work

Delivery work is focused on implementing the solutions that have been explored and tested and deemed good enough to be put out into the world. This type of work involves making sure the execution of those solutions is done to the highest standard, still as quickly as possible.

The “we believe vs. we know” question

It can often be hard to know which type of work a team is (or should be) doing at any one time as ideas about what to work on come thick and fast in most organisations.

My rule of thumb for filtering new work requests into discovery or delivery streams is to frame the work in terms of whether it’s something “We believe” we should do, or whether it’s something “We know” we should do.

If it’s something we believe we should do, we need more evidence that it’s worth pursuing before committing the time and energy to deliver it. That requires discovery work.

If it’s something we know we should do, we should know what measurable impact making the change will have. Once we know that, we can often (but not always) put it straight into the delivery stream.

I say not always, because sometimes there are things we know we should do, but we’re not entirely sure how to do them. In those cases there’s some discovery work to be done to determine the best way to deliver the work (answering the question: “which way of making this change will give us the biggest impact”).

All the work that’s done in the discovery stream should be focused on turning all the “we believe” statements into “we know” statements. If we get that right, all the work done in the delivery stream is worth putting the time and effort into getting right because we, the team, already know it will have a positive impact on the end customer experience of using the product or service.

When the solutions a team deliver are measurably better than what came before them, it’s a sign that the team are working well together and working as a unit.

If the solutions being delivered are not improving the product or service then it’s a sign that the Product Leader is not doing their job and needs to review what more the team needs to be able to deliver their best work.

As Marty Cagan wrote in Inspired:

“When a product succeeds, it’s because everyone on the team did what they needed to do. But when a product fails, it’s the product manager’s fault.”

– Cagan, Marty. INSPIRED: How to Create Tech Products Customers Love. Wiley.