Feb 24, 2019
On the Shift From Projects To Products and the Role of the Leader
Probably the biggest obstacle to innovation I have seen in my recent work with organizations from various industries (incl. public sector) is the dominance of "project" work. I expected bureaucracy, politics, stage gates, but no — the biggest problem is the perception that nothing gets done unless we create a project. A project with a clear brief and a number of people ("resources" as some would say) assigned. If you are lucky it might be the only project those people work on. Yet, the ugly reality says that this new project is most frequently only one of 5 that people have to balance.
The product vs project discussion is one more of a mindset and belief than anything else.
Projects are (overly) focused on Time, Budget and Scope. We deliver a product and most of the focus and thinking is on how to make the balance between those 3 factors optimal. Many teams would master some form of agile and manage to deliver "something" within time and budget. Yet, once that something is left on its own, evolution is translated in a number of overdue changes and that "something" becomes an outdated "something" lightning fast.
Once a project is done, we simply hand over to another team, which will observe how the product falls off a cliff.
Product teams operate in a very different way from project teams. Their mindset and believes are fundamentally different. They own the product and live along it. Unlike project teams once a product is live, the team continues to learn from the feedback of customers as well as from the data on how the product is used. Both of those feedback loops inform further evolution, new design decisions and the team keeps moving ahead. At times the product may take radical turns dictated by the market (customers' needs) and that is absolutely fine. We cannot predict the future or what new need our product may uncover.
Product teams look at products as a journey rather than a set of requirements or a spec to be developed. The journey goes through exploration of Desirability, Viability and Feasibility — over and over again.
Good product teams understand that by putting out their product in the hands of people (customers, users, whatever they are called) they are causing an interference in a complex system. The system changes in response.
By satisfying a need and/or relieving a pain our products may open the way for something new (of a higher order) to come to existence. In response, the product the team develops may need to change too. This is the ultimate motivation to have a team behind the product. A team, which will probe, sense and respond to the changes in the system through evolution of the product.
By putting out in the world something with the aim to learn, we influence the (eco) system and in return it influences the design of our product.
Projects have an end and often as a consequence people are led to believe that the subject of the project has some form of an end state too. A product is a journey. There is no end state of a product except eventually its death when it gets discontinued. What is even more fascinating —because of that interaction with the system, a product team can very quickly become a team maintaining a set of related product journeys, namely a product portfolio.
A product is a journey just like a dog is for life.
Despite all of the above managers still form and disband project teams on regular base and task them to build new products. Many of those managers argue product teams are superior only because people have focus and clarity, but that is impossible and unsustainable in enterprise reality. Really!?!
It starts with a leader.
How do you lead product teams?
David Marquet explains incredibly well what great leaders do.
All of that applies to product leaders and their product teams too.
We are used to celebrating and glorifying individuals when it comes to innovation. In reality, more frequently than not, those are good product leaders who understand that they can never have all the right answers. They recognize the need to engage the brains of a complete product team. Instead of building a full product alone, they do the following:
- Create diverse cross-functional teams — long-lived teams so people can achieve mastery, flow by avoiding context switching
- Create clarity of the strategic objectives
- Give intent by translating strategy and vision to day-to-day tasks
- Empower the team to participate or even make most of the product decisions on their own
Those may seem obvious things to do, yet try to identify concrete ways you can achieve the above. I am sure you will struggle as many of the product leaders I talk to.
Practices Which Enable Product Leadership
Practices can lead to cargo cults, yet this post will be too vague if I do not mention a few. Please understand that a pure application of practice is not bringing you a step forward, just like by having standup meetings you are not becoming more agile as an organization.
In my team at Red Hat Open Innovation Labs, we have worked out a set of practices that help in the above challenges. Many are captured in the Open Practice Library — an open source project we help maintain. It is based on another open source project —the Outcome Delivery framework, which describes through the infinity loop the endless cycle of evolving products until they become obsolete.
Below are a few examples of practices product leaders can use to achieve what David Marquet is describing as foundation for achieving Greatness — Competence and (Organizational) Clarity.
- Impact Mapping
- Whole Product Thinking
- The Kano Model
- Start at the End
- Backcasting/Pre-mortem
- HMW: How Might We
Remember: those practice will not work for you, but could work for your team. Use the practices to create focus on building for real impact— outcome over output.
I will soon find time to share further ideas on how leaders empower and coach a product team to build for impacts and outcomes rather than features.
