Most organizations are not good at building great products & experiences.
The vast majority of product leaders I talk to, all complain about the same thing –
“That despite their herculean efforts, they still have a hard time creating great products & user experiences and showing real business impact.”
It does not matter the size, the industry, or the geography. The names change but the struggle remains the same.
They all are not good at building great products & experiences.
Which then begs the question…why?
In my experience, it invariably comes down to one thing – they build products like projects.
To help understand why this project centric mindset is so harmful, this article will,
- Take a look at how products are built using a project mindset, and then
- Explore the 8 reasons why this approach delivers sub par results
(This is part 1 of a 3 part series. Don’t miss out on Part 2: How Digital Leaders Build Great Products And Experiences. Sign up for the newsletter.)
In most organizations, products are built like projects.
A typical project centric development lifecycle, goes something like this…
Step 1: Set up projects
Everything starts with an idea.
The idea may come from executives (“we need to capture a new market so we need to build a new product”), customers (“you need to build this for me”), or competitors (“see what they are doing, we must build something similar”).
Regardless of the source, in order for the senior business leader to bring the idea to life. She first turns it into a project, builds a business case, and then competes for funding.
If she is victorious, the project makes it into the annual budget and is then handed off to a product manager (in the business) to execute.
Step 2: Create feature lists
The product manager, usually someone with a sales or marketing or business analyst background, sets out to design the product by gathering requirements.
Requirements are gathered either by interviewing internal stakeholders, conducting brain storming sessions, or studying external third party research. With the goal of creating a “must have” features list (some times in the form of user stories).
Through out this entire process, developers and designers are rarely consulted.
Step 3: Develop, test, and launch features
All of the steps above involve multiple hand offs. But it is nothing compared to the hand offs required when it comes to developing, testing, and launching the code.
Some of the typical hand offs include
- Product manager hands the feature list over to the product owner.
- The product owner – who sits in IT and is responsible for managing the backlog – then schedules the work and hands its over to the engineering manager.
- Engineering manager then allocates the work to developers.
- If development is outsourced, then that adds another layer of hand off where the manager hands it to the vendor who then hands it off to the developers.
- Once development is done, it is handed off to testing.
- Testers complete the work, bugs are then handed back to the developers.
- Developers fix the bug and hand it back to testing (this cycle can continue for quite some time).
- Once the code is deemed to be ready to roll out, it is then handed to IT Ops.
- IT Ops assigns a release manager that then works with the infrastructure / devops team to move code to production.
- And since most infrastructure is outsourced, it may add another layer of hand offs.
No wonder, it takes product teams so long to bring anything to market.
Step 4: Move on
If and this is a big if, the launch is successful the team disbands and moves on to the next funded feature.
If there are a ton of P1 issues, the team stays on for an extra few weeks for hyper care. Eventually it is handed to an outsourcing provider (to save cost), who spends the next 2 years fixing bugs and making small enhancements.
However, the biggest tragedy is that no one stops to measure the feature’s impact and check to see if it was worth the investment.
And the cycle continues.
One feature after another. One project after another. One year after another.
The steps described above is only scratching the surface of what really happens.
I have deeply simplified the product development process. In most organizations, it is rarely this straight forward. Each step is never this clear cut and requires multiple sub steps that bring on its own set of challenges.
However for the purposes of this article, the above project centric approach will do.
Because even if the process was this simple (which it is not), it is full of flaws. And is the main reason why organizations struggle with building great products.
The problem with this approach is that the deck is stacked against you and you will always end up with sub par results.
I assure you, there are more than eight problems with traditional product development. But allow me to focus on the most important ones.
#1. Output (not outcome) centric
The goal of a product is to deliver an impact. It is not about getting something launched.
Yet, that is exactly what traditional development incentivizes.
Every step in the project centric process – getting projects approved, budgets allocated, teams assembled, road map created, code developed and tested etc. – is focused on one thing and one thing only. Move the work forward.
No wonder teams are so output focused. Where launch = success.
#2. Lacks empowerment:
In this model, people are treated like robots in an assembly line.
Executives hand the project to product managers. Product managers build roadmaps and hand it to product owners. They in turn hand it to developers. Developers write code and hand it to testers. Testers to IT Ops, who then releases the software.
The problem with this is that each and every role, downstream from the executives, exists only to implement. Executives decide what to do, the rest of the organization’s job is to do it as quickly and efficiently.
No wonder no one feels empowered.
#3. Underutilization of your most valuable resources
You will notice, developers are rarely consulted in steps 1 and 2. And if they are, it is to confirm t-shirt sizes for budgeting.
The problem with bringing them in too late is that you you are only getting half of their value.
Developers / engineers are your best source of what is technically possible. They intimately know what technology can do and the limitations of the current code base.
Asking them to just code and not participate upfront in strategy is like throwing half your money out the window.
The same case can be made of your UX designers. And is the reason why we get “lip stick on a pig” syndrome.
#4. Lacks end to end ownership
Due to the fragmented nature of how work is organized (multiple silos and lots of hand offs), everyone owns a piece of the puzzle. But no one owns the entire puzzle.
This causes three major issues. First, there is no single owner who is responsible for delivering outcome. Second, when something breaks (which it always does), there is a ton of finger pointing. And third, there is no incentive to collaborate. As long as the silos do their work, why should they reach out to others.
With so many people responsible, it is easy for no one to be responsible (regardless of what they claim).
#5. Lacks measurable success metrics (outcomes)
Being output focused is bad enough. However, many organizations get so wrapped up in “launch = success”, that they don’t even bother to define proper success metrics (OKRs).
Now I know what you are thinking. We have business cases – is’nt that our measurable success metric?
The problem with business case as a success metric is three fold.
First, they are not granular enough to judge if a single feature / experience was successful. Second, revenue is a lagging indicator and is heavily dependent on sales and GTM teams. Third, they exist to obtain budget…nothing else. Turning it into an OKR is asking it to do too much.
How is a team supposed to deliver impact, if they don’t even know what they are shooting for?
#6. Inward facing
The entire process is inward facing.
Instead of taking the time to understand the user’s real needs, experimenting with various options, and validating the solution.
The organization builds what they “think” the user wants.
So you end up with a roadmap that is full of pet projects, competitor copy cats, and the latest technology trends.
This lack of customer centricity eventually comes back to bite you. And as a result, you end up building mediocre (best case) or the wrong (most likely) product.
#7. Inefficient way to build a product
The biggest flaw of this process is that all risks are back loaded.
Building a product first and then validating it with the user is backwards. What is the point of spending all that time and energy building a product only to find out that it is not needed / valued by the user.
But that is not all.
Key architectural decisions made during the previous build, may make pivoting to what the users really want all the more harder (and expensive) the next time around.
What a gigantic waste of time, money, and resources. This is by far the slowest and most expensive way to build a product.
#8. Carries a huge opportunity cost
Piggybacking on the above bullet. What about the opportunity cost of all that wasted time, money, and resources?
Project centric development forces you down a one way street. And if the product is wrong (which it invariably is), then that time, money, and resources are lost forever. There is no way of getting it back.
Think about all the other things the organization could have done instead.
No wonder organizations are so frustrated
It’s no wonder organizations are frustrated with the way they build products and experiences. And for good reason, they spend so much money and get so little in return.
But there is good news.
There is a much better way – its called Modern Product Development (MPD). Where the team is focused on driving towards an outcome (business impact) not on output (delivering features). It is how digital leaders like Google, Facebook, Microsoft, Amazon consistently build digital products and experiences.
And while it may seem that the processes are some what the same. I assure you it is radically different. More importantly it is extremely effective. You can quickly learn what will work and what will not work. Without wasting a ton of time and money.
We will explore Modern Product Development (MPD), the process, and its benefits in Part 2 of this series.
Happy Building!!
