[Product Development Series — Part I] What makes great product managers: the case for learning
This article has been co-written by Steve Anavi, Co-founder and President at Qonto, and Regis Medina, a hands-on executive coach and lean researcher (his new book Learning to Scale is out), who has been working with Steve for the last 18 months. It is part of the Product Development Series composed of 3 articles: Part I (this one) | Part II | Part III.
With the rise of Agile in the past 20 years, companies have made great strides in their ability to quickly launch new products. In reaction to the slow and soulless processes of the Waterfall era, it brought back the joy of working in close-knit teams getting direct feedback from customers. Combined with the explosive growth of the Internet, it also gave birth to the Lean Startup movement, prompting many talents to start their own businesses and bring innovative products to the world.
20 years later, there is a new challenge. While most early-stage companies are now able to deliver Minimum Viable Products (MVP) in a few weeks, things tend to get a lot harder when the company needs to scale the tech and product organization, which is exactly what Qonto has had to deal with. And Product Management is an important piece of the equation.
While most early-stage companies are now able to deliver MVP in a few weeks, things tend to get a lot harder when the company needs to scale the tech and product organization
Most companies approach this question from a recruitment perspective, spotting and attracting the best and brightest already-Product Managers, each company being convinced that Product Managers in other companies are better than theirs. While this might be an undeniable advantage that we pay a lot of attention to, there is a fundamentally different way to look at this question. What if it was possible to accelerate the learning of existing product teams, turning them into the kind of people who know how to work together to consistently design great products that customers love and buy?
The inconvenient truth
Over the last 3 years, we have had the chance to meet 100s of product candidates. All those days spent trying to find the right ones have helped us acquire a pretty good understanding of how product management is practiced. Doing so, we have identified 2 major problems leading to a dreadful vicious circle.
Problem #1 - Stacking features
At the company level, Product Managers are often hired as countermeasures to facilitate project management between tech and business, instead of being tasked at thinking about how to create value that sells, and build it. As a result, we observe the following:
- Internal stakeholders across the company — operations, customer support, marketing — complain about the product lacking vital features for them to do their job.
- The flexibility offered by Agile makes it very tempting for stakeholders to ask for evolutions with little thought and course-correct later.
- The product team has a lot of ideas on how to move forward, with everyone thinking that the next feature should change everything.
- The engineering teams have no time to build theories on how to design robust systems. Quality is pursued through inspections (peer reviews, testing), which is a costly and ineffective approach.
- This all prompts to consider more changes, and all these ideas end up in an “aggressive” roadmap that becomes a political battle, takes ages to implement and frustrates all stakeholders.
- But customers are unmoved, and customer satisfaction is decreasing while revenue is just OK and cost is growing
And feature after feature, the situation remains more or less the same. As a consequence, the CEO or project sponsor could be wondering whether the right people are in charge, and the team members become frustrated and eventually decide to quit.
Problem #2 — Misconception of the job
The interest for the position has been growing thanks to blog articles, new SaaS to help PMs do their jobs or conferences with the promise of being the “CEO of the Product”. Yet, rare are the PMs who received a proper education to grow their passion through profound product design techniques.
As a result, we see a fairly large gap between what Product Managers hope to do and accomplish, the approach and skills they have and what they end up doing.
In the field, this will usually have bad consequences:
- Product Managers interpret incorrectly the customer need, or translate them into actions with minimum thinking
- They assume that a given limitation is not a deal breaker, or give up because of the deadlines or pressure from stakeholders
- They don’t think about all the functional edge cases, leading to a major issue during development
- They end up not delivering any value and/or emotions to the customers
A natural step forward would consist in pushing for yet another product development process, with even more activities and checks to perform. However, we believe that no matter how great the process, it could never successfully address a large and complex product development project. That’s why we started to look at this from a completely different angle, acknowledging that a product development initiative is first and foremost a learning expedition, highly dependent on who is assigned to the project.
In order to do that, we have decided to go back to the roots. Silicon Valley and Agile brought the job of Product Manager; Toyota, the Japanese car manufacturer, already had such a role in their ranks long ago: the Chief Engineer.
The case for learning
Back in the 60s and 70s, Toyota became a formidable competitor thanks to its ability to design new cars in half the time and with half the budget compared to its competitors, while developing a strong reputation for quality. The company could innovate fast, bringing the first hybrid vehicle to market in less than three years at a time when competitors still needed six to seven years to design a new fuel powered car — 15 years before the competition started releasing hybrid and electric vehicles.
What makes Toyota’s approach different from its competitors? It focuses on people. The company’s internal slogan lays out their secret in plain sight: “Good Thinking, Good Products.” And this is not just wishful thinking: they have developed over decades a system for developing good thinking in every employee, using the production activity itself.
The top of the Toyota Product System is focused on value: how to spark joy in customers with a great product. Value is constantly identified and designed through a cycle of Value Analysis / Value Engineering activities, which Toyota has honed over decades to form the Toyota Product Development System.
For sure, tech companies have different constraints than automobile manufacturers, where product development projects involve hundreds of people and dozens of suppliers. However, in the past few years, some CEOs and product managers of the tech community have proven that this system remains highly relevant for scaling the product development organizations of modern startups and scale-ups. And Qonto is one of them.
How can this be? The trick is to take the system as a set of principles to drive learning in the product organization, rather than copying a given product development process: sometimes it isn’t relevant enough to follow Agile which focuses more on mechanical routines and tooling than what customers really care about.
The Chief Engineer
In product development, learning should start with a person responsible for overseeing the product in its entirety: the Chief Engineer.
As an experienced professional, the Chief Engineer is the “CEO of a Product”. He or she is like a movie director, responsible for delivering top and bottom line results at a given date with a product that sells.
What makes this role different from most Product Managers? It encompasses all the dimensions of the product, from customer research to engineering, operations, marketing and sales.
The Chief Engineer usually leads a very small team, separate from the engineering and operations departments. The development itself is then made by stable teams led by specific managers in design, engineering, operations, and so on. She is mainly responsible for driving the vision of the product and challenging the experts from each specialty to bring their best ideas in support of that vision.
Chief Engineers have a real passion for the product, developed over the years by spending large amounts of time with their customers and studying all related products — the previous generations of their own product, but also its competitors and all kinds of products used by their customers (i.e. not only cars). They also study the craft of product design, across time and industries. This work usually leads them to know their users very well: their context, their goals, their preferences, and what brings them joy in the products they use.
Since they are able to call the shots for important product decisions, they usually benefit from the direct support of the C-Levels or the board of directors after spanning many roles and functions across the company to grow on strategy, sales, marketing, data, negotiation, performance monitoring, conception, and project management.
This brings us to the big question: what does it really take to be a great Product Manager (at Qonto)?
Qonto’s Product Managers
At Qonto, hiring Product Managers is not so much about hiring former Product Managers with product management techniques but rather people already engaged in the process of learning and self-development, and with high curiosity.
Here are the traits we care mostly about:
- Develops a clear opinion and ambitious vision, with self-confidence and accountability
- Has broad knowledge and conducts broad and deep research
- Applies knowledge and skills toward achieving concrete results
- Never takes the easy route to make it easy for herself; repeats each task as necessary
- Has a generous spirit and demonstrates unselfish dedication to success
As a consequence, our job as Managers is twofold:
- Creating the environment for them to build knowledge and expertise so they can really get to the hard task of understanding what customers really care about, where is the value, and what is the best product with limited cost
- Making sure that they have the help and training needed to succeed
For the first point (1), we have built modules to make sure they can focus on learning with limited attention to the core frameworks and tools. We see those as exercices to learn:
The Concept paper
- Running a current situation audit through flows analysis, data analysis, competitor teardown and state-of-the-art study
- Formulating a problem statement through causes analysis
- Identifying customer preferences leveraging data, verbatims, interviews and role games
The Design
- Mapping preferences to modules and technologies
- Building a catalogue of solutions
- Evaluating solutions through Quality Function Deployment
- Cracking hard points using trade-off curves
- Running target costing
- Converging to the best solution
For the second part (2), we make sure to allocate time to help them grow through several coaching moments, from Obeya to Kaizen to go-and-see.
The sum of those 2 parts (e.g. the act of writing the concept paper and discussing the elaborated theory around it) is the catalyzer of our continuous learning system. As suggested above, we focus less on Product Management through the skills of knowing how to write user stories or how to run user interviews along a given framework. However, we do care a lot about revealing “engineers” & “artists”: developing a craft in a true noble way through learning, with the intention to have a positive impact through innovation.
These principles are an essential part of what we call The Qonto Way, our practice to drive People Development. Good Products come from Good Thinkers.
Want to learn more about our way to go through Value Analysis? Read the next article here.
🔥If you want to join our amazing Product team, see job openings here.
