#13: Common ground

A Q&A with Scott Colfer

May 12, 2021

Pass It On is a bi-weekly newsletter bringing the tech and non-profit sectors closer together through knowledge sharing, written and edited by Lauren Crichton.

Welcome to all the recent subscribers! If you're new here, join us bi-weekly by hitting the button below:

—

Hello!

The previous issue of Pass It On was about the problem with problems— how we tend to avoid them in favour of shiny solutions.

Even though I wrote about this topic from a personal perspective (thanks to all of you who told me you were glad I did!), it's highly relevant to our professional lives—whether we work in the private, public, or third sector. Fortunately for us, this week's Q&A guest has experience in all three.

Scott Colfer is Head of Product for Ministry of Justice UK. Having spent over 15 years building products and services with a social mission, Scott is passionate about finding ways to improve lives. He's also passionate about (you guessed it) understanding problems in depth before building solutions, recognising the difference between skills and behaviours—but most important of all—stressing what our sectors have in common.

Over to you, Scott!

☯️ Finding common ground with Scott Colfer

What does it mean to build products that put people before profit, and are the respective processes as different as we're led to believe?

Value is context-specific. It means different things to different people depending on where they stand. In my context, building products that put people before profit means that we measure their value through how well we accomplish our social mission—rather than the financial profit we make.

The main difference that I've experienced between mission-driven products and profit-driven products is complexity. Often, profit-driven products can choose their users; they target enough people for a viable business model. Mission-driven products, by contrast, are typically more complex because they have to work for everyone or an extremely vulnerable set of people. Accessible and simple design is therefore key. For this reason, mission-driven products have some of the most robust research and service design practices across any sector.

Value and context aside, the approaches are similar. Product management has been product management no matter whether I've been working on a profit-driven product or a mission-driven product.

You've worked for commercial companies, non-profits, and the public sector. What similarities and differences did you observe, and why do you think they exist?

I used to assume that there were big differences between commercial companies, non-profits, and the public sector. Now I realise that's a red-herring. In my experience, the most significant differences relate to the organisation's size rather than its sector.

Working in a small non-profit was extremely similar to working in a small startup, for example. In both cases, the primary challenge was to secure enough funding to develop a viable business model without becoming so restricted by the funding that we couldn't move quickly and make rapid changes to the product.

At the other end of the scale, large companies, large charities, and large government departments are also more similar than they are different. They all offer stability, people, and resources but require more effort to navigate and understand from a culture, tools, and process point of view. In larger organisations, people are also more likely to be working on similar things without realising.

Ultimately, what we see as differences are more likely to be similarities lost in translation. More often than not, we mean the same things; we just describe them using different words!

You're writing a book about 'hands-on' product management. Can you tell us what that means?

I use the phrase 'hands-on' to refer to a product manager working on a single product. I use it to differentiate from product leadership, which involves acting as a product manager in a leadership team and providing direction to many products.

Becoming a product leader doesn't mean you stop practising the core concepts and techniques you learned as a hands-on product manager. Far from it. Shortly after I became Head of Product, I met a product manager at a conference who enquired after my role and asked if all I did was "manage people now." I replied, "yes, but that's all I've ever done." Product managers don't do anything. We listen. We think. And we talk. We understand other people's perspectives and find value in the sweet spot where those perspectives converge. Product management is a role based on the power of conversations. That was true when I was a hands-on product manager, and it remains true now that I'm a product leader.

You're not a fan of the term 'product manager.' Why?

I get why we're called product managers. The role grew out of brand managers responsible for tangible products. Like soap. And trainers. But product management stopped being solely responsible for physical products twenty years ago when Software as a service (SaaS) came along. I've used Spotify ever since it became popular in the late 2000s, and I've been a paying subscriber for 5-10 years. I own nothing tangible for my Spotify subscription; I'm renting access to a digital music library. What I'm getting is an outcome—the ability to listen to music whenever and wherever I want—not a tangible product like a CD.

I'm no longer a fan of the term 'product manager' because it's a rubbish way of describing how so many of us experience the role in 2021. My job is to achieve organisational goals by meeting users' needs and improving their outcomes, product or no product.

Take my colleague Simon. He's a Senior Product Manager working with others to modernise LPA—lasting power of attorney. (Read about why here.) The team has already made great strides in this area, digitising many paper-based elements. But moving the entire LPA process online is challenging: the protections in the current paper-based system are founded on decades, if not centuries, of tradition, case law, and social conventions, such as signing and witnessing. The solution here has nothing to do with technology or a digital product. The solution is broad system change: many disciplines and organisations working together, across boundaries, to achieve the desired outcome of improving the service for users. Folks like Simon and me aren't really product managers; we're outcome managers.

As a side note, Simon and the team are working in the open—a process that Lauren Currie OBE recommended in an earlier Pass It On Q&A. You can follow the team’s developing story here.

Best-practice product management (or should I say outcome management?!) starts with understanding and exploring the problem before building a specific solution. Can you tell us more about this process and why it's a challenge for non-profit organisations in particular?

It's important to define problems—and test our riskiest assumptions about these problems—before we invest time and money in solving them. If a problem isn't real enough, urgent enough, pervasive enough, or valuable enough to solve, any solution to that problem is doomed to fail. Discovery is a name given to this explorative research process, and it often involves talking directly to the people who are experiencing the problem you’ve identified.

In my experience, Discovery is a challenge for non-profits because it's not appreciated. Back when I worked for a non-profit, funders typically wanted us to pitch a solution; they wanted a specific deliverable to invest in. But in most cases, we didn't know what the right solution was—especially not at that early stage. We'd end up pitching regardless to win the funding, and if successful, doing the Discovery work afterwards to understand the problem. A completely backward process! Sometimes, we'd realise that we'd chosen the wrong problem to solve, but our funders still expected us to deliver the promised solution no matter what. We were acutely aware that our money was precious and wanted to use it to help our vulnerable users in the most impactful way possible. Without Discovery, this wasn't always happening as well as we wanted.

Eventually, we had a breakthrough with the Esmée Fairbairn Foundation. They agreed to fund 12 months' worth of Discovery so that we could understand a range of problems in depth before submitting a single bid. I can remember the first five opportunities we had to submit bids for that year. Ordinarily, we'd have applied for all five of them without hesitation and asked for around £50k each. But having carried out Discovery, we knew three of the bids weren't right for us: either we didn’t understand the problem well enough, or we were the wrong people to create a solution. The remaining two bids, however, were a great fit. We were so confident about our ability to deliver the right solutions that we submitted much larger bids at £150-200k each, and we won both. Over ten years later, one of those solutions still exists. It's changed hands and changed shape, but the solution is still helping people today because it solves the core underlying problem so well.

In one of your newsletters, you wrote about the difference between skills and behaviours. Tell us about that difference and why it matters.

I see skills as the practical application of knowledge to get a job done. Product strategy is an example of a key product management skill. As part of a product strategy, you might use a common technique like roadmapping.

Behaviours, on the other hand, are the attitudes and approaches that help our skills. They determine how we interact with others and whether our skills create value within an organisation. Let's take the example of product strategy and roadmapping. I might have produced the most technically perfect product roadmap in existence, but unless my team buys into it, it's close to useless. Unless I can collaborate with my team on building that roadmap and design it in a way that helps them do their jobs, I shouldn't bother creating it.

Behaviours are additionally important because they are more general than skills. It’s easier to find people who are empathetic and collaborative than people who know how to do a specialist skill like agile product ownership, for example. By being more general, behaviours can help us spot potential in a way that skills cannot. This is particularly important when recruiting at the associate or junior level, where we should be investing in someone with potential and helping them build skills over time.

How can Tech and Non-profits come closer together?

I think that Tech and Non-profits can come closer together for the better if both sides downplay the impact technology can have in isolation. Back in 2015, I sat on the steering group for New Philanthropy Capital's "digital transformation for charities" with Julie Dodd. Julie conducted some excellent research and discovered that technology was only one piece of the digital transformation puzzle. If charities wanted to make lasting change, they would need to evolve their mindset and approach to their people, processes, and tools. Technology is just one aspect of tools, and it's rarely the silver bullet when introduced on its own.

Which three books have had the most significant impact on you as a leader and why?

Communities of Practice by Emily Webber introduced me to many of the key concepts needed to run a profession at scale.

Lean Enterprise by Barry O'Reilly et al. helped me understand what a value-driven, mission command organisation looks like.

The Art of Business Value by Mark Schwartz taught me how to measure value without profit.

Thank you, Scott 🙏

If you’d like to learn more from Scott, check out his blog or catch him on Twitter and LinkedIn.

To any product folks reading this, I’m curious: do you think it’s time for product to re-brand?

Non-profit friends: did Scott’s experiences with submitting bids strike any chords?

Reply to this email or, even better:

Pass It On