Why do they keep hiring product owners 🧐 & not product managers?! And why you should avoid companies that do!

In 2021, I was working on a transformation for a client which failed!

Soon, a conversation with an aspiring product manager at that organization took place about their frustration with the organization and further, the difference between PO and PM.

This led me to explain the concept of project vs product organizations.

I also went into why scrum only leads to the build trap (aka feature factories) and why product owner is not a REAL role, and should not be hired at an organizational level, let alone exist at all!

Sidebar

The role of the product owner will be continuously hired at an organizational level and project organizations will always exist.

However, this behavior would help identify the project companies from the product ones where real innovation happens, while furthermore helping people who are passionate about product development and product management to avoid those companies.‌

Purpose of this article

I wrote this in mind to inform and help guide anyone in product management by identifying the good product companies with great product management practices from the poor product development organizations, which are stuck in the build trap aimed at hiring delivery teams, and to help avoid some career pitfalls of joining delivery teams and falling into these build traps.

• Aspiring Product Managers and Product Managers ‌‌
  This will help you identify if you are in a product company or project company.
• Product Leaders, Head of Products & Chief Product Officers ‌‌
  Please use this to help raise awareness in your organization and peers around poor product management practices and why you should avoid scrum and projects altogether.

Updates to article

4th Update 8/07/2022

4125 words

• Edit to Intro and Summary
• Updates to content for Parts 3‌‌ and 4
• Redone formatting overall article

3rd Update 24/06/2022

3730 words

• Major restructuring of the format of the article
• Added Sections - Purpose of the Paper and Summary
• Updates to content for Part 1 and 2
• Formatting changes on Parts 3 and 4

Summary

In product development, some organizations are like dinosaurs, they are meant to go extinct, while some are innovative and empower their teams to look at problems and opportunities using discovery techniques (product discovery), not just build solutions and jump to delivery.

These organizations challenge the status quo and are attractive to work for and they focus on validating ideas before going into the build (say a project) further to this, they avoid the trap of becoming feature factories by chasing feature parity with competitors.

They spend most of their time in the discovery of the problem rather than the solution space, which allows them to build innovative solutions that add value to customers and the business.

Part 1 - Project/Delivery vs Product Companies

In product development, there are 2 types of companies - project and product.

• Project companies are for delivery & process people.  ‌‌
  eg: Project Manager, Business Analyst, Product Owner, Developer, UX designer.
• Product companies are for product evangelists, visionaries, disruptors, and innovators.‌‌
  eg: Product Manager, Product Designer, Discovery and Product Coach, Product Engineer, or Software Engineer.  ‌‌‌‌
  
  This section highlights the key characteristics between the 2 types of organizations from focus, culture, the lifecycle of work, ways of working, hiring trends, delivery method, and modeling to discovery methods. We also look at why project companies exist and will take ages to go extinct. ‌‌

Part 2 - The 20-year debacle on Product Manager V/S Product Owner

Over the last 2 decades, there have been a few heated arguments about PM vs PO, but as time has progressed, it is very clear what the differences are.

To address this debacle of what the difference is between the product manager and product owner, we look into the details behind the difference in responsibilities of a product manager, product owner, and business analyst.‌‌‌‌A product manager is NOT a product owner and vice versa. An agile business analyst on the other hand is definitely a product owner. ‌‌

Part 3 - How to differentiate between an innovative company and a project company stuck in feature factory mode?

There are 4 factors that help differentiate the feature factories from the product organizations in product development.

Part 4 - The Agile Factory & CSPO CSM cert scams

• An explanation of what the "agile education McDojos" are
• Why are companies & people paying for these courses?
• A quick look at if Scrum is an effective delivery framework
• Why do many organizations or teams go for Scrum
• Lastly, how do I get out of the build trap?

Part 1 - Project/Delivery vs Product Companies

The key area to understand is that there are 2 types of organizations when it comes to product development and these organizations hire roles differently and operate differently.

Important call out

There is nothing wrong with being a project manager or business analyst, however, it is important to understand that you do not work in a product organization if you hold these roles.

I have worked for both types of organizations and have even done the roles of a project manager, business analyst, product owner & scrum master. This is where I came to realize the shortcomings of these organizations, techniques, methods, and frameworks and pivoted my career into product management to find better ways of working and shifting outcomes.

Further to this, I have helped a few project organizations that were stuck in feature factory delivery mode to move to product organization successfully. There have definitely been a few that have been unsuccessful.

Below are the key characteristics that I have found between Product Organizations and Project Organizations.

Product Organization Characteristics

These are often called innovative, tech, or product companies. They are visionary in nature and constantly try to disrupt and push boundaries of what is possible. ‌‌‌‌

Their key characteristics include:

• Focus
  ‌‌Very disruptive in nature with a focus on constantly evolving product market fit and pushing boundaries on what's possible. IT is a profit center no questions asked.
• Measuring success‌‌
  They are outcome focused not output-focused and measure their success based on how much they have shifted the outcomes such as stickiness, revenue, growth, etc.
• Culture‌‌
  They have a culture of empowerment and learning which leads to innovation.
• Lifecycle of work‌‌
  They avoid projects with initiations and closures and try to do things with initiatives in product lifecycles with continuous lifecycles.
• Ways of working‌‌
  They avoid feature builds and their main goal is disrupting the competition and market and continuously finding product market fit. They have prioritization and decision-making frameworks with empowered product teams who can move quickly.
• Hiring trends‌‌
  They hire product managers and product designers not project managers or product owners or UI/UX designers.
• Delivery method
  ‌‌They use Kanban or Dev Ops for delivery while also trying to break away from frameworks and models. They avoid scrum and SAFe like the plague.‌‌They also follow technical practices such as CI/CD pipelines to allow for continuous integration, deployment, and delivery.
• Modeling
  ‌‌They use business or product model canvases to discover the viability of their product. The cycle of the product is continuous and the focus is on growth models such as AARRR vs. RARRA.
• Discovery methods‌‌
  They are not afraid to speak with their customers or potential customers and empower teams to do so. They also try to follow innovative ways such as continuous discovery to explore new opportunities and spend 50%of their time on discovery rather than 5%. ‌‌

Project / Delivery Organization Characteristics

Project/ Delivery Organizations do not focus on innovation, they focus on controlled activities limiting Risk and Exposure. This is mainly driven by governance, accounting, and finance processes.

Further to this, their focus is on governance and the most common issue is the Top Down culture.

Many of these organizations are also sales or marketing-led. I refer to these organizations as dinosaurs or feature factories.

They probably call themselves "Agile Organizations".

• Focus ‌‌
  Their focus is to maintain feature parity and maintain market share to survive. They are lagers in innovation and mostly treat IT as a cost center.
• Measuring success‌‌
  They are output-focused not outcome focused and measure their success based on how much they have delivered on a particular budget.
• Culture
  ‌‌They have a culture of governance & control which leads to mistrust, blame and toxicity.
• Lifecycle of work
  ‌‌Everything is project-based, including product development with initiations and closures. The cycle of product development is within a project or feature build
• Ways of working‌‌
  They focus on feature builds and feature parity with the competition. Innovation is not part of their culture, process efficiency is. They may have prioritization and decision-making frameworks and have delivery teams who are tasked with delivering an output (scope) by a certain time frame and budget.
• Hiring trends‌‌
  They hire product owners, UX designers, project/program managers, and business analysts.
• Delivery method‌‌
  They use waterfall - PRINCE2 or PMBOK, Scrum, and SAFe. They avoid Kanban and DevOps.
• Modeling
  ‌‌They use business plans and cases to get approval for funding/budgets.
• Discovery methods‌‌
  They are afraid to speak with their customers or potential customers and there is a level of bureaucracy to battle to try and do so. 5% of time is spent in the problem space on discovery and 95% of the time is spent on delivery in the solution space.

Why do Project companies exist if they aren't great?

Irrespective of the organization's size or scale, project companies exist, some of which even have global success.

Despite the disruption and innovation from good product companies, these project organizations are not extinct yet and probably won't be for a very long time for many reasons.

Reason 1 - Cash flows and market share‌‌
In general cash flows and market share allows these dinosaurs to stay afloat  - till one day they aren't as they run out of money and lose market share drastically to an innovative startup or new product.

Reason 2 - Past success or accidental innovation
‌‌Most of the time, these organizations live off past successes where they accidentally innovated or met product market fit and then reached market share to be a monopoly. Perhaps they were once a product company but reached certain scale where process and bureaucracy took over resulting in bad strategy and ignoring the evolving product market fit. Think of the Kodak and Nokia stories.

These organizations were great innovative organizations that ended up getting too big and then not being able to evolve to innovate at scale, they failed to get out of the build trap. They also failed to use appropriate strategies that continuously look at evolving product market fit. An assumption is generally made when you reach a certain scale/monopoly status, you feel indestructible.

These organizations also failed to create empowered product teams to stay competitive in the 21st century by utilizing strategies that failed them.

Reason 3 - Mergers and acquisitions‌‌
Beware of the mergers and acquisition dinosaurs, there are organizations that realized they have killed innovation by scaling to a certain point and inducing large-scale bureaucracy and processes which slows down their decision-making and ability to innovate fast.

These organizations are unable to innovate due to their size/structure, so they end up acquiring smaller innovative organizations to survive.

Part 2 - The 2-decade debacle PM v/s PO v/s BA

For the last 2 decades, the PM vs PO roles have been debated by practitioners of software development and there are some great articles along with visualizations on this to describe what a PO is vs what a PM is and on occasion compare it to a business analyst role.

In the below clickable image, I highlight the key activities/ responsibilities that the 3 roles consist of.

Product Manager vs Product Owner responsibilities

Strategy vs Tactical and decision-making authority‌‌
The key difference is

• Product Managers are empowered to work on strategy and tactical, with the ability to make decisions and prioritize without permission.
• While Product Owners are delivery & tactically focused.
  They generally have a proxy role of a decision maker which is typically someone in mid to senior-level management but most often than not they have to confirm everything with a stakeholder before they make decisions.

Supporting roles
‌‌Depending on the scale of the organization and budgets, the product manager is normally supported by product designers, product marketing managers, and technical leads/managers.

While the product owners are normally supported by UX designers, solution architects, and business analysts who are often asked to wear the hat of the scrum master!

Key Accountabilities‌‌
Product Managers are accountable for the viability of the product and the value it adds to the business.

While the Product Owners are accountable for backlog administration. These are generally overpaid roles where the key is to help create JIRA tickets and fill out backlogs similar to business analysts in traditional organizations to keep feature parity with the competition and keep the development team busy.

BOOK QUOTE‌‌‌‌
As per Marty Cagan, in an empowered product team, responsibilities break down as:‌‌‌‌

1. Product Manager is responsible to ensure the product has value and is viable for the business.‌‌‌‌
2. The Product Designer is responsible for ensuring usability.‌‌‌‌
3. The Engineering / Technical Lead is responsible for feasibility.

‌             ‌

Part 3 - How to differentiate between an innovative company and a project company stuck in feature factory mode?

In my years in consulting, transformation, and business management, I found that assessing a company's digital maturity is a good place to start when understanding where its core competencies lie and if they have what it takes to be innovative in product development.

Below are 4 factors that help differentiate the feature factories from the product organizations.

1. Appetite for disruption and risk‌‌
   Project organizations have a lower appetite for risk and change whereas innovative product organizations live in the deep end.
   They tend to set visions that are disruptive in nature and are able to disrupt themselves to build innovative products.
   They understand that pivoting quickly is key. Failure is not treated as a failure but as a lesson learned.
2. Key roles in product development‌‌
   Think of organizations that constantly innovate on 'product market fit' and teams that are set up for innovation - good companies V/S  bad companies who have "death march delivery factories" that are stuck in the build trap. ‌‌
   Those organizations that want to innovate have product managers, not product owners or project managers.
3. Processes and controls‌
   ‌Bad companies are structured in a way to keep innovation to a minimum because to them innovation = high risk! ‌
   ‌They have controls as processes and strategies to eliminate any innovation.
4. Culture‌
   ‌Bad companies only do lip service when they talk about strategy and culture of innovation.

In addition to this, article, we are sharing the guide below on digital maturity and innovation which should allow you to assess and identify the key signs for yourself.

Guide #4 - Why you should care about your organization’s digital maturity and what it has to do with unlocking innovation and having successful transformations.

💡A guide on organizational redesign, digital maturity and unlocking innovation.Every organization truly wants to deliver quality products that customers love. They also want to grow/scale and increase revenue or maintain market share! Quite often they struggle to address the key gaps from culture,…

digitalproductjobsKJ Sethna

Part 4 - The Agile Factory & CSPO CSM cert scams

In the software space, for almost 2 decades now we have had multiple "agile education McDojos" running a scam to print money and publish certificates. 🤑

• This has led to a massive global epidemic of feature factories with folk calling themselves "🤡 certified product owners" - CSPO.
  CSPOs normally are brainwashed to think that a 2-day certification course makes them a product manager 🙄.

It does not.

This is very similar to what happened in the martial arts world where the term McDojos came from.

McDojo is a black belt factory that adds no value to a person.

These cert factories are cult based and brainwash their practitioners that they are able to defeat anyone in a self-defense situation and end up issuing certificates, running competitions, and different grades of black belts.

It occasionally then causes folk that walk around bragging about their belts and how many gold medals they have in some competition. 🤕

Why are companies & people paying for these courses if they are so bad?

Great marketing tactics for job seekers and ignorant management teams

• Great marketing from the agile factory on how getting a certificate after 2 days will make you a better product person has led to a spike in these certifications.
• Additionally, the marketing is so effective to ignorant management teams that they believe simply upskilling their people with a 2-day course will be an easy fix to some of their deeper inherent problems.
• Many people also believe that getting this certification on their resumes will help them land a job. On the contrary, it can be quite harmful. Hiring managers who are particular about not hiring " delivery" people will avoid candidates that boast their PMI, PMP, Scruminc, Scrumorg, and other agile cult certificates.

The silver bullet promise to companies for up-skilling and transformation‌‌

Many organizations have been led to believe that these certifications are a silver bullet to learning and development and they will solve problems with innovation and their teams' efficiency.

Companies also fall for the trap where they think it will help "up-skill" their project/delivery managers or business analysts to understand product management in a 2-day course and help them unlock innovation?!

If it's not waterfall, we will "be agile" mentality🤕‌‌
Due to the agile consultants that preach the manifesto like a bible, the common enemy across organizations is Waterfall. Saying anything against Waterfall helps steer emotion and behaviors.

At the time that Scrum became famous, waterfall was on the way out. It was easy to implement and see results in delivery with teams improving on output. This resulted in people assuming that certification will "get you there".

Why its a waste of money?‌‌

1. Course length to skills gained + NO BANG FOR BUCK
   Most courses worth their weight in gold are 1-3 years in length and teach you a range of skills and elevate your knowledge. These great courses have units that cost 1/4th of the cost of this 2-day course. In some countries, an entire semester or year can cost the price of this 2-day course.
   
2. Gamified leveling & stickiness
   These Product Owner / Scrum Master courses offer different levels of skimming. They aim to get more money from brainwashed people and further get you to invest in their cult making the stickiness greater.
   
3. They simply teach the wrong way of product development
   These courses teach people how to effectively become backlog administrators. They do not educate on product management and this results in a false ideology about how product development should take place.

🤫 Big secret

‌‌
Folk that normally have these certifications, wear them like a badge of honor and join the "agile cult", will not be able to see beyond this because they have been brainwashed to believe in the cult. I know this firsthand because I have been part of the agile and martial arts cults!

This is just like the world of martial arts where, black belt factories issue certificates, and where people put their black belt certificates up on the wall as something to brag about!

They call it McDojos.

You are then brainwashed to think that there is no other way or your style is the best. This is what the scrum guide does - don't believe me?

Then follow scrum practitioners on LinkedIn and see their debates for yourself if you object to something in the scrum guide.

🥺 So is Scrum an effective "delivery" framework?

In the new version of the scrum guide, the founders of scrum actually say it's not robust at all and is a lightweight framework.

So the simple answer is No.

• Scrum is a project management framework for delivery management
• The most effective piece of Scrum which is the Kanban board is from methodology outside Scrum.
• Scrum lacks the technical practices required to improve the way of developing code
• Scrum lacks product management practices to improve ways of conducting discovery and validating problems
• Scrum completely ignores how businesses operate operationally by locking teams into cyclic loops with slow-release cadences
• Scrum ceremonies/events result in chores that many teams end up hating to do but are forced to do
• Scrum forces a loop of backlog administration which leads to feature iterations

If a team combines elements of Scrum such as the empiricism practices with elements of other methodologies & frameworks you may have a framework & methodology that works for your team. But by itself, it's practically a pathway to being a feature factory. However, then the team must ask why do scrum at all!

Then why do many organizations or teams go for Scrum?

• Adopting the success of others or what the consultant told them‌‌
  With the success of some organizations adopting Scrum or Spotify tribe-like frameworks and achieving success, many other organizations thought, let's do this to replicate success!
  
  Or at least that is what the transformation consultants told them. This is almost like the organizations in the 90s that saw Toyota's success and thought taking the Toyota Production System and copying it over will help them achieve success.
  
  This led to organizations spending millions on transformation only to realize they cannot replicate Toyota's success. This was highlighted by the late Dr. Eli Goldratt in the Hitachi example (link below). ‌‌
  Hitachi Example
  
  Often these "delivery teams" end up being stuck in the build trap because they a flawed by design. The folk hired here don't know any better because they haven't seen it any different and live in a bubble.

Beware - this type of behavior kills innovation & adds no value to the organization or end customer.

• Process-driven delivery line‌‌
  The usual sign is a heavily process-driven factory-like product line in a manufacturing plant. ‌‌‌‌Another sign is the adoption of frameworks like SAFe.
  
  For example - ‌‌a Daily Standup + Design Sprint + Dev Sprint + UAT +Release + Retro/Showcase + Some giant planning session + GANTT charts?? & REPEAT!!!!!
  
• Bubble and no catalyst for change‌
  ‌Some organizations are lucky to live in the monopoly bubble which is a non-disruptive reactive bubble.
  Being in this bubble results in the organization not requiring any changes.
  
• It's not Waterfall‌
  ‌Waterfall led to massive delays in projects and product releases. ‌‌When the manifesto came out, organizations were looking for a silver bullet that can help them fast without much effort.  ie: Improve factory output not improve business outcome.

And at the time they were doing Scrum instead of waterfall seemed like an effective way to help eliminate dysfunction caused by silo department behavior and old-school processes from the 19 & 20th centuries.

• Bought into the cert kool-aid
  ‌‌Lastly, the cert factories and consultants have sold this kool-aid well. 🤑
  Once you are in the cycle, it's very hard to get out. Scrum can take a poorly oiled machine and make it a well-oiled machine.
  
  Ahem, a Factory with feature shipments every two weeks?!!

Wait! I am in this bubble. How do I get out of the build trap?

In my experience, you most likely cannot as it requires culture change and massive disruption to the organization which many organizations do not have an appetite for.

There is also a risk of becoming like the culture that you are trying to change.

This is why I call it a "death march factory".

My recommendation for anyone who really wants to work in an innovative organization is to seek one out and leave their current build factory.

Advice for transformation nerds
‌‌Beware: Trying to challenge the status quo in a team or organization that is deeply buried in cult-like behaviors will result in unwanted disruption and you may be cast out.

This takes some skill and experience of failing 😉 to get right or knowing when to step away from.

JAPANESE PROVERB‌‌
‌‌" the nail that sticks out get's hammered in".

As a product enthusiast, what can I do then?

1. Educate yourself on the topics of good product management and good product management practices. Read books like Inspired by Marty Cagan and Escaping the build trap by Melissa Perri.
2. Educate your teams on the topics of good product management and experimentation.
3. Build the skills of being a product manager by changing the way you work.
4. Inspire your teams and management team to work in a new way.
5. And if all else fails, get out and find a good company to work in or become a founder of one!

‌If you enjoyed this, be sure to tune in for more by signing up to the free newsletter.