ARTICLE
Eight Underused Technology Roadmap Tactics
In the nonprofit sector, we underuse many useful technology planning methodologies. Too often, the process of defining what will be included in a technology project—like a website or a new implementation—is based more on a gut feel and a prayer than any specific process.
Here's eight tactics that might be useful as you plan your next technology project. I'll be writing more about these soon, but hopefully the list itself will inspire you to Google a few to find out more.
1. Create a shared vision statement
Before pretty much any other tactic, you need to come to agreement with your key stakeholders on what you're building. What are the goals? What are planning to increase and decrease? Who are the audiences? What will it change in the world? This could be an easy documentation step or require a number of workshops to get everyone onto the same page.
I'll be writing more about these tactics over the next weeks, but hopefully the list itself will inspire you to Google a few to find out more.
Follow me on LinkedIn to hear about new posts.
2. Analyze Competitor (Comparative) Websites/ Products
This is probably the biggest overlooked opportunity, in my experience. It's almost always worth taking the time to review what others have done. For instance, look at websites of organizations that are similar to yours, or products that have a model that’s similar in some way. User testing other people's interfaces can also be enormously helpful—you can learn a huge amount about what works and what doesn't without investing a dime in development.
3. Review Academic Research
This is another strangely underused step—why not see if there's academic research that would inform some of the key questions that you're investigating? This might include how your demographic tends to use technology or best practices around the interfaces you're considering. Google Scholar is a great place to start, though you'll often need to pay to see articles. In the longer term, a partnership with a university program can make this easier.
4. Quickly Prioritize Possible Features
In the early phases of a project, it's not uncommon to be drowning in a list of possible features. Using a straightforward tactic to prioritize your list with the relevant stakeholders can help you to focus on what's important in the short term. You could do a quick workshop where you ask stakeholders to agree on a Critical/ Very Useful/ Nice to Have for each, or do that exercise by department. Or you could even use a card sorting tool to collect priorities across stakeholders. When there are a number of factors at play, it can also be useful to rate each feature by different "themes"—how important is it to the user experience? Internal efficiency? Ability to fundraise? Obviously, you'd need to define the themes specific to the project.
5. Interview (Rather than Survey) Audience Members
For some reason, many organizations translate "user research" to "let's do a survey." I rarely recommend surveys, though—they can provide useful data around "how many", but provide little "why" context for that data. And unless you invest a huge amount of money, you're by definition surveying only the people who are excited to take your survey, so it's hard to extrapolate to people who aren't as excited. Take the time you would spend on a survey and go talk to members of your audience instead. Create some straightforward questions and ask three to four people in each of the segments of your audience. You'll learn so much more.
6. Prototype
Think about creating one or more quick and dirty prototype in the early stages of your design. These could have different purposes—perhaps you're not exactly sure how to implement a technical feature, and can create something rough and ready to see what works and what doesn't. On the interface side, consider creating a "paper prototype"—literally, a sketch of what the interface might look like on paper, sometimes even hand-drawn—and then user test it. The joy of a prototype is that you can learn a lot without much investment, and if it turns out you've gone in the wrong direction, you can just throw it out and start again on an improved version.
7. Create a Minimal Viable Product
You could also create a roadmap designed around a Minimum Viable Product (MVP)—something with as few features and as few complications as you possibly can. You ideally then launch that MVP and start to learn from what works (and what doesn't) while you continue to develop. This can be very useful as an actual development process, or just as a thought experiment. There's a danger, though, that a MVP process can overprioritize features and underprioritize the user experience—such as interface usability and graphic design. People have coined things like the "Minimum Lovable Product" to underscore the importance of creating something worthwhile as an MVP.
8. Create a Vertical Slice
A "vertical slice" is a term from the video game world, meaning that every aspect is finished for a small piece of the game, like a level. This concept doesn't apply to every technology project, but can be very useful is some situations. For instance, will your project eventually need to support three different core audiences? Maybe it makes sense to get it completely honed for a single one first. A single geography? A single community of constituents? A deep dive into one place can give you a solid base from which to expand, rather than trying to do everything at once.