Haven’t heard of prove-out journeys yet? Neither had we until we wrote Open Innovation Works. An important open innovation engine was going unrecognized and under used, so we named it!
Large organizations are known for their alphabet soup of partnership arrangements, here are a few in alphabetical order (see descriptions below): JDA, JRA, JV, LOI, M & A, MTA, MOU, NDA, POC, pilot, SAFE, SiPA, plus straight-up sales and licensing, and many more.
In common practice, the big org talks to their potential partner a few times, and together the parties choose which agreement to sign based on current circumstances. Once the terms are completed, the partnership is over (without ruling out another in the future).
The most effective partnership leaders intentionally plan for a string of agreements as a chain. This is what we mean by a prove-out journey. It might look like this:
“Initial conversations made us curious enough to start with an NDA (non-disclosure agreement). If what we learn under this protection is compelling, let’s test using an MTA (materials transfer agreement). If the material meets our requirements, then let’s do an internal proof of concept (POC) to find out how it integrates with our technology. If it works, then let’s develop it further through a JDA (joint development agreement) in preparation for a real-world pilot. In the pilot, we go forward together to see what the market says. If the market says yes, perhaps a joint venture (JV) is in order, and ultimately maybe the BigCo acquires the partner through a merger or acquisition (M & A).”
If -> then, if -> then, if -> then.
The cognitive move is to imagine the entire journey in advance. The deliverables and goals for each agreement are designed as a scientific-method-style stage-gate process. In other words, clear one hurdle at a time, in order. The MTA is designed specifically to develop evidence for or against the hypothesis that a POC could be successful. The POC is designed to develop evidence for or against the hypothesis that a pilot could be successful, and so on. You’re proving out your chain of hypotheses all along the journey.
Some organizations do this instinctively. Putting a name on the concept allows us to understand it and measure it as a whole.
To make prove-out journeys really sing, look at the incentives provided to the team responsible for partnerships. Are they rewarded by sheer number of partnerships? You might get volume without much quality. Is the reward delivered for the success of each individual agreement? Though you might get quality within a narrow low-risk band, you might not learn much. Or is your staff rewarded for successful, successive validation or invalidation of a thoughtful chain of hypotheses?
There are at least three flavors of hypothesis to consider: technology (can this work?), business (can this make money?), and interpersonal (do we want to work with these people?).
One last note: If you’re asking a partner to travel a (potentially) long road with you, you’ll need to make sure they enjoy the trip enough to keep going. So find the sweet spot: Be founder-friendly without compromising your own boundaries.
| Agreement type | Suitable hypotheses | How to be partner-friendly so your partners stay on the journey with you. |
| Initial meeting | Partner has a story compelling enough to commit to the rather extensive internal research required to sign an NDA (non-disclosure agreement) which would require internal research about potential overlaps with the internal pipeline. | Be reachable (or tell people when you’re not). Be transparent about what next steps are possible (e.g., if you can’t sign NDAs, say so right away so the partner can accept this, or disqualify you, saving everyone’s time) |
| NDA (non-disclosure agreement) | Technology is at the right Technological Readiness Level (TRL) for us to be able to test it. Partner’s public story and private story line up appropriately. | Set appropriate expectations for what has to happen behind the scenes before you can sign an NDA, and how long it’s likely to take. |
| MTA (materials transfer agreement) | Partner’s material has the right characteristics to solve a known problem, or characteristics close enough to be worth exploring. Partner is reliable and trustworthy, meeting deadlines and delivering appropriately. | Pay costs for the material, and the time and resources required to produce it. Provide feedback on your test of the material. Be reliable and trustworthy yourself. |
| POC (proof of concept) | Partner’s material fits with corporate’s technology stack in the lab. Collaboration with this partner is smooth, transparent and productive. | Provide as much in-kind support as you can — your space, your equipment, your mentoring. Be transparent and productive yourself. Communicate frequently, even if your actions take more time. |
| JDA (joint development agreement) or JRA (joint research agreement) | Combined technology functions in the real world. Science and tech questions are solvable. Collaboration with this partner continues to be successful while investigating true uncertainties. | “ |
| Pilot | Combined technology is valuable to customers. Partner is mature and strategic about the business side of the work. | “ |
| Endpoint: Licensing or M & A | Technology and business value justify commitment. Partner is desirable. | Be fair in your valuation. |
The possible racecourses are many, but the journey is the same — line up your agreements with intentionality and validate as you go, for the win.