Product teams: The next wave of digital for NGOs?

We’ve reached a fascinating point in the evolution of technology within nonprofit and social change organisations: everyone we work with at Greenpeace and beyond seems to agree that digital has a critical role to play, but many struggle to find the staffing models and structures that enable their technology to truly thrive.

So we asked Sam Dorman to speak with us about his experience helping the Iraq and Afghanistan Veterans of America (IAVA) put a digital “product team” in place. Sam, a technology consultant who has worked closely with IAVA for years, reflected on how the product team approach transforms the relationship between technology, organizations and the people they serve.

You’re sitting down for your first meeting with an NGO’s digital, comms and tech leads — how do you explain a product model to them?

This is about putting your money where your mouth is when it comes to technology. It’s saying, we know that technology is essential to delivering our programs and having the impact we want to have. So we’re going to have a skilled team here that knows how to deliver it.

A digital product team is there to make sure your organization is using great, high-quality technology that is fully aligned with what you’re trying to accomplish, and really delivers the experience you want to create for people. Both internally and externally. It uses methods of “product management” that have emerged as best practices in the tech world, and acknowledges that we need to be just as sophisticated about how we manage technology in the social sector.

I think people have learned to have such low expectations when it comes to technology. Everybody kind of assumes it’s destined to be an area of frustration. But your technology should be great! It should be helping you. It needs to be reliable, it needs to be trustworthy, it needs to be easy to use, it needs to have great design, and it needs to deliver real value, consistently. That’s what this structure helps deliver.

How does the product team work? Who does what?

Well, one key point is that we’re actually not talking about a “tech team” of developers or IT specialists. We’re talking about people who understand how to drive and manage smart investments in technology. It’s more of a tech strategy role than anything very technical. You’re still working with external specialists when it comes to designing and developing things.

But the product team is made up of “product managers,” and each of them has a specific portfolio of products they manage. For instance, at IAVA there is a specific product manager in charge of the website, of their Salesforce database, of their online community, and so on.

The product manager has clear responsibility for that product, but they work closely with whoever are the appropriate “domain experts” from other departments. So the website product manager works closely with other teams like Communications, Fundraising, and Programs to make sure the website is meeting their needs and allowing them to do their jobs well rather than getting in their way. There is also a chief of the product team who conducts the whole symphony.

How does this model compare to the current “typical” NGO approach to digital?

We sometimes mix together a lot of things when we refer to “digital” as a whole. When we talk about the digital products team, we’re specifically talking about the builders rather than the executors. That could be building and maintaining the website, or customizing your database to fit your programs really well, or working with your field staff to build a mobile app that helps your grassroots leaders. It’s those kinds of “building” projects. Meanwhile, other staff or your constituents are the ones actually using those tools to execute their work. Even just having that clear distinction between those teams has been really helpful for people.

As far as where this differs from the typical approach, it might just be in actually admitting that it never works when you try to manage your technology off the sides of people’s desks, or if you just outsource everything, or if the technology gets ignored altogether because everyone is too busy trying to do their “other” jobs. You need a specialized, holistic and ongoing focus on technology.

So are you talking about hiring your own team of developers?

No, definitely not. Product management is something different entirely. The product manager has to synthesize a ton of inputs from all over the place into a clear, realistic product roadmap. They need to be able to balance all of the complex realities of people and resources and technology and budget. So they’re working closely with other internal departments, but they’re also talking to external designers and developers, and they’re looking at metrics, and they’re bringing in feedback from end users, and so on. They might also be communicating internally about the product and setting clear expectations, or inspiring people, or just being an advocate for the product when that’s needed. It’s a job that takes a lot of skill, but it’s not actually that technical.

Every group is building websites, posting to social media, sending email and setting up online actions. Are they doing it wrong? What are some of the main pitfalls of the existing usual approach?

I’m sure plenty of groups have figured out how to use social media and email well. Anything that’s working they should stick with.

But the website is an interesting example. Most groups love their website on the day they launch it. But there’s usually very little investment in it after that. And meanwhile, everything else is changing around it so every day the website gets a little bit farther and farther out of date.

Eventually, the website becomes a huge source of frustration and embarrassment, and gets in the way of people doing their jobs. Then eventually you knock the whole thing down and spend a huge amount of time and money starting the whole cycle over again. The problem is, you only had this brief window of time where you actually loved your website and were getting good value from it!

A product approach to the website is different. Instead of just letting it slip into decline, you admit that a website needs continued focus and continued resources in order to stay useful and relevant and secure, and even stylish. So yes, you’re investing more in it, but at least you know it will continue to deliver much better value as your organization changes and the world changes around it. And then along the way you are fixing all of these points of frustration for staff and keeping the technology strong underneath. You can even keep the style updated over time so everyone doesn’t start the usual complains that it looks “so 2 years ago.”

Overall, this is a really simple concept. In practice, it sometimes represents a big shift in the way people think about investing in technology.

Treating a website as product undergoing ongoing development sounds good, like what we’d expect from things like Facebook or Gmail, but it also sounds expensive (and a great deal for consultants). How can an organisation justify ongoing work to its website, or manage those costs?

Actually, I think it’s a much better return on investment to treat your website like a product. In the old model, every handful of years you invest this huge mountain of time and money to start over and build a new site from scratch. That’s usually a really painful and costly process. But even still, you’re only happy with your site for a really brief window of time. For most of the life cycle of the website, you pretty much hate it! And, of course, it’s not serving you well strategically, either.

With the product model, once you make the initial investment to build something great, it takes a much smaller ongoing investment to keep it great. And if you do that, you’re getting strong value and a great product during its entire lifecycle. That buys you much more time before you have to spend big again on your next re-build, and it also should mean you are getting better returns from your site the whole way through instead of just for a few brief months.

How much of this is the same product management that you’d find in Silicon Valley or is this a new adaptation or evolution specific to social change organisations?

Yes, it’s very much the same! Think about any tech company that makes an app — Instagram or anyone for that matter. Obviously, they have a whole team of people focused on making that product great and keeping it great. It doesn’t just happen by itself. It takes great design, great coding, great UX, great leadership, and a million passionate arguments between various people. It’s just a lot of detailed, painstaking work. Why should we think it would be any different for the rest of us?

In an NGO setting, we can’t afford to throw that same big dedicated team at it. And we have all these complex cross-currents to balance, complicated programs to deliver and real constraints on resources. We have no choice but to face the music and be sophisticated about the way we manage our tech. We have to invest in it and make it a priority if we want it to be valuable, and if we expect it to help us deliver on our mission.

This model seems to rely on federating activities typically managed by digital teams out to other teams like comms, membership, fundraising, program, etc. Is that a fair/accurate description?

I generally try to avoid lumping all things “digital” together, any more than you would create a “Department of Paper” for all things non-digital. Ideally, I think every department should be using the digital tools they need to accomplish their jobs, rather than having a centralized team that somehow owns all digital tools for all uses.

Practically speaking, a lot depends on the people you have in these various roles and whether they are comfortable and skilled in that particular medium. But in an ideal world, I would see using social media as either a communications or engagement function. It’s not really a tech function. What’s tech about it? Same with writing emails. That might be communications or engagement or even fundraising, but it shouldn’t be tech.

What are good examples of things IAVA was able to do differently or more effectively after moving to this digital products team model?

With this product team structure in place, each product they invest in has a clear, strategic purpose and is consistently kept at a high quality level. For example, we’ve built this online community called myIAVA where veterans and supporters can interact and support each other, and where IAVA can deliver services and support. It’s still pretty early in the lifecycle, but already there have been some amazing stories happening there, and we’ve been able to continually keep evolving it to try to deliver as much value as possible to both the end users and the organization itself.

The same can be said for their new website iava.org. The site looks great on the front end but is also carefully built on the back end to be easy for staff to manage and maintain. And the site is still evolving to meet new needs that emerge. For example, after launch, when the fundraising team realized they needed a new type of donate page for a big campaign, they had a product manager who worked with them to understand their needs, and then go get something beautiful and solid built that allows the fundraising team to easily spin one of those pages up whenever they need.

A big part of this is that staff from each department get to focus on the parts of the work they do best instead of getting lost in the weeds of the technology. Fundraisers can focus on fundraising, communicators can communicate, and organizers can organize. And none of them need to waste their time or sanity wading into technology quagmires or trying to manage developers. I think it’s had a real positive effect on collaboration and has removed some of the frustrating obstacles from everyone’s paths.

What are some pitfalls or concerns to be aware about when setting up and running product teams in a social change org or other NGO?

Changes like this are equally as much about people as they are about technology. So you’ve got all of the typical change management challenges you would normally have when you’re creating new structures and roles. It takes a lot of communication, a lot of time, a lot of energy, and a whole lot of buy-in from everyone.

It also sometimes takes a cultural shift for people to stop thinking about everything digital as I.T. or operations. We’re not talking about fixing printers here. We’re talking about a key strategic function of your organization, with an essential role and a meaningful voice at the leadership table. Everyone needs to understand and agree that this team’s success is essential to delivering on the overall mission.

At IAVA, it definitely helped that they had the leadership and vision to embrace this structure fully. They also have the advantage of a relatively young staff that seems to intuitively understand how technology is essential to what they’re trying to accomplish at scale.

Examples from other organisations?

I suspect big-time presidential campaigns have this figured out since they’re well resourced and they put a premium on digital. But they are pretty different beasts than your typical NGO. I’ve also talked to a few people at NGOs who have stumbled on some similar practices, even if they haven’t formalized it in this way. I’m sure there must be others, too, and I’d love to hear about them!

Sam Dorman is one of the social change sector’s recognized leaders in the technology arena, helping organizations deliver technology that works for people. With an extensive background working in organizations — as staff, leadership, and a consultant — Sam is known for his track record of helping organizations successfully deliver innovative solutions with wide internal adoption and external impact.