Pierre Garreau
A group of industry representatives from the Maritime Industry met last week to discuss models of collaboration with startups. The event was called Smart Transformation Hamburg. I heard at that event too many instances of the same buzz words: innovation, digitization, agile, blockchain, machine learning from both side of the wall, corporates and startups alike. In the end, both want a well designed product that customers love, build it rapidly, and for a moderate development cost. That’s the innovation. Yet that innovation is often buried in an aura of noise.
Traditionally, corporates are slow to innovate and do so at a tremendous cost. Think about the year long requirements, budgets and approvals gathering. Think about the length of the execution time frame because of incentive misalignments. Think about mistaken assumptions on the product-market fit. Think about the failing 3 year project which turns into the merger of a start-up doing exactly the same thing, and transforms into a long integration.
So why are start-ups better at building good products, fast? What is it they do well? What is worth protecting in a collaboration model with corporates? Undoubtedly, corporates have plenty to bring to the table: branding, HR, legal, funding and a sales network. The question is: when working with start-ups, or creating new products in house, what part of the start-up do we need to embrace?
I emphasized three things at that event: Fail fast and learn, No hierarchy, and Develop teams. These elements are essential to good product development, and need preserving in a collaboration between start-ups and corporates.
The fail-fast-and-learn philosophy is the contre-pied of the business plan. Start-ups recognize that it is impossible to make accurate predictions three or five years ahead of time. It is impossible to formulate correct assumptions about the product-market fit, the customer acquisition rates or product features that will make the core of your product.
The remedy to this uncertainty, inherent to early stage products, is to formulate assumptions, build experiments to test them, and learn from your customer feedback. Then to formulate news assumptions, and cycle through. This is called the build-measure-learn cycle, described in length in Eric Ries’ The Lean Startup.
This approach to product development incentivizes your teams to release early, and release often. It forces product and business to think in testable hypothesis. It breaks the uncertainty with a sense of continuous learning.
Let the team self organize! You want to create innovation, right? Innovation does not come from a single guru at the top spreading his vision. Sure it helps to have great leaders, and early stage product will need the support and direction of such individuals. However, if you are trying to solve a complex problem, then you will need the creativity of the group, the collective intelligence.
By putting most of the responsibilities on teams - and that includes hiring, firing, budget planning, tech choices, product decisions - you create ownership. By itself, this will increase all standards in your product development. The team - for instance the SCRUM team displayed below - only requires sparks to push them in the right direction, to help them produce their best work.
The topic of hierarchy is often a point of contention for the corporate world. But not only! Young CEO’s coming from the consulting world often struggle with this as well. The idea that one person in charge of one topic so that visibility to the top is maximized is just plain wrong. The team is responsible for a set of feature, for a part of the system, for a piece of the product.
A more complete coverage of this can for instance be found in Management 3.0.
Speaking of teams! The last piece of the puzzle is this famous spark. You have a set of rules on how to build your product - iteratively - and a set of principles for what a team is - empowered. Because you realize that developing new products has a strong component of uncertainty, you focus on these short cycles and your customer feedback. But you need to focus even more on your team. Why? It’s called the pivot.
Uncertainty in the product means it is likely that during the course of its development, you will be deviating course. If your team knows how to work together, the pivot will not create unnecessary lags in development or loss in quality.
This is in essence the idea behind retrospectives, as pictured above. At each iteration on the product, the different stakeholders gather and provide mutual - constructive! - feedback, with the help of a solid SCRUM coach. As illustration of this, I warmly recommend the TED talk of Ray Dalio. While this reference is a bit far fetched, and certainly not part of the agile literature, it is rather positive to see how far one can push the idea of mutual feedback, and reap the benefit of team consensus.
So what model of cooperation between start-ups and corporates? Whether it is a corporate venture, or an organically grown startup-up, the bubble in which the start-up exists needs preserving the three elements discussed above. Short iterations, no hierarchy and team focused. This is probably why mergers or many-shareholders start-ups fail: there is no base for the spark to ignite.