A workspace for keeping claims connected to evidence

A folder of saved links tells a team what it collected. It rarely explains which source supports a particular conclusion, why another document was excluded, or what changed after the last review. A focused software product could help connect those pieces. DoYourOwnResearch.com could be the address for that workspace, giving the product a plain invitation to investigate. The scenario below is an illustrative concept, not an existing software service.

Choose a user with a recurring handoff

Start with a small research team that prepares briefs for other people: a product discovery group, an editorial desk, or a consulting team studying a non-regulated subject. The useful moment to examine is the handoff. A colleague receives a conclusion and asks where it came from. Today, the answer may involve opening several documents, searching chat, and asking the original researcher to explain their notes.

Interview potential users about one recent handoff. Ask them to show the actual documents they are permitted to share. Where did they lose context? Which questions caused rework? What information could not leave their organization? Avoid asking only whether an evidence tool sounds useful. A concrete example gives the founder a workflow to improve and constraints to respect.

Build the smallest claim-to-source loop

The first prototype could contain a question, a claim, and a linked source passage. A researcher saves a URL, adds the document title and date, selects the relevant passage, and writes a short explanation of how it relates to the claim. A reviewer can open the claim and reach the passage in one clear sequence. Test this loop before adding dashboards, automated summaries, or a large taxonomy.

Imagine a team comparing documentation platforms. One claim says a particular product supports exporting content in a portable format. The researcher attaches the official documentation section and records the date checked. Another teammate notes that the documentation does not describe image handling. The workspace should preserve that limitation beside the claim, where the decision maker will see it.

Respect what existing tools already do

Reference managers provide useful capabilities that a new product should understand. Zotero supports collections and tags, including placing one item in multiple collections. A founder should compare the proposed workflow with those established features and determine where a new interface actually saves effort. A different brand and a fresh sidebar are not enough to justify switching tools.

The possible distinction here is the relationship between a source and a team conclusion. A single document may support one claim, challenge another, and be irrelevant to a third. Represent those relationships explicitly. Keep a person's explanation separate from an excerpt so the product does not present interpretation as original source text. Make the distinction visible in both the interface and exported files.

Design for revision from the beginning

Research changes. A source gets updated, a colleague notices a missing qualification, or the question itself becomes narrower. The workspace should retain who changed a claim, when the change occurred, and what the previous version said. Start with a simple readable history rather than an elaborate activity feed. Reviewers need enough context to understand the current position and revisit a consequential edit.

Use stable identifiers for questions, claims, and source records. If a title changes, the links between records should still work. Provide a way to mark a source as superseded without deleting the earlier record. Deletion, permission changes, and shared links need careful product decisions because a team may rely on evidence that another person can no longer access.

Make export part of the first release

A research team may need to share a brief outside the product or retain a record when a project closes. Test an export that includes the claims, source titles, URLs, dates, and qualifications in a readable format. A pile of disconnected files would lose the relationship that made the workspace useful. Portability is also a practical sales concern for buyers who cannot commit their institutional memory to an unproven vendor.

Zotero's notes documentation distinguishes notes attached to an item from standalone notes. That is a helpful design reference for thinking about context: some observations belong to a source, while others belong to the larger question. A new workspace should make that difference clear without asking users to learn a complicated data model.

Keep the first sales conversation narrow

A plausible first offer is a paid pilot for one team working on one recurring brief. Agree on the number of users, the supported file types, the access controls, and the support available during the pilot. Security and privacy requirements may rule out some customers until the product matures. Make those limits explicit during qualification rather than promising broad organizational readiness.

Distribution could begin through research-practice communities and direct demonstrations to teams with the same handoff problem. Show a real permitted example moving from a messy source collection to a reviewable claim. Ask prospects to perform the task themselves. The most useful feedback may be the point where they abandon the prototype and return to their existing document.

Test before building the platform

Create a clickable prototype and observe five researchers working through the claim-to-source sequence. Record completion problems, misunderstood labels, and missing context. Five sessions are an initial discovery exercise, not a statistically representative market study. Use what you learn to revise the interaction and decide whether a working pilot is justified.

The domain acquisition can sit alongside that product discovery. A founder considering DoYourOwnResearch.com can send an inquiry describing the intended user, the evidence workflow, and the proposed scope. The domain is the asset offered here; development, customer acquisition, and the responsibilities of operating the software would belong to the future business.