Inspired
How to create tech products customers love
How do today's most successful tech companies like 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.
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.
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 projects fail for a 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 or a number things wrong.
Some of the biggest winners in history, actually made some mind blowing 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 mark of quality of 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.
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:
- The vast majority of the failing projects I have been a member of were co-located teams, with no exceptions.
- 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.
The five dysfunctions of a team
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.
Despite this, I decided to accept that this was merely the authors experience, and although it may work for him and the teams he's worked with it may not work for everyone and it doesn't necessarily discount everything he has to offer.
Despite my private tussle with the author, 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. I also learned a lot from the book, and more than likely I would concede to the authors perspective.
A significant amount of the book is focused on the importance of solving customer problems - outcomes over outputs, which is the theme of a lot of tech 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.
It also deals with the elephant in the room, that while even though more organisations are adopting Lean and Agile project practices, that most new projects and product development activities continue to fail. It's primarily due to the fact that most organisations completely fail at implementing these practices completely wrong.
The way agile is practised in most product companies is hardly agile in any meaningful sense
Inspired - How to create tech products customers love
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
how to cut your acquisition costs and scale further...by making your product the tool that helps you acquire, convert, and retain customers.
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 goes into developing great software products other than beautiful clean code and unit tests. Software developers need to spend more time considering these other aspects.
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
The Pragmatic Programmer
your journey to mastery
20th Anniversary Edition (2nd Edition)
- What is this Directory.Packages.props file all about? - January 25, 2024
- How to add Tailwind CSS to Blazor website - November 20, 2023
- How to deploy a Blazor site to Netlify - November 17, 2023