The information you provide on this form will be used to send you a welcome and periodic emails about Fast Forward and the greater tech nonprofit community. You can change your mind at any time by clicking the unsubscribe link in the footer of any email you receive from us, or by contacting us at [email protected]
“Start with the problem you want to solve. Spend time with it. Let it surprise you. Let it give you the motivation.”
– Karin Underwood, Founder & CEO, CoachMe
You’ve done it! You’ve come up with a great idea that solves a problem markets won’t touch. Now, it’s time to research the bejeezus out of the problem and test your concept. Let the user research and user testing begin!
Start With User Research
First things first – talk to your users (also known as customers or beneficiaries). We’ll keep repeating ourselves: the user research never stops. From idea, to product, to continued iteration, your users should drive the product you build, so interviewing your customers at various milestones is critical.
Interview your users with a user-centered lens to allow opportunities to reveal themselves (read: without an agenda). It’s up to you how many interviews to conduct, but it should be enough that you have a broad sample of perspectives and a deep understanding of the problem from the point of view of people who experience it firsthand.
A few things you want to learn through user research:
- Your future user’s experience with the problem.
- Analog ways your future user is currently tackling the problem at hand.
- The types of devices and networks your future user already has access to or frequents.
When Conducting User Interviews
|Do This||Don’t Do This|
You Can Never Do Enough User Research
Rey Faustino, Founder and CEO of One Degree, had ample experience with the problem he sought to solve (the accessibility of social services). Even so, when he was researching his idea for a platform that helps low-income families access social services, he set up tables in front of schools and talked to parents to learn more about their concerns around social services.
Once you’ve developed an understanding of the needs of your future user, use this research to build a hypothesis (or answer a question) around what the useful product might be. It’s common for this hypothesis to differ from your original concept! With your hypothesis in hand, it’s time to design a prototype that will inform your MVP – your Minimum Viable Product.
Fast Forward’s User Research Process
Fast Forward’s mission is to support and grow the tech nonprofit sector. Fast Forward was recently at a crossroads: deciding what product to build next to increase our impact. So what did we do? We dove into user research to learn about existing behaviors. We first identified the goals of the user research, and then developed a question list.
Main Goal: Determine where tech nonprofits most need support and through which channels they’d like to receive that support.
Sub Goal 1: Understand the biggest challenges tech nonprofits leaders and employees face and where they go to get advice/questions answered around those challenges.
Sub Goal 2: Discover how tech nonprofits are currently engaging with tech employees (volunteers or mentors) and other ways these groups could be useful.
Interview Question List
- Tell us about yourself.
- What stage do you consider your organization?
- What are your preferred methods of communication with your team? For example: email, Slack, conference calls, in-person meetings.
- What are your preferred methods of communication with your professional network?
Sub Goal 1 Questions
- Tell us about a recent time that you needed help with a task related to your work.
- What ultimately enabled you to solve the problem at hand?
- Where do you turn for support if your first attempt at solving a problem fails you?
- When you have a problem, how do you decide where to go?
- Where or who would you not feel comfortable turning to for support in the face of a problem?
- Tell us about a time that an employee came to you with a question that you couldn’t answer. What was the first action you took when guiding the person towards an answer?
Sub Goal 2 Questions
- Tell us about a time that an external tech employee was helpful to your tech nonprofit.
- What has previously motivated you to seek support from someone who works in tech?
- Is there anything that would have made finding a connection with a tech person easier?
- When was the last time you met someone who was not a direct connection through your personal network?
- If you needed support from a tech employee tomorrow, where would you go to find one?
- How do you stay connected to a broader tech nonprofit community?
Research the Market Landscape
Once you have a deep understanding about the user you want to serve, it’s critical to take time to survey the landscape. This will be helpful – not just in thinking about what you build – but in how you communicate your impact to funders and followers. The interwebs are teeming with helpful studies and analyses that will deepen your knowledge about your issue area.
Before you build, you should be able to answer these important questions:
- What’s the market size? In other words: how widespread is the problem I want to solve? How many people does it negatively impact today?
- What will the world look like if I succeed? What’s the potential for positive impact?
- How are my future users currently attempting to solve the problem? Is there an analog solution? And if so, what are the shortcomings of this analog solution?
- Is there anyone else trying to solve this problem? How many “competitive” solutions are out there? What are the benefits and shortcomings of other solutions?
- Are the existing solutions sufficient? (I.e. is there actually a need for a competing product?)
- How can I leverage my nonprofit status to work with – not against – the “competition?”
Test Your Idea with an MVP
This is when the bifurcation between brick and mortar nonprofits and tech nonprofits begins. If you wanted to run a brick and mortar nonprofit – say a soup kitchen – you could bring people into your home and feed them. You wouldn’t have to open the full kitchen to prove that you were capable of finding hungry people in need and feeding them well. This is not the case for tech nonprofits.
Tech nonprofits must build what we call an MVP (minimum viable product). You have to build an MVP early because until you put your solution into people’s hands, you’ll never know if your solution can solve the problem. It doesn’t have to be a fully functioning app. For example, Upsolve, which helps low-income Americans file for chapter 7 bankruptcy, built an MVP on Typeform (essentially a digital form) early on – but only after ample user research which included walking dozens and dozens of clients through the bankruptcy filing process manually.
Let’s say you want to launch a tech nonprofit that helps people find soup kitchens in their community. You have to get people to use your MVP to understand if the product is easy to use, if it delivers the service you promised, and if people are willing to use it. It’s hard to build a great tech product that people want to use. It is certainly harder than feeding people out of your home kitchen. You may have to go back to the drawing board many times before you lock in a solution that best serves your customer.
WHAT?! But I haven’t raised any money! We know, we know. But designing an MVP pilot is both critical and cheap. Conversations with users will only get you so far; observing the way your users engage with an MVP will take you to the next level. Since it’s a minimum viable product, it doesn’t need bells and whistles – nor does it even need to be a fully-fledged tech product. Your MVP can be a clickable demo, basic website, online form, or even a physical space where you’re helping your users IRL.
Keep it to the most basic features in the beginning. We’ve seen tech nonprofits get bogged down with features; you need to figure out which are the most essential. Or as you know we like to say at Fast Forward: keep the main thing the main thing.
Launch a Pilot
Once you have a clear idea of the market landscape and your user’s needs, the next step is to design a pilot using your MVP to determine viability.
Let’s say you’re building an edtech (educational technology) product. You’ve shown your MVP to a handful of committed teachers that are willing to be early adopters. The pilot is an opportunity to get your MVP in front of more teachers in different kinds of classrooms who may not be as committed to you as a founder. Pilot users tend to be a bit more discerning – and that’s a good thing. If you need to get creative in order to reach users who will pilot your product, consider teaming up with groups or organizations that serve your target customer currently using an analog competitive product.
Remember, use validated learnings to iterate as you go. Once you learn a key thing about your user, iterate so you can learn the next new thing! This phase is all about learning. Once you’ve piloted your MVP for enough time that you’ve confirmed, denied, or altered your hypothesis – and you’re confident that you have a viable solution – it’s time to build a beta product.