Introduction

I am always trying to learn more about what makes technology companies successful. So a natural question to ask was “What factors, from a product development perspective, make modern product companies such as Google, Spotify, and Facebook successful, and what sets them apart from other, less successful companies?”

I mentioned this to Our Head of Product at Seccl and he recommended a book called Inspire by Marty Cagan (MC). I found the book eye-opening and incredibly interesting.

I find writing about what I have learnt helps me to better understand it and I love helping other people learn new things. Here are some of my notes, in my own words, and observations from reading the book. Hopefully you find them useful as well.

Overall

This book was really interesting and really powerful for me. It helped change my whole perception of how companies and teams decide what to do and how they do it. It made some really strong points about why the way most product development companies work (the classic approach that most people would be familiar with) don’t have the same velocity and general success as some of the well known modern tech companies (Apple, Facebook, Netflix etc.)

What do the ‘product’ team do?

The product team, in the modern sense, focus on finding out what problems customers have and working out how can we solve them in a way that fits in with the business. The are interested in finding the answer to “What do we build and why should we build it?”.

Embracing a holistic definition of product

What is the ‘product’ that companies are building?

MC sees it as everything to do with what the customer receives through your company. Think of Amazon as an example. It seems natural to say that Amazon’s product is their search and buy functionality on their website.

But its also things like their FAQs and help centre documentation, their security protocols and their warehouse management solution. It even includes their ‘offline’ experiences such as customer service functions and password reset functionality.

MC argues that lots of companies lost sight of this view and only focus on improving their narrow definition of what their product is and this is one of the big factors that separates successful product companies form unsuccessful ones.

Problems with the classic product company structure

MC talks about the ‘classic’ and, he argues, outdated, approach to how a product company is structured. In this model, senior management and a classic ‘product’ team would decide what needs to be built and then there would be a sequential chain where each team passes along their work to the next team (product write requirements for the design team who pass their specifications to the engineers who pass their code to the quality assurance team who pass to the delivery team).

Some of the problems with this approach are:

Mercenaries not missionaries

Each team in the chain is restricted by the previous steps in the chain - their ability to have an impact on product is reduced. This can lead to a culture of just passing stuff to the next team. People find it hard to become invested and passionate about helping the customer because they aren’t involved in the process of creating the solution and they are often shielded from the customer experience and business context. This leads to a lack of innovation and motivation.

Also, the ‘chain’ approach of this starts by assuming that the product/feature idea will solve the client’s problem which very rarely is the case. MC argues that we need to continuously discover what to build and continuously deliver it in order to really solve our customers problems and that these two activities need to be carried out in parallel.

4 key risk addressed too late

MS explains that there are 4 key risks associated with product:

  1. Value risk - will this solve the clients problem, does it have any value?
  2. Usability risk - can someone figure out how to use it?
  3. Feasibility risk - can this actually be built with the technology and the skills we have?
  4. Business viability risk - does this sit well with the constraints of legal/finance/sales/marketing etc.?

The problem with the ‘classic’ approach above is that these risk aren’t addressed until the final step - we wouldn’t even know if the solution is usable until the very last step, let alone if it actually solves their problem!

This can lead to a huge waste of time and effort and demotivated teams.

Some solutions

Cross-functional teams

Instead of having separate teams split by their business function you should create cross-functional teams made up of a flat hierarchy of product managers, engineers, testers, designers who understand the client problem, design the solution and are responsible for delivering it. MC recommends a team size of about 10-12 as a maximum. This means that all members of the team can have input in shaping, designing and delivering the product which leads to a team of missionaries.

Also, this approach means that engineers and testers can be involved at a very early stage of a project and the feasability risk can be identified and dealt with early.

Continuous discovery and delivery

Continuous discovery: The product team should be getting customer feedback very regularly on what has been built to discover what needs to be done to solve the clients’ problem (which can change depending on their feedback).

Continuous delivery: The engineering team needs to be able to regularly release their changes into the system in order to get customer feedback into the system.

These two are deeply connected and feed into each other. They should be happening in parallel at all times. This is in stark contrast to the approach mentioned above.

Company structure, the role of management and OKRs

How do companies like Google and Intel manage to have successful teams even though they are very large?

MC argues that one of the key reasons is the focus and responsibility of the senior team and the individual product teams and how this is subtly but importantly different from other companies that fail to achieve these levels of innovation.

MC argues that one of the big reasons that lots of companies fail to innovate and are unsuccessful is how things get decided to be built. The classic approach is where the senior team would work with product mangers (who don’t have the same role as the product managers in the newer approach outlined in the book) to prioritise a list of feature which determines what needs to be built. The engineers and testers are then essentially handed a specification and asked to create these.

Firstly, MC explains that the no one really knows what exactly will solve the customers’ problem without a lot of discovery and iteration (which can’t really happen with this model). Leaders don’t actually know what the customer wants and the customer doesn’t actually know what they want a lot of the time (although they are aware of the problem they are facing). The other big reason that this model breaks down is that the leaders are prioritising features instead of prioritising business results.

In a successful and modern product organisation, MC says the role of the management team is to decide on business objectives and prioritise them accordingly. The CTO and CPO then work out the OKRs (objectives and key results) for each of the product teams (remembering that product teams are cross-functional teams of engineers, designers, tests etc). The important thing here is that the product team are given a problem and a way of measuring their success but they are responsible for how the problem is solved. The teams are empowered for finding solutions and they are accountable for those results. This links into the point about about building a team of ‘missionsaries’.

Instead of prioritising what should be built, the business focuses on prioritises business results. MC argues that this leads to more innovation, happier and more enthusiastic team (a missionaries and not mercenaries), a focus on solving the customers problems and faster delivery of real business value.

Going full agile

The ‘classic’ team structure clearly encourages the ‘waterfall’ development process. MC mentions this and says that although lots of companies reject the waterfall approach adopt an agile approach (of working in small batches and regularly reviewing to react to change), lots of companies only apply this to their software development and delivery process (the very few final steps at the end of the chain). Instead, MC says that companies should apply this approach to all aspects of the product development lifecycle (idea generation, prototype creation, marketing).

This way, companies can get the full benefits that come with embracing an agile methodology and not just in the software development part.

New roadmaps

Following on from the above, MC talks about how the classic product roadmap (which defined exactly what was features needed to be built in the next quarter/12 months) should be replaced by a prioritised list of business results.

He goes one step further to say “If the first time your developers see an idea at sprint planning, you have failed.”

This is because we need to ensure feasibility before we start building a production solution (which is difficult and expensive).

Also, but getting engineers to just code losing more than half their value - get them involved in creating the solution to get more ideas into the mix.

Also, this will help share the learning and give more context and make the engineers feel more like missionaries than mercenaries.

Half of all ideas won’t work

… and the ones that will require several iterations! MC says we can’t expect to know what will solve our clients problems and there are so many ways an idea can fail. Part of this is accepting that although you may release a feature it may not solve the clients’ problem, and you won’t know until you ask them.

In response to this MC recommends to adopt continuous discovery and delivery (see above) and asses risks early on to get feedback quicker

“Fall in love with the problem, not the solution”

According to MC this mentality is at the heart of a successful product strategy. This is an important approach to take for several reasons:

  • This approach this will keep you focused on solving the actual problem, not just pushing features or products.
  • It is easy for us to become attached to ideas for products/features/solutions that we have worked hard to create, and it can be easy to keep on pursuing a solution even when we receive feedback that the approach isn’t the best way forward (see the section above about continuous discovery). Focussing on the problem means our bias towards our solution wont get in the way of our actual goal, which is to solve some kind of problem.
  • Also, quite often our first solution won’t solve the problem, at least not in a way that can fully power a business. There is also an important link to continuous discovery above here.

MVP should be a prototype

MC writes how companies often go wrong when creating what they consider to be a MVP (a minimum viable product). MC argues that most companies spend far too much time and money on the MVP for an idea. He argues that the point of a MVP should be about learning what solutions solve customer problems and, perhaps more importantly, learning quickly. Instead of months, a MVP should take days or just a few weeks to develop in order to start testing and get data to validate or dismiss an idea.

For me, this links back to kinks back nicely to the idea of focusing on business results rather than output (what’s the point of producing something big and substantial with loads of features if you aren’t it solves the customers problem) and obsessing over the problem at hand and not the solution (becoming too attached to a solution can mean you end up not solving he customers problem)

Culture of innovation and culture of execution

The final chapters make it clear the focus of the book is on developing a strong product culture. To MC, the strength of a company’s product culture can be measured along two axis: their innovation and execution.

Innovation

Having a strong culture of innovation is centered around being able to discovery the right products to build.

Some things to consider are based around:

  • experimentation - are teams able to run tests regularly knowing that many will fail and a few will pass?
  • how business-savvy is the team - do engineers understand the business constraints and customer challenges?
  • technology - does the team keep up to date with technologies and understand that they can be a major source of innovation
  • open-mindedness - does the culture recognise that good ideas can come from anywhere? Do you consider everyone’s input when designing a solution, not just senior management or the product managers?

Execution

A strong culture of execution leads to be able to delivery to customers more frequently and more reliably. Some of the factors that influence this are:

  • urgency - does the culture make it clear that there is always a need to innovate and constantly disrupt yourself in order to not get left behind?
  • empowerment - do teams have the tools, knowledge and permissions to create and release in the way they need?
  • results - is the focus on producing output or achieving business results?

Strength along both axis

MC says that very few companies are strong at both, some are strong at one and lots of companies are poor at both (and these are usually the companies who have failed to innovate and have relied on their brand and reputation to get them through tough times).

Conclusion

I believe this book is really important to read for anyone who wants to work in a successful product company. The book has helped shape my way of thinking and influences the questions I ask at work and the way I approach developing our products as an engineer at Seccl.