What’s the difference between product manager, project manager and delivery manager?

Admin on 02/11/2021

Product manager, project manager and delivery manager each play a different role on a modern agile development team, but share a focus on achieving the outcome of the work.

Overlapping focus for product managers, project managers and delivery managers

What do product managers do?

Product managers focus on:

  • Vision – Understand the problems the product aims to solve, who has those problems, and why they are worth solving.
  • Strategy – Present how the product will solve the problem, and how solving the problems will achieve organisational objectives and meet user needs.
  • Alignment – Ensure the product vision and strategy are aligned with organisational objectives and stakeholders expectations, and that the team are aligned on the problem and the solution.
  • Prioritisation – Decide which the parts of the solution achieve the most for the organisation and the users.
  • Value – Understand the value users will get from using the product and where they might lack value they expect.
  • Cost – Balance the cost of building the product with the expected return on investment over the life time of the product.

What do project managers do?

Project managers focus on:

  • Planning – Coordinate all aspects of the project to meet the project goals.
  • Cost – Monitor and report on the cost of the project.
  • Time – Understand the schedule of work and monitor progress.
  • Governance – Ensure the project follows organisational control procedures.
  • Resourcing & dependencies – Monitor project resources and escalate dependencies.
  • Risks & issues – Monitor and resolve risks and issues that may impact the success of the project.

What do delivery managers do?

Delivery managers focus on:

  • Time – Decide how the development team best uses the time available.
  • Value – Understand what value the user should get from the product.
  • Scope – Control the scope of work that the development team work on the ensure the solution is appropriate and proportional to the problem.
  • Quality – Ensure the solution meets quality standards, e.g. accessibility and security.
  • Barriers – Remove barriers and impediments that slow down the development team.
  • Process – Implement, monitor and improve the processes the team uses to manage it’s work.

How do all three work together?

All three overlap with a focus on the outcome. All three roles succeed if the work achieves the outcome it set out to.

The Project Manager and Delivery Manager overlap their focus on time. For the Project Manager

The Product Manager and Project Manager overlap their focus on cost. This includes all investments into the project and product to ensure a positive return is going to be achieved.

The Delivery Manager and the Product Manager share a focus on the value that end user of the solution will receive. For the Delivery Manager, value is closely connected to scope of the work as defining and building the wrong product or feature risks reducing the value it provides.

Although each role has different aspects to focus on, good teams don’t work in isolation and support each other to succeed.

Retrospective August 2021

Admin on 31/08/2021

This month’s lessons: focusing on fewer things makes it much easier to to stay on schedule (who knew) and having things on a delivery plan that just happen without any focus is kind of missing the point.

Contributing to the digital transformation of the charity sector

I got where I needed to with product requirements for two of the three projects. The third project has a more extended timeline and a slower pace, so will come in time. Also did a little bit of strategy work using Wardley mapping, which has got me thinking.

Learning about innovation, technology, product and design

Finished my dissertation. Which means I’ve finished my masters. It feels weird. Partly because it’s been a big part of my life for two years and now all that pressure is suddenly gone. It’s going to leave a big gap. And partly because I can’t do anything more about the final grade I get. It’s out of my hands now. A lesson I need to take into whatever I choose to spend my time doing next is that in order to get me to focus, that thing needs to have some external commitment (for my masters that was the money I’d paid) and some future benefit to achieve (which is getting the masters). Other projects I’ve started before haven’t had either of those and I quickly lose interest when I have a new idea.

Wrote weeknotes on schedule every week. I’ve been mixing them up a bit by adding a photo of the week, things I’m grateful for, and what my growth area for the week has been. They continue to be a really good prompt to looking back over the week.

Leading an intentional life

I reached a new level of appreciation for my digital nomad life this month. I started a map to keep track of the places I’ve visited. I saw dolphins, seals and a lizard.

I completely smashed my purposely low target for stiles. I have 348 on stiles.style whereas my target for this month was 315.

I achieved the increase in runway I was aiming for.

All three of these targets are starting to feel out of place on my delivery plan. They just happen without me needing to give them any focus so I think I might drop them and think about whether I should add something else. I still think of them as being part of the goal of leading an intentional life so they should be on my roadmap, but not on the delivery plan.

Weeknotes #253

Admin on 04/06/2021

This week I did

New strategy

Our new organisational strategy was released this week. I’m keen to spend some time soon reading it more deeply and thinking about how to interpret it for the work we’re doing. I’ve noticed a few strategic mis-alignments recently between the work our programme design team is doing and the direction I thought the product team was heading, so now is the time to bring together the different perspectives and course correct before we get into the next phase of work.

I also spent a bit of time working on product strategy to develop some guiding principles. One of those is about the ensuring that the speed we introduce change is matched to the speed at which the changes can be adopted. Just going as fast as we can seems like the wrong thing to do, as counter as it is to lots of product development thinking and my personal beliefs, because it’ll cause bottlenecks and futureshock.

Systems training

Delivered training on using some of the new systems we’re putting in place. As part of the thinking for what to include in the training I was imagining the ‘system of systems’ we have. There are lots of distinct systems that have certain data and perform certain processes, and then there are linking processes, automated and manual, that move that data between the systems, and then the human nodes in the system that contain information about how the system works but are very much part of the system. Maybe I should just stick to delivering the training.

Delivery planning

I wrote out my delivery plan (still a work in progress but mostly there) to help me track what I’ve done throughout the year towards the goals on my roadmap and to get into the habit of monthly planning. As part of my monthly planning cycle I did a retro of the things I’d learned in May that had affected my ability to deliver on my goals. I don’t really have a format that works for me yet but it started me thinking about methods for retrospectives and what they should aim to achieve. I think looking back is useful but really retros should be about increasing agency and ownership in order to change the approach which then improves everything you do in the future rather than just individual process improvements.

Vanlife fail

I visited Stonehenge and found a large community of vanlifers. I wanted to hand out my flyers to ask them to do the survey but it felt really uncomfortable intruding into their community as an outsider. There’s a different between vanlifers who live in semi-permanent communities together and those who live more solitary, transient lifestyles. Some outsiders and more outsiders than others.

Blockchain and social good

This week’s lecture was about how blockchain and distributed ledger technologies are being used for social good, and posed the question, ‘should more technological development be focused on making the world a better place?’ The answer is clearly and obviously, yes. The case study was how blockchain was being used to manage commons resources and some of the resources included a sector-specific study from Stanford University and looking at Blockchain for Humanity, which is a not-for-profit foundation with the mission to drive the adoption of emerging technologies that can offer a positive social impact. There is so much possibility.

And thought about:

Hybrid meetings

I had my first hybrid meeting, with some of us in the room and some joining via video. It started me thinking about the pros and cons of hybrid meetings so I collected my thoughts into a blog post. Although I’m certain that remote, virtual, asynchronous work works best for me, that doesn’t mean there isn’t something interesting to try to figure out about hybrid working, especially if it’s likely that we’ll be working with others who do have hybrid ways of working.

Dealing with unknown unknowns

The common wisdom for dealing with unknown unknowns seems to be to adding them to a matrix with the known knowns, unknown knowns and known unknowns so you can (hopefully) identify by contrast the unknown unknowns. This way assumes that all domains of knowledge exist within that matrix, so I wondered about switch it around and putting a matrix within each domain of knowledge. Galbraith talks about how organisations deal with uncertainty and unknowns by processing more information between decision-makers as the way forward is figured out than is processed where decisions can be pre-planned. If unknowns are broken down into smaller and smaller domains of knowledge then perhaps the unknown unknowns become smaller and more specific, which might make them easier to imagine. Dealing with uncertainty and adapting to change is a capability every organisation is going to have to figure out how to build and I’m not sure there is a lot best practice in how to do that yet.

Ukrainian aviators love me

One of my most popular (I mean popular in my terms, which isn’t very popular by most people’s terms) blog posts is Schmenner’s Service Process Matrix – but for charities. It seems to show in Google searches for Schmenner, and weirdly, the Ukrainian National Aviation University link to it in one of their papers about applying the service process matrix to logistics. This amuses me.

And read this:

Maintaining Radical Focus and Staying on Strategy with OKRs

The One Knight In Product podcast episode with Christina Wodtke was really good. It seemed like a really authentic talk about when and how to use OKRs effectively rather just a sales pitch for a book. The best thing I took away was ‘Cadence is everything!’

What is digital ethics?

“No framework can possibly be complete, so it is important for employees in any organisation to examine the digital ethics dimension in any digital project they undertake.” Ethics isn’t about big dramatic decisions. Every single little decision is an ethical decision.

A thread of product management frameworks

Another thread from Shreyas Doshi, this one about product management frameworks.

What’s the difference between a roadmap and a delivery plan?

Admin on 10/03/2021

So many discussions must take place in digital teams about the difference between a roadmap and a delivery plan. They are very different tools that serve different purposes, and you probably need them both, but it’s easy to say one and mean the other. So, here’s what makes a roadmap different from a delivery plan.

Roadmaps

Roadmaps are usually (or at least should be) goal-based, whether implicitly or explicitly (which is better). They state what you’re trying to achieve, hopefully because those goals will help the organisation implement its strategy for being successful.

Gov UK Roadmap
Gov UK Roadmap

A roadmap is used to prioritise the work, which means choosing what you will and won’t do. It’s logic is ‘this, not that’. As it the example above from gov.uk, some of the things that can be done to achieve the goal are being worked on now (they’re in the ‘Now’ column) and some might be worked on later, which expresses the either/or choice that roadmaps require.

Good roadmaps also express options and uncertainty. The items in the ‘Later/Future/Exploring’ column might never make it into the ‘Now’ column because as they are investigated and shaped it could be that it’s found that the option wouldn’t help to achieve the goal.

Once we have a roadmap, then we produce a Delivery Plan to describe when the work in the ‘Now’ column can be delivered.

Delivery plans

A delivery plan is used to sequence the work. It describes when the work will take place and when it is expected to be finished. It’s logic is ‘this, then that’. It helps to understand what work can happen in parallel and what is dependent on a piece of work being finished (the dependency might be technical or because people are busy).

Example of a delivery plan
An example Delivery Plan

A reliable delivery plan needs work outside of the plan to consider people’s availability and capacity and some idea of whether the work can be achieved in that length of time, otherwise it’s a bit of a guess rather than being based on facts.

Questions about roadmaps and delivery plans

Can a roadmap have dates?

Yes, it definitely can, but those dates should be for information against each of the goals, for example, ‘Goal 2 must be met by date x for this reason’.

Does a roadmap list features?

No, a roadmap isn’t just an ordered backlog. A backlog is a whole other tool that does a different job. Roadmaps help to understand what the goal is and options for how we’re going to achieve it

How far into the future or past should a roadmap show?

For as long as it takes to achieve the goal. That’s why roadmaps are often organised in columns of ‘Now’, ‘Next’, ‘Later’, ‘Done’ as they convey a past and future without being constrained to a date on a timeline.

Who should see the roadmap?

Everyone who’s work has impact or is impacted by the work that will happen to achieve the goal.

How detailed should a delivery plan be?

It shouldn’t go to the level of tasks, but it depends what other planning tools you use. If, for example, week 14 shows that an identity management solution is being developed, and the developers have user stories to take into a sprint planning session, then the delivery plan doesn’t need to be detailed.

How to Excel at Both Strategy and Execution

Admin on 11/06/2020

For decades, we’ve often thought of leadership profiles in unique buckets—two popular varieties were the “visionaries”, who embrace strategy and think about amazing things to do, and the “operators”, who get stuff done. We intuitively knew that there must be leaders that span these areas, but in fact, few do. According to a global survey of 700 executives across a variety of industries conducted by Strategy&, the strategy consulting division of PwC, only 8% of company leaders were said to excel at both strategy and execution.