The Parable of Frank de Boer – Evolution, not Revolution in Building Product Teams
On June 26, 2017, English football team Crystal Palace enthusiastically announced the appointment of the great Dutch defender Frank de Boer as its new manager. Admittedly he was joining after a disappointing spell in Italy, but his success with the Dutch champions, Ajax, with whom he won the Champions League four consecutive times, was heralded as the template for his vision at Crystal Palace. He announced he would take a middling team and turn them into a whirring, possession-based team emulating the lofty ideals of Total Football.
He was fired four games into his tenure – the shortest stint of any manager in the Premier League’s history.
Frank de Boer was fired as Crystal Palace manager after only four games
So what happened?
De Boer had arrived with the promise of delivering “evolution – not revolution”. He would over a period of time mould the team that had finished a measly 14th (out of 20 teams) the year before into a team comfortable with more advanced tactics. Both he and the owners of the club advocated this plan in a number of press conferences and laid it down as the roadmap for a long-term project. However, for a multitude of reasons, the management brought in only two new personnel to help with this evolution, and De Boer instead opted for revolution rather than evolution and tried to force a system on players who just weren’t built for it. The result was the loss of four games on the trot, without a single goal scored – the worst start by the team in 93 years!
The Product Connect
So how does this relate to product building and management? If you build a team from scratch it can be easy to implement new ideas and methodologies. If the pegs don’t fit into the holes, you find other ones that do. However, in most cases, as product managers and product builders, you will not have this advantage. Instead, like De Boer, you will probably be parachuting into existing organisations with existing teams and existing working methods. And unless the organisation you work for is highly accommodating or has infinite resources to spare, the likelihood that you will be allowed to make wholesale changes to team structures is almost nothing.
Instead you will be asked to implement your vision while making do with existing resources. In many cases these resources may be multi-shaped pegs for your round-shaped vision. You might want to implement different methodologies such as agile or Kanban or scrum, but the teams at your disposal might not be well-versed in these styles. Worse, they might not all be up for it.
Evolutionary Product Team Building
Given that you might not be able to change everything you want overnight, what other options do you have? Throw in the towel and jump ship? Or raise a storm and demand your every need be met? Personally, I’d recommend a mix of the following approaches:
- Understand Your Team: One size does not fit all! One of the basic mistakes product people make while trying to push processes is to not understand the strengths and limitations of the teams they’re working with. If things don’t click, there is frustration and blame-gaming. Instead, try to map out the different strengths and weaknesses of your team, and those of the different methodologies you want to employ. Each one requires specific skillsets in terms of ownership, independence and speed. Find the framework that fits your team best, instead of the other way round.
- Bring In the ‘Beacons’: One of the best ways to evangelise your ideas is not through yourself but through the product team members you bring in who are well-versed in the methodologies you want to implement. These people become the exemplary ‘beacons’ on the ground to inspire and drive the teams. Think of great managers in any sport and you will notice a trend on bringing on board players whom they trust and know will emulate their style.
- Constant Evolution: Instead of large, wholesale changes, focus on bringing about incremental improvements. This can be through regular upskilling workshops, team reviews and continuous dissemination of your product and process vision. This will also help you identify the parts of the product team who are not working well and make gradual changes.
While building a product, the process often ends up being as important as the vision it is trying to achieve. However, unless you’re working in a startup, there is often a limitation on the kind of resources you have access to. In these cases it’s extremely important to clearly evaluate the best process to suit the product team you have at hand, start moving forward, continuously evaluate your progress and make a gradual evolution towards a revolution.