How can you generate a company brief and ICP from a website URL?
Generate a company brief and ICP from a URL by safely crawling public same-domain pages, extracting explicit claims about the product, audience, outcomes, and alternatives, then converting those claims into reviewable drafts. Website copy is founder-authored context, not customer validation, so every imported statement should remain labeled as a hypothesis until evidence supports it.
What decision does this guide help you make?
Use the website to bootstrap editable hypotheses, then validate those hypotheses against customers and behavior.
Re-entering a company's public story wastes time, but automatically treating marketing copy as verified research creates false confidence. The useful unit is not the number of notes collected. It is the quality of the decision those notes can support. existing founders moving a business into a structured workspace need to see where a claim came from, whether it repeats, and which assumption it changes. Without that chain, a polished canvas can still hide weak reasoning.
A practical workflow separates four things: raw evidence, the founder's interpretation, the decision being considered, and the next test. That separation prevents a confident sentence from quietly turning into “proof.” It also makes disagreement productive. A teammate can challenge the source or the interpretation without rebuilding the entire board from memory.
How should you approach it step by step?
Start with the decision, collect only evidence that could change it, and end with one observable test.
Do not begin by opening a blank canvas and asking what belongs on it. Write the decision first: the customer, problem, promise, feature, or experiment you are choosing. Then gather the smallest set of relevant inputs. The sequence below keeps research from expanding forever while still leaving room for a surprising result.
- Fetch safely: Restrict the crawl to public same-site pages and block private network targets.
- Extract explicit claims: Separate product, customer, outcome, pricing, and competitor language.
- Draft for approval: Show proposed card changes before writing them to the board.
How do the main options compare?
Compare tools by the job their objects perform, not by the length of their feature lists.
General canvases, document databases, and evidence boards can all hold text, but they create different defaults. A sticky note asks the user to invent structure. A database asks the user to define properties. A purpose-built card arrives with a job and a relationship to the rest of the product decision. None is universally best; the right choice follows the decision you need to make.
Use the table as a selection framework rather than a universal ranking. Collaboration-heavy workshops may favor broad whiteboards. Operational knowledge may fit a database. Early product discovery benefits when competitors, complaints, ICP assumptions, positioning, and experiments remain visibly distinct but spatially connected.
| Approach | Best fit | Main trade-off |
|---|---|---|
| Manual transcription | Maximum human control | Slow and repetitive |
| Unrestricted crawler | Broad collection | Security and relevance risks |
| Bounded import | Fast, reviewable setup | Still requires founder correction |
What should you avoid?
Avoid collecting more material when the real problem is an undefined decision or an untested assumption.
Do not infer traction, satisfaction, market size, or customer pain merely because the landing page claims an outcome. Another common mistake is treating every request as equal. A feature suggestion from a paying customer with an urgent workflow is not the same signal as a casual preference from an unrelated audience. Preserve the source, context, and strength of each signal before combining them.
Do not ask AI to fill gaps with plausible language. Ask it to label what is missing, show which cards support a conclusion, and propose a test. A useful thinking partner should make uncertainty easier to inspect. If it turns a thin board into a confident strategy without showing the missing evidence, it is producing theater, not product judgment.
How does this work inside Plot Workspace?
Plot turns each research input and product decision into a movable card with a specific job.
A founder can give Plot a public domain; the companion can gather bounded site context and propose Company Brief, ICP, Positioning, competitor, Notes, or next-step cards. The founder can keep the evidence near the decision without flattening everything into generic sticky notes. Competitor cards record strengths and gaps. App Review, Video Feedback, Custom Review, and Feedback cards preserve customer language. Company Brief, ICP, and Positioning cards hold the current interpretation. Notes, goals, checklists, and MVP questions turn that interpretation into work.
The Thinking Partner reads the current board context, can point out contradictions, and prepares proposed edits for approval. It does not make a proposed change silently final. That matters because the board remains the source of truth: the founder can see what changed, reject a weak suggestion, or remove stale evidence. Plot currently supports up to 500 recent public app reviews, up to 100 public video comments per request with a 1,000-comment daily account cap, and 10 free Thinking Partner answers per UTC day.
A useful board for this case would place the decision near the center, evidence on one side, and assumptions on the other. The imported board becomes a starting hypothesis that the founder can correct before gathering real evidence. When a new review or interview contradicts the current direction, update the source card first. Then revise the ICP, positioning, or experiment deliberately. The history of the decision stays understandable because the inputs never disappear into an untraceable summary.
This is the practical difference between arranging information and operating from it. The board stays flexible: cards can move as the idea changes. The structure lives inside each card, so freedom does not require starting from a blank rectangle every time. The result is not certainty. It is a shorter path from evidence to a test that can prove the founder wrong before expensive code hardens the assumption.
What else should founders know?
Who is this workflow for?
It is designed for existing founders moving a business into a structured workspace who need to connect research to a concrete product choice. Large teams can use the same logic, but the workflow is intentionally understandable without a dedicated research-operations department.
How much evidence is enough to make a decision?
There is no universal count. Look for repeated pain in the intended customer segment, a costly or awkward workaround, and evidence strong enough to justify one small falsifiable test—not a full roadmap.
Should every customer request become a feature?
No. Preserve the request, its source, urgency, and surrounding job. Several requests may point to the same underlying problem, while one loud request may be irrelevant to the customer you chose to serve.
Can an AI thinking partner replace customer research?
No. It can organize board context, compare claims, flag contradictions, and draft changes. It cannot manufacture customer evidence. Interviews, public feedback, behavior, payment, cancellation, and test results remain the inputs.
What should happen after the board is organized?
Choose one decision and run the smallest credible test. The imported board becomes a starting hypothesis that the founder can correct before gathering real evidence. Record the result beside the original assumption so the next decision starts from evidence rather than a reconstructed memory.