Co-Innovation Builder: how to organize a startup corporate collaboration

A collaboration between a corporate and a startup can take different shapes according to their needs. But their very different cultures can make it difficult. Corship designed a free tool to help those companies to settle the foundations of such a project for a greater success.

Vocabulary

Before going further, let’s check some definitions of concepts we mention in this article:

MOOC
Massive Open Online Course. It’s a course we can take online.

MVP
Minimum Valuable Product. This is the first and the smallest version of a product, containing a minimum amount of features, which is available on the market.

POC
Proof of concept. We call POC a test of a product to validate that it is relevant and has a value for the market.

KPI
Key Performance Indicator. It is a measurable quantity showing an important aspect of the project. It is monitored to track the project health.

TRL
Technology Readiness Level. On a scale of 1 to 9, it measures the maturity of a product.

CORSHIP has developed several tools, in the frame of their MOOC about entrepreneurship. See our article in french: Co-Innovation Journey for Startups and Corporates, un MOOC de la CORSHIP Team. The Co-Innovation Builder is one of them.

At the end of this post, you’ll find references that helped us to write it.

What is the Co-Innovation Builder (CIB)

It is a simple table! But it took a lot of engineering to make it so simple as it gathers many company feedbacks.

So it allows to gather in one place all the required data to drive the collaboration between a startup and a corporate. As those 2 kind of company are extremely different, it is a nice tour de force to have come out to such a simple yet effective tool.

We’ll see how to fill every part of it.
In the following parts, we may call it just the “CIB” to simplify.

How to fill the Co-Innovation Builder

Identification

Like every living document meant to evolve, it must have a version number and a date.

Off course, for each evolution, both shall be updated. It enables to build a complete historic of the CIB and allows to track and understand the previous choices of the collaboration.

Collaboration (center part)

First of all, name the collaboration the CIB deals with. It could be the first of many collaborations between those 2 companies!

This center part shall be field by both the startup and the corporate at once. It is very important that both of them acknowledge, agree and get to grips with all the items of this column.

Goal

This is the common goal of the collaboration, shared by both stakeholders, their “greatest common divisor”. It is the objective of the collaboration. They are now both in the same boat so the Goal is the direction toward they are moving to.

Format

As we already mentioned, the number of shapes such a collaboration can take is virtually infinite. Here are some examples:

• Accelerator: the corporate welcomes the startup into its acceleration program.
• Call for project: a corporate has published a public request for proposal. And it has chosen this startup to collaborate with.
• Means commitment: the corporate has agreed to supply several resources to the startup for the development of its product.
• Co-development: the startup and the corporate will work as equal partner in a product development.

Off course your format can be a very specific mix of several kinds. The benefit of the CIB is to find one that is satisfying for both in order to avoid any misunderstanding.

Outcomes

You describe here what is supposed to come out of the collaboration. What items will be delivered at the end. In my opinion it is important that such outcomes are concrete, factual and obviously identifiable. The outcomes are highly dependent on the companies investments, the goal and the format of the collaboration.

Risks

Every project includes a risks management. What are the metrics to monitor the collaboration health? What could go wrong?

Those risks are also specific to all the previously listed components of the collaboration. To identify the risks on your collaboration, here are some questions to think about:

• What could delay the collaboration?
• What could increase its cost, its budget?
• What could lead the collaboration to a status quo?
• What could lead one of the stakeholder to quit?
• What could stop the collaboration from reaching its goal, its objectives?

KPI & Milestones

While driving any project, you have to monitor the key performance indicators to measure its progression. In addition to such indicators, you may have to gather them trough milestones pacing the life of the collaboration.

Such rationalization ensures a continuous and strong progression, step by step, toward the goal. Then you have a clear roadmap for everyone to be aware of what comes next.

Besides, if a risk gets real, KPI and Milsestones can be updated to overcome the difficulty. As you see, all the CIB components are connected.

The stakeholders sections

This time, each stakeholder should fill its column on its own. Those items describe private elements for each company. But it is important that the other one is aware of those elements to understand the expectations and the means of its partner.

In this current revision, the CIB shows 2 collaborating companies. Off course collaborations can involve more than just 2 actors, therefore each of them should fill out such column.

Drivers

The drivers are the personal motivation for each company to do this collaboration. What make them want to achieve the common goal can be different. Yes, the boat they are in is heading to… America, for example. But one might go to America to see his aunt, whereas the other goes to explore New York!

A startup can be looking for funds, or testimonials to prove its expertise. It may want to test its solution. On the other hand, a corporate can look for innovation, developing a new technology or conquer new markets.

Even if those drivers are personal, they still can be compatible. They’d better be for the collaboration to be working.

Deciders

As we would expect it, it is here that each stakeholder lists the people in charge of making decisions for their company about the collaboration.

According to my own feedback, the fewer deciders for a company, the better. When more and more people are involved to state a topic, the decisions will take time to be settled. It is even more true with corporates where a complex hierarchy can bring inertia which isn’t very compliant with a startup pace or lifespan.

Contributors

This item can help with the reduced number of deciders previously set. The contributors are people whom deciders can refer back to in order to get their expertise. It shows to the other stakeholder the people the company is willing to involve in the collaboration. They can be of any kind: experts, users, a complete department… You name it.

It can be useful to sign a Non Disclosure Agreement with all the people.

Resources

Just like the contributors, the resources are the items each stakeholder is willing to bring to the collaboration. For example they can be:

• software
• expertise
• business contacts
• hardware, tools or special equipment
• time
  If time is a asset to be listed as a resource here, you should detail all the time slots dedicated to the collaboration. If some people can work full time on it, some other may not. This can turn the time into a risk for the collaboration.

Returns

And finally the Returns. To me they are just like the outcomes for the collaboration. Returns are what a stakeholder intend to draw back at the end of the project. They are close to the Drivers but more tangible, more concrete. For example:

• a business contract for the startup
• an exclusive licence for the corporate
• a proof of concept
• a financial gain
• …

Improvement suggestions for the CIB

After several uses of the CIB, we have come to some suggestions or improvement ideas to make the tool even more concrete and practical.

We have to keep in mind that its actual form is very efficient to shape the collaboration. Adding too much features could kill this simplicity and make it more difficult to be adopted. And this simplicity is, in my opinion, what makes the CIB very powerful.

It has a great potential. We could turn it into a bigger tool, such as a Business Plan dedicated to collaboration. It wouldn’t be just a canvas but a whole dashboard where every section could be detailed at will.

KPI ordered within Milestones

“KPI & Milestones” is a first way to improve the CIB in my opinion. Obviously, in any project, KPI and Milestones are very closely connected and it is a very good idea to show them together. But it would be even more efficient to draw a table where milestones are in columns and KPI in rows. Indeed, a KPI value could be set as an objective for a specific milestone. And this objective could evolve through milestones. This representation would draw a roadmap where the collaboration is rationally planned in time.

Let’s take the example of a collaboration aiming to reduce the cost of a process at corporates thanks to a product developped with a startup. Here are 2 KPI to follow, with their own objectives for the end of the project:

• The reduction of the process cost, objective: R = 30%
• The number of users for the product, objective : U = 1000 users

It would be safer to set several sub-objective to reach for each step (milestones) of the collaboration. Like this, it would be easier to back on track if we observe such objectives were over-evaluated:

Anticipate the intellectual property for the outcomes

For a startup, the intellectual property (IP) is a crucial asset bringing future value to the company. In the same time, a corporate has supposedly more assets, and therefore more IP, than the startup to bring to the collaboration. For either the startup or the corporate, IP is a very important element, so they’d rather precisely define which collaboration outcomes belong to whom early in the process to avoid any conflict.

What element each stakeholder bring to the collaboration is clearly defined in the “Resources” section. But what about the element that are created during the collaboration? Actually they are defined in the “Outcomes” section regardless to whom they belongs. This is this last point that should be improved. When an asset is created it whether belong to one company or both (if it is shared).

If it is not shared, it still can be used by the other company. So there is either a property or a usufruct to be settled for each stakeholder regarding each outcomes. This is why I suggest to add 2 sub-column “License” to “Outcomes” section.

Conclusion

The CIB synthesized the main design elements for a startup corporate collaboration. Even though at the moment this article is written, the CIB only knows one revision, we can easily imagine the great structuring potential it has for cooperative projects. Collaboration are almost mandatory nowadays for B2B startups so they can legitimate their solution for the market. But the corporates needs them too because of their constant need for innovation.

CIB, as a normative tool, is satisfactorily agile to guide the stakeholders on any collaboration field that often seems to be a jungle: lots of things to deal with in very little time. The shortest way too a successful collaboration isn’t always the straight line and we all know how a bad communication can be deadly, at least the CIB allows to put everything on the table.

Home page of the Co-Innovation Builder

[Article] Collaborate to innovate : the keys to a successful startup-corporate collaboration by Adèle Yaroulina one of the creators of the CIB

[Article] Co-Innovation Journey for Startups and Corporates, un MOOC de la CORSHIP Team our french article about the Corship MOOC

[MOOC] Co-Innovation Journey for Startups and Corporates, the MOOC itself.

What about you?

Did you know the Co-Innovation Builder?
Have you already use it?
How do you manage the collaborations with your partners?
Do you use others concepts, other frameworks, other methods?

Originally published at https://www.naept.com on September 30, 2020.