How to Product Discovery for Open Source Projects - Step by Step
Step-by-step guide to Product Discovery for Open Source Projects. Includes time estimates, tips, and common mistakes.
Product discovery in open source is different from discovery in a traditional SaaS company. You are balancing user needs, maintainer capacity, community expectations, and often limited funding, so a lightweight, repeatable process helps you validate demand before contributors spend time building the wrong thing.
Prerequisites
- -Access to your project's GitHub repository, including issues, discussions, pull requests, and labels
- -A way to gather community feedback outside GitHub, such as Discord, Slack, Matrix, Discourse, or a mailing list
- -Basic contributor and user data, such as recurring issue themes, support requests, download stats, package manager metrics, or docs traffic
- -A documented project scope or roadmap, even if lightweight, so you can evaluate whether requests fit the project direction
- -At least one maintainer or community lead available to review findings and make prioritization decisions
Start by deciding what kind of decisions this discovery round should support. For an open source project, that might mean identifying the most valuable feature to ship next, deciding whether a request belongs in core or a plugin, or validating whether a hosted or sponsored feature has broad community value. Write down the goal in one sentence and define the user segment you are listening to, such as self-hosters, enterprise adopters, plugin developers, or first-time contributors.
Tips
- +Limit each discovery cycle to one decision area, such as integrations, performance, onboarding, or governance tooling
- +Separate requests from end users and requests from contributors because they often reflect different problems
Common Mistakes
- -Starting discovery with a vague goal like improving the project without naming a concrete outcome
- -Treating every GitHub issue as equally relevant, even when some are outside the project's stated scope
Pro Tips
- *Create a dedicated label set for discovery, such as validated-problem, needs-research, strategic-fit, and plugin-candidate, so triage stays structured over time.
- *Review closed issues every quarter to spot recurring requests that were previously dismissed because they arrived too early or lacked enough evidence then.
- *Track whether feature requests come from maintainers, end users, integrators, or sponsors, because each group signals a different kind of product risk or opportunity.
- *When a request has strong demand but weak maintainer capacity, publish an RFC or implementation brief to attract contributors without committing core maintainers too early.
- *Document why a request is out of scope in one reusable public note, then link back to it whenever similar issues appear to reduce repetitive triage work.