×

Tag: value

How to be a Product Advocate

Why you need a Product Person in your team.

Since joining Kainos a few weeks ago, I’ve had a number of conversations internally and with clients about the relationship between Delivery and Product; and why I as a Product Person moved over to Delivery.

‘Products at the heart of delivery’ image

My answer to that question was that, having spent over 10 years as a Product Person, and seeing the growth of Product as a ‘thing’ within the Public Sector; helping Product grow and mature, developing the community, ways of working, career pathway etc; I realised that what was missing was Product thinking at a senior level. Most Senior leaders within the Programme delivery or Transformation space come from a traditional delivery background (if not an operational one) and while many of them do now understand the value of user centric design and user needs etc; they don’t understand the benefit of a product centric approach or what value Product thinking brings.

The expansion of Product people in the Public sector has predominantly been driven by GDS and the Digital Service standards; with most organisations now knowing they need a ‘Product Manger‘ in order to pass their Service Standard Assessment. However, almost 10 years later, most organisations are still not prioritising the hiring and capability development of their Product people. In May I worked with four different teams each working to the Digital Standards and needing to pass an assessment; and in none of those teams was the role of the Product manger working in the way we intended when we creating the DDaT Product Management capability framework.

Most organisations (understandably) feel the role of the Product Manager should be an internal one, rather than one provided by a Supplier; but 9 times out of 10 the person they have allocated to the role has no experience in the role, have never worked on a product or service that was developed to the digital standards never mind having been through an assessment; and they are regularly not budgeted or allocated the project full time; often being split across too many teams or split between the Product Manager role whilst still working in Ops or Policy or whoever they have come from previously; more often than not their actually a Subject Matter Expert, not a Product Manager (which I’ve blogged about before).

As a supplier; this makes delivery so much harder. When the right Product person isn’t allocated to a project, we can quickly see a whole crop of issues emerge.

So what are the signs that Product isn’t being properly represented within a team:

  • Overall vision and strategy are unclear or not shared widely; teams aren’t clear on what they’re trying to achieve or why; this can be because the Product person is not able to clearly articulate the problem the team are there to solve or the outcomes that team are their to deliver aren’t clearly defined.
  • Roadmap doesn’t exist, is unstable or does not go beyond immediate future/ or the Scope of the project keeps expanding; often a sign that prioritisation isn’t being looked at regularly or is happening behind closed doors making planning hard to do.
  • Success measures are unclear or undefined; because the team doesn’t understand what they’re trying to achieve and often leads to the wrong work getting prioritised or outcomes not getting delivered or user needs not met.
  • Work regularly comes in over budget or doesn’t meet the business case; or the team keeps completing Discoveries and then going back to the start or struggling to get funding to progress. This can be a sign the team aren’t clear what problem they are trying to solve or that the value that the work delivers cannot be/ isn’t clearly articulated by the Product person.
  • Delivery is late/ velocity is slow. This can be a sign the team aren’t getting access to their Product person in a timely manner causing bottlenecks in stories being agreed or signed off; or that the Product person is not empowered to make decisions and is constantly waiting for sign off from more senior stakeholders.
  • Role out is delayed or messy, with operational teams frustrated or unclear on project progress; a sign that the team doesn’t have someone owning the roadmap who understands what functionality will be available when and ensuring any dependancies are clearly understand and being monitored, or a sign that there isn’t someone engaging with or communicating progress to wider stakeholders.

More often than not as a Supplier I’ve had to argue that we need to provide a Product person to work alongside/ with teams to coach/support their internal Product people in the skills and responsibilities a Product person needs to have to enable successful delivery. Where clients have been adamant they don’t want Product people from a Supplier (often for budgetary reasons), we’ve then had to look at how we sneak someone in the door; usually by adding a Business Analyst or delivery manager to the team who also has Product skills, because otherwise are ability to deliver will be negatively impacted.

When budgets are tight, the role of Product person is often the first thing project managers try to cut or reduce; prioritising the technical or project delivery skills over Product ones. As such, teams (and organisations) need to understand the skills a good product person brings; and the cost of not having someone within a team who has those skills.

  • Their role is to focus on and clarify to the team (and business) the problem the team are trying to fix.
  • Ensure a balance between user needs; business requirements and technical constraints/options.
  • Quantifying and understanding the ROI/ value a project will deliver; and ensuring that can be tracked and measured through clear success measures and metrics.
  • Being able to translate complex problems into roadmaps for delivery. Prioritising work and controlling the scope of a product or service to ensure it can be delivered in a timely and cost effective manner, with a proper role out plan that can be clearly communicated to the wider organisation.

As an assessor, I have seen more projects fail their assessments at Alpha (or even occasionally Beta) because they lack that clear understanding of the problem there trying to solve or their success measures etc; than I have because they’ve used the wrong technical stack etc. This can be very costly; and often means undress of thousands (if not millions) of pounds being written off or wasted due to delays and rework. Much more costly than investing in having a properly qualified or experienced Product people working within teams.

While Product and Delivery are often seen as very different skill sets; I recognised a few years ago the value in having more people who understand and can advocate for both the value Product thinking brings to delivery; but also how delivery can work better with Product. People who can not only understand but also champion both in order to ensure we’re delivering the right things in the right ways to meet our clients and their users needs.

Which is why I made the active decision to hop the fence and try and bring the professions closer together and build understanding in both teams and senior leaders in the need for Product and Delivery skills to be invested in and present within teams in order to support and enable good delivery, and I as really glad to see when I joined Kainos that we’re already talking about how to bring our Product and Delivery communities closer together and act for advocates to support each other; and it was in fact a chat with the Kainos Head of Product Charlene McDonald that inspired this blog.

Having someone with the title of Product Manager or Owner isn’t enough; we need people who are experienced in Product thinking and skilled in Product Management; but that isn’t all we need. We need to stop seeing the role of Product person as an important label needed you can give to anyone in the team in order to pass an assessment and understand why the role and the skills it brings are important. We need senior leaders, project managers and delivery teams who understand what value Product brings; who understand why product is important and what it could cost the team and their organisation if those product skills are not included and budgeted for properly right from the start. We need Senior Leaders to understand why it’s important to invest in their product people; giving them the time and support they need to do their job properly; rather than spreading them thin across teams with minimal training or empowerment.

We need more Product advocates.

Delivering Value for yourself and others

Just short of two years ago I accepted the role of Director of Delivery at Difrent, a big move for me as I’d only worked in the Public Sector, but a good opportunity to see how things worked on the other side of the commercial table; and a great opportunity to work with some fantastic people (Honestly, Rach Murphy herself is a powerhouse who can teach the world a thing or two and always worth making time for) outside of the public sector, and learn new skills.

The services we were delivering at Difrent we’re very similar to those I’d been working on before, and I worked with many familiar faces; but still the challenges were new. Working at a start up that was beginning to scale up was a very different environment to working in a large established Government Department. Not just delivering great services that meet user needs, but also building up business processes; scaling up teams; winning new business.

And then there was the pandemic.

Because of it’s strong background in Health, Difrent was on the front line when it came to stepping up and supporting the COVID-19 response working with the NHSBSA; NHSX and DHSC. I always thought that my time on Universal Credit was the most fast pacing and demanding time of my life; which it turns out was nothing compared to being asked to stand up 6 teams of experts within 72 hours at the start of the first wave to support various urgent pandemic related services.

Alongside supporting and delivering high priority COVID-19 related services in unprecedented timescales (we successfully helped delivery of the Home Testing service in under a month) we also had to keep delivering our existing products and services; helping Skills for Care go Live with their Adult Workforce Data Set service, continuing delivery of NHS Jobs, helping the Planning Inspectorate pass their Beta Assessment for their Appeals service and delivering the wholesale business transformation for the British Psychological Society; whilst also picking up and delivering a whole host of other projects and services that we continued to win.

Because of the pandemic, a lot of new teams were beginning to work with Digital Service Standards, and having to go through Service Standard Assessments for the first time; and an increasing amount of my time began being demanded by clients to support them understand and adhere to the service standards. I’ve always joked about my perfect record for passing Assessments (while being clear, that not passing the first time isn’t failure, it just means you have more to learn!) working with one client to turn around their service in under 3 weeks from complete un-adherence to the standards to passing a Beta assessment has got to be a personal best!

The last year has been full on, with long weeks and even longer days. I’m so proud of everything DIfrent has achieved in the last 18 months; but I also recognised the time is right for me to move on and focus more on the bits of my role I am most passionate about.

And what is that? Being hands on and working with clients to solve problems. Having the time to work with teams to understand the issues they’re facing and how to go about fixing them. Seeing the positive changes being made and thinking of ways to keep iterating and improving on what we’ve done. Investing in and building that cultural and organisation change up over time. Whilst at the same time having a proper work life balance again; having time to give attention to my family and friends; rediscovering the things I enjoy doing outside of work and having time and energy to do them. As lockdown begins to end, it’s time for me to have a new start.

And so, from next week I’m moving on to work with Kainos, I’m really excited about this new opportunity. Going into a larger organisation means there will be more peers to share that load; bigger problems to solve for clients, bigger teams to work with, all with the benefit of the organisational processes etc in place already that we will need to deliver large projects; which will allow me to focus on working with clients fully and ensuring I’m delivering real value to them, and getting real value myself from my work.

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.

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.