What Your NonProfit Can Learn From Startup Culture, and What It Can’t

Nonprofits are turning to the startup model for inspiration on how to improve their services. There is a lot of good that can come from this, but there are a few caution flags worth considering.

A lot of what you’ll find online about using the web and social media is targeting for-profit businesses. It’s focused on how to generate “leads” that you can turn into future customers, how to directly sell online, or how to manage your customer support needs and brand reputation. If you are a for-profit business, those are all important considerations, but nonprofits have different concerns to keep in mind. While nonprofits, churches and faith communities, schools, and other similar types of organizations may sometimes engage in directly selling goods or services, often they provide their services free-of-charge or at a highly discounted rate and depend primarily on donations to pay their bills.

It’s for this reason that we often say that churches and nonprofits are not businesses: their primary activities don’t directly generate the revenue they need to fund their operations. Of course, there is a certain amount of business logic that is required to keep these organizations afloat. Bills still have to be paid, and that means income has to be generated. Traditionally, this income came from philanthropy, and much of it still does. But for small nonprofits — especially churches/faith communities and locally oriented organizations — who have seen their membership/donor numbers decline over the past few decades, this isn’t always enough.

There is another, newer business model that some church and nonprofit leaders are looking to for alternative approaches: the legendary startup. Though many people associate startups with wildly successful companies like Facebook or Google, the general paradigm of “startup culture” has certain commonalities with nonprofit organizations. Startups are often loss-making rather than profit-making (for example, Twitter, founded in 2008, has never made a profit. And Amazon, founded in 1994, didn’t begin making a profit until 2009). Frequently they provide their services either “free-as-in-beer” (as most social media platforms do, for example) or at a deep discount. Startups are often focused around solving a particular “problem” or fixing a particular “pain-point” that their founders have identified, and so they tend to have some sort of “mission” or “vision” that motivates them. And they are often dependent on venture capital or other outside investors, so their primary source of funding is not (at least at first) directly tied to the product or service they provide.

Such similarities have led some church and nonprofit leaders to adopt a lot of startup language, using terms like “agile,” “adaptability,” and “focus” to describe how their organizations should change to address the challenges of the 21st century. Some of this can be helpful, but there are some critical caveats to keep in mind.

What You Can Learn

Let’s start with the positive: what can churches and nonprofits learn from startups? There are a number of things that startups do well that churches and nonprofits may find really valuable to emulate:

User Testing and Experimentation

One of the most critical rules of building a successful startup is to “get out of the building” and “validate” your idea. No matter how ingenious you think your product might be, if no one is willing to buy it, you’re done. So startups put a lot of emphasis on testing. They begin by validating the core of their offering (to see if anyone is even interested in it). Then they test all the details, from their web-page layout to the precise wording of the menu options in their app, honing in on the most effective strategy for implementing their “value proposition.”

Nonprofits can adapt this sort of testing and experimentation to great effect. Most existing nonprofits have a core offering that is well established and not going anywhere, but you can always use testing to refine it. For example, if you are considering a new event (perhaps a new fundraiser or a conference/class), testing the idea on a smaller core group can help you ensure that its a success. Start by pitching it one-on-one to a few key people first to see if there is interest before you publicly announce it. This validates the idea and may give you useful feedback about how to implement it, such as helping you to decide the best timing or the best way to pitch it.

It’s important to keep in mind that experimentation is meant to generate learning. Startups can be very “data-driven,” often making even seemingly mundane decisions based on the statistical results of experiments. While I don’t necessarily recommend that nonprofits let statistics become the only guiding light they follow, I do think it’s important that you be able to articulate what you have learned from any “test” or “experiment.” If you don’t know why a test worked or didn’t work, it’s hard to know what to do next.

So using our example above, let’s say the feedback you get from your initial one-on-one asks about a potential new program or event is that your key players are interested, but the dates you’ve proposed don’t work for them. Fairly intuitively, your next step might be to propose different dates and try again. In other words, you likely would not conclude that there was no interest and the idea isn’t worth pursuing at all, but rather that the original details weren’t ideal. Having reached that conclusion, you have a fairly clear path forward for trying to make the event a success.

But imagine if you had started by simply announcing the event publicly and putting out a registration form (whether physical or digital doesn’t matter in this case). No one signs up. You haven’t had any personal conversations with people about the event, you just have an empty roster. What would you take away from that? It’s much more likely that you’d conclude that no one was interested and drop the idea altogether, but that might be the complete wrong conclusion. How would you ever know?

The point is — and this is possibly the most valuable lesson nonprofits can learn from startups — when you “test” something, it’s important to structure your test in a way that you can clearly pinpoint why it succeeded or failed. That way, you know what the right next step is. If you don’t do that, you’re left with a big question mark and might walk away with the complete wrong lesson, missing future opportunities as a result.

Incremental Iteration and Agility

Hand-in hand with user testing, startups focus on “iteration.” If you’ve heard the buzzword “agile,” this is (in a nutshell) what it refers to. In the software world, for example, an “agile development process” is one that uses constant testing to roll out small changes quickly. The tests validate the specific changes (you can measure based on user activity whether a change had the desired effect or not), and doing them in small, incremental batches means you can roll out the next round of tests more quickly and make sure you are moving in the right direction.

Similarly, nonprofits can adopt a strategy of incremental iteration alongside testing new ideas and concepts. In our example above, having gotten feedback of interest but that the proposed date didn’t work, the next iteration of an idea might be with a changed set of dates. Another example might be a proposed change in fundraising strategy. You might identify a small set of changes to your current strategy, set a time-table for testing them, and then evaluate whether or not it is succeeding in increasing your fundraising (compared to a similar period using the old strategy), make some more changes, and try again.

The point is this: rather than trying to get everything perfect the first time, this approach moves in small, bite-size chunks to progressively get better and better. This is both easier to do (it takes less time and energy to pull off each iteration), and it’s overall more efficient because you can more easily pinpoint the impact of individual changes and adjust accordingly as opposed to needing to guess about what part of a large systemic change is causing a given (good or bad) change in results.

Contextual Metrics

If you are following an agile development process — using experimentation alongside incremental changes and testing — you need a way to measure the results and determine if what you are doing is working. What metrics you use, though, must be chosen carefully. It’s very easy to fall into the trap of using “vanity metrics.” Vanity metrics are numbers without a context. Let’s try one: we had 5 new members this year. How do you interpret that? Is that a good number or a bad number?

The answer is, it depends on the context. If you are a church or nonprofit with a very small member base, 5 may be a significant growth for one year. Likewise, if you have been stagnant the last three years, 5 may be a step towards positive growth. On the other hand, if the past five years your average member growth has been upwards of 100+, 5 might be a crash-and-burn year. And if you’ve been declining for years, 5 could represent another step in a downward trend.

In other words, the context of the number matters more than the number itself.

One way to keep numbers in context is through a strategy called “cohort analysis.” In cohort analysis, you make comparisons along stages of involvement within your organization. So for example, for a church your cohorts might be: new visitor, returning visitor, new member, active member, inactive member, lost members (whether by transfer/request or by the church deciding to remove them from the rolls). Breaking down all your contacts into these categories allows you to know things like:

• how many of our new visitors come back?

• how many of our visitors became new members?

• how many of our new members have stayed active and how many have fallen inactive?

• is our overall membership netting in a positive or negative direction when you take into account losses in membership?

These sorts of metrics are far more helpful than raw numbers without a context. Particularly if you combine this sort of contextualized data with “qualitative” insights (not numbers) from conversations with new visitors or members who have decided to either join or leave your church, these metrics can be used to create a narrative about how your growth is progressing, which can give you valuable insights into what’s working, what’s not, and where you need to make changes.

What NonProfits Can’t Quite Duplicate

These are great things that nonprofits can learn to replicate from our startup colleagues, but there are also a number of things that nonprofits can’t quite duplicate.

Here’s a few:

Venture Capital Funding

Let’s start with the really obvious one: funding.

Startups are either “bootstrapped,” meaning they are relying only on the initial investment of the founders and raise all additional money through their sales, or they are “venture backed,” meaning that they are relying on outside investors to support them until they have a clear profit model (something many may never achieve) or an “exit event”, like a buy-out. The latter is the more flashy, idealized form of startup funding: it’s how you really make it big, spinning an idea into a multi-billion dollar business (never mind that you may only own a slice of it when it’s all said and done). It’s also something that nonprofits will find difficult to duplicate.

Nonprofits have always relied on philanthropy, often from very generous large-amount donors. And there are some certain similarities in concept between relying on large outside donations and relying on large outside investments. But there are a couple of critical differences: venture capitalists expect to make a return on their investments. And they often expect some sort of “stake,” or equity ownership, in the business they are investing in. Neither of these things are up for offer from nonprofits. In fact, offering either to donors would be illegal.

This has ramifications beyond the technicalities of how you raise money. It also impacts strategy and introduces another critical difference between many (if not most) startups and most (if not all) nonprofits that is so important it’s worth emphasizing: many (if not most) startups intend to “fail” by traditional business standards. They have little ambition to become a self-sufficient, long-lasting, or profitable company. Instead, they intend to take an “exit,” often a buy-out from a larger firm who will take on the job of figuring out how to make their product profitable (or incorporate it into other products they already own). In contrast, most (if not all) nonprofits intend to be in it for the long-haul.

Venture funding and the motivation of an exit strategy combine to drive a lot of how startups operate, from the way they develop and test their products to the pricing strategies they employ. Demonstrating that they have a large, engaged user-base that can be converted — either by them or by another company that acquires them — into a source of profit is what attracts more investors to a startup. In other words, for almost every venture-backed startup business model, a larger base of users/potential users translates to a larger future profit potential, which in turn translates to more interest from investors or possible buyers and, as a result of that interest, a larger valuation and more opportunities for funding or successful exit events. This impacts strategy for all kinds of things, such as marketing, paid advertising, and pricing. Putting your new product in front of a lot of eyeballs, showcasing big-name companies that might have teams/team members (or at least that one guy) testing your product (a practice known as “logo-collecting”), and offering at least the basic version of your product (if not the whole thing) for free are all strategies designed to accumulate a large user base that can in turn attract more funding and/or a buyer.

In contrast, nonprofits by definition don’t have the intention of converting their constituencies into a source of profit or selling their “customer base” to a bigger fish for them to do so. In fact, often a nonprofit’s constituents are by definition a “loss center” and can never be converted to a “profit center” — they will always spend more on them than they bring in from them. And that is fine: that’s what the whole mission of the nonprofit is! However, it also has consequences for how nonprofits organize themselves, present themselves to potential donors, and measure success. For example, an exponential growth rate in constituents might not be a good thing for a nonprofit (it might signal a loss of focus or dilute the impact they are able to make). That in turn might actually scare away potential donors who want to see their money well spent. So nonprofits need different strategies: ones that focus on the long-term sustainability of their services and not on the “flashiness” of a new offering bursting onto the scene.

Singular Focus

Part of the concept of agility that drives many startups is an exclusive focus on a singular problem they are trying to solve. While large, established companies in any industry — whether it be Apple, JP Morgan, or GE— offer their customers a wide range of products and services, startups tend to pour all their energy into one thing and one thing only. This enables them to focus on making their one product the best they can possibly make it. It also allows them to attract the attention of bigger fish who might be interested in adding the startup’s product to their own portfolio of offerings.

While there are some “startup nonprofits” that can duplicate this singularity in focus/mission, most established nonprofits are more like larger, established firms. They often have an already built-up collection of programs and services available for their community. Narrowing the focus to one single thing would be impossible. Internally, their various program teams might adopt something of a startup’s agility with regard to their specific program area or focus, which could help these programs to grow in a more effective and efficient way. But the organization as a whole cannot become a single-focus startup.

What they can do instead is focus on tighter “integration” between their existing programs and areas of operation. For example, if your nonprofit operates a homeless shelter, a food bank, a soup kitchen, and a free clinic, most of the time (with a few possible exceptions) it would be the wrong approach to drop everything and put all your energy into only operating the free clinic. But it might be a good approach to adjust the hours on your clinic so you can maximize the number of guests in your shelter who use its services. Tighter integration of existing programs can improve the effectiveness of all the programs you offer. It might also help to spur some start-up style experimentation within or between programs and teams.

Speed of Movement

One of the keys to the agile workflow that many startups adopt is quick turnaround on their iterations. The faster you can make a tweak to your product, get it out in front of live customers, and measure the impact, the faster you can know whether you are moving in the right direction and adjust your other work accordingly. Two things drive that speed that are not always possible to replicate in a nonprofit setting. First, the product designers and developers working at a startup are professionals for whom this work is their full-time job. Second, the startup paradigm envisions primarily low-stakes digital products, which means that pushing out new features can happen almost instantly, measuring results can be automated and feed you “live” data, and any errors or glitches that occur are relatively minor bumps in the road in the grand scheme of things. In contrast, nonprofits are often working with a largely volunteer workforce, in a largely not digital sphere (at least not yet, but also possibly not ever, depending on the kind of work the nonprofit does), and often providing vital (maybe even life-saving) services with really significant real-world impacts.

It may seem obvious, but volunteers generally do not move as fast as full-time professional staff. Many, if not most, of them have day jobs and they are giving you their evening and weekend hours, as available, to help out. How fast can you really expect them to move? They may also be working outside their real area of expertise, and therefore unable to move at a rapid pace because they are climbing a learning curve. Even for nonprofits with large, professional staffs, there is usually a level of dependence on outside volunteers for part of their operations that will have an impact on how fast or “nimble” your organization can be.

Combine this with the realm in which nonprofits work. Most nonprofits are operating in the “real world” and providing logistically complex services to real people who depend on them to follow-through. While every nonprofit is different, for many it is genuinely the case that people’s lives (or at least their health and wellbeing) are on the line when their operations get derailed. That’s a much heavier burden to carry than almost any startup I can think of. So while there are many tweaks to your services and processes that you can adopt — and ways you can roll those out in an “experimental” and “agile” way — it’s unrealistic to expect complicated, vitally important operations to change at the speed of software development. Most nonprofits, even as they are experimenting with new ideas, need to be sure that those who depend on them will continue to receive the services they need during any transition period. That requires a level of certainty about the outcome even before an “experiment” is put in place that startups, especially in the “instant rollback” world of software development, simply don’t have to be concerned with. Maintaining that level of certainty requires an intentionally slower “design” process for new ideas or implementations (to make sure all the most important questions have been asked), an intentionally slower “development” process (to ensure all the pieces are in place to keep services fully functioning), and an intentionally slower “deployment” process (to ensure that transitions go smoothly and services are still operating as expected for those who depend on them). In other words, regardless of the speed at which your organization might potentially be able to operate based on your staff/volunteer abilities, you likely need to intentionally move slower in order to make sure that those who depend on you continue to receive the services they need.

Conclusion

Nonprofits are not startups. They cannot accept venture funding, cannot drop all their programs in favor of one singular offering, and will find it difficult (if not impossible) — and probably ill-advised — to move at the speed of “agile” software development. Of course, there are things that nonprofits can learn from startups. They can learn to present data contextually, within a narrative framework, and to work on ideas or changes in bite-sized iterations instead of singular, massive shifts. Perhaps most importantly, they can learn to develop and run “experiments” to test out new ideas in a way that provides discernible, actionable feedback. These lessons can help nonprofits greatly improve their effectiveness and efficiency and are well worth learning. But trying to emulate too much of the startup approach can lead to a nonprofit that is stretched too thin and fails to offer meaningful services to its constituents. As with much else, balance is the key.

What do you think? I’d love to hear from you. What are some specific ways that nonprofits might implement some of the lessons of startups? Are there pitfalls you’ve seen, or challenges you’ve encountered when trying to adopt startup approaches to the work of nonprofit organizations? Please share your thoughts, I’d love to hear them!