*When I say “nonprofits” I’m still largely thinking of the XX,000 orgs using NPSP, but take it where you will.
I’ve been doing a lot of thinking about values and framing for our (now rescheduled) all-hands, and I’m still chewing through quite a bit.
Some of this comes from conversations at NPSP Day Seattle. It was grounding to be in a room of folks trying to use Salesforce to use their jobs and recognizing that many of them had never (intentionally) used an LLM. At least one person had never heard of NPC/AFNP. Unsurprisingly, one of the big discussions was about navigating the Salesforce landscape – if you’re using NPSP today or migrating to Salesforce for the first time, particularly as a small organization, what should you do? It’s still pretty clear that there are some significant flaws in every option available at this moment.
I’ve also been drafting possible versions of our vision statement and goals through the end of the year. One phrase that keeps coming to mind (and that I assume I’m not the first to use) is Software As Service, not Software As A Service. What happens when you prioritize your product choices by the best shared outcomes for your users instead of your buyers or shareholders?
I’ve been thinking about the options for building features as extensions of NPSP, as Bobby and Karen have been advocating. I don’t think this replaces the need for a new product under a namespace we own, but there is something compelling about offering upgrades on top of NPSP for a number of reasons – it gets help in the hands of those who need it sooner; it sends a signal to organizations who may be afraid of starting or continuing with NPSP that someone is still working that space.
I’m still worried about dividing our/my attention. And I still want to have a ready answer if NPSP is completely sunset (though I still think this is a long ways off). There’s still so much plumbing in NPSP that could be so much better if we ripped it out and started over, and we can never attempt to solve the problem of assured long-term existence without owning the foundational package(s).
But before we even dig into the pros/cons of various approaches, I keep coming back to: What do nonprofits really need in this moment? What problems would we solve if we start only with the small-medium nonprofits’ admins in mind? And if we apply that to possible roadmaps, what features would that include (either net new or rebuilt)?
Faster and better access settings. It’s really painfully slow when I try to show options to clients, especially for NPSP rollups.
Fix to the stupid bug that the primary affiliation for contacts is removed if contacts are merged and have the same primary affiliation.
I am curious about a few things for areas where I find myself frequently doing custom build outs, like Donor Journeys, Boards & Committees, Badges, Revenue Goals, etc. (Idlewild’s accelerators are an interesting thing to review - I wonder how useful and used they actually are?)
Might be interesting to see if there are some easy and inexpensive places where we could call outs to AI. A demo I saw from another consultant searched for public information about organizations and summarized as a component on the account layout. That one is nice because there are no data concerns. Something that could search metadata and report back from a screen in Salesforce would be amazing too (so you could ask where things are used or what emails are automatically sent or things like that).
Overall it’s also just really important to be able tell clients that there is a future for NPSP and they shouldn’t panic. Most of them are actually pretty happy overall with what they have now. The biggest complaints I get are around the perceived complexity of the system, especially with reports for the less technical folks.
I chatted with a few of my consultant colleagues and we discussed how we’ve all built potentially reusable features.
Evan Ponter has a screenflow with a single screen for adding a gift while assigning GAUs and entering payment info, and he also built a cool flow so you can easily add the recipients of a list email to be set to just selected campaign member statuses.
Todd Ching mentioned that basically for every client he ends up building fields to indicate Major Donor status: one that is automatically calculating based on giving behavior and then also an override so staff can manually mark someone as a current or prospective major donor.
I have a set of moves management fields/flows and flows to do things like copy over all the grants from one year to the next year (while resetting the statuses, updating the campaigns, etc.). I am also a big believer that for Donor Advised Funds the account for the gift should be the donor household and there should be a separate “Paid By” account lookup to store the account that technically made the gift.
Everyone agrees that the current engagement plans are typically a non starter because the levels are too rigid (it is ranges on a single field, which is not useful).
I think the big question is how we choose which things we might want to add and how to avoid things like the seemingly half built features of NPSP. We would also want these things to be customizable, which is tricky. If you’ve used Scrum, we need someone or a group of someones who can be the “Product Owner” for these sorts of things, who has deep domain knowledge for fundraising.
I think identifying features an design patterns that consultants have had success with is a great idea.
Some things com to mind:
Are there ways to make Organizational Affiliations easier to use or more robust/useful?
Adding a custom Interaction Notes object with some customizable categories would be helpful. Orgs could run a reverse cron report to get a quick brief on the most recent notable conversations they’ve had with a constituent.
Maybe also being able to set a customizable schedule/cadence of outreach based on the type of constituent one is. This is lighter and more flexible than engagement plans. It’s more like," I expect that we touch base with our board members once or twice a month. We call significant donors twice a year. We call recurring donors at least once a year."
Interesting to hear about the person who had not even heard of NPC. Makes me wonder how many folks are out there still on NPSP 2.0…
When trying to answer the question of “what do nonprofits need” it is probably worth making explicit in your research, contemplation, and your answers that there is no universal non-profit, so probably no such thing as a universal need. NPP certainly can’t be all things to all people, but in addition to focusing on “which things” it is also helpful to try to also answer “which people”.
Maybe you should try to sketch out some personas which group together the different types of organizations and people you’re trying to serve-- it doesn’t have to be a perfect partitioning, but something that at least makes explicit the fact that there are non-profits out there that haven’t heard of NPC, that are looking to move onto Salesforce, that are looking to move off of Salesforce, some have developers and admins and some don’t, etc.
Trying to find out what the people who do the work at the non-profits need is the most important question, and using consultants and implementors as a conduit to get those answers is a great idea, but realistically the consultants and implementors should be yet another set of personas which nppatch considers part of their audience. As you collect stories which describe the needs of individuals, you can hang them off of the persona they best fit (and/or use them to refine and shape the personas to better fit the stories you are hearing). One benefit of maintaining a distinct persona for consultants is that if you find yourself hanging too many stories on the consultant persona it might be a signal that you haven’t yet reached the root of what the non-profits themselves need. Its true that what is good for consultants and implementors is usually ultimately also good for the non-profits, but why not make that chain of benefit explicit by tracking the “who” in addition to the “what”?
The Verge podcast talks about the “theory of wearable bs” when reviewing devices. The utility of the product has to overcome its inherent fiddliness (VR headsets have a high utility bar to climb compared to a fitness band since you wear them on your face).
I think a similar framework is helpful for thinking through what can work for nonprofits in the Salesforce ecosystem.
NPC has a lot of fiddliness to clear for existing NPSP orgs: increased cost, the need to rip up existing infrastructure and rebuild around a more complicated data model, more cognitive overhead for users:
NPPatch has less friction to overcome since it starts out being compatible with NPSP, but to be adopted still needs to provide enough utility to make the change worth it.
Thinking through different personas:
Orgs looking to move to SF:
Basic utility starts higher because we can count baseline NPSP features as an immediate benefit.
Utility:
NPSP functionality + any NPPatch enhancements
Friction:
Questions about NPPatch long-term stability
Existing NPSP orgs:
More friction because of migration costs and lower utility since NPSP functionality that’s working fine in an existing implementation doesn’t have much immediate benefit from being swapped to the NPPatch version.
Utility:
NPPatch enhancements
Fixes to outstanding NPSP tech debt / bugs
Ability to keep building on existing infrastructure rather than starting over
Friction:
Need to migrate data, and rebuild or update custom metadata touching NPSP objects
Risk of disruption to operations
Questions about NPPatch long-term stability
Since the new org persona has an easier time reaching the point where NPPatch makes sense, it seems like the existing NPSP org persona requires the most attention. To get to the same place for this group, I feel like the tricky balance is to provide meaningful enhancements over base NPSP without increasing the friction of migration (so it seems like building in a modular way is important). At the same time anything that helps reduce friction points (like migration tools and an established governance structure) helps from the other direction.
You could further break down the existing org persona into fast and slow adopters.
