Book Review: Inspired

Inspired: How to Create Tech Products Customers Love

Inspired: How to Create Tech Products Customers Love

Inspired
How to Create Tech Products Customers Love

Marty Cagan

How do today’s most successful tech companies―Amazon, Google, Facebook, Netflix, Tesla―design, develop, and deploy the products that have earned the love of literally billions of people around the world? Perhaps surprisingly, they do it very differently than the vast majority of tech companies.

In INSPIRED, technology product management thought leader Marty Cagan provides readers with a master class in how to structure and staff a vibrant and successful product organization, and how to discover and deliver technology products that your customers will love

Buy Now

As Software Developer, it is almost an inevitable fact of life that you will find yourself working or contributing to a new product or working on team known as a Product Development team. In fact, I have done so for large portions of my working career as a Software Developer.

These engagements may be defined formally, as in the team has been explicitly been formed with the sole purpose of developing a new product or service offering for customers, or rather as in most cases for Enterprise Software development teams, informally where you may be tasked to develop a new software package to address some specific business need.

Fundamentally software projects, by their very nature in a majority of instances, primarily have one objective to build a product, which may be renamed to application, service, app, stack or whatever, and the end product will always have a customer, you may rename customers to users, stakeholders or whatever you like. The fact is the core principles remain the same Product –> Customer.

Why I read this book

As mentioned previously, I have spent a large portion of my career developing products, of one description or another. Generally, in one of the guises of Code Monkey, Geek, Programmer, Senior Developer or multi purpose Code Slinging trouble shooter! Whatever the title the primary focus on these engagements has always been about the technical implementation as member of multi disciplinary team.

For better or for worse, I have predominantly taking guidance from the Business Facing representatives of the team, trusting that they know more than I about the real needs, desires, wants and objectives of the product we have been tasked with creating.

Over the years, I have also experienced a number of failed projects, which should come as no surprise to most people who work in IT based projects, because the it is still the harsh reality that a vast majority of IT based projects fail.

The Standish Group research shows a staggering 31.1% of projects will be cancelled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates.

The Standish Group Chaos Report

The statistics over the years very rarely improve, and if they do its usually just half a percent or two, but never anything drastic. This is despite the fact, that the industry has supposedly drastically improved due to adopting Agile Project Management practices. I’m often reminded when I hear the term Agile Software Development, is that it often bares no resemblance whatsoever to Agile Business practices, as I have grown to understand them from reading Business Agility: Sustainable Prosperity in a Relentlessly Competitive World.

Business Agility
Sustainable Prosperity in a Relentlessly Competitive World

The relentless pursuit of industrial efficiency no longer yields the profits it once did because it requires a level of business predictability that no longer exists. Instead, the Internet and global video and telecom systems provide a massive and continuous flow of data that causes the whole world to behave like a giant stock market, with all the volatility and uncertainty that goes along with such markets.

Michael H. Hugos

Buy Now Read Review

I also find it perplexing that when reflecting on these statistics and reviewing the profiles of IT professionals on LinkedIn, I never come across the failures, all I ever find is the old cliche phrases of “Delivering on time and on Budget, High quality blah, blah …………”

I’ll freely admit I’ve worked on failed projects, I don’t believe there should be any shame in that. The fact is project fail for an entire myriad of different reasons and not just the result of 1 individual, they fail mostly because an entire group of people or organisations collectively got something wrong!

Some of the biggest winners in history, actually made some mind blowingly stupid decisions before achieving some form of success! In fact, the key points to take away when reading the biographies of successful people, is that they all emphasise how they learned from their failures, I’ve yet to read any that emphasise that they only learned from their successes! I have yet to meet, read or even hear from anyone that can say their life has been a series of success! Everyone fails, deal with it!

So with this in mind, I have recently reflected on what were the major contributory factors to the failing projects I have worked on and the in a vast majority of cases the primary reason was that the entire team plain and simply got the product wrong!

You could say the right product for the wrong target or wrong product with the right target. It really doesn’t matter which way round you choose to phrase it, the fact of the matter is that the product team f*cked up! The key here is that it was the responsibility of the team as whole, not just any one individual in the team. Everyone contributes to the collective f*ck up.

I realised one of my great contributions to failing product ventures, is that the striking reality is that I didn’t have enough knowledge about Product Development as a whole. There are a lot more factors in developing a successful product than just ensuring writing good code and unit tests, the reality is that those factors very rarely if ever make a product successful, they only ever contribute.

All developers should remember the only true quality code in a project, is the code that makes money, and the only code that makes money is the code that is in use!

I’ve lost count of the projects I’ve worked on where the software development teams have wasted countless hours of wasted effort providing no real value what so ever, debating coding standards and whether certain programming language constructs should be allowed in the code base.

In fact, a recent project that we have taken over at threenine.co.uk as one of our what we will call, at least in this case, our Application Modernisation , is an application that the client had developed by another software development company, which in the clients words does not meet their business requirements.

The code itself wasn’t that bad, in fact it had at least 98% code coverage with unit and integration tests, which translates to the fact that the previous developer wasted a huge amount of their effort in methodically testing almost 100% of the code the client is unlikely to use!

The client never mentioned that they appreciated the code or anything, all they ever mentioned was that the in their eyes at least the code was useless! So one can only deduce from this perspective that the development team achieved success and complete failure in equal measure. However, it would be unfair to portion the blame on the on the software development team, but the reality is they did fail. Despite, their best efforts.

The only measure of success that actually matters to a software project, is the fact that it is being used! That is the only measure of success that is relevant to any product!

What I learned from this book

I have to admit that I nearly gave up with this book, especially when in the opening chapters the author advocates that product teams can only be successful if they are co-located in an open plan office, and the author states that this is just the way it is. I have two major problems with this, in that:

  1. The vast majority of the failing projects I have been a member of were co-located teams, with no exceptions.
  2. He doesn’t offer any verifiable facts and statistics to prove this hypothesis.

I decided to carry on reading this book, despite this and the fact that anyone who knows me will testify that I am one of the biggest proponents of remote work and distributed teams. There is also a lot evidence to point to the fact that remote working and teams can be successful, in fact many companies and product teams have been successful.

Remote

Office Not Required

The classic guide to working from home and why we should embrace a virtual office, from the bestselling authors of Rework 

 

In my opinion, many of the success criteria the author attributes to co-located teams are actually directly attributed to teams that pay special attention to and overcome the 5 Dysfunctions of teams. Its not to say there aren’t any benefits to co-located teams, but it is also fair to say that this is and never will be the primary factor of success. In fact, the team that delivered the product to our client, was a co-located team working out of an open plan office!

The Five Dysfunctions of a Team
A Leadership Fable

reveals the five dysfunctions which go to the very heart of why teams even the best ones-often struggle. Outlining a powerful model and actionable steps that can be used to overcome these common hurdles and build a cohesive, effective team.

Patrick Lencioni

Buy Now Read Review

Despite this, I decided to accept that this was merely the authors experience, and although it may work for him and his teams it may not work for everyone and it doesn’t necessarily discount everything he has to offer.

The book for the most part, is well thought through and is generous in providing the tools, skills and methods which could assist in building effective product teams.

A significant amount of the book is focused on the importance of solving customer problemsoutcomes over outputs, which is the theme of a lot of product books around.

In total there are 67 chapters covering:

  • The different growth stages of tech companies, lessons and some really good success stories from Product Managers of Google, Adobe, BBC, Microsoft, Netflix and Apple
  • The challenges and the reality of being a Product Manager
  • The different roles of the Product/Agile team, supporting roles and additional leadership roles needed as you scale
  • Plenty of advice about product vision strategy and Key Performance Indicators (KPI)
  • Discovery and transformation techniques
  • Stakeholder management

One of the key things from my perspective at least, the book also accurately describes a number of the reasons why many organisations suffer from the loss of innovation and velocity.

I feel it is also important to read this book in tandem with Product-Led Growth because both books emphasis that you cannot build great products without building a customer base. The key points that both books cover is the importance of ensuring that Customers and their needs are of vital importance.

Product-led Growth
How to Build a Product That Sells Itself

Wes Bush

Product-Led Growth also comes packed with “do this, not that” real-life examples from the industry’s biggest brands—as well as a collection of high-converting email scripts you can customize and send out immediately to turn more users into customers.

Buy Now Read Review

Why I recommend this book

I firmly believe that this book, should be compulsory reading for all software developers, primarily because it provides evidence that there is a whole lot more that does into developing great software products other than beautiful clean code and unit tests. Software developers need to spend more time considering this.

You won’t go far wrong, insisting that every member of your product team, irrelevant of role or position read this book, if anything it will provide clarity of what is actually important when developing products!

Cagan dedicates a chapter on how Product Managers should dedicate some time and even attend courses on learning how to code just so that they can gain an understanding of the engineering aspects of developing products, in order to improve relations with the software engineering team. All to often I witness that this approach is reciprocated by the software teams because all to often software teams don’t really know what it takes it takes to build tech products people actually want to use and pay for.

In my opinion and experience it is a very difficult concept for software developers to grasp, that nobody outside of the software development community actually cares that much about the quality and beauty of code, or that you have 100% code coverage with your tests and a great CI/CD pipeline. The fact is these are just merely small contributory factors and never will be considered by the cash paying customers. Customers just want working software that meets their objectives and requirements. I’ll be the first to admit I have wasted countless unproductive hours fretting over a piece of code, to get it perfect, but in the grand scheme of the product itself it never really mattered!

By all means, all software developers can pursuit that fictional ideal of Software Craftsmanship, but they should also be mindful that they only true measure of craftsmanship is if your product is actually being used!

This is also really ironic, because after all this is what mostly is constituted by what many in the industry to proclaim they are as Pragmattic Programmers