Four Pitfalls of Social Product Innovation

(Image courtesy of iStock)

Nonprofits and other social sector organizations are enthusiastic about using innovative mobile and web-based tools to improve their programs and service delivery, and as costs per line of code drop and an “app for that” mentality becomes ubiquitous, these organizations—with their domain expertise, end-user proximity and trust, and general scrappiness—are well positioned to design digital solutions.

It’s worth pausing for a moment, however, to recognize that today’s leading product development practices often conflict with the way social sector organizations traditionally attract resources and manage workflow. In my own product innovation work, I’ve seen common pitfalls emerge in four main areas: funding, identity, operations, and experimentation. By understanding these risks and establishing mitigation strategies in advance of innovation, organizations can save resources while deepening their impact.

For social sector organizations building digital products, common pitfalls emerge in four main areas: funding, identity, operations, and experimentation. (Images courtesy of Adobe Stock)

1. The funding pitfall

Product innovation requires continued iteration, experimentation, and learning, and carries a high risk of failure. But while the funding and lifecycle of tech businesses through an established venture model accounts for this, most social-sector funders are risk-averse and inclined to pay for expected outcomes rather than iteration. They expect a given amount of charitable grant capital to create a stated impact on a predictable number of users. They might expect a soup kitchen, for example, to serve 1,000 meals a month. But it’s unlikely that any organization trying new ways of doing things, experimenting, and iterating will rapidly achieve a pre-determined outcome.

If a funder insists on pre-determined outcomes, it can lead organizations to a focus on “vanity metrics” and resort to things like getting more users to sign up for a product, even if it’s failing, just to ensure “grant success.” Worse, it can lead to the costly design of a long and involved product impact study that hasn’t had a chance to reach sufficient efficacy. During our initial AppLab work on Google SMS Health, a texting application for maternal and reproductive health, for example, there was an expectation that we would run a randomized control trial (RCT) of early users. This required tight coordination to prepare a treatment group right before a comprehensive national launch that faced various delays, and ended with an evaluation suggesting the opposite of the desired impact.

Funders need to understand what they’re getting into with digital service delivery and make sure they want to play in the space. Some—like the Center for Financial Services Innovation (CFSI), which funded work on WageGoal, a cash-flow service that helps workers avoid payday loans and overdraft fees—embrace the ambiguity of the development process, allowing for open-ended research and development in their grant design. CFSI’s funds provided a safe sandbox in which to learn and iterate, and its frequent convening and tight network made other practitioners, funders, and regulators accessible.

Practitioners need to meanwhile educate funders about how to view evaluation, making it clear that they aim to generate learning through active experimentation but may not produce definitive outcomes in a known timeframe. They also should explore non-traditional funding structures that enable and incentivize product development and testing, including innovation awards like X Prize, where funds rewarded to winners of a race to demonstrate a desired functionality—like building an autonomous vehicle that can complete a lap on an off-road track—serve as a catalyst for multiple teams to work on an important problem. Practitioners should keep in mind that most products require “follow-on” investment—beyond the initial spend—to reach a significant inflection point, and they should be wary of committing to the “gold-standard” randomized control trials too early, before developing deep conviction and validation that the product is indeed ready to create provable and demonstrable impact.

2. The identity pitfall

The social organizations most capable of attracting funding for product innovation usually provide proven, high-impact services offline. For example, an established, successful soup kitchen operator would be more likely to find funding to develop an on-demand delivery model than a newer, unproven initiative. And if the soup kitchen’s product innovation team is anything like most organizations’, it would assume that at some point, a scalable, digital solution could create broader impact than the offline program delivery model. However, innovation teams rarely consider the implications of innovation on the prevailing model, or how the online and offline programs will co-exist. This conflict, and the realization that automated, digital experiences require more clarity to deliver than human-driven interactions, which allow for improvisation and flexibility, can surface hidden tensions within the organization about its mission and program priorities. Our hypothetical soup kitchen will no doubt identify new efficiencies in its efforts to run a real-time, digital operation that will clash with the deeply held beliefs of those who built the existing model. 

Push and pull related to organizational identity can threaten product initiatives. Emerging innovations tend toward entrenchment in independent silos, where they can build velocity and momentum—the “oxygen” of innovation. But this can lead to misalignment with the organizational mainstream, creating tension and jeopardizing the continued flow of resources. Conversely, innovation efforts can get pulled more centrally into the organization, ensuring that they receive more resources and attention, but exposing them to latent blind spots and slower decision-making processes. This tendency mirrors how industry incumbents are often inhibited from disrupting their own products, à la Clay Christensen’s innovator’s dilemma. In several efforts I’ve supported, organizations’ internal “immune systems” have pre-emptively crushed an emerging innovation by viewing it too rigidly within the constraints of the old model.

To mitigate these risks, organizations developing new products need to know who they are and where they are going, and how the new development process will build on and advance its fundamental pillars. The development team needs clear guidelines on what is sacred and what is malleable before it can build in a way that truly reflects the organization’s identity and voice.

3. The operational pitfall

Innovation efforts usually originate as an appendage of an organization’s more-mature core and may seem less deserving of focus than more-established programs. Many organizations believe that, if fruitful, innovation efforts will show their value, and that resource investment will grow as the efforts become more central to the organization’s mission and outcomes. But this dichotomy—viewing a new effort as less worthy until it proves itself—will likely be a self-fulfilling prophecy if it drives sub-optimal choices about how to execute the plan. Anything short of complete conviction, and tight linkage to leadership’s view of the future and theory of change, inhibits the creation of an impactful product experience. For one of the mobile services we built in the AppLab in Uganda, for example, our technology partner insisted on using an outdated and inflexible technology, even in places where we had the capability to deliver something more functional, which limited the app’s effectiveness.

People working at social sector organizations are generally cause-driven, which can contribute to an environment where consensus triumphs. Early-stage products meanwhile thrive when they focus on limited and specific needs of a clearly defined segment. Conflict between these orientations frequently leads to product design by committee, where groups make decisions en masse and based on existing beliefs rather than validated learning. This often yields products that satisfy the team but lack a clear, objective view on how to solve user challenges. In my work on a finance application, in partnership with a talented and diverse set of people, we struggled to create a common understanding of how to solve the user’s problem and what the threshold should be for solving it. The result was a “least common denominator” prototype that tried to do everything for everyone rather than doing one thing well.

Organizations also often don’t recognize the considerable additional costs and demands that come with the total cost of ownership software development brings—above and beyond simply “writing the code.” To ensure that the development process is smooth and efficient, organizations need to invest in a knowledgeable product manager, a reliable and secure server infrastructure, backups, redundancy, and other protections. Obligations tend to grow exponentially as an application adds users, requiring more servers, more management and monitoring tools, and a host of new resources that are likely outside an organization’s frame of reference. And since product builders must incorporate productivity tools, analytics services, application programming interfaces (APIs), and other third-party offerings into any solution, costs and complexities such as API enhancements or cloud storage upgrades tend to increase as a product moves forward. Product reliability on one product I supported was limited by an unwillingness to budget for these types of costs, despite the fact that they were essential to delivering the service at the quality both the business and its users expected.

It’s important that practitioners agree early on how they will optimize product strategy for success. Product developers need to understand how their process will play out within an organization, and what skills and resources it will demand—inclusive of the total costs of ownership for an organization. Product innovation teams, whether at the core of an organization or in a silo, need a clear framework for how the team will make decisions—linked to clear hypotheses and learning agendas. Finally, the organization should evaluate how it can best get from A to B without re-inventing the wheel—resisting the urge to build the slickest app or tool and instead focusing on their unique abilities and advantages—then partner with companies who are well-aligned with mission and expectation.

4. The experimentation pitfall

Prevailing wisdom in Silicon Valley is that breaking things and failing fast is a necessary part of innovation. Indeed, the space technology company SpaceX failed spectacularly on three rocket launches before getting it right. In the impact business, attitudes toward fiery disasters are less generous—many people consider mucking up even one user’s savings account or providing erroneous health information too damaging, even in environments where the prevailing models yield imprecise impact. I’ve seen a great deal of misalignment within organizations related to risk tolerance. One finance app I supported sought to optimize users’ savings and bill payments, but the team disagreed on how strongly to recommend savings and money movements to a user. This discord led to a “make everyone happy” solution that inadvertently minimized potential learning.

Before putting a product in people's hands, organizations also need to establish avenues for mitigating risk. Failure is part of the innovation process, and any beta or user testing is going to generate unexpected challenges. Ideally, builders should have a plan for beta and pilot groups so that they can manage any downsides and avoid harming any individuals, but they should not be deterred from trying something new simply because they fear something will go wrong.

Product development is an intensive undertaking that requires dedicated resources, conviction, and commitment, regardless of an organization’s mastery of existing programs. It also requires consistent buy-in and steering from the highest levels and alignment with the organization’s most central values. Advisory groups composed of supportive outside experts can inform and help shepherd these efforts. Leadership should see innovation as incremental, and authorize, for example, six months of milestones and resources at a given time to allow the team to execute with confidence at each step. Builders should transparently provide clear learning and experimenting goals at the outset of each period, and follow up regularly to check in on how those are performing and what pivots they suggest. Organizations must let go of the idea that they will get it right from the start, and try to appreciate the tremendous learning and growth that comes with the journey. Finally, it’s essential that funders understand the bigger picture, and that partner companies can tolerate the risk while taking quick and deliberate action on ideas and insights that emerge.

Social-sector organizations—with their authentic DNA, capacity for developing deep community trust, and commitment to solving problems—will play an important part in understanding and addressing humanity’s deepest challenges into the future. As we harness the power and reach of emerging technologies to address important social challenges, we would do well to keep in mind the pitfalls implicit in the prevailing model.

Read more stories by Eric Cantor.