Three times I was surprised by the differences between the charity and private sector

Two years ago I made the decision to leave the charity sector and, due to Covid, I’ve actually managed to have three jobs in that time, so I thought I’d take the opportunity to reflect on my assumptions going in and share a few surprises I’ve found since making the change.

We value quantity over quality

The most surprising difference I’ve found is the tradeoffs in quality and best practice we are willing to make in order to increase our profits as quickly as possible. In the charity sector, we aim to do things cleanly and well, and we care less about how quickly value is returned for our efforts. We tend to be painfully diligent people, all too aware that our users are living with cancer, degenerative physical diseases or mental health problems and a good day in the office for us goes some way towards lightening that load for them.

In the private sector, however, the speed at which money is generated is the number one priority and we appear to be willing to sacrifice almost anything to get it. The consequence of this is the mounting of an endless and often prohibitive amount of technical debt. This is not only technical debt in the backend, for example in pipeline or service stability, but also in the frontend too. We worry little about bugs, broken UI, brand violations or fragmented user experiences. If a new feature will generate more money than fixing these issues, then that’s what we’ll work on, everything else is off the table until ‘quieter moments’, which of course never materialise.

We believe we deserve our jobs

Approach and attitude is another significant difference that continues to surprise me the more people I meet in the private sector. In charity, I always felt a sense that everyone around me believed they weren’t good enough and that even if they were, they were the luckiest people in the world to have that job and would work tirelessly to prove themselves and keep hold of it in the face of never-ending financial worry.

In the private sector, that sense appears reversed, people generally seem to feel the company they work for is lucky to have them and with that comes a strange sense of complacency and entitlement that feels uncomfortable to me as someone coming in from a world dominated by anxious insecurity.

As a Product Manager, my job includes overseeing delivery and this is where I most notice the attitudinal disparity. If deadlines were threatened in the charity sector, people would be up all night, working at weekends or crying in private meetings with their managers, afraid that they were letting everybody down and would deserve to be fired as a result. Whilst in the private sector, deadlines approach with a disinterested shrug as people casually state they didn’t achieve anything yesterday because they had to take their dog to the vet, it was already 5pm or they couldn’t see the value in the task.

There still isn’t enough money

One of the reasons I was initially interested in seeing what life was like on the other side of the fence was to see what could be achieved with much larger budgets. Working for a charity you become very creative, always looking for new ways to get around the fact that you can’t really afford to do what you need to. In the private sector I came in with the assumption that money would flow more freely and liberate teams to be bolder and more ambitious in their digital aspirations.

Instead, what I’ve largely experienced is a form of financial Parkinson’s Law in which premium capital leads to premium spending and what remains feels equally small and difficult to secure. This is particularly noticeable in recruitment where wages are vastly higher than in the charity sector and teams are comparatively very well staffed. This makes the case for additional resource and even the backfilling of existing roles surprisingly challenging.

And yet, I love it

Despite every surprising difference and every complex challenge, I find it difficult to imagine going back, at least for now.

Every day I come to work it’s interesting, fun and nobody is going to die.

Instead, the worst consequence of a bad day is a little lost revenue or a few disgruntled colleagues. I’m no longer fixated on the fact that what I do is too important for me to be doing it. Because it isn’t important, not really. I like my job, I’m grateful for it, take pride in it and work hard. But when I leave in the evening, I no longer lie awake at night wondering whether I did enough to alleviate the burden on someone living with stage four breast cancer or contemplating taking their own life.

Every time I lose a UX battle, a leadership debate or a consequential decision, I no longer torture myself with the potential implications for users whose lives are hard enough already. I can afford not to place such heavy expectations on myself and those around me because it’s finally, actually, all going to be absolutely fine.

Creating a digital breast cancer support course

Breast Cancer Now offers physical support courses to people living with primary and secondary breast cancer. One of these courses is Moving Forward, supporting people once they’ve finished treatment to cope with issues such as body confidence, returning to work and managing fear of recurrence.

As a charity, we can’t provide this free service to everyone we’d like to, we can’t run one in every part of the country, we can’t pay for people to travel up to 200 miles for their nearest service and we can’t offer much desired refreshers to previous attendants because it would take away a first time space from somebody else.

As a product manager, I was given the amazing opportunity to create a digital solution to these challenges with an online tool that would allow more people to access and work through the course material from home. It’s been one of the best projects I’ve worked on in this role, so I thought I’d share how it’s going so far!

First off I had research phase, I wanted to find out as much as I could about the needs of the course, the appetite for a digital version, feedback on the physical courses that I could factor into the development and I wanted to know more about what makes a successful online learning and support tool.

After that was a prototype phase, which allowed me to check the conclusions I was drawing in my mind were an accurate reflection of what the tool should be for users, course providers, content and health information specialists.

Then it was time to make an Alpha product which we could take ‘on the road’ to user groups around the country. This was the first time everyone had the chance to see what the tool could look like and how they might interact with it as a participant of a Moving Forward Online course. We’d got a lot of things right, people valued the usability, the content and the interactive nature of what we’d created, but the immense value the users provided as they participated in our workshops and feedback sessions was context.

As digital and health professionals, we were experts in how to technically make and deliver a valuable product, but most of us knew nothing about what it was like to participate as someone who had been through a breast cancer diagnosis. With insights from users with these direct experiences, we were able to identify what we hadn’t got right yet, which means by the time we create a Beta version of the tool for the New Year, we’ll know we’ll have created something that’s not only usable and informative, but also feels safe and empowering for everyone at home who’s been through the trauma of diagnosis and treatment and is looking to understand where to go from here.

The feedback sessions highlighted the importance of connection with others who are going through similar experiences, so we added a private and moderated group to the Breast Cancer Now Forum, which Moving Forward Online participants can connect to via single signon straight from the tool.

They also highlighted the importance of having a healthcare professional available as people worked through the material and worried about issues that might affect them, so we connected the tool to the Breast Cancer Now Helpline with a dynamic prompt, which means a phone icon displays when the Helpline is open, and an email icon displays overnight. That way users are always connected to the best way we can help them at the time they need it.

We knew managing fear of recurrence was what people reported to be most worried about when they came to the physical courses, so we’d made this the first section. But we hadn’t fully appreciated what an emotional trigger the topic would be for individuals participating in the course, so we reorganised the content and the language around this to much more sensitively and resourcefully guide people through valuable, informative and empowering modules and eventually towards issues around breast and body awareness after breast cancer.

After the Christmas holidays, we’ll deploy the sprint that includes these and many other new iterations of the tool, we’ll finalise the content, agree our evaluation strategy and be ready to launch a year long Beta with a select group of live users looking for support to Move Forward after breast cancer.

I’ve loved working on this project and while I’m leaving Breast Cancer Now in the New Year, I’m looking forward to checking in with the team on how the 2020 Beta goes!

Designing our way out of a microsite culture

When I first started as a product manager at Breast Cancer Care, I was aware that I had a limited window of impartiality, so I decided to use it to conduct a front-end audit of the site. I wanted to see what some of the main challenges of the role would be before I knew anything about our digital history or ways of working.

At the end of the audit, I’d examined every forgotten corner of the site, identified the areas I felt presented the biggest user experience challenges and created a list of seventy-six questions I wanted to spend the next few months gathering answers to, either internally or through user research.

A key challenge to solve

One of the biggest issues I noticed was our tendency to create microsites for every new campaign or fundraising activity. Internally this was taking a great deal more time than it needed to, and meaning quite small pieces of work were stealing the team’s attention for months at a time.

Externally I worried about the user experience implications of treating each activity as separate from the site as a whole, particularly as the microsites were so difficult to navigate to and from, and often contained a number of subsidiary pages that took users away from the actions we wanted them to complete.

Talking to people around the organisation, I realised a lot of this practice had developed because the site offered internal teams no good alternative. We didn’t have a sophisticated suite of content types to cater for the various ways we wanted to engage the outside world in our work, which left staff little choice but to begin almost entirely from scratch each time.

How we tackled the problem

To solve the problem we started working with the design agency William Joseph to create a new suite of content types, so that the site could better cater to user needs as well as our internal requirements. The first type we began working on was a flexible, modular and mobile-first campaign template, which is currently being used to showcase eleven of Breast Cancer Care’s key campaigns and fundraising activities.

Following the success of this approach, we set about creating a full suite of new and updated content types that are now in use across the site and better meet both the user and our internal fundraising, campaigns and information needs. These include types for:

The end result

Through this approach we’ve found an enormous reduction in the time and resource needed to create engaging content during key campaigns, activities and other peak periods.

We’ve been able to up-skill digital champions around the organisation to create more of their own content and reduce reliance on agencies to create landing pages on our behalf.

Brand-wise, the site has benefited from a vast improvement in standardisation and consistency, which proved difficult to achieve with so many agencies each interpreting our brand guidelines in slightly different ways.

Finally and most importantly, we’re now in the second year of using our new suite of content types and have seen a marked improvement in engagement and conversion to our key activities and campaigns.

If you’d like to see an example of a campaign page in action, you’re welcome to sign up for a Pink Ribbon Walk this summer. (See what I did there?)

This post was first published via Just Giving.

Learning that compromise doesn’t equal failure

I was on holiday in Africa this week, leaving product behind and heading for the mountains and the sun.

Whenever I’m away I tend to keep a sneaky eye on anything involving developers, because issues that arise there are usually the most complicated to fix, and I’m the one who knows what shade of yellow all the balls in the air are.

Mostly I decide things can wait, but occasionally I’ll step in if I see conversations heading towards a consequence that hasn’t been accounted for.

When that happened during my holiday this week, it made me wonder whether imperfection is inherent to product management and whether that might not just be a reassuring fact, but also a positive one that leads to better overall results.

Playing out on Podio this week I could see my team trying to fix something in a way I knew would break something else. They’d done all the right things; figured out the problem, consulted with a developer, kept people informed and agreed a fix.

When I jumped in and got them to revert their decision, it made me stop to notice that they were dealing with a problem that, in the timeframe, didn’t have a correct answer – there were two paths and the one I pushed them to take was still wrong, just less wrong than its alternative.

These are the types of decisions I make all the time, but on each occasion a tiny bit of me feels like a failure; I didn’t find the third way, I couldn’t get everybody to win before the clock ran out and I had to settle for something less than what I wanted.

Watching a great team of capable people going through the same process this week made me not only resolve to cut myself a little more slack in this area, but also gave me the opportunity to reflect on the benefits of that rock and hard place situation. There will be a third way for next time and getting back to work on Monday will allow me to find it, but will also give me something I wouldn’t have had if the issue had been easier to solve.

These trickier problems and craggier paths to success lead to the pondering, consulting and late night googling that make us good, better and then the best at our jobs. They’ve led us to find the third way more often than we’ve ever stopped to notice. The development is gradual, but the only way to achieve it is to keep clashing with the issues that don’t have an obvious answer and use what we learn to keep moving forward.

Five minutes with a user

General Assembly at the moment are running a series of free introductory seminars in various specialist areas. They’ve been great, I’d definitely recommend signing up to a couple if you have the time.

Last week I went to one on user experience design and I thought I’d share a highlight of the session.

Usually when a speaker says “I’d like you to get into pairs” I get an internal sense of dismay. After all, if I relished opportunities to make awkward chat with humans I didn’t know, I wouldn’t be working in digital.

However, what I have realised over the last five years is how much I love user research, and fortunately that was the task we were set in this session.

We had five minutes to imagine we were working on improving the Citymapper app and run user testing with the person next to us about their experience of using it, in order to make informed recommendations about what could be improved.

The most interesting challenge with my partner, I’ll call him Adam, was that he was very distrustful of apps generally, particularly apps that asked for access to his location. He felt ill-informed about how his data might be used, and uncertain about the location-driven apps he downloaded having access to other areas of his phone.

Adam had never used a travel app, when I asked him about the methods he preferred for navigating London, he said he would use the TFL website. This started as a productive line of enquiry as we went through the way he used the site, but it soon became clear that he didn’t have very high expectations of TFL, it was simply ‘fine.’

Fine was enough for Adam when it came to maintaining his digital privacy. When I asked him how he would get around outside of London, he said he would ask for directions or take a printed map of his journey – that was how strongly he felt about protecting his identity online.

Thinking about the app design brief, I wanted to get to more than ‘fine’ with Adam, I wanted to know what would make a digital experience great for him. So I started asking him about his favourite non location based app.

It took him no time to get out his phone and show me a radio product he loved, and the most interesting thing about this was how much of what he said could be applied to the development of the Citymapper app.

On the radio app’s home screen, there were six content categories – things like ‘popular now’ ‘stations’ and ‘favourites.’ Though the ‘favourites’ option was in the bottom left corner, not the usual position of popular actions, Adam went straight to it and started showing me around. This indicated how important personalisation was to him, something really useful to explore with users in the context of the Citymapper app.

I then asked him to show me how I might use it as a first-time user, to get an idea of the journey he might have been on when he first signed up, and what he liked about that.

He showed me the search function and commented on how good the app was at returning exactly what he was looking for really quickly – another useful insight for apps more generally. The interesting thing about that search function was how it remembered his latest query and then made suggestions on what his next one might be.

He said he found this feature surprisingly accurate and  that it had introduced him to new stations he wouldn’t previously have come across. It was clear from this that he had begun to trust the app and let it guide his behaviour and propensity to try new things – another great example of something that could be explored more generally in the development of other platforms.

The whole task was a great reminder that good digital experiences come from putting the person before the product. To learn these things in five minutes made me really excited about some user testing I’m running for Breast Cancer Care next week. If you haven’t done any for a while, I hope this can be some inspiration!

Adopting a ‘start where you are’ approach to digital

A few months ago, I went to one of the really great (and free!) digital seminars run by Precedent Communications.

The main takeaway for digital progress in an organisation was to “start where you are”, which was interesting for me as one of the things I was working on at the time was creating a tool for the site which would allow all supporters to share examples of having challenged mental health stigma in their community, school, workplace or daily life.

As the needs of each group were so similar, I was keen to find a way to unite them into one resource that would work for everyone both internally and externally, without any UX compromises that would undermine the value and potential of the tool.

At the same time, I was aware of the need to view the tool’s creation in the context of other interactive areas of the site, to ensure we weren’t reinventing the wheel and dividing supporter attention between similar actions.

In ascertaining requirements, both internally and among key supporter groups who had initially expressed a need for the tool, I identified a significant functionality overlap between this project and something we had previously produced to support our national campaign drive in 2015. The campaigns team had been keen to find a way to ensure this bit of the site remained relevant beyond the campaign, so to my mind, this was a perfect opportunity to test out the “start where you are” philosophy.

Adopting this approach saved us a lot of time and money; we were able to get the tool built easily within our usual monthly sprint turnaround, and for just over £1,000. Most importantly, we were deploying to live having already worked out any UX kinks from the previous iteration, giving us a valuable product from the outset that supporters immediately began to take advantage of.

I’ll definitely be incorporating this into my thinking again!

Getting started with Accelerated Mobile Pages

With everyone on holiday over the summer, we’ve had some time at Time to Change to do a few nice UX improvements that have been on the list for a while. My favourite has been getting the site AMP ready on blogs and news stories.

Working in comms, news sites amping their articles has been really useful for me. When stories break I want to know the details fast, and as a commuter, I’m often on a train with terrible signal when those ‘need to know’ moments happen. Getting quick access from my phone has taken a lot of the frustration out of browsing for information, and gradually I started to think how great it would be if everyone got on board with amp – including us.

Deciding to get started

In April I went to Brighton SEO and heard a talk from Dom Woodman about getting started using amp with Drupal, WordPress and Joomla. The talk was great and gave me the confidence to know we could do it, as well as being a good opportunity to ask questions about wider uptake beyond Google’s ‘top stories’ carousel.

Dom’s advice was to get going and sure enough, a few weeks after we completed the sprint, Google blogged an early preview of their plans to expand amp.

Other benefits along the way

As the Guardian worked in partnership with Google in order to get amp working on their top stories, I picked them as a model for how I wanted it to work on our site. One thing I noticed most prominently was the consistent, engaging use of images in every post. At first I wondered how they were able to incorporate images without compromising the integrity of a high speed article, then I noticed the <amp-img> tag and other similar solutions, which we would also use as part of our own installation.

Previously, feature images weren’t something we’d used very often on the Time to Change site, so this has been a real bonus in getting amp ready and is something we’re now thinking about expanding to other content types across the site.

Any compromises

Installation and testing was fairly standard and took the usual month we allow to get new things done. One compromise we did have using Drupal was that amp is only compatible with page content types, which means our comments module doesn’t pull through to amp articles.

If you’ve recently installed amp yourself, I’d be interested to know how this compares to other CMS’ and I’ll be looking out for how Drupal 8 develops as amp popularity grows.

More on amp from Moz >

Managing support time with external developers

In the last few months, I noticed our support bills with external developers had slowly been creeping up, so I created a workflow document to manage the way we’re using helpdesks internally.

Although it’s a very low-key, totally internal workflow chart, one developer mentioned that quite of few of his clients ask for similar guidance, and asked whether he could share it more widely.

I hadn’t really considered it might be something useful beyond our team, but he made me realise this is probably quite a common problem, so here’s a format-free copy in case it’s useful for you too:

What’s the issue?

A new requirement: 

  1. Have the team given you a full and robust description of what they want?
  2. Would what they want provide significant value for Time to Change?
  3. If yes, give full brief to Becca
  4. Becca puts in development sprint
  5. Becca manages sprint, UAT and deployment

A problem with something that used to work:

  1. Have the team given you a full and robust description of the problem?
  2. Is it broken for everyone, are they using IE, remote desktop, or another likely cause?
  3. Can you easily / routinely resolve it yourself without any unknown implications?
  4. If difficult to resolve alone, have you discussed with the rest of the digital team?
  5. Before escalating to a developer, is it critically urgent, or if not, has it been consistently broken for two days?
  6. Have you described the full problem and expectations for resolution in one simple Podio message?
  7. Once actioned by the developer, does their solution match or better what you asked them for?

If you’ve had similar problems, l’d also be really interested to know how you’ve solved them!

Using social listening to find and amplify user-generated content

As Time to Change is a social movement, sharing personal stories from people with experience of mental health problems is an essential part of our content strategy.

A lot of these stories we commission from the general public and host on the Time to Change blog, but we’re also a big fan of amplifying user-generated content, to strengthen the voices of people who will ensure the movement  can continue long after our funding runs out.

As we’re such a big campaign, a lot of user-generated content comes directly to us without much effort on our part. People write blogs or produce video content and tell us about it, knowing we’re always looking for great things to share more widely.

But what this doesn’t allow us to see is all the amazing people out there who are fighting for the same things, but doing it alone. Harnessing these voices really drives the campaign forwards because, as well as being stronger and louder together, every person who produces content for themselves has the potential to inspire someone else to do the same – building the foundations of a sustainable legacy.

In order to reach these people, we needed a social listening tool that would show us all the content being produced around the world that related to mental health and stigma. Google is a great tool for finding the top ranking HuffPo and Buzzfeed articles, but those need no amplification, what we wanted was to find everyday people who had powerful personal experiences, wanted to change the world and would inspire others to do the same.

We looked at four platforms that would do this, along with the other operational requirements we had. They were:

Having interviewed them all, we landed on two finalists. The first we picked didn’t work out, they had a few development issues they couldn’t resolve and I didn’t want to keep paying for something that didn’t work properly, so we switched to Meltwater, who have been fantastic.

We’ve been with them a few months now and they do everything we were looking for to help make our social media as good as it can be. We aim for every post to get 600 engagements and 60,000 reach, but invariably our user-generated content found through Meltwater vastly outperforms this, growing our online community and spreading our message of change to a wider audience. This month our top user-generated post gained 8,700 likes and 1.3 million reach – all made possible with a couple of clicks in a pre-built search.

If you’re thinking about using social listening more, for this or the many other reasons, let me know and I can share my notes on suppliers we spoke to.

In the meantime, here’s a lovely post from someone whose blog we shared this month!

Brooke on mental health stigma

Removing redundant, out-of-date and trivial web content

This blog is about removing redundant, out-of-date and trivial (ROT) web content from a large site.

Before I start, I should say that a much more sensible person would have got an agency to do this. At several points during the process (which I started in October) I’ve thought I was being far too stubbornly INTJ about the whole thing and it would be easier to hand it over to a bigger team of people who could work on it full-time. But it was interesting and technically achievable – I’ve come to realise I can’t say no to anything that can be described like that.

What were the issues?

During my first year at Time to Change I’d slowly been discovering a lot of ROT content. A lot of it was unnavigable, which I think was part of the problem – whoever created it had left, forgotten it was there or for whatever reason abandoned it to float around the website without its parents. It happens in any organisation, perhaps particularly in busy charities where everyone’s working at such breakneck speed that the phrase “just get it up there and we’ll deal with it later” can become common by necessity.

The tricky thing is that nobody does deal with it later, because we’re all straight on with the next cripplingly urgent thing. And so it continues until there are are over 5,000 out of date pages that no-one but Google has time to notice.

A crucial part of this was that we didn’t have a system for forcing parent page assignation, so bypassing this step and saving everything as a page in its own soon-to-be-forgotten-about right became inevitably common practice overtime.

A further contributor to the problem was that we had no processes in place to deal with content that had a known shelf-life, so community event listings from 2011 continued to sit there gathering dust in the absence of an agreed way of unpublishing and redirecting them.

How did we address these?

As well as dealing with the content that needed to be removed, I’ve been keen to make sure we improved our set-up to negate the need for such a time-consuming audit in the future. With a bit of development, now when people add content to the site they’re asked to assign a parent by default, and an auto-generated url now inherits that breadcrumb trail as standard.

To deal with the event listings, I’d hoped for a module that would manage these automatically based on a set expiry date, but the slightly more laborious alternative of manually setting an auto-unpublish date when approving the listing and then using Siteimprove to pick up the 404 for redirecting is a fine substitute.

Incidentally, Siteimprove has also been great for us in a number of other ways, and I found you can haggle them down fairly substantially from their opening service offer, I’d definitely recommend them.

How did we ascertain the ROT content?

Although we can export all pages on the site from our CMS, I wanted to make sure we knew which were the high performers so we were making removal decisions within an informed SEO context. With that in mind, I picked the slow route of exporting them 5,000 rows at a time, in rank order, from Google Analytics. 

Once I had a master spreadsheet of 17,000 pages, I looked through the first hundred or so to identify any top performers that might also fit the removal bill. Happily there weren’t any I could see that ticked both boxes – top performers were, as you’d hope, well used and positioned pages, or personal stories and news articles that remain indefinitely evergreen.

With that reassurance locked down, I could sort the spreadsheet alphabetically as a way of identifying groups of similar pages – e.g. blogs, news stories, user profiles and database records which we wouldn’t want to remove. It also identified duplicate urls and other standard traffic splitting mistakes. I then selected and extracted these from the spreadsheet, cutting the master down to around 10,000 pages.

Next I wanted to filter out the dead links, because we now had Siteimprove to pick these up and a weekly digital team process of redirecting highlighted 404s crawled by the software, so they didn’t need to be included in the audit.

As GA exports urls un-hyperlinked and minus the domain, I needed to add these in. I used the =concatenate formula to apply the domain and the =hyperlink formula to get them ready to be tested. I then downloaded a free PowerUps trial and ran the =pwrisbrokenurl dead link test for a couple of days over the Christmas holidays. It’s worth saying my standard 8gb laptop struggled a bit with this, so if you have something with better performance, definitely use that.

PowerUps divided my data into broken and live links so I could filter out the broken ones and be left with an updated master spreadsheet of every page that needed auditing by the team. There were just over 6,000, which we divided between us and checked on and off over several weeks, marking them as either ‘keep’ or ‘delete’ and fixing the url structures and parent assignation as we went.

That process identified 1,000 relevant and valuable pages to keep, and 5,000 redundant, out-of-date and trivial ones to remove. Past event listings make up a large proportion of these, but I’d also say you’d be surprised how many other strange things you find when you do something like this!

What’s next?

Now we know what we’re removing, I’m going to get a temp to unpublish and redirect it all, which I hope will take about a week. From there I’m going to look into how we might go about permanently deleting some of the unpublished content, as a spring gift to our long-suffering server.

Once that’s done we can move onto the content we’re keeping, so the next phase of the audit will be about ensuring everything left behind is as fit for purpose as we can make it – I expect this to go on until the end of the quarter.

That time should start to give us an indication of Google’s response to the removal of so many pages. I’m a bit nervous about this and prepared for an initial dip in traffic, but by Google’s own standards I’m hoping for a curve that looks a bit like this:


I’ll keep you posted!