How you structure your discoveries decides how usable Harvestr feels six months in. A messy backlog turns prioritization into a chore; a well-structured one makes the right decisions obvious. Here are the patterns we see working.
Problems or solutions: say which
A discovery can describe a problem ("Users can't find the export") or a solution ("Add a CSV export button to the reports page"). Both are fine. What matters is knowing which is which, because you treat them differently:
Problems are for exploration: gather feedback, talk to customers, compare solutions.
Solutions are for delivery: spec, build, ship.
The simplest way to make it explicit is a Type select field on your discoveries, with values like Problem, Solution and Initiative. See Add structure to discoveries with custom fields.
Start broad, split later
The most common mistake: creating dozens of small discoveries early, each with two or three pieces of feedback. Nothing rises to the top, and prioritization becomes a wall of low-signal entries.
Do the opposite:
Create broad discoveries first, such as "Improve dashboard performance" or "Make onboarding self-serve". A few dozen across the whole product is plenty.
Let feedback pile up on them. The signal becomes easy to read at a glance.
Split into sub-discoveries when the work gets close to delivery, and you need to scope specific solutions.
Prioritization meetings then stop being about sorting fragments, and start being about choosing between real bets.
Use sub-discoveries for the solutions
When a broad problem is about to move into delivery, add sub-discoveries for the options you're considering. For example, under "Improve dashboard performance":
"Lazy-load chart components"
"Cache aggregated metrics"
"Reduce the default time range to 7 days"
Each sub-discovery gets its own state, fields and linked engineering issues, while the parent keeps the full picture of customer demand. Sub-discoveries go one level deep. See Turn feedback into product opportunities with Discoveries.
Components for the topic, tags for the intent
Each discovery lives in one component: that's where what it's about belongs (Mobile, Billing, Onboarding). Tags work best for how you'll use it:
Quick win: small, high-leverage work you want to find fast
Deal blocker: tied to lost or at-risk revenue
Roadmap candidate: shortlisted for the next planning cycle
Strategic bet: tied to a company initiative
Pitfalls to avoid
One discovery per piece of feedback. Discoveries exist to group feedback. If each feedback gets its own, you're back to a flat list.
Duplicates from different teams. Sales and Support both spot the same problem and word it differently. Give each component an owner who merges duplicates as they come in. You can also ask HAI to "Find duplicate or overlapping discoveries".
Big discoveries that never move. If one has piled up feedback for a year and a half without changing state, have the conversation: is it a deliberate not now, or are you avoiding it?