Most developers can imagine useful software. The harder skill is learning whether the idea matches what people actually need. In the Ideation & Discovery phase, your job is not to prove that your first idea is right. Your job is to understand the problem well enough to decide what is worth building.
User discovery interviews are one of the simplest ways to do that. You talk with the people affected by the problem, listen carefully, and look for patterns. This is especially important for Open Source projects built for public benefit, where the people who need the software may not be the same people who fund it, maintain it, or talk about it online.
Software for Progress Foundation supports Open Source developers because useful tools should reach the people who need them, not only the people who can pay. Good discovery helps you build toward that mission from the beginning.
What a Discovery Interview Is
A discovery interview is a short conversation focused on someone’s real experience with a problem. It is not a sales pitch. It is not a demo. It is not a survey where you try to collect quick yes-or-no answers.
The goal is to learn how the person currently handles the situation, where they get stuck, what workarounds they use, and what would make a meaningful difference.
For an Open Source project, discovery interviews can help you answer questions like:
- Who experiences this problem most often?
- What are they using now, even if it is messy or manual?
- What makes existing tools too expensive, too complex, inaccessible, or untrusted?
- What constraints matter, such as low bandwidth, privacy needs, language, disability access, or limited technical support?
- Who would benefit if this problem were solved well?
Start With the Right People
Do not only interview other developers unless developers are your intended users. If you want to build education software, talk with teachers, students, tutors, school volunteers, or caregivers. If you want to build accessibility tools, talk with disabled users and people who support them. If you want to build security software, talk with the people who must make safe choices under real pressure.
You do not need a huge research study. Five thoughtful conversations can teach you more than weeks of guessing. Try to include people with different levels of technical comfort, different devices, and different environments.
A simple outreach message can be enough:
Example: I am exploring an Open Source tool to help small community learning programs track student progress without expensive software. I am not selling anything and have not started building yet. Would you be open to a 25-minute conversation about how you handle this now and what gets in the way?
That message works because it is honest. It makes clear that you are learning, not recruiting users for a finished product.
Ask About Their World, Not Your Idea
A common mistake is asking, “Would you use an app that does this?” Most people want to be supportive, so they may say yes. That answer feels good, but it does not tell you much.
Better questions focus on past behavior and current pain:
- When was the last time this problem came up?
- What did you do in that moment?
- What tools, spreadsheets, paper forms, or messages did you use?
- What was frustrating, slow, confusing, or risky?
- What happened when the process failed?
- Who else was affected?
- What have you already tried?
- What would make this easier without creating more work?
Notice that none of these questions require the person to design your software for you. They help you understand the job the software might need to do.
Listen for Constraints
Public benefit software often fails when developers ignore constraints. A tool can be technically impressive and still be unusable for the people it is meant to help.
During interviews, listen for constraints such as:
- Access: Does the person have reliable internet, a modern device, or admin permissions?
- Cost: Are paid tools impossible, unpredictable, or hard to approve?
- Time: Would the tool save time, or would it add another system to maintain?
- Trust: Is sensitive data involved? Who needs to feel safe using the tool?
- Accessibility: Does the current process exclude people with disabilities?
- Language and literacy: Would the tool need plain language, translation, or non-text workflows?
- Support: Who helps when something breaks?
These details can shape your entire project idea. They may lead you away from a complex platform and toward a small utility, offline-first workflow, browser extension, command line helper, or documentation tool.
A Concrete Example
Suppose you want to build an Open Source reading practice app for after-school programs. Your first idea is a polished web app with accounts, dashboards, badges, and analytics.
After interviewing six tutors, you learn something different. Many programs share old tablets. Internet access is unreliable. Tutors do not want another login system. The biggest pain is not motivation badges; it is quickly finding age-appropriate, printable reading passages and tracking which student read which passage last week.
That discovery changes the idea. Instead of starting with a full learning platform, you might explore a small Open Source library of printable passages, a simple offline tracker, and a format that programs can adapt. The result may be less flashy, but more useful. It is closer to the real need.
Take Notes You Can Actually Use
Right after each interview, write down what you heard while it is fresh. Do not only record feature requests. Capture the situation.
Use this structure:
- Person: Who they are and what context they work in.
- Problem moment: A specific time the problem happened.
- Current workaround: What they do today.
- Pain point: What makes it hard, expensive, risky, or inaccessible.
- Constraint: Any limits around devices, time, privacy, language, or support.
- Quote: One sentence in their own words.
- Open question: Something you still need to learn.
After several interviews, look for repeated patterns. One person’s opinion is useful. A repeated problem across different people is a stronger signal.
Know What Not to Build Yet
Discovery is not only about finding ideas. It is also about avoiding premature commitments. If people are not currently trying to solve the problem, the pain may not be strong enough. If the problem depends on policy, staffing, or funding rather than software, code may only help a small part. If a trusted Open Source project already solves it well, your best contribution may be joining that project instead of starting a new one.
This is not failure. It is responsible development. Sustainable Open Source starts with choosing problems where software can make a real difference and where maintainers can stay focused over time.
TL;DR
Before you build, talk with the people affected by the problem. Ask about their current experience, not whether they like your idea. Listen for workarounds, constraints, access barriers, trust concerns, and repeated pain points.
A few honest discovery interviews can save months of building the wrong thing. More importantly, they help you create Open Source software that respects real needs and serves the communities you hope to support.