What can you learn about successful product development from Marty Cagan?
As a lead developer aiming to build the best solutions for people, common questions arise during every project – no matter if it’s making a mobile app, an e-commerce platform, or an AI tool. Are we doing our best? Would another solution work better? Is our team really consistent? Should we try something new?
Answering these questions requires access to the best teams. Here is where the book Inspired: How to Create Tech Products Customers Love shines through as author, Marty Cagan, captures key points about what’s so special about strong teams. Here are a few of the best takeaways from the book.
1. Value and tap your engineers for their ideas
‘If you’re just using your engineers to code, you’re only getting about half their value. The little secret in product is that engineers are typically the best single source of innovation…’
It is not just about delivering a feature – we need to solve the underlying customer problem. Engineers and product designers should be involved from day one to help validate hypotheses via a structured process of creating prototypes for user testing, and as a basis to iterate until you reach the best solution. The tech lead has the explicit responsibility to help product managers and product designers discover a strong solution. And as well emphasized, even the ‘P’ in MVP, which usually stands for ‘product’, should really be considered more to be ‘prototype’.
2. The best products take great technology and design, combined with true persistence
‘Behind every great product there is someone who led the product team to combine technology and design to solve real customer problems in a way that met the needs of the business.’
When looking at well-established solutions today, they can seem so natural that it’s hard to imagine how anyone would go against them. However, pushing a new idea requires persistence from stakeholders you may not know today. Technology and business risks arise from all sides and you must provide evidence on why this new product represents the future. In his book, Marty gives some great examples of people who had these blockers in their way.
For Jane Manning, pushing AdWords for Google wasn’t an easy task. Lea Hickman knew the market was changing, and Adobe’s Creative Suite desktop-centric, annual-upgrade model necessitated a move into a new subscription model. But money was flowing, so what would spur that change? And how hard would it be to change development processes in order to have a continuous delivery?
As a fact defined by Marty, big companies that don’t try new ideas tend to die.
3. Risks aren’t risky – if you manage them
‘The riskiest strategy of all is to stop taking risks.’
Half of our ideas will fail for different reasons, and Marty discusses how really good teams assume that at least three-quarters of the ideas won’t perform as they hope. The biggest flaw is how companies think they are using Agile effectively, but in reality they are just using a waterfall process. Agile enters only at delivery, meaning that all the risks are taken at the end and so customer validation happens way too late.
When validating a new idea at product discovery, we must address four critical risks:
- Value risk. Will the customer buy this, or choose to use it?
- Usability risk. Can the user figure out how to use it?
- Feasibility risk. Can we build it?
- Business viability risk. Does this solution work for our business?
Our opinion is not enough; we must collect evidence. And for this, Marty explains how a good product manager will have basic knowledge of programming languages (not HTML) and data tools. The product manager may have someone to help them, but they must be ready to answer questions from their tech team.
4. Reframe your focus – solutions, not features
‘We need teams of missionaries, not teams of mercenaries.’
Marty chose a great quote from inventor John Doerr to describe what we should prioritize when building a strong product team. If our engineers only receive a list of features to deliver on a fixed timeline, they will work like mercenaries to finish it and will commemorate a release.
We want our team to understand customer challenges as this is what will give them all the data they need. Empower the product team to give solutions and not just implement features. Celebrate when a customer problem is solved. This is the missionary behavior that happens on strong teams.
5. Focus on the outcome rather than the output
‘Typical roadmaps are the root cause of most waste and failed efforts in product organizations.’
There are valid points for having product roadmaps: they are desired for management to ensure the team is working on the highest-value tasks first, and they help coordinate marketing, training etc., on a larger business scale.
Marty provides some amazing takeaways about roadmaps and how they can be successful tools.
Product discovery shouldn’t be ignored. Ask for an initial time with your product team to find what solutions will work best for you. It is better to spend time finding an effective solution at this beginning point than when the project is already being built. The team will be more motivated if they are free to solve the problem. Instead of features, give them objectives to tackle.
A new reality and some final thoughts
At the time the author wrote this book, we lived in a world without a global pandemic. He described how a co-located team works better, sharing activities like lunching together etc.
Our current situation doesn’t allow this, and we may never return to a previous ‘normal’. That is our current challenge, and ignoring this truth may be the difference between a company growing or a slowly dying company. So instead, focus on other ways to collaborate and connect in real time to build strong team dynamics.
This book is a reminder about the elusive silver bullet in product development: it is as much about the perfect team as it is the process. With the right experts, and collaboration between technology and design, we can create a product our customer will love.
Watch the Bookmarked discussion on Inspired: Marty Cagan in conversation here.
