Working with startups without wasting their time or yours

To work well with startups, start from a problem you have already agreed to solve, give one person the authority to decide quickly, and run a short, paid pilot with success criteria written before it starts and a contract waiting if it succeeds. Most corporate-startup collaborations fail not because the technology is wrong but because the large organisation moves at its own speed, changes its mind, and treats the pilot as an experiment with no consequence. For a startup, a six-month unpaid "proof of concept" that leads nowhere can be the difference between surviving and not.

This piece is about the practical mechanics. For the wider picture of organisations solving problems together, see Ecosystem innovation.

Why these partnerships go wrong

The two sides run on different clocks. A startup measures runway in months; a large organisation approves budgets annually. A startup's founders make decisions in a day; a corporate decision may need four signatures and a procurement review. Neither is wrong, but the gap produces the same failures again and again:

• The scouting trap. An innovation team meets fifty startups, holds a demo day, and has no business unit ready to use any of them.
• The endless pilot. The test drags on because nobody agreed what "success" meant, so nobody can declare it.
• The free consultancy. The startup spends weeks tailoring its product to your requirements, unpaid, and then hears nothing.
• The procurement wall. The pilot works, the business unit wants it, and then supplier registration, security review and tendering take a year.

The fix is not enthusiasm. It is structure on your side.

How to do it, step by step

1. Start with a problem a business unit owns. Not "we want to explore AI", but a named problem with a named owner who has budget and will change how they work if a solution fits. Write it as a how might we question: "How might we cut the time our claims team spends reading handwritten forms?" If no business unit will sign up as owner, do not approach startups yet.

2. Decide which kind of relationship you want. There are broadly four, and confusing them wastes time:

   • Buy: you become a customer of a product that already works. Fastest and most common.
   • Pilot: you test a working product in your context before buying.
   • Co-develop: you build something new together, usually with shared IP questions.
   • Invest: you take equity. A different team, different terms, different timescale. The "venture client" approach, which BMW's Startup Garage popularised from 2015, argues that most organisations should start by buying and piloting rather than investing, because being a startup's customer creates value for both sides fastest.

3. Fix your internal path before you search. Before you contact anyone, find out what your organisation needs to pay a small supplier: registration, security and data review, contract template, payment terms. Agree a fast track for pilots below a set value. If you cannot pay a startup within weeks of a successful pilot, solve that first.

4. Search with the problem, not a call for "innovation". Describe the problem, the data and environment available, and what a successful result looks like. Startups that cannot solve it will self-select out. Shortlist with a short weighted decision matrix: fit to the problem, maturity of the product, ability to deliver in your environment, team.

5. Give a decision within days, not months. Meet the shortlisted startups, then decide. Tell those you decline that you have declined, and why. Silence costs a startup more than a no.

6. Write the pilot plan together, on one page. State the hypothesis, what will be measured, the threshold for success, the duration, who on your side supports it and what happens if it passes. A hypothesis test format works well. Use assumption mapping to find the riskiest assumption, and test that one first.

7. Pay for the pilot. Even a modest fee changes the relationship: both sides take it seriously, the startup can staff it, and your organisation has already passed the procurement steps it will need later.

8. Staff it on your side. A pilot needs a business owner who will use it, a technical contact who can grant access, and someone who clears blockers. A RACI for the pilot takes ten minutes and saves weeks.

9. Decide on the date you set. At the end, compare results against the threshold you agreed. Pass means move to a contract on terms set in advance. Fail means stop and say so. "Let's extend it a bit" is the answer that wastes everyone's time; if you extend, extend once, for a reason, with a new date.

10. Plan the rollout before the pilot ends. Who will run it, what systems it connects to, who trains users. A rollout checklist keeps the hand-over from stalling.

Do's and don'ts

Do

• Name a business owner before you contact a single startup.
• Tell startups early what you can pay, how fast and through what process.
• Agree success criteria before the pilot starts.
• Pay for pilots, even modestly.
• Protect the startup's IP. Be clear about what you need rights to, and do not ask for more.
• Introduce them to other units if it works. A reference from you can matter more than the contract.

Don't

• Don't run demo days without owners in the audience who can buy.
• Don't ask for bespoke development during a pilot. Test what exists.
• Don't change the person in charge mid-pilot without a proper hand-over.
• Don't let legal review start after the pilot succeeds. Start it in parallel.
• Don't use pilots to collect free ideas for an internal build. Startups talk to each other, and your reputation spreads.
• Don't measure your programme by how many startups you met. Measure how many pilots became contracts.

Illustrative example

Illustrative. A mid-sized insurer in the Netherlands wanted to reduce the time its claims team spent on household water-damage claims. The claims director agreed to own the problem and set aside a small pilot budget.

Before searching, the innovation lead spent three weeks with procurement agreeing a fast track: pilots below a set value could use a short contract template and pass a lighter security review, as long as no customer data left the insurer's systems. The call described the problem, the anonymised claims data available and the target: cut handling time on simple claims by a clear margin while keeping accuracy at least at current levels.

Twelve startups responded. Four were shortlisted using a weighted matrix; two were interviewed; one was chosen within ten days, and the other three were told why they had not been selected. The pilot plan fitted on one page: eight weeks, three claims handlers, a defined set of claim types, a threshold for success and a pre-agreed licence price if it passed.

The pilot met the threshold on most claim types and missed it on one. The claims director signed the contract for the claim types that passed, with the remaining type moved into a second, shorter test.

Questions people ask

Should we pay startups for a proof of concept? Yes, in most cases. A paid pilot is taken seriously by both sides, lets the startup assign people to it, and forces your organisation through the procurement steps it will need anyway. Unpaid proofs of concept tend to drift and favour startups that can afford to work for free, not those with the best product.

How long should a startup pilot last? Long enough to measure the result you agreed, and no longer. For a working product in a defined process, six to twelve weeks is common. If the pilot needs six months, you are probably co-developing, which needs different terms.

Who owns the IP in a corporate-startup pilot? Normally the startup keeps ownership of its product and anything it brings, and you keep your data and anything your staff create. Agree in writing what rights you need to use the results. Your legal team decides the details; the principle is to ask only for what you genuinely need.

Where to go next

Use how might we to frame the problem before searching, a weighted decision matrix to shortlist, and a hypothesis test to write the pilot plan. For the bigger picture read Ecosystem innovation; for a public call to many startups at once, see Open innovation vs co-creation vs crowdsourcing, and for research partners, Partnering with universities on innovation.