×

Tag: Product Management

Measuring cost vs. measuring value?

Discussing the differences between Product Management in the Private and Public sector.

There has always been a perceived difference in how Product Managers in the public and private sector work, what their priorities are and their key focuses.

Historically at its most simplistic the view has been that within the Public sector the Product Manager focuses on what user’s need. Whereas Product Managers in the private sector focus on what users want.

Interestingly as more organisations in the Private Sector adopt the user centric design principles championed by Government Digital services and public sector organisations the difference in the role between the Private and public sectors decreases. Within the public sector we do indeed focus on user’s needs, however we do have to consider their wants as well if we want to create services our users will enjoy using.

Equally while Product Managers in the Private Sector will focus more on want’s, as that is where their revenue is likely to be, and what will give them the edge in the market. But they will also consider need’s, because when developing a service for users, it’s important to understand whether users wants and needs are polar opposites to ensure your not setting your scope too small or your costs too high. As such, while this difference between need and want is possibly still the best way to separate the roles, they are not as different as they once were.

A simple task backlog

No matter what sector they work in, be that private sector or Public, Product Managers are still there to ‘represent’ the end user and their needs/wants, within the Public sector the Product Manager is more likely to work with a user researcher who will help them understand those needs, and there will be more of a focus on user research to ensure the users are properly understood and represented, but at their core the Product Manager is still there to ensure those needs are met in the best possible way.

They are also responsible for understanding the opportunities and gaps within the market place, looking for opportunities to fill a need that is missing; for developing their Product strategy and roadmap and setting the scope for their Product to meet the needs or target the gaps they have identified.

So, perhaps the other key difference between the Private and Public sector Product Managers, is cost revenue. Within the Private Sector, the Product Manager is responsible for ensuring the Product or Service they are developing will fit within the Business Model, they manage the profit and loss for their Products, and the development of the business development strategy. They will quantify the return on investment predominantly through revenue return. They will be examining the market place to understand what similar products are out there, and their costs to users to use; Once they have a rough idea on how much they can make they can determine their ROI is based on how much it will cost to develop vs. how much profit are they likely to make from users once the Product or service is live.

Within the Public sector there is not the same onus on cost revenue. Departments are funded by the treasury, very few agencies or bodies generate their own revenue, and while there are some, they are not looking to create a profit in the same way the private sector is.

Instead the return on investment we are considering in the Public sector is about value to the public purse. Is there value in spending public money on developing this product or service? We do this by examining how much is currently spent on running any existing services; how much is ‘lost’ through waste or inefficiencies; how much can be saved by introducing service improvements or a new service for users and how much will it likely cost to develop? If the savings out way the spend, then there is likely value in us using public money to develop this.

A dashboard showing user numbers

This approach to determining value is the difference between the public and private sector product managers, but also shows how similar the roles actually are. Product Managers, no matter what sector they are in, care about their users and developing products and services for them. They look to the market to understand opportunities; they work to develop their Product strategy and to quantify the available Return on Investment.

I think we need to put to bed this idea that the Private sector solely puts revenue over users, and that the Public sector doesn’t care about costs.  Both Private sector and Public sector Product Managers have a lot they can learn from each other, and we should be looking for more opportunities to join up and share our experiences and knowledge.

I believe both Private sector and Public sector Product Managers have a lot they can learn from each other, and we should be looking for more opportunities to join up and share our experiences and knowledge. I think we need to put to bed this idea that the Private sector solely puts revenue over users, and that the Public sector doesn’t care about costs.

What is the value in a Head of Product?

Our numbers are growing, but what is the role, and what value does it add?

When I first took up the role of ‘Head of Product Management’ back in October 2016, I was one of the first in Government to have the title, and within a few months there was a very small band of 5 of us, who were responsible for looking after the Product Management professionals within our own Government Departments. We were professional leaders, tasked with building capability and skills, and building communities of practice. The original job description we created for a Head of Product was very different to what I do now.

In my first 12 months of the role I focused on the people, working with the others across government to develop a capability framework, training and development plan and a career pathway that Product Managers could use to develop a proper career as a Product Manager within Government.

A lot of our time was spent debating the skills Product Managers needed, and what value Product Managers brought to Projects and teams. It was, upon reflection, a very inward focused role; which given the maturity of the profession at that time made sense. But several years later user needs have changed and I think it’s a good time to reflect on the value we Heads of Product now find ourselves adding within our work, and making sure everyone understands the work some of us are now doing and why. To discuss what that difference is between what we were doing and what we are doing now, and does everyone understand and agree that difference.

This change in the dichotomy of the Head of Product role came up at our last Head of Product catch up, for those of us in role a few years ago, we have all separately found that our focus isn’t purely on developing that community and the professional skills and capabilities of Product Managers anymore.

Instead we are now focussing on Product strategies, on aiding Prioritisation of portfolios, of working with Senior leaders to break problems down, understanding the value we are trying to gain, or the outcomes we are trying to achieve through the Products and Services we are developing. We’re running roadmap workshops across directorates, debating Targeting Operating Models and strategic alignment.

Most departments are now hiring ‘Head’s of Product’ or ‘Deputy Directors of Product’ to be part of their Senior Leadership teams within Digital, and personally I think that is the right move.

As organisations mature in their agile ways of working, the role of prioritisation has become ever more important, and as Product Management professionals, the ability to weigh up data and evidence to make decisions about priorities is our bread and butter. As organisational budgets continue to be constrained we all need to get better at focusing on outputs and understanding the value we are looking to deliver through our projects and programmes, ensuring we are meeting user needs whilst spending public money wisely. Determining priorities and ensuring we are delivering value for users are the fundamental objectives of the Product Manger role, and as such it makes sense to utilise those skills at an organisational level.

We are, in fact, much closer to our counterparts in the private sector determining Returns on Investment etc. than we have ever been before. Yes, we as Head’s of Product still work with Product Managers and teams to help them ensure they are meeting the standards and delivering value, and we still look at the resource demands of teams and make calls on which person within our professional community might be best placed to work on with Product; and in some departments the community is so big that actually they still need someone to focus onleading that; but for the most part, our communities and our people have grown along with us, and most don’t need the level of support from us as community managers that they did before.

#ProductPeople

Most of the communities now across government are self-sustaining, events like #ProductPeople are being set up and run by members of the community; and while we as Heads of Product are still here to help champion Product Management, and to support the people in our communities, the role of the Head of Product Management as a community lead, has adapted and gown into what our organisations need now, someone who can use those Product Management skills at an organisational level.

As such, I think it’s time we look at the Digital Data and Technology capability framework again for Product Management, talk to community, and review the job description for the Head of Product role we initially developed and iterate that. We need to understand the role of the community lead and the need for that, whilst also recognising the value of Product Management and the skills Head’s of Product can bring to our senior leadership and our organisations.

Theme vs. Epic vs. Feature vs. Component vs. Story

Probably the question I get most (after what is Product Management, and what is the difference between a Product Manager/ Product Owner/ Delivery Manger)… ok so the third most common question I get asked is “what I mean by Epic/ Theme/ Feature, Componant or Story, what is the difference?”

And given I get asked it so regularly I thought it was worth sticking my thoughts down in a blog, so that I can call upon it in the future for reference, but also so I can understand whether I’m using them differently to others.

Theme:

When I tall about a theme, I mean something like Accessibility. It weaves through pretty much all stories as a thing we need to consider, will be key in multiple epics, but is not a deliverable ‘chunk’ of stuff on its own.

Epic:

When I’m talking about Epics I’m talking about things like Payments. These are tied generally to a specific outcome or high level user need or part of the journey or process someone takes in using the service. “As a business I want to be able to pay my staff so that they are remunerated for their work” for example. All the stories within an epic are related to delivering that outcome, the stories collected in an epic deliver value together, but the Epic is too big to do in one sprint. An Epic may be made up of several Features, or it may not. If it contains several Features you may prioritise all the “must have” stories from the epic to deliver together, and come back to the “should’s and could’s” later. Or you may save up the stories to deliver all the stories together in one larger release.

Features and Components:

Sticking with the Payments analogy, given the scope of that Epic is large, it would probably contain several features and componants. a Feature would be something like your payments engine, a collection of stories you have to develop and deliver together to release value, whereas a Componant is generally something you can plug in like Bank Wizard. Neither of these things deliver the full outcome required, which is why they are not an Epic.

Just because you can physically pay someone doesn’t mean you can calculate the right payment for example, there will be other stories to allow you do that, all of those stories would sit within the Payments epic as you need them to meet the outcome you’re looking for, but would be developed separately to your payments engine or allowing you to plug in bank wizard.

Finally there are the stories and tasks that are fundamental to delivering everything:

Stories are the individual bits of ‘stuff’ you are trying to deliver. And the tasks are the actions you will undertake to deliver the story. So “as a manager I want to stop payments to members of staff who have left the business so that I’m not paying the wrong people” is a (terrible, sorry) story. It would still sit within the Payments epic, could possibly be part of a feature, but it meets an individual user need. The story would need to meet accessibility criteria, and there are several tasks you’d have to do to deliver it, develop a prototype or speak to stakeholders etc.

Originally posted on Medium

What does a Product Owner own anyway?

Recently Ross Ferguson wrote a great blog about why GDS chose Product Manager rather than Product Owner as the role title of its Product people.

Ross is right when he says that Product Management is the profession, and more widely understood by the wider industry, so why do we in DWP not use that term for our people?

I could be, and often am, glib about why DWP chose to stick with Product Owner, even after we stopped purely using SCRUM methodology, but a good conversation on twitter got me thinking about the debate again.

So what is a Product Owner?

The question on Twitter was ‘does Business Analyst + Project Manager = Product Owner?’ And while a good PO needs some of the skills from both of those professions, that’s not all they are.

For me, a good Product Owner is part Business Analyst, part project manager, part researcher and part service designer.

They have to analyse and understand the problems and options whilst also researching and understanding the needs of their users. They have to understand and manage the details whilst also being able to dream big and understanding the opportunities.

But they don’t own the analysis, or the research, or the plans or the design, they don’t own the code or the solution. Agile is a team sport, and as @Scott offer says a good Product Owner is the generalist in a roomful of specialists. They manage the backlog and make sure all the things happen, but they don’t own those tasks.

Product Owners are accountable for making sure we develop the right thing. That we solve the right problem. That we meet the needs of our users in the right way. But accountability and ownership are different.

So, if they don’t own the tasks, is it actually the Product they own? In smaller organisations, absolutely. But in an organisation as big as DWP do our Product Owners really own the full end to end service?

Honestly? 8 times out of 10 probably not. Most of our Products and Services are so big they can only be owned by the Senior Responsible Officer.

So what do they own?

The vision.

The vision is what makes or breaks a Product or Service. A good vision solves a bigger problem. A good vision is the difference between transforming something or redesigning it. A good vision challenges and moves us all on.

And that is what a Product Owner owns.

I don’t think Product Manager is wrong, and in the future the community in DWP may choose to being Product Managers, they are all empowered to choose the term that they feel fits best, but it’s not the term that resonates with me.

I own the Vision, it does not own me.

Sorry, for the geeks amongst you, this is Vision…. I’ll get my coat.

Originally posted on Medium