Recruit roadmap evidence beyond the issue tracker

An issue tracker records problems that someone could recognise, describe and choose to report. A product roadmap also needs evidence from people who worked around a problem, abandoned adoption or never learned the project’s vocabulary. Deliberate interview recruitment can bring those workflows into view. Counting existing requests alone gives the most visible participants an advantage that may have little to do with the cost of the underlying problem.

This is a recommendation about where to look for product evidence. It does not turn interviews into a representative market survey. Looking back from November 2026, Rust’s Vision Doc process provides a useful account of both the value of broader conversations and the limits that remain after substantial research. The transferable lesson concerns recruitment and concrete work, rather than a ranking of languages or a measure of developer productivity.

Separate two research activities

The 3 December 2025 Vision Doc retrospective describes a survey with about 4,200 responses followed by more than 70 interviews of roughly 45 minutes. Recruitment included contacts, conferences and meetups, including a Python meetup. The authors describe difficulty finding people who disliked Rust and acknowledge selection bias. They propose a dedicated research team; that proposal is not evidence of a statistically representative adoption study.

The 17 November 2025 State of Rust Survey launch is a separate annual survey invitation, including people who had not yet used Rust but intended to. Its announced response deadline was 17 December. That launch must not be presented as the completed source of the Vision Doc interviews described on 3 December. Keeping the activities separate prevents a plausible chronology from replacing the documented one.

The retrospective also acknowledges that the work did not provide enough technical detail to settle specific feature priorities. That is an important limit on interpretation. Discovering recurring difficulties can justify a more focused investigation without deciding the implementation. The evidence can improve the next question even where it cannot yet choose the next feature.

Silence has several possible meanings

An absent issue might mean the software works well. It might also mean a person found a workaround, assumed the limitation was intentional or stopped using the product before learning where to report it. The tracker alone cannot distinguish those explanations. Treat silence as missing evidence until another source helps explain it, rather than automatically counting it as satisfaction.

Project vocabulary can create a further filter. A newcomer may describe a failed business task while maintainers organise discussion around internal components. Searching the tracker for the component name then misses reports written in the user’s terms. Interviews can preserve both descriptions: what the person tried to accomplish and how the project eventually classified the obstacle.

Recruitment should follow that distinction. Speak with active users who file issues, active users who do not, and people whose adoption stopped, where they can be reached. These are proposed recruitment groups, not observed market segments or quotas validated by Rust’s process. The purpose is to expose different routes into silence, with the remaining gaps recorded explicitly.

Ask for an episode before a feature

A useful conversation starts with a recent task the person actually attempted. Ask what they were trying to finish, what happened next and what they did when progress stopped. A request for a favourite feature can invite a design answer before the team understands the problem. An account of a specific episode supplies constraints that a feature name often hides.

Workarounds deserve particular attention. They can show a cost the product’s own telemetry never captures, such as work completed outside its boundary. A person may report successful completion in the application while still copying information elsewhere to make the result usable. This is a possibility to investigate, not a claim that a particular Rust user or AL+ customer followed that workflow.

Record the episode separately from the proposed remedy. An interviewee can be an excellent witness to a difficulty without knowing the cheapest implementation that would resolve it. Preserving that distinction lets designers compare several remedies against the same task. It also avoids turning a memorable suggestion into a commitment simply because the conversation produced a compelling story.

Broader recruitment still selects people

The strongest counterargument is that interviews are expensive and self-selecting. People willing to meet a project team may differ from people who have already moved on. A conversation can uncover a serious problem without showing how common it is. More diverse recruitment improves coverage of experiences; it does not automatically produce population weights or a defensible market percentage.

A small product team can respect that limit by choosing a narrow decision. Investigate why one kind of onboarding stops or why a recurring export needs manual repair. Record how participants were found and which missing groups might change the conclusion. A bounded study with an honest gap can inform a reversible decision more usefully than a broad claim based on an unexamined sample.

Existing support evidence remains valuable. Issue histories can document reproduction steps, affected versions and the cost of unresolved defects. Interviews should connect missing workflows to that evidence where possible, not discard it. The aim is a richer account of the task, with different sources answering different questions about mechanism, frequency and consequence.

Turn findings into a decision with limits

Before prioritising a feature, state the problem, the affected workflow and the evidence that another design would address it. Name any remaining uncertainty about reach or implementation. A research proposal is a next step, and an interview theme is a hypothesis to investigate. Neither should become a guaranteed adoption gain in a business presentation.

For custom software development, include recruitment beyond the request list when defining a product investigation. Agree which decision the conversations will inform and what would require further evidence. The roadmap can then reflect people whose work never became a well-formed issue, while retaining a clear distinction between a discovered workflow and a measured market claim.