Three reflections on ten years in charity product management

I’ve been doing product management in the charity sector for ten years. So, as I leave the sector, I thought I’d reflect on that time. I’ve been lucky enough to work on products that changed lives, made millions of pounds, and that failed. I met amazing people, and I hope I helped a few of them. I definitely learned from them. And I certainly had a lot of fun along the way.

When I started working in charities, I worked on ecommerce products. It was a great introduction to managing products because I had a lot of responsibility for making the business successful. I didn’t only manage the ecommerce website, I did market research, sourced merchandise, answered customer service queries, recruited new team members, managed the relationship with the warehouse, and liaised with the marketing team. I had responsibility for the end-to-end value stream. I was lucky to be given the autonomy many charity product managers dream of.

Since then I’ve worked on all kinds of products; websites, customer service and logistics, fundraising, health behaviour change, volunteering, chatbots, and learning products. Looking back at these different products at different charities, I can see some of the same patterns occurring.

No one knows what product managers do

Even product managers struggle to explain what they do, so it’s understandable that others aren’t clear. This lack definition is good and bad. It can allow for flexibility in the role to meet organisational needs but often means products don’t get managed as well as they could.

To be effective in charities, product managers have to be the ultimate generalists. It isn’t enough to know agile methodologies and how to write requirements for developers. PMs have to know about laws and regulations, psychology and behaviour change, charity finance, design, commercial and fundraising, finance and budgeting, marketing, software testing and release management, delivery management, leading teams, user research, market analysis, supplier relationship management, strategy, security, data protection, and most importantly developing internet-era business models. They need to know about all these things to work with the experts in those areas, and to fill the gap if there’s no expert available. That’s the good thing about not having a single clear definition that is applied consistently across all charities. It’s good for charities because they can hire someone with the skills they need. And it’s good for product managers because they can work on all kinds of different products and develop a broad set of skills.

I’ve seen leaders, who feel responsibility for a product, acting as product managers. They make the strategic decisions (often without the rigor a PM would bring) and tell others what to build. This is the bad thing about the lack of definition. It makes the role of the actual product manager too much about implementing technology to achieve someone else’s vision and strategy, just because that’s one of their skill sets that no one else on the team has. This is the usual issue of product managers working as project managers or tech support. If leaders understood what product managers can bring and how to work more collaboratively with them to set goals, explore problems and define solutions, the charity would get better products which achieve better outcomes and more impact.

Too much looking inward

Connected to no one knowing what product managers do, is product managers focusing too much on process within the organisation. When we do this (and I’ve done plenty of it myself), we set ourselves up as being internal-facing rather than focused on the people we’re trying to help and what the change we create could look like.

It’s hard to claim PMs can bring more value if we aren’t doing the things that bring that value. It’s hard to help others understand how technology at scale can create change or what internet-era business models for a charity could look like if we spend too much time on low value activities like what the roadmap should look like or what prioritisation framework should we use.

In more mature product organisations, the ‘product trio’ of product manager, tech and ux/design is a good way to structure a team. In less product-oriented organisations like charities, I think the duo of product and delivery works better. Product management focuses on outward looking things like market analysis, user adoption, etc., and delivery management focuses on internal things like helping the team work better together, stakeholder involvement, etc.

When product managers aren’t spending their time on internal facing activities, they can bring the value of looking outwards. More experiments. More speaking to users. More understanding the wider context and the forces that affect the people with the problems you’re trying to tackle. More developing internet-era business models. More focus on outcomes and impact.

Wicked problem solvers

Charities tackle wicked problems. But they haven’t yet figured out how to use technology to tackle them. We know from numerous examples in the commercial sector that tech at scale can have a profound effect on our society. But charities haven’t realised they can too, so instead they rely on the tried and tested methods of campaigning and advocacy to create change.

This means that charities tend to look at digital products as merely more modern ways of doing what they’ve always done. Things like taking donations, applying for jobs or volunteering opportunities, communicating, etc., can be done using technology, and so charities focus their product managers on these. This means product managers act as a conduit between stakeholders and developers, collecting requirements and project managing changes to the systems. Marty Cagan wrote about this ‘IT mindset’ back in 2014 (when I was getting started) and it’s still mostly true in charities in 2024.

But product managers and digital technologies have so much more to offer. Figuring out how to use tech and data in responsible ways to intervene in complex social systems to create intentional change is a far better use of the product manager’s skill set and mindset. If Uber can use technology to change how we travel and Spotify can change how we listen to music, then charities can use technology to make the world a better place.

What I hope the next ten years looks like

I firmly believe technology has the potential to create change at scale for all kinds of wicked problems affecting the world, and I hope charities embrace the opportunities it provides. And I hope product managers are instrumental in helping charities understand this opportunity and make the most of it. To do so, the value product managers bring will need better definition, product managers will have to develop their outward-facing knowledge and skills, and charities will have to explore and experiment ways of using technology.

How long does work take?

Screenshot of LinkedIn Poll showing that 72% of respondents think doing four hours of work over four weeks means the work takes four weeks, not four hours.

72% of respondents to my LinkedIn poll think that if I do four hours of work over four weeks, then the work takes four weeks, not four hours.

Of course, both are true. It just depends on what you mean when you say “work”. And that’s what makes talking about deadlines and estimates and the time work takes so difficult.

But, is it ever possible to talk about work, and delivery, and value without also talking about time?

What’s in my bag

As part of my goal of being even more minimalist this year, I’m going to try to live out of two 35 litre bags.


  • Hat – Warm hat
  • Shell jacket
  • Down jacket
  • Waterproof jacket
  • Fleece jacket
  • Shirt x3
  • T-shirt x3
  • Jean x3
  • Shorts x3
  • Socks x3
  • Trainers
  • Belt

Ditch pack

  • Passport
  • Bank card
  • Driving licence
  • Cash
  • Hard drive
  • Spare car key

Wash kit

  • Tooth brush
  • Tooth paste
  • Towel
  • Flannel
  • Shower gel
  • Nail clippers
  • Deordorant
  • Moisturiser
  • Hair trimmer
  • Scissors


  • Work laptop
  • Work laptop charger
  • Surface laptop
  • Surface charger
  • Phone
  • USB to USB-C cable
  • USB-C to USB-C cable
  • Kindle
  • Backup phone
  • Wall plug
  • Battery pack
  • Wired earphones


  • Glasses x2
  • Sunglasses
  • Swiss army knife
  • Car keys
  • Window tool
  • Pen
  • Notebook
  • Headtorch

What does team capacity even mean anyway?

We pretty much agree it’s not right to refer to people as resources (or at least we should). It’s disrespectful and dehumanising. It smacks of an outdated industrial mindset where people were thought of as interchangeable cogs in the machine, easily replaced by the next person in line.

So, in avoiding that problematic term, we seem to have replaced in with the term ‘capacity’. What does that mean? Is it just a different term for the same kind of thinking or is it something different?

When we say ‘capacity’, we often mean it as short-hand for ‘who does what work when’. If we take the definition of capacity as ‘the maximum amount something can contain’, then when we say, “the team is at full capacity this month”, we mean that a group of people (who) are already doing all the work they can in the time they have available. We think of the ‘who’ and the ‘what’ as fixed (throwback from the industrial mindset) and the ‘when’ as the variable. “The team might have more capacity next month”, means we expect them to have more time next month and the work they couldn’t fit in this month will have to wait till then.

But in modern digital work all those things are variable. Not just when, but who and what too.

Who might be on the cross-functional team could change, but also what skills, knowledge, time, processes and environments the people might have could also change. These things vary depending on the work. A developer using a new language and unfamiliar systems to what they are highly-skilled in will take longer.

What the work involves also changes. Understanding the work, doing the work of figuring out how to do the work, realising the problem the team thought they were tackling turns out not to be the real problem, doing the work of coordinating the work. It all has to be done. And it all changes with each new piece of work. Even the same work changes as a team gets more practiced at doing it.

What gets in the way of the work also deserves a special mention. Teams doing one piece of work that takes four days or four pieces of work that take a day each is taking the same amount of time, but in latter the work-in-progress is much higher. That’s four times the coordination required, four times the dependencies, four times the context switching, four times the amount of knowledge people have to keep in their heads. Not having the right tools or systems necessary for the work also gets in the way.

To help us understand these variables we can think about them on a sliding scale.

  • What – the type of work ranges from delivering known, fixed, repeatable outputs… to… achieving uncertain, novel outcomes.
  • What gets in the way – the amount of work-in-progress ranges from low, where the team can focus on one piece of work at a time… to… high, where the team has lots of distracting priorities.
  • Who – the people on the team range from highly-skilled, knowledgeable, have the right processes in place, etc., for the type of work … to… learning (either because they are inexperienced and haven’t developed yet or because the type of work is uncertain and new to them), setting things up, improving practices and processes.

The more we’re on the right of the scales, the more impossible it is to estimate team capacity, and in fact, the more meaningless the term becomes. We should accept that.

When we have conversations about team capacity, it’s useful for us to be clear about why we’re having those conversations, what question are we really asking. Sometimes, when we ask, “how much capacity does the team have next month”, we’re really asking, “can the team do x work next month”. That changes it from a capacity conversation to a prioritisation conversation (which isn’t necessarily any easier, but there you go).

But where this becomes really useful is in changing the conversation from ‘capacity’ to ‘ability’, from how much can the team do, to how do we help them be more able to do different things better. How do we help team’s improve on their ability to achieve uncertain or novel outcomes, to drive down their work-in-progress limit, to learn new things, to work at a sustainable pace?

We’ve gone from harmful assumptions about resource utilisation, to understanding how the variability of digital work makes capacity a meaningless term, to talking about improving a team’s ability to do good work. This is where the impactful value is for teams, leaders and organisations, not in making sure everyone is always busy or in guessing when a piece of work will be done, but continually improving team ability.

Which dates matter

Within product teams and for leaders, which date matters tells us whether the focus is on outputs or outcomes.

If when a piece of work is available to users is the date that matters, then we’re focusing on outputs.

If when we have enough data to know if the work has achieved what we wanted is the date that matters, then we’re focusing on outcomes.

If all you have is a hammer

I’m not sure about the saying, “If all you have is a hammer, everything looks like a nail”.

Even if you only have a hammer you still recognise the difference between a nail, a screw and a bolt. You know you can use your hammer pretty effectively on nails. You know using it on screws is going to be messy but might kind of work. And you know your hammer definitely isn’t going to work on bolts.

So, only having a hammer limits the problems you choose to tackle, it doesn’t mean you tackle them all in the same way.

Maybe the saying should be, “If all you have is a hammer, go find the nails that need knocking in”.

100 days of task tracking

The background

For 100 days, starting on the 1 August, I recorded every task I did in a spreadsheet. I set up the spreadsheet to count how many tasks I completed a day, which project they were for, and which of my four objectives they contributed to. All I had to do was make a note of what I did in the right cell.

I wanted to learn what I actually spend my time on. Most task management is about forward planning, and most task management systems are really bad at showing how you’re actually performing. They can only show you the tasks you had the foresight to add ahead of doing them. And whilst humans are really bad at predicting the future, spreadsheets are pretty good at tracking the reality of completed tasks.

How many tasks

Over those 100 days, I completed 1124 tasks, which averages 11.24 tasks a day.

Graph showing the number of tasks completed over 100 days.

On my least productive day I completed 2 tasks (I was on leave that day), and on my three most productive days I completed 21 tasks. On 35 days out of the 100 I completed 10, 11 or 12 tasks, which is right around the average.

Graph showing the distribution of tasks completed per day.

Mondays and Tuesdays were my most productive days with 22% of tasks completed on each of those days. 20% of tasks were completed on Wednesdays, 19% on Thursday and 17% on Fridays.

How those tasks contributed to my objectives

I have four long-running objectives that align to the purpose of my role:

  • Objective 1 had 251 (22%) tasks. This objective is about team performance and the number of tasks increased considerably for over half of the 100, but that provides an interesting comparison with the rest of the days.
  • Objective 2 had 519 (46%) tasks. This is the most obviously role-aligned objective as it’s about managing our products, so it makes sense that it has the most tasks.
  • Objective 3 had 91 (8%) tasks. This objective is long-term and organisationally-focused, so it’s the one that drops when I’m busy with the others.
  • Objective 4 had 92 (8%) tasks. This task is operational, so although there aren’t many, there is a steady stream and they have to be done fairly promptly.

I also did 171 admin, or non-objective contributing tasks, which was 15% of the tasks completed. This feels broadly right. 15% of my tasks were finance, non-project related planning, reporting, etc. If it was 15% of my time it would three quarters of a day a week, but I don’t think it’s quite that much time.

Chart showing the number of tasks completed each most from August to December 2023.

What this system doesn’t do

There’s a lot it doesn’t do, but it is pretty good at what it does. It doesn’t:

  • track how much time is spent on a task. It doesn’t matter whether a task takes two minutes or two hours, it’s counted as one task.
  • consider whether they are the right tasks. Whether the task is urgent, important, or neither. Whether it unblocks others (possibly the highest impact type of task), or is some mundane admin task (although I hope I’m pretty good at avoiding these), it’s counted as one task.
  • differentiate between planned and unplanned tasks. But that’s a fuzzy, and probably unhelpful, distinction anyway. How planned does a task have to be to be considered planned? If you know you have to do a task but you don’t know when you’ll be doing it, is it planned or unplanned?

Whether a task is planned or unplanned doesn’t seem important. Learning whether I’m doing the right tasks, and spending the right amount of time on them, does seem useful, although I’m not sure how it would affect my decisions about what to work on.

Things I tried and failed to do

I tried to make the system work more as a planner, but it hasn’t worked yet. I tried:

  • setting monthly goals that aligned with my four objectives. I never came close to achieving them. A month is too long a time period to predict
  • setting (and am still setting) weekly goals that align with projects I’m working on. At the beginning of the week, I usually set between 3 and 5 goals and then at the end, give myself a percentage of how close I came to the goal. Across all the weeks so far, my total completion percentage is 43%. That also represents how successful I think weekly goals are. They are better than monthly goals, but they serve more as reminders of thigs to get done than as actual goals.
  • using what I completed last week to help me plan this week. I couldn’t find any helpful insight as so many other factors changed from one week to the next.

What I learned

Having the data is better than not having it. Without it, you’re just guessing at what you spend your time doing and how it contributes to goals and objectives. I’m definitely going to carry on tracking my tasks.

Recording what you actually did is far more helpful for understanding your work and how it contributes to your objectives than “planning” (AKA guessing) what you’d like to do in the future.

Medium and long term goals are better thought of as reminders rather than actual goals (especially given the point about not yet having a means of telling whether they are the right goals).

Shorter time periods are better. Planning day-by-day, I can get close to predicting what I’ll actually achieve, especially as I have historic data which tells me how many tasks I completed on similar days. Planning on a weekly basis yields less than half of the accuracy you’d expect. Monthly planning was more fantasy than fact. I can’t even imagine how planning quarterly or annually could be at all useful.

Other posts:

Digital at RNID

RNID is a digital-first charity. That means a few different things.

It means that our products and services are developed in digital ways first and only become physical when digital doesn’t work, so for example our RNID near you service which helps people fix their hearing aids. You can’t do that kind of thing online. But products like the hearing check are entirely online. This is how more than three hundred thousand people have checked their hearing and lots of those who found out they have hearing loss have gone on to get hearing aids. That kind of impact at scale would be really hard to achieve off-line.

It means we all use digital technology in our work. RNID has over two hundred different technology systems. We have more technologies than we have people. I think that shows how digital-first we are as a charity.

And it means we think and work in modern, digital ways. Ewen Stevenson, our chair of trustees, talks about how we can use technology to connect with millions of people. Digital isn’t just about websites, it’s about RNID’s entire business model for how we use digital technology to have impact at scale. If Uber can use digital to change how we travel, and Spotify to change how we listen to music, then RNID can use digital to change society for people who are deaf, have hearing loss or tinnitus.

Who we are

There are eleven of us in the Digital team at the moment. We’re made up of four specialities:

Delivery – Help the whole of RNID figure out better ways of working and how we deliver value to our communities in impactful and agile ways.

Design – Includes service design, interaction design and content design. Use collaborative, user-centred thinking, to design products and services with subject matter experts from across RNID.

IT & data – Do the complicated technical work to make sure our systems and technologies are working.

Product – Develop and manage our suite of products, including things like the website and hearing check.

What we do

Deliver technical projects, like CRM systems, and essential business systems.

Develop new products, like the Hearing Loops Map which lets people update Google Maps about where hearing loops are installed.

Improve existing services, like creating a self-serve option for people looking for information so the Contact Centre can focus on supporting people that really need their help.

Support teams all across RNID with things like analytics and digital skills.

How we do it

Matrix – We work in matrix teams. That means we bring together skills and expertise from across RNID to work on all kinds problems. The hearing check team, for example, has a programme lead with experience of behaviour change, a content designer, web developer, interaction designer and product manager. We all work together, bringing our different perspectives and skills, to make the hearing the best it can be.

User-centred – We do lots of research to figure what the people who will be using the products and services ned from them.

Sprints – We generally work in fixed time-boxes of a week, fortnight or month. This helps us focus on the work that brings the most value for our communities the soonest.

Feedback and continuous improvement – We get lots of feedback on how people are using RNID’s products and services. This includes user interviews, satisfaction surveys and usage analytics. We use all of this to make sure we’re improving the products and services in ways that matter to our communities.

How I use my task tracker to know if I’m achieving my objectives

I previous wrote about my system for tracking work and checking where I’m focusing. Like all good systems, it is constantly evolving. Most task management system expect the user to predict when they’ll do a task, but this one tracks what I actually did and gives me the data to figure out if I’m doing the right things.

Connecting daily tasks to long-standing objectives

I have four long-standing objectives, ongoing outcomes that will never be achieved but which guide what I work on. They used to seem a bit vague as I had no way of connecting them to the work I do.

I grouped all the things I work on under each of the four objectives to make it easier to count tasks for each objective. It only one that doesn’t fit is Admin tasks. These are about 10% of the things I do, which means 90% of my work contributes to my objectives.

Task tracker dashboard showing how many tasks were completed on each day between the beginning of August and 20th October.

I set-up a tab for reporting on my four objectives by number of tasks, and, more interestingly, by percentage. This is the most useful part as it helps me ask myself if I’m focusing on the right work, and whether I should do more for an objective.

Table showing percentage of tasks and number of tasks completed each month.

Finding out who I work with

As an experiment, I’m going to track how many times I interact with different people. This should show me two things; the number of different people I talk to, and how much I talk to each of them. I’m expecting to see that there are some people I spend lots of time with and others I speak to only occasionally. One of my objectives depends on spending time with more people across the organisation, so this should give me some data on how to improve on achieving that.

Monthly priorities

I used to set a few goals for each project at the start of the month, but things would change so much over those weeks that I’d almost never achieve them. Instead, I’m going to switch my monthly planning to be about priorities rather than goals, and about the four objectives rather than each of the sixteen projects. These aren’t trackable yet, but I review them at the end of each month a colour them green, amber or red for how much I actually focused on them.

Weekly goals

I always start the week by thinking about achievable goals. Just like the monthly priorities, these are trackable yet but are reviewed and colour-coded. I’m still pretty poor at choosing goals that are actually achievable but I’m going to keep doing it to see what else I can learn and how I might be able to connect them to the daily tasks.

What next?

Make it open – I could create a Google Docs version in case anyone else wants to try it.

Team sport – It occurred to me that this type of tracker could be used by a team just as easily as by one person. I doubt I’ll put it into practice but I might think a bit more about how it would work.

Wrong images on websites

Why do websites have images? They up space on pages, take time to download, and are costly to create.

The reason is, I think, because our brains process images far faster than text.

An ecommerce website selling red and blue shoes has text to tell you which is which, but they also have images. They know that we make really quick, snap decisions when we process information visually.

Images on ecommerce websites are an easy and obvious example, but images serve other purposes too. They can help set the emotional tone of the website, direct people’s attention, and provide information. But overall, all images on websites serve the same purpose; they provide mental shortcuts.

So, what might happen if we put the wrong images on a web page? Obviously wrong images, like red shoes on the blue shoes listing, might create confusion. More subtly wrong images might create harder to grasp dissonances that feel wrong in ways we can’t explain. Images of people smiling on a web page about funerals, for example.