Product Discovery: How Public Boards Surface What to Build Next

Product discovery is the process of figuring out what to build before you build it. Traditional discovery involves interviews, surveys, and experiments. A public board adds a continuous discovery layer that works alongside these methods.

Traditional Discovery vs Continuous Discovery

Traditional discovery is episodic. You schedule interviews, run surveys, and synthesize findings. It produces deep insights but requires dedicated effort and captures a point-in-time snapshot.

Continuous discovery happens passively. A public board collects submissions and votes every day without anyone scheduling anything. It captures demand as it emerges, not as you think to measure it.

Both are valuable. A public board makes continuous discovery effortless.

How Public Boards Surface Problems

Users don't submit solutions — they submit problems disguised as feature requests. "Add CSV export" really means "I can't get my data out." The request describes a solution, but the underlying problem is data portability.

A good product team reads through the requests to find the problems:

• Cluster related requests — Five different export requests are one data portability problem
• Read the descriptions — Users often explain their workflow and where it breaks
• Look at vote patterns — High votes on workaround requests signal missing core capabilities
• Monitor new submissions — Emerging themes show evolving user needs

Validating Discovery with Votes

Traditional discovery can lead to building something based on 5 interviews. A public board lets you validate with hundreds of users:

1. You identify a problem through interviews or submissions
2. You post a potential solution on the board as a "Planned" item
3. Users vote and comment
4. High engagement validates the direction. Low engagement suggests reconsideration.

This validation step costs nothing and takes days instead of weeks.

Discovery Signals to Watch

Your public board generates discovery signals continuously:

• Unexpected categories — Requests for things you never considered building
• Cross-feature patterns — Multiple requests that point to a missing workflow
• Frequency shifts — A topic that suddenly gets more submissions
• Power user requests — Advanced needs that indicate where your product should grow

From Discovery to Delivery

The full cycle:

1. Public board surfaces a problem pattern
2. Team investigates the underlying need
3. Solution is posted as "Planned" — community reacts
4. Team builds and ships
5. Changelog announces the improvement
6. Voters get notified — loop closes

Each cycle feeds the next. Users who see discovery leading to delivery submit better, more detailed requests.