Yeah, great question—I agree that this is more important than many of the questions I lay out in the FAQ (but unfortunately it’s not one we’re frequently asked). I agree the mobile app did not have PMF (which is why we shut it down). The vast majority of the 40k donors are from DBT (it’s the largest campaign we’ve launched by far), so the interesting question is if we can replicate that to demonstrate PMF.
We spent most of this last year rebuilding our technology and running campaigns with small nonprofits to see which features are needed for PMF. We can now easily acquire small nonprofit customers but have now learned all we can from them. While these are easy minimum viable sales tests, these customers don’t have substantial donation volume. Saying that we got a 40% increase in donation volume isn’t meaningful if we moved an org from $200/mo to $280/mo. Now that we’ve hired several engineers and upgraded our tech, we’re moving on to testing with larger nonprofits with significant donation volume (our target market is orgs moving over $1M/year). Of course, even with the right product you still need to find the right growth channel, but that should also be revealed through the tests we’re running on the new market segment. We believe these tests will answer the three most important questions right now: do we truly have PMF, which growth channels should we be prioritizing, and precisely how large is the increase in donation volume for a nonprofit using our software.
Yeah, great question—I agree that this is more important than many of the questions I lay out in the FAQ (but unfortunately it’s not one we’re frequently asked)
<3
TL;DR: My suggestion would be checking Product Market Fit without developing any significant technology, especially since you said things like “We spent most of this last year rebuilding our technology”
For example:
Use your existing tech from the Trump campaign
Use your existing tech from the $280/mo orgs
I imagine both have messy code (as with all startups) and require actual developer time to customize for the customers, but I think that’s all ok (as long as you don’t make wrong financial transactions).
I’d try selling to a $1M/year nonprofit, I’d tell them “you’ll be our design partners and we’ll do custom development for you”, and I’d try making nothing generic (are you trying to make tech that will be relevant for multiple customers? Maybe that’s our double crux).
I don’t know anything about your internals so these suggestions might be totally silly for reasons I don’t understand, sorry for that. I thought It’s better to offer than not to. And that it would be better to put all my disclaimers here instead of in each sentence above :P
I’d be happy for lots of pushback of course <3
Or maybe I misunderstood and this is already exactly what you’re doing:
we’re moving on to testing with larger nonprofits with significant donation volume
Yeah, I basically agree with everything you said! More specifically:
We tested with the small nonprofits using the same hacked software we used for DBT (literally a static page with an iframe to our webapp)
We were in fact making financial transaction errors (e.g. double charging donors) since our database was not designed for scale, so we had to rebuild our backend. We had no in-house engineers, so we paused development until we hired engineers who have rearchitected the backend.
We’re trying to launch with mid-sized nonprofits using the improved technology we built for the small-nonprofits.
Our sales calls have revealed pretty similar feature requests from every mid-sized nonprofit (e.g we need a CRM integration). Many of these features are in our roadmap, but I agree with you that it would be even better to build it for a specific charity that is willing to sign rather than based on “generic” tech.
We’re already focused on getting 3-5 “case studies” from mid-sized nonprofits, but I’ve been reflecting recently on going to greater lengths to build custom features for those organizations, and after reflecting on your comments I’m updating further in that direction.
We did a lot of this custom work for DBT—we stopped developing generic features and almost worked like a dev shop to meet their needs (although we’ve slowed developing custom features for that charity as we are no longer learning as much from them).
Yeah, great question—I agree that this is more important than many of the questions I lay out in the FAQ (but unfortunately it’s not one we’re frequently asked). I agree the mobile app did not have PMF (which is why we shut it down). The vast majority of the 40k donors are from DBT (it’s the largest campaign we’ve launched by far), so the interesting question is if we can replicate that to demonstrate PMF.
We spent most of this last year rebuilding our technology and running campaigns with small nonprofits to see which features are needed for PMF. We can now easily acquire small nonprofit customers but have now learned all we can from them. While these are easy minimum viable sales tests, these customers don’t have substantial donation volume. Saying that we got a 40% increase in donation volume isn’t meaningful if we moved an org from $200/mo to $280/mo. Now that we’ve hired several engineers and upgraded our tech, we’re moving on to testing with larger nonprofits with significant donation volume (our target market is orgs moving over $1M/year). Of course, even with the right product you still need to find the right growth channel, but that should also be revealed through the tests we’re running on the new market segment. We believe these tests will answer the three most important questions right now: do we truly have PMF, which growth channels should we be prioritizing, and precisely how large is the increase in donation volume for a nonprofit using our software.
<3
TL;DR: My suggestion would be checking Product Market Fit without developing any significant technology, especially since you said things like “We spent most of this last year rebuilding our technology”
For example:
Use your existing tech from the Trump campaign
Use your existing tech from the $280/mo orgs
I imagine both have messy code (as with all startups) and require actual developer time to customize for the customers, but I think that’s all ok (as long as you don’t make wrong financial transactions).
I’d try selling to a $1M/year nonprofit, I’d tell them “you’ll be our design partners and we’ll do custom development for you”, and I’d try making nothing generic (are you trying to make tech that will be relevant for multiple customers? Maybe that’s our double crux).
I don’t know anything about your internals so these suggestions might be totally silly for reasons I don’t understand, sorry for that. I thought It’s better to offer than not to. And that it would be better to put all my disclaimers here instead of in each sentence above :P
I’d be happy for lots of pushback of course <3
Or maybe I misunderstood and this is already exactly what you’re doing:
Yeah, I basically agree with everything you said! More specifically:
We tested with the small nonprofits using the same hacked software we used for DBT (literally a static page with an iframe to our webapp)
We were in fact making financial transaction errors (e.g. double charging donors) since our database was not designed for scale, so we had to rebuild our backend. We had no in-house engineers, so we paused development until we hired engineers who have rearchitected the backend.
We’re trying to launch with mid-sized nonprofits using the improved technology we built for the small-nonprofits.
Our sales calls have revealed pretty similar feature requests from every mid-sized nonprofit (e.g we need a CRM integration). Many of these features are in our roadmap, but I agree with you that it would be even better to build it for a specific charity that is willing to sign rather than based on “generic” tech.
We’re already focused on getting 3-5 “case studies” from mid-sized nonprofits, but I’ve been reflecting recently on going to greater lengths to build custom features for those organizations, and after reflecting on your comments I’m updating further in that direction.
We did a lot of this custom work for DBT—we stopped developing generic features and almost worked like a dev shop to meet their needs (although we’ve slowed developing custom features for that charity as we are no longer learning as much from them).