×

Category: Agile

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.

When is Digital not Digital?

When it’s not about user needs or human centric design, but instead about fixing technological infrastructure.

When it’s not about transforming the service but keeping the lights on systems.

When it’s not about asking “why?”, because you already know the solution you want.

A sign asking “Why?”

As Tom Loosemore said, Digital is applying the culture, practices, processes & technologies of the Internet-era to respond to people’s raised expectations.

There are lots of conversations online about being digital, not doing digital. Digital is not a process, it is a cultural mind-set.

It is a way of asking questions and prioritising needs. It’s about delivering value and designing services that meet user needs and expectations.

A person using a smart phone.

Now and then you can still see organisations that use Digital as a label when they mean technology or IT.

However, those things are not interchangeable. The culture and mindset of of the teams of the teams, and the organisations itself, is very different.

In organisations that use digital as a label but are not embracing what it means to be digital you will still see a separation between change or transformation and digital. They will still have siloed ways of working.

The business will still separate the programme funding, governance and strategy from the digital teams tasked with delivery.

Organisations where digital is a way of working, not just a label, you will see properly empowered teams made up of people from across the business. You will have teams who ‘own’ the holistic service they are delivering from strategy to delivery.

Open plan digital office space

These are organisations where the multidisciplinary team isn’t just something that digital ‘do’ but the whole organisations embraces.

This comparison between Digital and Technology is equally relevant when considering the role of the Chief Digital Officer vs. a Chief Technology Officer or Chief Information Officer. There’s a good discussion of the various roles here. As with the other roles the Chief Digital Officer looks after an organisations data and technology assets. However, they go one step further and have a wider eye, considering the strategy and the possibilities for innovation and wider transformation. Their focus is not on keeping the lights on, but understanding why the lights are needed and are there any other options?

Servers

For me this sums up why digital is wider ands more far reaching than Technology, and why the Digital mind-set and culture is so important to get right for organisations trying to deliver transformation. And why, if you don’t have these things right, if you are digital in name but not culture, you are going to struggle to deliver real transformation.

Building a case based on assumptions

Why you shouldn’t start with the business case.

I’ve been working within Digital transformation for almost ten years now, working on some of the largest projects and programmes within the public sector. From front line services to backend systems, from simple forms to complex benefit processing applications.

One thing that has been a feature of every product or service I’ve been a part of has been the business case. Over the years I’ve worked to challenge and transform the business case itself, making it more agile and less cumbersome, in multiple organisations.

Traditionally business cases have been built on the preconception that you know exactly what solution you want, with the costs and timings estimated accordingly. These behemoth business cases usually clock in over 25 pages long, with very little room of flexibly or change. The millstones in them are clearly laid out and everyone sits around clapping themselves on the back for delivering the business case, and then wondering why the Product itself never gets delivered.

A laptop with a document on next to a notebook and smartphone

In the last decade as the more agile methodologies and user centric ways of working have spread the traditional business case, and the role of those individuals who are focused on their development, has struggled to keep pace with the changes happening within the projects and programmes themselves.

The traditional method of drafting business cases that map out your road map and spend in full are now antiquated, and holding back teams from delivering. New business cases need to instead focus on agreeing design principles and the problem the business is trying to fix rather than bottoming out the minutiae of the roadmap. On explaining the assumptions that have helped define the scope of the Product or programme, which can be backed up by evidence , this is worth more than a cost estimate hammered down to the pounds and pence.

Before doing Product evaluations it is vitally important to ensure all senior stakeholders agree on the assumptions the team is working too (regarding the scope, business needs, user needs etc.) And these are the things new business cases should be focused on, not jumping straight to a solution based on product comparisons that have been carried out before everyone has agreed what is in scope.

One anecdote in particular has always stuck with me, in terms of why it’s important to agree your scope, before you start comparing products.

A few years ago, back when I was working with the Office of the Public Guardian on their CRM replacement, the team at the time did some research and analysis into the best options for the business and whether they should be looking to build, buy or configure a new system.

As the business wanted to be a digital be default exemplar, there was an early assumption that the new system would only need to ingest data received via digital channels, or call data for the minimal cases that couldn’t be dealt with digitally. This led to some early product comparisons being done, into Products that would meet the business’ requirements.

However, some research and conversations with legal SMEs during the Discover period highlighted that, as the OPG had responsibilities as a safeguarding body, they needed to be able to accept and analyse data received via any source. Which meant they actually needed a system that could ingest and understand faxed data, call data, digital data and handwritten data. The ability to ingest and assign meta data to handwritten data meant some products that had actually been in consideration now had to be ruled out.

Thankfully the business case for the CRM system had been developed with enough flexibility and empowerment and trust within the programme team, that this did not dramatically slow down or derail the team in terms of delivery as they were still working within the agreed scope and cost envelope, but the Product Comparisons had to be reconsidered and the scope and cost estimates changed accordingly.

While this was a relatively small example, it highlights the importance of validating scope assumptions before pinning down your business case.

Many organisations embracing Digital and agile ways of working have struggled with how they can fit the need for traditional governance structures, and especially the business case, into the culture and ways of working that Digital brings with it. My honest opinion is that you can’t.   

Instead, there has been a movement in some areas, led by the likes of GDS and MoJ which I have been apart of and leading conversations along with others on for some years, to change the role and format of the Business case. To encourage the business case itself to be developed and iterated alongside the Product and Programme it supports. This approach to iterate the business case alongside the agile Project lifecycle was first laid out by GDS back in 2014 for digital transformation programmes. The Institute for Government did a report back in October 2018 on how business cases were used, and what could be improved to enable better delivery.

Rather than a business case written almost in isolation by a Programme Manager before going round and round for comments, there is value in treating your business case like any other output from the a multidisciplinary team.  

A blank notebook next to a laptop

Instead of a 25+ page tome that aims to spell everything out upfront, before the project even commences properly, there is much more value in simply having a couple of pages explaining the problem the project is seeking to fix and why, along with estimated timing and costs for some exploratory work to define key assumptions and answer key questions (like what happens if we don’t fix this? How many people will it effect? Are there any legal requirements we need to be aware of?) that will help your project start on the right foot.

Once you can answer those questions, then you can iterate the business case; taking a stab at estimating how you think you might going about fixing the problem(s), how long it will take to fix the important key problem(s) you identified need fixing first, are there any products out there in the market that could do this for you? How much might this roughly cost?

You can then iterate the business case again once you’ve started developing the Product or implementing the identified solution. Once you have validated the assumptions you’ve made previously about the solution to the problem you’re fixing.

This means the business case is a living document, kept up to date with the costs and timetable you’re working to. It means your board are able to much more accurately assuage their accountabilities, ensuring costs are being spent in line with the scope of the programme or project.

Empty chairs around a table

Whatever methodology you are using, the importance of being able to explain why you are doing something, and what the problem you are trying to fix is, before leaping into what software product is the solution to buy and how much it’ll cost you. If it’s done right, the business case helps you evidence you are doing the right thing and spending money in the right way.

Delivering Digital Government 2019

This week Claire Harrison (Head of Architecture from CQC) and I had the opportunity to attend the Delivering Digital Goverment event run by Worth Systems in The Hague.

The event was focused on how digital has transformed governments across the world, sharing best practices and lessons learned. With speakers from the founding of GDS, like Lord Maude, as well as speakers from the Netherlands, and it was a great opportunity to meet others working on solving problems for users in the Government space wider than the UK.

A lot of the talks, especially by the GDS alum were things I had heard before, but I actually found that reassuring, that over 5 years later I am still doing the right things, and approaching problems in the right way.

It was especially interesting to hear from both Lord Maude, and others, about the work they have been doing with foreign governments, for example in Canada, Peru and Hawaii. The map Andrew Greenway, previous of GDS now from Public Digital, shared of the digital government movement was fantastic to see, and really made me realise how big what we are trying to achieve around the world really is.

@ad_greenway sharing a map of the Digtial Government transformations happening around the world

The talks from some of the Dutch speakers were really interesting. I loved hearing about the approach the council in The Hague are taking to digital innovations, and their soon to be published digital strategy. One of the pilots the city are running in particular intrigued me; in an effort to reduce traffic, they put sensors onto parking spaces in key shopping streets and all disabled parking bays in the city. This gave them real time information on the use of the parking spaces, and where available spaces were and successfully decreased traffic from people driving around searching for spaces. They were now looking at how to scale the pilot an manage the infrastructure and senor data for a ‘smart’ city, working with local business to enable new services to be offered.

The draft digital strategy for the city of The Hague

We also heard about the work the Netherlands has been doing to pilot other innovative digital services, like a new service that allows residents in an area to submit planning ideas to improve their neighbourhoods, with the first trial receiving over 50 suggestions, of those 4 have been chosen to take forward. We heard about the support that was given to enable everyone to take part, and it was nice to hear about the 78 year old resident who’s suggestion came 5th.

It was also great to hear from the speaker from Matthij from Novum, a digital innovation lab in the Netherlands, who talked about his own personal journey into Digital transformation, learning from failures and ensuring that you prepare for failure from the start. He also told us about some fascinating research they have been doing into the use of smart speakers, especially with the elderly, to enable better engagement and use of government services to those that need assistive technologies.

An image of an older lady talking to an AI robot, courtesy of Novum

Realising that 30% of eligible claimants for the Dutch state pension supplement were not claiming it, they believed that this was potentially down to the complexity of the form. They hypothesised that smart speakers might be one way to solve this problem. However recognising that it was no good to make assumptions and design a solution for users without ensuring they had understood the problem their users were facing properly they did a small sample test with elderly users to see whether they could use smart speakers to check the date of their next pension payment (one of the largest contributors to inbound calls to the Sociale Verzekeringsbank), they found that not only could elderly users use the smart speakers, but that the introduction of smart speakers into their homes decreased loneliness dramatically.

There were other good sessions with James Stewart from GDS & Public Digtial on technology within digital, and an interesting panel session at the end. Every session was good, and I learnt something I heard something new at each one. My only grumble from the day was the lack of diversity in the speakers. Which the organises themselves put their hands up and admitted before they were called out on it. A quick call on twitter and the ever amazing Joanne Rewcaslte from DWP shared a list of amazing female speakers, so hopefully that will help with the next event.

One key thing I took away from the day is that the challenges are the same everyone, but the message is also the same, involve users from the start. In the practical steps everyone could start tomorrow, Matthij talked about ensuring you interview 5 end users, and some steps to simple prototypes you could develop to engage your users.

This slide from Lord Maude summed up three of the main things any organisations needs to succeed in delivering Digital Transformation

Lord Maude talked about the importance of a strong mandate, Novum talked about having a good understanding of the problem you are trying to fix at the start. The digital strategy from the Hague highlights the fact they want everyone to be able to participate and deliver a personal service to their citizens. As Andrew Greenaway said, they key thing is to “start with user needs”.

The other second key message from the day was that, as Lord Maude put it… “Just Do it!” A digital strategy delivers nothing, the strategy should be delivery, instead of spending months on developing a digital strategy, “you just have to start” by doing something, this in turn will help you develop your strategy once you understand the problems you are trying to solve, the people you will need, and the set up and way of doing things that works best in your organisation. This was a message reinforced by every speaker throughout the day.

@jystewart sharing a statement from Ivana Osores from Interbank… “You have to just start”

The third key message was the importance of good leadership, good teams and good people. Talk in the open about the failures you’ve made and what you have learned. Build strong multidisciplinary and diverse teams. As Andrew Greenway said, Start with teams, not apps or documents. In the round table discussion on building capability we spent a lot of time discussing the best ways to build capability, and the fact that in order to get good people and be able to keep them, and to go on to develop good things, you need strong leadership that is bought in to the culture you need to deliver.

I left the day with a number of good contacts, had some great conversations, and felt reinvigorated and reassured. Speaking to Worth I know they are aiming to run another event next year, with both an even more diverse international cohort and an equal number of female speakers, and I for one will definitely be signing up again for the next event.

Lord Maude, myself and Claire Harrison at the social gathering after the event

Service Standards for the whole service

How the service standards have evolved over time….

Gov.uk has recently published the new Service Standards for government and public sector agencies to use when developing public facing transactional services.

I’ve previously blogged about why the Service Standards are important in helping us develop services that meet user needs, as such I’ve been following their iteration with interest.

The service standards are a labour of love that have been changed and iterated a couple of time over the last 6 years. The initial digital by default service standard, developed in 2013 by the Government Digital Service, came fully into force in April 2014 for use by all transactional Digital Products being developed within Government; it was a list of 26 standards all Product teams had to meet to be able to deliver digital products to the public. The focus was on creating digital services so good that people preferred to use them, driving up digital completion rates and decreasing costs by moving to digital services. It included making plans for the phasing out of alternative channels and encouraged that any non-digital sections of the service should only be kept where legally required.

A number of fantastic products and services were developed during this time, leading the digital revolution in government, and vastly improving users experience of interacting government. However, these Products and Services were predominantly dubbed ‘shiny front ends’. They had to integrate with clunky back end services, and often featured drop out points from the digital service (like the need for wet signatures) that it was difficult to change. This meant the ‘cost per transaction’ was actually very difficult to calculate; and yet standard 23 insisted all services must publish their cost per transaction as one of the 4 minimum key performance indicators required for the performance platform.

The second iteration of the digital service standard was developed in 2015, it reduced the number of standards services had to meet to 18, and was intended to be more Service focused rather than Product focused, with standard number 10 giving some clarity on how to ‘test the service end to end’. It grouped the standards together into themes to help the flow of the service standard assessments, it also clarified and emphasised a number of the points to help teams develop services that met user needs. While standard 16 still specified you needed a plan for reducing you cost per transaction, it also advised you to calculate how cost effective your non transactional user journeys were and to include the ‘total cost’ which included things like printing, staff costs and fixtures and fittings.

However, as Service design as a methodology began to evolve, the standards were criticised for still being too focused on the digital element of the service. Standard 14 still stated that ‘everyone much be encourage to use the digital service’. There were also a lot of questions about how the non digital elements of a service could be assessed, and the feeling that the standards didn’t cover how large or complicated some services could be.

Paper and Digital

The newest version of the Service standard has been in development since 2017, a lot of thought and work has gone into the new standard, and a number of good blogs have been written about the process the team have gone through to update them. As a member of some of the early conversations and workshops about the new standards I’ve been eagerly awaiting their arrival.

While the standards still specifically focus on public facing transactional services, they have specially be designed for full end to end services, covering all channels users might use to engage with a service. There are now 14 standards, but the focus is now much wider than ‘Digital’ as is highlighted by the fact the word Digital has been removed from the title!

Standard number 2 highlights this new holistic focus, acknowledging the problems users face with fragmented services. Which is now complimented by Standard number 3 that specifics that you must provide a joined up experience that meets all user needs across all channels. While the requirement to measure your cost per transaction and digital take up is still there for central government departments, it’s no longer the focus, instead the focus of standard 10 is now on identifying metrics that will indicate how well the services is solving the problem it’s meant to solve.

For all the changes, one thing has remained the same thorough out, the first standard upon which the principles of transformation in the public sector are built; understand the needs of your users.

Apparently the new standards are being rolled out for Products and Services entering Discovery after the 30th of June 2019, and I for one I’m looking forward to using them.

Launch!

Scrum Master or Delivery Manager – what’s in a name?

Are the roles of Scrum Master and Delivery manager the same?

Continuing on my recent musings on the different roles within Agile multidisciplinary teams, today’s blog focuses on the role of the Delivery Manager, or the Scrum Master, and whether these roles are really the same thing.

This is a conversation that came up a few weeks ago at the #ProductPeople community meetup in Birmingham, and something that causes quite a bit of frustration from those people I’ve talked to in the Delivery Manager community.

The role of the Scrum Master is that of facilitator within the multidisciplinary team, it is a role particular to Scrum, and they are the ‘expert’ on how to make Scrum work, often described as a ‘Servant leader’ they help everyone in the team understand the theory and practices of Scrum as a way of working together.

Within digital government the role has been widened out to include other responsibilities, and often mixed with the role of the Delivery Manager. Emily Webber did a fantastic blog a few years ago on the role of the Delivery Manger, and as she put’s it, while the roles are often used interchangeably, they really shouldn’t be.

But why not? What makes them different?

As said above, the Scrum Master focuses on the ‘how’ of Scrum as a methodology. The are the expert in the room on how best to utilise Scrum to deliver. They are more akin to an agile coach, guiding the team, and often the person best versed on the most up to date practices and ways of working.

But for me, the Delivery Manager focuses more on the ‘What’ and ‘When’. While the Product Manager (or Owner) focuses on ‘Why’ the team are doing what they are doing, the problems they are trying to solve, the vision they are trying to deliver. The Delivery Manager is looking at what could block the team from being able to deliver; what the right make up of the team needs to be in terms of roles and capabilities, what governance processes does the team have to meet in order to stay on track to deliver, and when delivery will happen.

As the Digital Data and Technology capability framework says, at the most basic level the delivery manager is accountable for the delivery of products and services. They are very much a doer paired with the Product Managers visionary thinker. They make sure things actually happen. They hold the Product Manager and the team to account and keep them on track.

They are the heart of the team, responsible for maintaining the health and happiness of the team; they understand who from the team will be available and when, making sure people are able to work well together, identifying conflicts and ensuring the team stay motivated and happy in order to enable delivery.

When you look at the role as explained in the capability framework it looks very straight forward, build and motivate teams, manage risk s and issues, ensure delivery, ok great. But then you get to the bit that merges the scrum master tole and the delivery manager role, and this is where a lot of individuals I know within the team struggle, “coach team members and others, facilitate continuous improvement and apply the most appropriate agile and lean tools and techniques for their environment”.

This is actually quite a big task, to stay on top of the most appropriate agile and lean tools and techniques requires a lot of self learning; which is fantastic, but also requires quite a bit of time away form the team you are meant to be supporting.

Most Delivery Managers that I know (certainly within CQC, and others I have talked to across Government) are involved with (if not directly responsible for) the business cases for their Products and Services. Unblocking issues, ensuring funding requests, requesting resources, etc. this all takes up a lot of a Delivery Managers time. When you are also meant to be running the daily stand-ups, managing team retrospectives, monitoring team velocity and organising show and tells you can find your days are very full.

More and more delivery managers that I know are finding they just don’t have time for the ‘people centric’ part that is meant to be at the heart of their role, as Projects and Programmes utilise them more and more as project Managers who are also scrum masters, and so our Delivery managers feel pulled in two directions, and our teams suffer because of it.

When organisations so often find they are struggling to deliver, often at the heart of that is the issue that they have not properly recognised the role of the Delivery Manager. This is a fundamental issues, especially when organisations are new to agile ways of working. Embedding ‘how’ to be agile, takes up just as much time as understanding ‘what’ you can deliver and ‘when’.

Perhaps in mature agile organisations bringing those roles together makes more sense, but for now I think we need to go back to letting our Delivery Managers focus on making sure we can deliver, and our scrum masters helping us use the right techniques to be able to delivery well.

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.

What is the role of Business Analysts within agile?

Analysisng the role of the Business Analyst.

When we were looking at the Digital, Data and Technology (DDaT) roles and capabilities back in 2016, one of the roles we really struggled with was the role of the Business Analyst (BA).

Not because we didn’t agree that it was a role (because we absolutely did) but because we struggled to define the scope of the role in comparison to things like; Product Management, Design or User Research roles.

It’s one of the questions, that three years later still comes around regularly. Who is responsible for defining the requirements? What is the role of the BA?

Who holds the requirments?

The role of the BA in an agile team

One of the problems we had back when we were defining the BA role as part of the DDaT professions, was that the Government Digital Service didn’t have BA’s in their teams. Similarly, the original Scrum Manifesto only has 3 roles in an agile team, the product owner, development team members and scrum master.

Because traditionally, the BA acted as the link between the business units and IT, helping to discover the requirements and the solution to address them; when multidisciplinary teams bought those members together the role of the BA became less clear.

This has meant when adopting agile, different government departments implemented the role in slightly different ways. The biggest trap I have seen teams fall into was the BA getting stuck with all the admin roles for the project.

Roman Pilcher argued for those BA’s moving into Scrum there were two options, becoming the Product Owner, or becoming a ‘team member’.

While I agree that Business Analysts are a key member of a multidisciplinary team, I disagree with this assumption that everyone on an agile team who isn’t the scrum master or the PO is simply ‘a team member’ I think the Business Analyst is a critical role (especially for Product Managers!) that brings unique skills to the team.

So, first things first let’s look at what requirements are in the agile space.

Certainly, within digital government at least, we use a user centric design approach. We are developing products and services that fix the problems that our users are facing. We are identifying user needs and testing and iterating those throughout the product development lifecycle. A lot of the time this conversation about ‘user needs’ has replaced the more traditional conversations about ‘requirements’. Which is good in some ways, but has also led to a bit of confusion about what Business Analysts do if it’s not gathering requirements. Who owns the requirements now?

Are user researchers responsible for gathering the requirements from external users (user needs), whereas Business Analysts are responsible for gathering requirements based on what the business needs (sometimes called business user needs)?

That line of conversation worries me, because it suggests that we don’t need to carry out user research on internal staff, it forgets that internal staff are users too.

So, what is the role of the BA?

In my experience the conversation about who is responsible for gathering requirements is symptamatic of the limitations of the English language, and our obsession with ‘ownership’.

User researchers primarily focus on gathering more qualitative data; why users behave the way they do, how things are making them feel; probing their views and opinions to understand what it is they actually need etc. They will help understand who they users are and verify what the users need. They will work with the team to test design assumptions and help ensure the options being developed meet user needs.

Business Analysis primarily focus on gathering the more quantitative data about the process; both the ‘as is’ process, and the future process we are designing. They work to understand how many users are being or will be affected? What are the cost/time impacts of the problem as identified? What value could be gained through the implementation of any of the options the team are considering?

They help identify the stakeholders that will need to be engaged, and how to best engage with them. They will turn the user needs into user stories that the team can develop and identify the metrics and success criteria for the team to help them measure value.

Where you have a Product or Service that is live and being used by real users, the BA will work with Performance Analysts to understand the feedback data coming from the users.

User Researchers and Business Analysts will often work closely together, while BA’s will use tools like process mapping to identify pain points, user researchers will work with them to map the emotions users are experiencing so that we can fully understand the impact of our current processes and the value we can release by fixing the problem. When User Researchers are planning in research sessions etc., they will often work with BA’s to get the data on where best to test in terms of locations or user groups.

Good Product Managers will use both the Quantitative and Qualitative data to help them pick which options to test. Designers will help both the user researchers and business analysts look at the data and design prototypes etc. to test with users.

For me, each role is clear in its scope, and their need to work together to identify the right problems users are facing and the best way to test those; and it’s not about what individual owns the requirements, because the answer is the team do.

Round and round we go.

In other words Agile isn’t linear so stop making it look like it is.

Most people within the public sector who work in Digital transformation have seen the GDS version of the Alpha lifecycle:

Which aims to demonstrate that developing services starts with user needs, and that projects will move from Discovery to Live, with iterations at each stage of the lifecycle.

The problem with this image of Agile is that it still makes the development of Products and Services seem linear, which it very rarely is. Most Products and Services I know, certainly the big complex ones, will need several cracks at a Discovery. They move into Alpha and then back to Discovery. They may get to Beta, stop and then start again. The more we move to a Service Design mentality, and approach problems holistically, the more complex we realise they are, and this means developing Products and Services that meet user needs is very rarely as simple and straightforward as the GDS Lifecycle makes it appear.

And this is fine, one of the core principles of Agile is failing fast. Stopping things rather than carrying on regardless. We iterate our Products and Services because we realise there is more to learn. More to Discover.

The problem is, especially in organisations new to Agile and the GDS way of working, they see the above image, and its more linear portrayal seems familiar and understandable to them, because they are generally user to Waterfall projects which are linear. So when something doesn’t move from Alpha to Beta, when it needs to go back into Discovery they see that as a failure of the team, of the Project. Sometimes it is, but more not always, sometimes the team have done exactly what they were meant to do, they realised the problem identified at the start wasn’t the right problem to fix because they have tested assumptions and learned from their research. This is what we want them to do.

The second problem with the image put forward in the GDS lifecycle is that it doesn’t demonstrate how additional features are added. The principle of Agile is getting the smallest usable bit of your Product or Service out and being used by users as soon as you can, the minimum viable product (MVP), and this is right. But once you have your MVP live what then? The Service Manual talks about keeping iterating in Live, but if your Product or Service is large or complex, then your MVP might just be for one of your user groups, and now you need to develop the rest. So what do you do? Do you go back into Discovery for the next user segment (ideally, if you need to yes), but the GDS lifecycle doesn’t show that.

As such, again for those organisations new to Agile, they don’t’ factor that in to their business cases, it’s not within the expectations of the stakeholders, and this is where Projects end up with bloated scopes and get stuck forever in Discovery or Alpha because the Project is too big to deliver.

With Public Services being developed to the Digital Service Standards set by GDS, we need a version of the lifecycle that breaks that linear mindset and helps everyone understand that within an Ariel project you will go around and around the lifecycle and back and forwards several times before you are done.

Agile is not a sprint, a race, or a marathon, it’s a game of snakes and ladders. You can get off, go back to the start or go back a phase or two if you need to. You win when all your user needs are met, but as user needs can change over time, you have to keep your eye on the board, and you only really stop playing once you decommission your Product or Service!