×

Tag: Product Management

Why SME’s are important, but shouldn’t be the Product Manager

Along time ago in a land far away; well four years ago and sat in a very cold office in trafalgar square; Ross Ferguson , Alex Kean , Scot Colfer and I plus a few others sat discussing the DDaT capability framework for Product Management.

The discussions we had at the time focused on “how do we actually define the role? And what makes a good product manager?” And there have been plenty of blogs written on those questions over the years. It definitely feels like the role has matured and progressed over the last few years, and now is generally pretty well recognised.

However yesterday chatting to Si Wilson about SME’s and Product Managers, and why they were different roles, I realised this may be one area not touched on much, and actually a pretty key difference it’s important to understand.

In the private sector, the Product Manager is often “the voice of the business”, they are equally seen as the “voice of the customer” but when developing products to take to market and make a profit, it’s less about what the users need, and what the business can sell to them.

In the Public Sector, the role of the Product Manager is a bit different. The Product Manager is NOT the voice of the business, instead they are the voice of the vision. The Product Manager is responsible for ‘what could be’ they ensure the team are delivering quality and value, weighing up the evidence from everyone else in the team and making the decisions on where to focus next in order to meet the desired outcomes.

This slight change in focus is where the role of the Subject Matter Expert (SME) comes in. The Scrum Dictionary states the SME is the person with specialised knowledge; in my experience the SME provide’s the voice of the business; and what ‘is’ rather than what will be. They understand the in’s and out’s of an existing product, service or any sacred cows that need to be avoided (or understood) within an organisation. They usually work closely with the Business Analyst to map out business processes and User Researchers to understand staff experiences.

Back when we merry band of Head’s of Product were trying to understand the role, the decision to not have Product Managers ‘be the voice of the business’ was a very deliberate move as we felt it hampered the move to User Centred design, as it felt it was hard to step back and be agnostic about the solution if you’ve had years in the business and know every pain point and workaround going etc.

Some of the dangers of having a Product Manager who is also an SME are:

  • They feel they know everything already because of their experience, so feel that user research or testing is a waste of time.
  • They become a single point of failure for both knowledge and decision making, with too many people needing their attention at the same time
  • They can get lost in the weeds of details, which can lead to micromanaging or a lack of pace

That is not at all to say that Product Managers can’t ‘come from the business’ because obviously having some knowledge about the organisation and the service is helpful. But equally, having a clear delineation between the roles of the Product Manager and the SME is important; so if you do have someone covering both roles, it’s important to understand which hat is being worn when decisions are made; and for that individual to be able to draw a line between when they are acting as the PM and when they are the SME.

A person presenting at a whitewall to a team

As a Product person, a good SME is worth their weight in gold. good ones bring loads of speed and stretching thinking — and even packaging thinking. They can help identify pain points, and help user researchers and business analysts find the right people to talk to when asking questions about processes’ etc. They give the Product Manager room to manoeuvre, and make sure things are moving on. Equally the best SME’s can be pragmatic, they understand that what the business wants doesn’t always match what users want, and work with the team to find the best way forward.

Where the role of the SME hasn’t worked well, in my experience, it tends to be because the individual hasn’t been properly empowered to make decisions by their organisation or line manager; or don’t actually have the knowledge required, and are instead their to capture questions or decisions and feed them back to their team/manager. Another common issues is that the SME can’t be pragmatic or understand the difference between user needs and business needs; and won’t get involved in user research or understand its importance. Rather than helping the team move work forward, they slow things down; wanting every decision justified to their satisfaction; wanting to make decisions themselves rather than working with the Product Manager.

Rarely have I found SME”s that could be dedicated full time to one project, they tend to be Policy or Ops experts etc. and so there are a lot of demands on their time. I suspect this is one of the reasons the role of the SME and Product Manager if sometimes blended together. However, while they ‘can’ be filled by the same person, in my experience having those roles filled by separate people does work much better, and allow the team to deliver value quicker.

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

The strength of Product People in Government

For those that don’t know me I’m Zoe, proud mum, avid geek and currently the Head of Product at the Department for Works and Pensions.

At the start of this year, we in the DWP worked with the Goverment Digital Service to host the first ever cross-government Product Management conference.

Why? Because we wanted to bring together all the Product Managers and Owners currently working within government to celebrate our achievements, grow our community, and look at what more we could all do to keep driving our work, our profession and us as individuals forwards.

The event was, I believe, a massive success, we had speakers and representatives from a wide variety of departments, the community nominated to topics that it wanted to discuss and we all got a chance to network and share stories. I got a lot out of the day, not only professionaly, but personally. But, that event was never designed as a one-off, and the main thing I and many others took from the event, was what more can we do?

So what have we done since then?

Well, we’ve expanded the Product People community dramatically, we’ve grown the network outside of London, and started having regular gatherings of Product People in the North.

We’ve got the Product Management career pathway into Beta and being used by most departments within government. A handful of the Heads of Product are now getting together regularly to share news and updatesand we’re using this group to share recruitment plans, job or secondment opportunities, training and development ideas, for example.So we’re building consistency and collaboration to benefit all those working in the profession within government.

We’ve continued to work with the Digital Academy to deliver the Product Owners working level course across government, and started development on the first Product Management masterclasses, that will begin role out shortly.

We’re starting to offer cross-government mentoring opportunities for Product Managers, and building those networks between departments, allowing us all to workmore closely and learn from each other.

Many government departments are now recruiting for Product Owners and Product Managers up and down the country at various levels. This gives us all a great opportunity to grow our community and keep building the user-centred culture we need in order to solve the right problems and deliver the right things.

Product Management is a very exciting place to be right now, and planning for the next conference is now underway, with HMRC taking the lead this time, and I for one can’t wait to see all we’ve delivered in the last 6 six months together.

You can read more here about what our Product Owners in DWP do, and what we’ve been doing to build our community:  https://dwpdigital.blog.gov.uk/?s=Product