At SwitchPitch, we spend a lot of time helping companies find startups. Companies tell us what they're looking for, we identify startups that could be a fit, and they tell us which ones they like and which ones they don't.

We recently looked across more than 1,100 of those decisions, covering more than 100 corporate innovation needs, to see what we could learn. All of the data was anonymized and aggregated. We weren't interested in how any particular company was using SwitchPitch. We wanted to understand what makes startup scouting work better in general.

The biggest takeaway was pretty simple: Finding startups isn't the hard part anymore. Finding the right startups is.

That distinction has become even more important with LLMs. Anyone can now give ChatGPT or Claude a description of what they're looking for and get a pretty good list of companies in seconds. We think that's great. But it also changes what a good technology scouting process needs to do. The challenge is increasingly about having the right data, understanding the need well enough to identify less obvious matches, and having a process for evaluating what you find.

Here are a few things we learned.

Be specific. Really specific.

This is probably the biggest piece of advice I'd give anyone starting a scouting project. Don't worry about making your brief too long. If there are technical requirements, include them. If the solution needs to work with existing equipment, say that. If you need a certain level of commercial maturity, include it. If there are approaches you've already tried or technologies you absolutely don't want, include those too.

There's a big difference between saying, "We're looking for AI solutions for manufacturing," and explaining that you need computer vision technology that can identify very small surface defects on a continuously moving production line, work in real time under variable lighting, integrate with existing camera infrastructure, and already be commercially deployed.

The second version gives a scouting system a lot more to work with.

Interestingly, when we looked at our data, longer briefs didn't automatically lead to higher acceptance rates. I don't interpret that as "keep your briefs short." I think it means more words only help when they provide useful information.

A long brief that explains the problem, technical requirements, constraints, current process and what you've already tried can be great. A long brief filled with general background probably won't improve the results.

Tell us what you don't want

This is easy to overlook. Companies naturally spend most of their time describing what they want, but knowing what doesn't work can be just as useful.

If you've already looked at a certain technology and decided it won't work, say so. If you don't want consultants, tell us. If you only want companies with a commercial product, include that. If replacing a piece of existing equipment is a nonstarter, make that clear.

Every exclusion helps narrow the universe. This is especially important with AI scouting because AI is very good at finding adjacent companies and technologies that may not use the exact terminology in your search. That's one of its strengths, but it also means context matters. Knowing why something isn't a fit can be almost as useful as knowing what is.

Start with the problem, not necessarily the technology

Companies often come to us knowing exactly what technology they want. That's fine when you really do need a particular technology, but sometimes I think companies narrow the search too early.

Instead of just telling us, "We're looking for startups using Technology X," explain the problem you're trying to solve. Tell us what happens today, what's wrong with the current approach, what constraints exist, and what a successful solution would accomplish. Then let the scouting process look more broadly for ways to solve it.

This is one of the things that gets much more interesting with AI. A traditional database search generally starts with knowing what category or keywords to search. AI gives us an opportunity to start with the business or technical problem and work backward toward possible solutions.

That can uncover companies and approaches you wouldn't have thought to search for.

Where you look matters

This is one place where I think the conversation about AI scouting sometimes gets oversimplified.

An LLM can be very good at identifying companies that are already well represented on the web. But if you're trying to find emerging technology, some of the most interesting companies may not have much of a web presence yet.

So the underlying data matters.

If I'm scouting for very early-stage technology, I want to know who has recently received government research grants. I want to look at companies coming out of accelerators. I want to see university technologies and spinouts. I want venture portfolios, startup databases and other sources that may surface a company before it starts showing up everywhere else.

This doesn't mean AI is less important. It's the opposite. AI becomes much more powerful when you give it better data to reason over.

For scouting, the question shouldn't just be, "How good is the AI?" It should also be, "What is the AI searching?"

More startups isn't necessarily better

This was one of the more interesting things we saw in the data. Across the needs we analyzed, there was essentially no relationship between the number of potential startup matches and the percentage that companies ultimately liked.

That makes sense when you think about it. If I'm an innovation manager, I don't really want 300 startups. I want the 15 or 20 startups that are most likely to solve my problem.

Of course, you still need a large underlying universe. If the right company isn't in your dataset, you can't find it. But once you have that coverage, the goal shouldn't be to produce the longest list. It should be to produce the most relevant list.

There's a real cost to false positives. Every irrelevant startup takes someone's time to review. As AI makes it easier to generate huge lists of companies, I think this becomes even more important.

Tell us which requirements really matter

Not everything in a scouting brief is equally important. Maybe the technology must work above a certain temperature. Maybe you'd prefer a company with customers in the U.S. And maybe having an API would be nice to have.

Those are very different requirements, and it helps to spell that out.

Otherwise, a scouting system may reject an excellent company because it misses something that wasn't actually essential. Or it may rank a company highly because it checks eight boxes while missing the one requirement that actually matters.

I'd encourage companies to literally separate requirements into must have, preferred and nice to have. It's a simple thing, but it makes the search much clearer.

Explain why you're looking

Don't just tell us what you're looking for. Tell us why. What are you doing today? What's wrong with it? What have you tried? What would change if you solved the problem?

That context can change the search completely. If you tell me you need a better inspection technology, I'll look for inspection technologies. If you tell me the real problem is that the current inspection requires shutting down a production line for four hours and sending employees into a hazardous environment, there may be entirely different ways to solve the underlying problem.

That's the kind of context that helps both human scouts and AI find less obvious solutions.

Finding the company is only the beginning

This is another place where I think "AI scouting" and actually running a scouting program can be two different things.

Once you've found 20 interesting companies, what do you do with them?

You need enough information to compare them. What does the company actually do? How mature is it? How much has it raised? Who are the investors? Who are its customers? Has it received government funding? Is it connected to a university? What other technologies or companies should you compare it against?

Then your team needs somewhere to capture its own judgment. Which companies did we review? Who liked them? Why? Did we contact them? Did we have a meeting? Did we run a pilot? What happened? Has another team inside the company already evaluated them?

That's why I think discovery is becoming just one part of technology scouting. Finding a company is useful. Building institutional knowledge around that company is much more valuable.

Otherwise, six months later someone runs another search, finds the same startup and starts the process all over again.

Give feedback, and use it

The other big lesson from looking at our data is how valuable feedback can be. Among the startup recommendations that received explicit feedback in our analysis, 59% were rated highly relevant. But the overall percentage isn't really the interesting part. What matters is what happens next.

If we show someone ten startups and they don't like five of them, that's useful information. Were they too early? Was the technology wrong? Were they selling software when the company needed hardware? Did they require changing existing infrastructure? Were they solving a slightly different problem?

Every answer helps refine our understanding of what the company actually wants. I think the future of scouting looks less like describe need → get list and more like describe need → get recommendations → give feedback → get better recommendations.

And over time, that feedback should become part of the company's institutional knowledge. The system should know not just what the internet says about a startup, but what your organization already knows about it.

The way we search for startups is changing

LLMs have dramatically lowered the barrier to technology scouting, and I think that's a good thing. If you're looking for startups in a particular space, you should absolutely see what ChatGPT, Claude or another AI tool can find.

But finding a list is only one piece of the job.

The quality of scouting ultimately depends on how well you've defined the problem, what data you're searching, how well you can evaluate and compare what you find, and whether your organization learns from the work it's already done.

So if you're starting a scouting project, my advice is pretty straightforward. Be specific. Give context. Explain the problem. Include the technical requirements. Tell the system what's mandatory and what's optional. Tell it what you've already tried and what you don't want. And don't be afraid to write a long brief if that's what it takes to explain the problem properly.

Then make sure you're searching more than what's easy to find on the web. Look at startups, but also look at government-funded companies, accelerator portfolios, university technologies and other places where emerging technology shows up early.

And once you find something interesting, don't lose the work. Capture what you learned, compare it against other solutions, share it with the right people and use that feedback to make the next search better.

The goal isn't to find the most startups. It's to find the right ones, understand why they're right, and turn that discovery into something your company can actually use.


This analysis is based on aggregated and anonymized activity on SwitchPitch. No company, individual innovation need, startup or individual evaluation is identified.

Ready to start scouting? See how SwitchPitch compares, or go straight to submitting a need.