Founder research for angel investors

Start with an evidence question, not a founder narrative

A founder’s biography can be compelling and still tell an investor very little about the current company. Begin by writing the claims that must be true for the business to work. A claim might concern a customer’s recurring problem, the product’s ability to fit a workflow, the team’s relevant capability, or a market condition that makes adoption possible. Phrase each claim so that evidence could support or weaken it.

This approach keeps diligence proportional. It discourages a common error: treating a polished announcement, a professional profile, or a single customer quote as proof of everything. A useful research question is specific: “Does the published product documentation demonstrate the workflow described on the company site?” A weak question is broad: “Is this founder impressive?” The former produces observable answers; the latter invites confirmation bias.

Use a simple evidence hierarchy. First-party product documentation, public demonstrations, customer case studies, regulatory records, and published technical work are often direct evidence of what exists or has been said. Independent journalism and analyst material can add context, especially when it identifies a customer, competitor, or market constraint. Social posts and directories can be leads, but they should not carry a central claim on their own. Public sources can also be incomplete or out of date, so each item should retain its publication date and a note on what it does not establish.

Public records can serve a limited but valuable role. For a company subject to public-reporting requirements, the U.S. Securities and Exchange Commission explains that its EDGAR data services provide filing histories and extracted financial-statement data. That makes EDGAR a source for checking a public issuer’s disclosures, not a substitute for conversations with a private company.

Test the product against the customer’s job

Build a public product record

Product diligence should answer a plain question: what does the user do differently because this product exists? Read the company’s home page, documentation, onboarding flows, pricing page where available, release notes, developer materials, and public demonstration. Record the exact user, the workflow, the promised outcome, and the dependencies required for that outcome.

Then look for evidence that the product is usable outside a polished presentation. Public documentation can show whether a team has defined roles, integrations, data inputs, limits, error handling, and support paths. A repository, technical paper, or changelog may reveal how the product is evolving. For software that touches sensitive data or critical workflows, product research should include the company’s published approach to security, access control, logging, incident communication, and responsible deployment. Absence of public detail does not establish a defect; it creates a question for the founders.

The CISA Secure by Design guidance is a useful lens for this review. It frames customer security as a core business requirement rather than a feature added later, and it points to measures such as multifactor authentication, logging, and single sign-on being available without added cost. An investor does not need to perform a technical audit to ask whether the company treats customer protection as a product responsibility, who is accountable for it, and what public evidence supports that answer.

Treat AI and security evidence as operating evidence

For AI-enabled products, separate capability claims from operational evidence. A product may demonstrate an impressive output while leaving important questions about reliability, evaluation, human oversight, data handling, and use limits unanswered. NIST describes its AI Risk Management Framework as voluntary guidance for incorporating trustworthiness considerations into the design, development, use, and evaluation of AI products, services, and systems. Its govern, map, measure, and manage framing can turn vague concerns into focused founder questions: Who is accountable? Which contexts create harm? How is performance measured? What happens when the system behaves unexpectedly?

Look for customer evidence before market arithmetic

Customer diligence is strongest when it describes a real person or organization, a pre-existing problem, and a behavior that changed. Look for customer stories that identify the workflow, implementation effort, and outcome in concrete language. A customer logo without context is a discovery prompt, not verification. If a company provides a case study, distinguish the customer’s quoted experience from the company’s interpretation of it.

The U.S. Small Business Administration recommends combining market research with competitive analysis: market research helps identify customers, while competitive analysis helps define what makes a business distinct. Its market-research questions cover demand, the addressable population, location, saturation, and what customers pay for alternatives. These are useful prompts because they force the research back to behavior. Who experiences the problem? What do they use now? What friction is strong enough to cause a switch?

Public evidence can help build a customer map. Review job listings, implementation guides, integration partners, testimonials, event presentations, support materials, and user communities. Each item can indicate a buyer role, a user role, a sales motion, or a technical dependency. Do not stretch a signal beyond what it says. A public partner page may show a relationship; it does not, by itself, establish adoption depth, retention, or customer satisfaction.

A founder conversation should fill the gaps that public material cannot. Ask for the evidence behind the company’s core customer claim, then ask what the team learned when that claim was wrong. Specific learning is more informative than a rehearsed success story because it connects the founder’s judgment to observed customer behavior.

Research the market as a set of constraints

Market diligence is not a search for the largest possible label. It is an effort to understand the conditions that shape a buyer’s choice. Name the customer segment, the existing alternatives, the budget holder, the procurement or adoption path, and the external conditions that could slow or accelerate use. The SBA’s competitive-analysis guidance also directs researchers to identify competitors by product line and market segment, including indirect alternatives, barriers to entry, and the importance of the target market to competitors.

Read competitor sites, documentation, public pricing, customer materials, hiring pages, and technical announcements. The goal is not to declare a winner. It is to test whether the founder’s differentiation is legible in the market. A useful output is a brief comparison: the customer problem each alternative addresses, the workflow it changes, and the trade-off a buyer makes.

Sector context matters most when it changes the proof a company needs to show. In regulated, security-sensitive, infrastructure, or AI-enabled work, public standards and official guidance can reveal adoption requirements that a simple feature comparison misses. For example, NIST’s framework makes risk management an explicit product and organizational consideration for AI systems. CISA’s guidance focuses attention on whether the product maker bears responsibility for customer protection. These sources do not certify a company; they help an investor ask better questions about a company operating in that environment.

Evaluate the team through artifacts and collaboration

Team research should focus on evidence of relevant work, not prestige alone. Start with the founders’ published technical work, product launches, operating roles, open-source contributions, public talks, and domain-specific writing. Look for a connection between the problem and the skills the team appears to have developed. A founder who can explain a customer workflow precisely may have useful proximity to the problem; a founder who has shipped a relevant system may have useful execution evidence. Both are hypotheses to test, not conclusions.

Examine whether the public record shows a coherent division of responsibility. Product, technical, commercial, and domain responsibilities do not need to map neatly to titles, but the team should be able to explain who makes which decisions and how it learns. Look for continuity across the company site, founder interviews, public materials, and the product itself. Contradictions deserve a neutral follow-up question, not an accusation.

Do not turn diligence into surveillance. Avoid collecting irrelevant personal material, treating online visibility as a proxy for ability, or making judgments from protected characteristics. Keep notes tied to business-relevant claims and publicly available work. When a question concerns behavior under pressure or collaboration, a reference conversation is more appropriate than a search result.

Ask references for observable behavior

References are most useful when they add context unavailable in public materials. Ask the founder for people who have worked with them as a colleague, customer, technical collaborator, or manager. Then, where appropriate, identify additional public professional contacts who can speak to the relevant work. Be clear about why you are calling, respect the reference’s time, and do not request confidential information.

Good questions invite examples rather than verdicts:

• What problem did you work on together, and what was the founder responsible for?
• Tell me about a difficult decision. What information did the founder seek, and how did they decide?
• How did the founder respond when customer evidence challenged an early assumption?
• What was their standard for product quality, reliability, or customer communication?
• How did they handle disagreement with a collaborator?
• What strengths would you want a future collaborator to use well, and what context would help them work effectively with this founder?

Listen for specificity, consistency, and appropriate limits. A valuable reference can describe an event, the founder’s role, and the result without disclosing sensitive details. A cautious reference is not necessarily negative; it may simply be respecting obligations. Record what was directly observed, what was second-hand, and what cannot be corroborated.

Build an evidence log that preserves uncertainty

An evidence log makes the research reviewable. It protects against over-weighting the most memorable source and makes it easier to distinguish fact from interpretation. Write it while researching, not afterward. One row should capture one claim and the source that bears on it.

Field	What to record
Claim	A testable statement about the product, customer, market, or team.
Evidence	The exact public statement, artifact, or reference observation.
Source	Publisher or speaker, title, URL or contact context, and publication date.
Strength	Whether the item is direct, independent, or merely a lead.
Limits	What the item does not demonstrate, including missing context.
Follow-up	The shortest question that could reduce the remaining uncertainty.

Keep direct observations separate from interpretation. “The documentation describes an integration with a named platform” is an observation. “The integration will make adoption easy” is an inference that needs more evidence. Tagging this distinction prevents the final memo from sounding more certain than the record permits.

At the end, write a short synthesis under four headings: product, customer, market, and team. For each, state the strongest evidence, the most material unresolved question, and the next best way to answer it. The appropriate result can be “unknown.” Good diligence narrows uncertainty; it does not manufacture confidence.

Use public portfolio research responsibly

The public portfolio and investor-research pages on this site are a directory of public information, not a record of private company details. Use the portfolio to explore company categories and public descriptions, the investor index to see publicly reported investor research, and the public portfolio context to understand the site’s stated context. Company and investor research may be incomplete, so treat it as a starting point for primary-source checking.

Founders preparing for a conversation can pair this guide with public portfolio and the public portfolio hub. The goal is not to perform for an evidence log. It is to make the company’s claims clear enough that an investor can test them fairly.

Frequently asked questions

What is founder research for an angel investor?

Founder research is a disciplined review of public evidence about the people, product, customers, market, and operating claims behind a company. Its purpose is to separate directly supported facts from open questions and inferences.

What public evidence is most useful when researching a founder?

Primary material is the best starting point: the company website, product documentation, public demonstrations, customer materials, regulatory records where relevant, and the founders’ own published work. Use independent reporting to test context, then record the source and what it actually supports.

What should an angel investor ask founder references?

Ask references for concrete observations: how the founder handled a difficult decision, whether they listened to customer evidence, how they worked with others, and what they would want a future collaborator to understand. Seek consent and avoid asking for confidential information.

How should uncertainty appear in a founder research memo?

Write unknowns explicitly, separate direct evidence from interpretation, and record the shortest follow-up question that could reduce the uncertainty. Do not turn missing public detail into a negative conclusion.