A useful sector study narrows a broad industry into a specific user, buyer, workflow and decision. It triangulates dated public evidence with direct learning, maps incentives and constraints, compares current alternatives and identifies what a small test could resolve. It treats every statistic according to its population, geography, method and date. A sector trend can justify investigation, but it does not establish a customer problem or a venture opportunity.
Why sector labels are not markets
“HealthTech,” “FinTech,” “EdTech,” “Agritech” and “Enterprise AI” group very different buyers, workflows and rules. A sector title can hide the distinction between a payer and user, between a digital feature and a regulated activity, or between a documented need and a commercially reachable buyer. Start the study with a question narrow enough to be disproved.
OECD/Eurostat’s Oslo Manual offers a recognized vocabulary and guidance for collecting and interpreting innovation data. The Manual notes the scope of its statistical collection recommendations, so researchers should not assume one measurement method covers every institutional or market setting. The OECD’s Business Innovation Statistics database organizes comparable indicators by country and industry and reports the period covered for each release. Its aggregated measures provide context; they do not validate a specific product’s demand.
The sector research stack
1. Frame the system. Identify geography, time period, value chain, user, buyer, payer, operator, regulator, supplier and affected groups. Write a one-sentence question and mark excluded use cases.
2. Map the workflow. Document the trigger, steps, handoffs, delays, failures, data and existing tools. Separate what the user experiences from what the institution measures or pays for.
3. Build an evidence inventory. For each source, record publisher, date, geographic coverage, sample/population, method, unit, limitations and the question it can answer. Prefer original regulator, government, standards body, scientific, company filing and institutional sources for factual claims. Keep desk research distinct from primary interviews or observation.
4. Map incentives and purchasing. Identify who benefits, who bears costs, who approves change, who controls required data, who integrates the product, who can block deployment and how procurement works. Include staff workload and the costs of switching or coexistence.
5. Compare alternatives. Include the current process, manual work, incumbent vendors, adjacent tools, in-house development and no change. Review substitutes as well as direct competitors. A product is not differentiated simply because it uses AI or addresses an important sector.
6. Analyze economics and constraints. Document likely pricing basis, frequency of value, implementation effort, gross delivery costs, sales cycle, distribution access and dependencies. For regulated or high-impact contexts, identify the relevant authority and request qualified review; do not infer regulatory status from a marketing label.
7. Create competing hypotheses. State two or more plausible explanations for the observed problem. Examples: lack of software, poor process ownership, data quality, incentives, policy, workforce capacity or a buyer/user mismatch. Choose a test that could distinguish among them.
8. Record a decision. Name what is known, inferred, assumed and unknown; cite sources; state the next experiment and the result that would cause proceed, revise or stop.
Use an evidence matrix
| Question | Evidence type | Example source | What it can answer | What it cannot answer alone |
|---|---|---|---|---|
| Is the workflow common? | Official statistics or administrative data | Relevant government or industry classification data | Scale and trend within its defined population | Whether a specific buyer will adopt a new product |
| What happens in practice? | Direct observation or structured interviews | Authorized users/operators | Workflow, exceptions, workarounds, decision context | Representative prevalence without a suitable sample |
| What do buyers purchase? | Procurement notices, filings, budgets, contracts where public | Primary buyer records | Existing spend, procurement route, vendor landscape | Future demand or private budget availability |
| What constrains the solution? | Official rule, standard, policy or technical documentation | Relevant regulator/standards body | Current published requirements in scope | Case-specific legal advice or product clearance |
| Does the proposed solution help? | Bounded test with baseline | Rights-cleared cases, approved pilot or observed process | Specific test outcome under stated conditions | Transferability, long-term impact or market scale without more evidence |
Adapt the method by sector
- Health technology: distinguish consumer wellness, provider workflow, clinical decision support, devices and care delivery. Consult the relevant health authority and qualified clinical/privacy reviewers for the actual geography and use. Do not imply a product has clinical benefit or regulatory clearance without evidence.
- Education technology: identify learner, educator, institution, subject, age, purchasing authority, accessibility requirements and data custodian. Separate engagement/usability from measured learning outcomes.
- Financial technology: trace the activity, money/data flow, decision authority and customer; identify regulators and licensing questions for the actual activity and jurisdiction. Do not assume that a technology vendor’s label determines its legal status.
- Agritech: map the production cycle, geography, grower/processor/buyer, physical infrastructure, seasonality, risk and input constraints. A short demonstration cannot establish performance across seasons or locations.
- Enterprise AI and B2B SaaS: identify the actual workflow, integration, procurement, support and renewal conditions. Compare AI-enabled features against workflow redesign, automation and existing software.
These are prompts for research scope, not sector findings or recommendations.
A compact sector brief
A useful two-page brief can contain: (1) research question and scope; (2) value-chain and stakeholder map; (3) five dated evidence points with limitations; (4) workflow and buyer map; (5) alternatives and substitutes; (6) constraints and unresolved expert-review issues; (7) three competing opportunity hypotheses; (8) first validation test; (9) source list; and (10) explicit confidence and stop conditions. Do not fill gaps with invented market-size estimates.
Worked hypothetical
A fictional team compares two education-technology opportunities. Public data suggests that both topic areas exist, but does not identify a specific product buyer. Interviews with school staff reveal that one problem is caused by a local reporting process and varies widely by institution; the other has an existing purchasing owner and repeatable workflow but unresolved accessibility and privacy requirements. The team chooses the second topic for further discovery—not because the source data proves the market, but because its next evidence questions are identifiable. No actual institution, customer or result is represented.
FAQ
How large should a sector market be? There is no required market-size threshold in this research framework. Specify the initial segment, countable units, geography, period, source and realistic route to buyers before making a market claim.
Can public reports identify the best startup idea? Reports can help frame opportunity areas and constraints. They do not rank ideas for a specific founder or prove willingness to adopt.
Should every sector guide have the same KPIs? No. Choose measures that reflect the job, buyer, risk and value in that context, and document definitions.
How often should a sector brief be refreshed? Set the review cadence according to the volatility of the underlying evidence and the decision. Recheck dated data, regulation and market structure before a current claim is published.
Limits
This methodology organizes learning; it does not predict winners, provide consulting or investment advice, estimate returns, or replace specialist diligence. The Oslo Manual is a statistical guide with a stated scope, not a venture-screening tool. Every sector claim needs a source whose population, date and method match that claim.
Source notes — reviewed 2026-10-31
- OECD/Eurostat, Oslo Manual 2018 — concepts and guidance on collecting/interpreting innovation data; observe scope limits.
- OECD, Business Innovation Statistics and Indicators — country/industry indicators and dataset coverage as described on the page; not evidence about a specific startup’s demand.
- U.S. SBA, Plan Your Business — general market-research questions and public data resources, not a cross-border sector forecast.
This guide is Silicon Founders editorial material for general educational purposes. Examples are hypothetical. It is not investment, legal, accounting, technical assurance or regulatory advice, and it does not describe an active investment, partnership, client mandate or company result. Source links are provided for context; the editorial framework is Silicon Founders’ synthesis.