Building Products with Nonprofits—Lessons Learned from VMware Pivotal Act

This post was co-authored by VMware Pivotal Act Co-founder Aly Blenkin.

“We’re not really sure yet how users are interacting with it, but the app pulls information from multiple social media platforms and plots it on a map, as you can see here,” said the presenter. We peered at the screenshots from the application, which showed photos, hashtags, and warning signs overlaid onto a map of Indonesia.

It was 2017, and we were at a workshop that aimed to share ideas around developing technology to address the challenges coastal communities face due to climate change, such as flooding, storms, and fires. One of the sessions involved an opportunity for several product teams to demo tools they’d created expressly for this purpose. The teams were full of energy and amazing ideas, however, they didn’t seem to know who was using the apps and whether they were making an impact.

Such a statement was not new to us. At the time, one of us was a consultant product manager and the other a designer at Pivotal Labs—now formally known as VMware Pivotal Labs. We worked closely with enterprise customers to build custom software, which often involved getting client product teams to be more user-centered and problem-driven.

Co-creating a user journey is one way to build an understanding of who we are designing for

“It’s like Christmas—you can pick your own solution!” one of the other participants at the 2017 workshop offered. Framing products as solutions in search of a problem, rather than starting with the user problem, is something we saw with our private sector clients as well. But we also saw how excited the cash-strapped nonprofits at the workshop were about the apps, which had been developed to tackle the problems they were working on. There was, we realized, potential for furthering the impact nonprofits can make through technology.

After seeing this type of pattern occur time and time again, we started to think about whether we could expand our offering beyond enterprises, to launch a program that works with nonprofits, at discounted rates, to design and build technology to further their impact. After doing a lot of research and testing a few ideas, VMware Pivotal Act was born. 

In this post, we’ll share some of the key learnings that have emerged from adapting our approach to designing and building technology in the commercial sector and applying it to the social impact space, namely how to:

• Design and build when working with historically underinvested groups 

• Know what success looks like when impact is the goal 

• Acknowledge the limits of where you can add value 

• Find ways to reduce team stress 

• Find a balance between adapting and sticking to your process

First, iterate continuously

To be sure, the way Pivotal Act operates today is not how we initially envisioned it. We have been testing out ideas and adapting our approach nonstop over the last three years. We’ve made many incorrect assumptions, and in hindsight would have done a number of things differently. 

Frequently testing and getting feedback reduces the risk of releasing something that doesn’t add value to people we are designing for—or the business

At Pivotal Labs, consultant teams comprise a product manager, designer, and one or more software engineers who apply the principles of lean, agile, and user-centered design while working with clients’ own teams to build products together as part of a “core product team.”

Our philosophy is to “learn through doing,” which is just as much about arming the client with the capabilities needed to continue delivering good software as it is about getting continuous feedback from the intended audience.

We pair individuals on the client side with Pivotal team members to work collaboratively as a core product team 

It’s an approach that has helped companies around the world achieve their business outcomes since Pivotal’s founding in 1989. As such, it was the model we intended to apply to a new set of customers: nonprofits. However as we quickly learned, working in the social impact space brings its own set of challenges, which meant we had to continuously iterate our approach. 

Design and build when working with historically underinvested groups

If you work in the social impact space, you’re aware of the risks involved when it comes to  experimenting and testing ideas for people who might not have their basic needs met. In the commercial sector, the focus is often on engendering delight—a team might design a shopping function that creates a seamless delivery experience, for example. Whereas when designing for the impact sector, we can’t assume people have either a safe place to sleep at night or a consistent paycheck.

Maslow’s Hierarchy of Needs adapted to emphasize how in the social impact space we design for those who have the most basic needs

All technology should be developed in a way that’s responsible, regardless of the circumstances of the people it could affect. However, when working with groups that might not have their basic needs met, the importance of considering any unintended consequences of our products is greater. We can’t simply move fast and break things or create a new product just because we have the skills; the stakes are too high, and even the best of intentions can cause more harm than good. As George Aye of Greater Good Studio says, we also have to recognize the power and privilege that working in the impact space affords us.

When it comes to designing and building software, product teams often leverage user-centered design methods. But while the user-centered framework is great for defined problems, it can be limiting and linear, as it doesn’t equip us to handle the complexity of the larger system within which products and services sit. Whether we’re designing tools for delivering cash aid or services for young people in government care, we can’t ignore the wider implications of the technology decisions we make. To that end, as part of any Pivotal Act project, we have incorporated systems thinking and scenario planning to avoid causing unintentional harm.

Maps showing the interaction between systems that were affected by the 1987 Cyclone Uma in Vanuatu

For nonprofits and practitioners in the impact space, thinking about systemic issues and how to address thorny problems at scale isn’t anything new. This is among the benefits of working side-by-side on a product with a nonprofit: They constantly challenge us and the way we frame problems.

For example, one of the Pivotal Act teams was working with A21, an organization with the mission of ending human slavery. The team used a framework called the Futures Wheel to identify any potential unintended consequences of delivering human trafficking prevention education online as well as the steps needed to mitigate them. Using this framework, the team evaluated a potential feature idea that would enable students to study the most sensitive topics on their own, but have the ability to privately message the teacher if they had questions. This feature idea came about through researching how other sensitive topics, such as sex education, are taught. Using the framework, the A21 team was able to come up with a variety of potential unintended consequences, such as: 

• The teacher not immediately responding to a student’s question because they are inundated, leaving the student to feel neglected or unable to learn, which could in turn lead to potential liability issues for the educators

• Students entering personal information about themselves, leaving them at risk if the tool was ever to get into the hands of abusers

• An unintended audience, such as a student’s younger sibling, viewing the tool’s more sensitive material 

At the end of the day, there were so many potential risks to this feature idea that A21 and the Pivotal Act team decided against pursuing it and refocused their priorities elsewhere.

Designers and engineers pair to think through the technical risks and feasibility of feature ideas together

Know what success looks like when impact is the goal

When we were first deciding how to measure the success of projects at Pivotal Act, we started off by establishing goals in four categories: 

1. Organizational — What the nonprofit wants to achieve 

2. User — What the product or service should enable its users to achieve 

3. Learning — What the individuals in the nonprofit want to learn, such as user research or other product development methodologies  

4. Impact — How the product or service is going to make the world a better place

At the end of a project, we’d assess how we did. We thought that if we hit all—or even most—of those goals we could consider the project a success. However, what we found was that we weren’t seeing success in the fourth category of impact—arguably the most important goal, as the whole purpose of Pivotal Act is to drive impact. 

We had gotten used to the cycle of starting a project, working intensely on it for the duration, and then assessing success at the end. But real impact takes time. As Shanti Mathew, deputy director of Public Policy Lab, likes to say, “When working at a systems level, impact is measured in years, not months.”

It took us several projects and iterations to realize that in order to measure success with clients we needed to look beyond the end of an engagement to understand if we were truly making an impact. A more realistic goal during the time frame of the project would be to make sure that the nonprofit was set up to measure the impact we’d hope the initiative would achieve. We also needed to consider the sustainability of the nonprofit continuing to implement its strategy after the project ended. If it made sense to build custom software, as opposed to using an off-the-shelf solution or not building tech at all, but that nonprofit wouldn’t be able to continue to develop on its own, that would not be sustainable and impact wouldn’t be achieved. We subsequently realized that it’s crucial to consider sustainability in all product decisions on projects, and ensure that we develop a realistic plan with the nonprofit so they can continue the work on their own, taking into account all the resources, budget, and skills involved.

We redefined the success measures by creating a new sustainability category and separating impact from the other project goals. During the project time frame, we would check if we were on track to hit these success measures and course-correct accordingly if not. We would evaluate success at the end of the project, and afterwards—first, after six months, and then again after a year—to give us the longer time frame we need by which to assess impact. When we don’t see the intended impact over time, or if the nonprofits that engage with us aren’t able to continue the work on their own after the engagement, that’s a learning opportunity for us and a signal that we need to adapt the program further.

The various success measures we look at and how we use them to course correct (during the project) or evaluate whether we made an impact (after the project)

The way we track progress and evaluate success is by doing so-called health checks, which we perform during projects, at the end of projects, and then after projects end. The health checks involve both the Pivotal Act team and the nonprofit team. Everyone is given a prompt and asked to vote with a color—green, yellow, or red—to indicate the extent they agree with each prompt. To ensure we hear from everyone, we ask people to vote simultaneously for each prompt, thereby ensuring no one feels pressured to change their vote based on those of any senior stakeholders. After the votes are tallied, team members discuss their reasoning. And in the case of any yellows or reds, which indicate that a project is in danger of not being successful, come up with solutions.

For health checks to be useful, the team needs to be in a psychologically safe environment where people can speak freely. Talking about risks that might hinder success is not an opportunity to blame anyone, but rather a chance for everyone to learn and improve.

Acknowledge the limits of where you can add value

How do we know which nonprofits we are best suited to making social impact with through technology? For Pivotal Act, we initially leveraged the same set of qualification questions used at Pivotal Labs, such as “What is the problem you’re trying to solve?” and “What impact are you looking to make?” We would then decide whether we thought it would make sense to do a workshop to dig deeper into their goals and challenges, which would allow us to scope what a project together would look like.

Initially, the decision point between the qualification questions and whether or not to move to scope the potential project was fuzzy. We would go by our gut to choose what felt right. But we quickly realized we needed to clarify to ourselves what a good fit between a nonprofit and Pivotal Act meant, exactly.

Keeping in mind our measures of success, we developed a visual consisting of so-called “project fit criteria,” which allowed us to evaluate collaboration potential on a sliding scale from “not a good fit” to “ideal fit.” This helped us get aligned around the nonprofits we thought we could provide the most value to and those we knew we couldn’t, where it would be best to recommend working with an agency that takes a different approach.

We learned early on, however, that even though we’d made our criteria explicit internally, we hadn’t properly communicated it externally after one nonprofit with whom we’d had several conversations expressed surprise upon learning we didn’t believe we’d be their ideal technology partner. That individual had put time and energy into talking with us, and we wish we’d communicated our criteria sooner. It was in that moment (one that we still feel terrible about) that we realized we need to collaboratively come to a decision around whether to work together or not. Now, in the first meeting with any potential nonprofit client, we show them our criteria and evaluate the fit together, which saves everyone time.

We go through each criteria on the left with a nonprofit as early as possible, and together decide how to score each statement

In true “lean” fashion, we continue to iterate on this criteria as we run more projects and gather more data. For example, the ideal fit we’d initially envisioned for the team within a nonprofit was a “balanced product team,” by which we mean a product manager, designer, and software engineer. However, as we soon learned, few nonprofits have balanced product teams in-house, which has forced us to explore what sustainable product development looks like for them.

We continue to experiment with our approach by working with individuals in other roles within nonprofits, such as project leaders, subject matter experts, and key decision makers, and in the meantime are developing new criteria specifically for nonprofits without product teams.

Find ways to reduce team stress

At Pivotal Labs, we always aim to bring a sustainable pace of work to projects. We work eight-hour days and take hour-long lunch breaks, usually all at the same time so everyone’s otherwise available. Our enterprise clients often find this approach surprising, but we model this behavior and encourage them to adopt it as well. The benefits speak for themselves: fewer mistakes made by team members working alone late at night, and an energized, more productive, happier team whose members trust each other.

Bringing an organization around to working this way is part of a broader cultural shift that we try to get teams on board with throughout our time working together. Other aspects of team culture we try to promote include:

• Openness to feedback

• Psychological safety

• Autonomy for teams working towards agreed-upon outcomes rather than outputs 

We believe working in this way results not only in better business outcomes, but healthier and happier staff.

As with other practices from our commercial work, we planned to bring this same approach of sustainable pace to working with nonprofits at Pivotal Act. We found, however, that many people working in social impact don’t have the luxury of working at a sustainable pace, especially when they’re on the frontlines helping people in emergencies. There is huge pressure to deliver, and individuals are often so incredibly passionate and dedicated they readily accept longer hours. Working long hours in stressful environments is a challenge across the social impact sector, so blithely telling nonprofit leaders all the advantages of cutting back to eight hours a day was not well received. It made us seem unrealistic at best and at worst, lacking in empathy. 

We are still figuring out how to encourage maintaining a sustainable pace in nonprofits while being sensitive to the hectic demands of impact work. And while we’ve learned that we can’t advise nonprofits how they should spend their time, we can listen to their needs and be more flexible. For example, we used to ask them to spend full days with the consultant teams during projects, but found this resulted in them doing the rest of their work in the evenings. We’re now experimenting to find the right balance of hours, one that’s acceptable to nonprofit teams but is still enough for them to build up their product skills.

Even if teams are working long hours, we can still try to reduce their overall levels of stress. We can encourage a psychologically safe work environment by giving feedback, calling out disrespectful behavior, and leveraging facilitation techniques such as retrospective workshops, or retros, which encourage everyone to have a voice. One framework we like to use is to make sure feedback is actionable, specific, and kind. We also encourage folks to think about feedback as a gift (thanks to Chisara Nwabara, a former Pivotal employee, for that framing).

A retro, where team members can share safely what they think worked well, not so well, and anything in between

Find a balance between adapting and sticking to your process

There are many ways in which we’ve adapted the Pivotal Labs approach to suit nonprofit needs, but we’ve also found times when that wasn’t appropriate. On more than one occasion we tried to adapt our services to help alleviate some of the pressures facing the nonprofit. That was a mistake, as those pressures were ultimately systemic problems for nonprofits that we can’t solve, and led to compromises that hindered rather than helped.

For example, in one project, we underestimated how long our collaboration should be so as to keep the overall price tag low. Unsurprisingly, we didn’t make as much progress as we’d hoped or planned to, and were later told by the nonprofit’s management that they would have preferred to pay more to go further together.

In another example, we were afraid of slowing down the good work of the nonprofit with our practices. Our typical process involves “going slow to go fast,” meaning we take the time to step back, question the project’s goals, and prioritize accordingly. We didn’t push hard enough on that process, however, and while we thought we were helping the nonprofit move quickly, over the long term we actually slowed them down. It was a stark reminder that no matter how fast you’re going, if it's in the wrong direction it ultimately ends up being more costly.

It can feel uncomfortable to temporarily slow down the delivery of products that are materially helping people’s lives. But doing so is a fundamental aspect of building technology responsibly. If we don’t, we’re doing a disservice to the very nonprofits we’re aiming to support.

Moving forward 

We’ve learned so many things over the past few years, and we know we’ll continue to learn as we work with more nonprofits. We hope others working at the intersection between technology and social impact will be able to take our learnings from the last few years and apply them to their own work. By no means have we figured out the exact right formula, and of course, there will never be one “‘right way” of doing this type of work. We are keen to hear from others about the ideas they have tested out. We hope that we can together hold space for reflection on our failures and successes, so that we can collectively move towards our goal of creating meaningful impact for people and the planet.

If you’d like to learn more about how VMware Pivotal Act could help your organization, please get in touch here. 

Find the authors on social media: Ellie Ereira on Twitter; Aly Blenkin on LinkedIn and Twitter.

About the Author

Ellie co-founded and is head of VMware Tanzu Act, an initiative dedicated to working with nonprofits at discounted rates to collaboratively create technology to drive social impact. She has tackled the challenge of building technology for impact from many different sectors, including at the World Bank, UK-based startup OpenSignal, the U.S. Department of Energy, and in academia, at MIT. Ellie is passionate about supporting product teams, helping them to take an outcomes-focused, systems-led, ethical approach to creating impact in partnership with the communities for which they design.

Follow on Twitter More Content by Ellie Ereira