×

Category: 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.

How do we determine value?

And how do we make sure we are delivering it?

In a previous blog I discussed the importance of understanding the value you are trying to add, and how you measure cost vs vale. How we measure value and ensure we are delivering a valuable return on investment is one of the ‘big’ questions at the moment, that never seems to go away.

Scott Colfer has equally blogged before on the complexity of measuring value when there is no profit to measure against. When working in the public sector it’s not an easy problem to solve. There is a lot of conversations about making sure we don’t waste public money, but how do we actually make sure public money is being spent in a valuable way?

A jar of coins
A jar of coins being spilt

The first principle of the Agile Manifesto is “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” But what is valuable?

At a kick off session this week, for a new project we’re shortly going to begin, a client said one of their hopes was that all code deployed would work first time; and someone else stated that they ‘didn’t want rework’. When we broke these thoughts down to understand where these fears were coming from, it was the need to add value and not waste money; which itself was coming from previous issues caused by a long time to deploy, and the cost to make changes.

There was equally the fear that by swapping out suppliers mid project we (as the new supplier) would want to redesign and rework everything to make it our own; which would slow down delivery and drive up cost even more.

There is obviously no value for anyone in doing that. The value comes by having a short feedback loop, co-designing and constantly testing, learning and iterating, working together in short weekly or fortnightly sprints, to get things delivered. Making sure there is little time as possible between designing something, to getting it tested and used by real users; ensuring it meets their needs as quickly as possible.

Through examining what has been delivered already against the user needs and the outcomes the organisation is looking to achieve; by identifying gaps and pain-points we reduce waste; and by prioritising the areas where improvements can be made we ensure that reworking only happens when there is actual value in doing so.

A parcel being delivered
Parcel delivery

At a talk this week I was asked how we prioritise the work that needs doing and ensure that we do deliver. The important thing is to deliver something, but ideally not just any old thing, we want to ideally be delivering the right thing. Sometimes we won’t know what that is, and it’s only by doing something that we can establish whether that was the right thing or not. But that’s why short feedback loops are important. Checking back regularly, iterating and testing frequently, allows you too recognise when there is value in carrying on vs. value in stoping and doing something different.

When I’m trying to decide where the value is, and where is the best place to start, I consider things like:

  1. Why are we doing this?
  2. Why are we doing it now?
  3. What happens if we don’t do this now?
  4. Who will this affect?
  5. How many people will it impact?
  6. How long could this take?
  7. Any indicative costs?
  8. Any key milestones/ deadlines?
  9. Any critical dependancies that could affect our ability to deliver?
  10. Will this help us deliver our strategy? Or is it a tactical fix?

Once we have started work, it’s important to agree measure of success (be they financial, reducing time, staffing numbers; or things like improved uptake or a better customer experience) and keep measuring what is being delivered against those targets.

At Difrent a key part of the value we add is about the people, not just the technology or processes; there is value in us working in the open, by being transparent; running lunch and learn sessions or talks; blogging or speaking at events etc. we can add wider value outside of a specific project or service.

A person presenting at a whitewall to a team
People listening to someone speaking/ sharing

When we are considering what adds value, the other thing it’s important to consider is the culture we are delivering in. Are there communities of practice in place already, any design patterns we should be adhering too? There is value in building in consistency, as this helps us ensure we are delivering quality.

There are many different ways to determine what adds value, and many different kinds of value, but the importance is by focusing on making positive improvements, and by constantly learning from mistakes and ensuring they don’t get repeated so no time is wasted and real value can be delivered.

Thoughts from the other side

No, don’t worry, I’ve not passed on and started speaking from beyond the grave; but given I’m now 3 months into my role at Difrent I thought it might be worth reflecting on how I’ve found things on the other side of the commercial table so to speak.

In the first 3 months I’ve worked with our teams, been in multiple contract meetings, client meetings, negotiations, done my first ever bid presentation and helped win my first piece of work for the organisation.

@Rachel0404 and I looking at a rich pic for NHS Jobs

In the 15 years I spent in the public sector I have done my fair share of time working alongside procurement, drafting Pre-Qualification Questionnaires and Invitation to Tenders as part of a commercial team, or assessing bid responses and pitch’s as a programme lead. But if I’m honest in all that time I never considered the work that suppliers put into their Tender responses; the effort different commercial frameworks might require nor how companies pick and choose which work to bid for.

It’s been fascinating within the Difrent SLT talking about the kind of work we want to be bidding for, assessing what work aligned with our #TechForGood goals and values. It’s also really been reassuring to be involved in conversations where we have decided not to bid on work that doesn’t align with the company values.

‘Do something great’

One of the things I’ve quickly had to get my head around is the complexities of the Digital Marketplace and the ins and outs of the different commercial frameworks, be that G-Cloud, DoS or PSR. If I’m honest I’d never really got my head around the pros and cons of the different frameworks before taking this role, it was always one of those things I simply had to approve before.

While I have previously managed projects and programmes, and managed the suppliers working with us to deliver the work; it was equally never a thing I massively had to dwell on, beyond the question of ‘are they delivering what we need or not?’

In the last three months I’ve really gotten to understand the amount of work that has to be put in to make sure they answer to that question is ‘yes’.

Graphiti saying ‘yes’!

One of the trickiest aspects to that relationship is making sure as a partner we are providing the right amount of rigour, challenge and reassurance so that our clients feel assured that we are doing the right things in the right way to deliver the outcomes they are looking for. Balancing the need to challenge and ask why to ensure the work we are doing is right, with the need to keep the client happy, engaged and onside. Not the easiest thing to do, but definitely vitally important in order to ensure value is actually delivered.

As a supplier I now realise how tricky it is to walk the tightrope of helping the client deliver the right thing, when this might mean a scope change that means more time or people (ie. more money) vs. wanting to ensure you deliver on time and within budget.

As a Product Person, I have always spoken about the importance of prioritisation and focusing on the problem the organisation was trying to solve. I used to find it incredibly frustration trying to get suppliers to understand and deliver what we needed, not just doing the work, but helping us do the work right. I was involved in multiple conversations across government about good suppliers vs. bad. Those that actually challenged us to do the right thing, and those that just delivered ‘what it said on the tin’ without helping check the label on the tin was right.

Now working on the other side of the table, I am doubly as determined to make sure we are delivering both the challenge and the outcomes our clients are looking for, to help deliver truly meaningful products and services and add real value to our clients and their users.

A mug bearing the message ‘What good shall I do this day?’

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.

Producing Code or Fixing Problems?

The role of Developers in user centric design.

I’ve been working with Developers of different flavours for almost a decade now, and in that time I’ve worked with some amazing Devs, and some frustrating ones; the same as any role it depends on the person.

I’ve also encountered a lot of stereotypes about Developers, primarily that they’re all introverts who like to work on their own, which is as true as saying all Product Managers must be extraverts.

In the last couple of years I’ve also been lucky enough to take part in recruiting and interviewing Developers, and as such I’ve found it fascinating to discuss the role of the Product Manager and the role of Developers, how we can work better together, to support each other and get the best out of each other.

I’ve found it very positive to see the role of the Developer begin to be more central within user centric design, and to have more Developers proactively taking part in user research and design sessions. The days where meeting user needs was solely the domain of the User Researcher and the Product Manager, and that Developers only cared about producing code felt like one we had, at least within Government Digital circles, left behind.

Code

As such, it almost felt like having a bucket of cold water tipped over my head to be told recently that Developers shouldn’t be overly involved in user research, and should be focusing on producing code.

As a Product Manager I don’t want Developers who just produce code, I’ve seen in the past the dangerous waters that can lead to. If you don’t understand why users are doing things, what their needs are, the problems we are trying to fix for our users, then how could you, as my technical expert, challenge me? How can you understand the options and give me advice on how best to tackle the problems we are trying to solve? How can you ensure the code you are writing actually meets the requirements if you don’t understand why it’s needed?

The best Developers I’ve worked with have been proactively working with the user researchers to suggest things to test, using tools like A/B testing to help explore the options and determine the best solutions we can test to help fix the problems we’re trying to solve, using feedback from users to iterate and learn and improve.

Product Development Team

I recently did a google search for the ‘role of developers in user centred design’ and was saddened to see there wasn’t much out there, other than a few scholarly articles citing the importance of getting Software Engineers and Developers to integrate user centric design into their approach.

So maybe this is where we are going wrong, maybe we are not talking enough about how important it is that user centric design isn’t just the domain of the designers and user researchers. That the principles of UCD are just as important in the development stage as the discovery phase.

As the Government Digital Service famously said, ‘User Research is a team sport’, and we need to makes sure everyone gets the chance to play.

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.

Bringing Product and Design together to build a user centric culture

Why bringing Product and Design together is such a good idea.

Within the Product Management community we often talk about the importance of the Vision and how critical a prioritised backlog is. Making sure we understand our users needs and making sure we deliver quality services that meet those users needs.

Recently Service Design as a principle has been more widely embraced, and within Governments Digital, Data and Technology Professional Capability framework Service Design is now recognised as a role within its own right.

Within DWP the User Centric Design community has always been strong, brining together the Service Designers, Content Designers, Interaction Designers, Front End Developers and User researchers. Passionate people who want to design make sure we are designing our services around user needs.

Within the last year we’ve recognised the benefit of expanding our Product community to include not only our Product Owners and Managers, but also our Business Analysts and Business Architects. Those passionate about developing visions and products based on user needs, making sure we understand our processes and the vision and strategy for moving forward.

But so much of what those communities do, so much of what they are passionate about is the same. We all want to solve problems for our users, be they claimants, other government departments or our own staff. We want to do the right things for the right reasons. We ask “Why” a lot.

So it made sense for us to bring the Design and Product communities together into one overarching ‘family’; to share what we’re doing, to talk about what we all do and why, to share ideas for how we move our services and products in DWP forward.

To celebrate bringing our communities together, I organised and ran a conference to talk about Product and Design; how we could best work together to develop DWP’s User Centric culture, and ensure User Needs were at the centre of everything DWP delivered.

I found the day itself really positive. Lara Sampson, our new Product Design Directory, kick-started a jam packed day full of energy and enthusiasm. It was great to talk to people I hadn’t really had chance to talk to before. To learn more about some job roles I might be less familiar with, and I look forward to our next event when we’ll have even more members of our Product Design community there to celebrate with us.

The day was also a poignant one on a personal level as we said goodbye to those leaving DWP to move on to pastures new. On a personal note I had to say goodbye and thank you to Ben Holliday who has for the last year been DWP’s Head if Design, my co-conspirator, confidant and beacon of sense and stability. I’m very sad to see Ben go, but delighted that he had this new exciting opportunity to explore. Just know that the Product Design community would not exist today without Ben, he helped make us what we are and we are all incredibly greatful!

But for now, onwards and upwards, there is anyways more to do, and I for one am excited to see what our Product Design communities can deliver working closer together than ever.

This blog was originally written for @DWPDigital

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