Ragtag exists because of two ideas: (1) plenty of technologists — engineers, UX designers, user researchers, product managers, and so on — would love to volunteer their skills to help progressive causes and candidates (who would love the help); and (2) many “we’re gonna build tech to help you out!” project teams lose their footing, run out of steam, or otherwise don’t come close to everyone’s dreams.
If everyone’s smart, dedicated, and on the same side, why does this happen? In our work over the last two years, we’ve seen three common wrong turns that lead to less than stellar results — and we’re here to help you avoid those mistakes.
1: “Adding tech is the answer”
Your project might start when you notice something irritatingly inefficient about a group’s work, and you get inspired to jump in and help. If you find yourself thinking (or worse, saying) “why can’t they just…”, do yourself and the group you’re thinking of helping a favor: don’t. There are probably reasons why they “can’t just,” and they might not have time to explain them to you, at least not if you ask like that. Trust me, there are names for the “why can’t they just” people, and let’s just say…they’re not polite.
Instead, take a deep breath and reframe the question. Consider “would it help if I…?” or better yet, ask “product-market fit” questions: who might your new project idea help, by how much, and what’ll it cost; is there money to build and launch it, time for retraining, and ongoing money and time to make sure it keeps working? Be prepared to hear that something new is all very well and good, but their main problem isn’t technical. It’s also possible that they tried your idea a while back and can tell you what went wrong.
By the way, this assumes you’re working with a group that has a good understanding of the people who’ll use this new tech and can get it into their hands. Sometimes building the tech with no budget is the easy part, compared to trying to distribute it — or market it — with no budget. But that’s a topic for another day.
2: “Custom software is always better”
AKA “Not-invented-here syndrome”
I love the block-diagram-on-an-envelope stage as much as anyone. As you design that great new tech, though, please make sure that the answer isn’t already out there. Here are a couple of reasons why:
SPEED. Building stuff can be slow, even more so if you’re relying on volunteers. Promising your new friends a tool might mean they stop looking for other solutions. If your project is volunteer-supported, you’ll need to prepare for the inevitable hiccups: front-end developers sent overseas by their day jobs? Access control more complicated than you thought? If volunteers’ availability becomes unpredictable, not only is the project delayed, but the organization you’re supporting loses time they could have spent solving the problem a different way.
SUPPORT. Think about launch day and beyond. Who’s gonna train the staff and volunteers at the organization (the ones who will be there on launch day, and the new ones who join later)? Who will answer their questions because they didn’t read the how-to Google Doc you wrote? Who will fix the dependencies when GitHub sends a security notice? Thinking through an organization’s ongoing needs may mean choosing a product with an active, on-call, or readily available support team.
So, ask yourself: Do you need to make a data-gathering app from scratch, when you could use a mobile form builder? Should you hand-code that website, when good website builders cost about $25/month, including hosting? Is it necessary to build a volunteer management tool, when you could set the org up with a CRM? Your best technical contribution might be figuring out whether a tool that looks like it’s only for corporations could do the trick.
TL;DR — Do your research! For the love of all that is good, don’t go off and start an app that’ll alert people when it’s time to call their elected officials. I know you can do it, and it would probably be fun. First please please please make sure that you’re building something different from what 5Calls, Amplify, or NewMode already have, and that your content strategy doesn’t duplicate Americans of Conscience, Rise Up Now, Rogan’s List, and… well… do a quick search to find the others.
3: “Launched === Done”
AKA “the ninety-ninety rule”
You’ll probably want to launch your tool quickly to get it into the hands of the people who want it. You might get some nice blog posts or even press about it. Hooray! But you know how this story goes….you’re not done.
Think about what should happen if someone nefarious gets into the tool. Is there a way to get them out, and to undo any harm they caused? Make sure your UI design doesn’t have bugs (by which I mean, does it work as per spec, but nobody can figure it out)? Does your tool play nicely with what the org’s already got, or is everyone downloading and then uploading csv files?
We’ve heard from orgs whose tech projects were too complicated to use, got left in some weird state, or didn’t really solve the problem. Sometimes the orgs tell us how they feel. Disappointed, irritated… lots of stuff you’d put in the “bad” column. The good news is, you can avoid a lot of the heartache by hanging out with the people who are going to use the tool, checking out their true needs, and making sure you’ve gone beyond thinking about the tech to thinking about the project as a whole.
Interested in checking out Ragtag’s projects? Come join us at ragtag.org/join.