13 Feb 2023
In 2023, there is a large number of organizations practicing product development, and this led to an evolution of 2 main types of organizations. The “Agile” project organization and the “Empowered” product organization.
These organizations are structured and operate differently. Their culture and strategy are also vastly different. The way they operate allows them to deliver innovation at different paces.
The key difference is that project-focused organizations are not for product people but are definitely for delivery people as they require delivery skills over product management skills.
The good news - both types of these organizations will exist in the near future. However, empowered product organizations will dominate the markets and customers’ hearts.
As a product person, understanding that difference can help elevate your career, and reduce stress while preventing burnout. Having this clarity of different types of organizations will allow you to make conscious decisions on where you want to work.
Please note, there is nothing wrong with being a project manager, scrum master, agile coach, product owner, or business analyst; however, it is important to understand that you do not work in a product organization if you hold these roles.
You are also not truly empowered and may be part of a dysfunctional factory outlet. If you are comfortable with that type of work like many, then go ahead doing what you are doing – it helps pay the bills! However, if you want to change – read on as I describe the key differences between both types of organizations.
There are 4 fundamental concepts that are highlighted by some key product evangelists previously which are relevant:
1-The Feature Factories coined by John Cutler
2-The Build Trap described by Melissa Perri in her book
3-The Product Death Cycleas David Bland described it
4-And my favorite thus far - The product team vs the feature team by Marty Cagan, where he refers to them as truly being empowered
I have spent the majority of my career working for “project organizations” or organizations trying to “be Agile”.
Further to this, I have even been offered the role of an agile coach for a famous Melbourne-based Agile consultancy which I declined. During this journey in product development, I came to realize the shortcomings of our industry.
By working with many organizations, I was able to identify the patterns in the techniques, methods, and frameworks they use and see the shortcomings of the world of Agile and the world of Scrum.
This has allowed me to pivot my career into product management with the sole purpose of finding better ways of working. Agile and scrum are not it!
I am now able to truly shift outcomes, which allows me to work as a product manager, product director, head of product, and product coach.
Further to this, I have helped a few project organizations (and the people in them) that were stuck in what I like to call “the feature factory delivery mode or death marches!” to move to empowered product teams successfully allowing them to build product practices from scratch.
In this article, I will share my findings from my travels in the world of Projects and Products so that others can draw from them and help determine if they belong in products or projects.
These are often called innovative, tech, or product companies where IT is a profit center, no questions asked. They are visionary in nature and constantly try to disrupt and push boundaries of what is possible.
Their nature is to be disruptive with a focus on constantly evolving problem solution fit to find a product market fit and eventually a business model fit. This allows them to push boundaries on what's possible.
They are not afraid of getting rid of customers that do not fit their ideal customer profile.
The success is driven by the key quadrants of a core product - desirability, feasibility, viability, and scalability.
These organizations allow their teams to have psychological safety to make decisions, fail and learn, ultimately creating a culture of empowerment and learning which leads to innovation.
They avoid projects with “initiations and closures” and try to do things with growth lifecycles of products – where the product has continuous lifecycles. The work on product development is focused on the following main quadrants – retention, activation, referral, revenue, and acquisition.
Multiple initiatives are taken to shift the needle on these. Most often, these teams follow the OKR framework.
They avoid “feature builds” as their main goal is disrupting the competition and market to continuously find product market fit or even problem-solution fit.
These organizations have prioritization and decision-making frameworks, with teams that are empowered to make decisions quickly. This allows the teams to pivot quickly and discover, validate and ideate on ideas and solutions fast.
The work is carried out in continuous discovery techniques as defined by Teressa Torres in her book, rather than the traditional project cyclic discovery.
50% of the time is spent on problem and solution discovery.
They hire product managers and product designers.
They do not hire project managers or product owners or UI/UX designers.
They use Kanban or Dev Ops for delivery while also trying to break away from frameworks and models.
The most commonly found pattern is that they avoid scrum and SAFe like the plague.
They use business or product model canvases to discover the viability of their product, identifying the potential revenue and costs while setting goals. The cycle of the product is continuous, and the focus is on growth models such as AARRR vs. RARRA.
They are not afraid to speak with their customers or potential customers. The teams are empowered 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%.
These organizations are not scared of failure and will test their products in the market to find their ideal customer profile (ICP).
When they realize the customers are not part of their ICP they make the respective changes to ensure that they retarget and market only to the ICP while putting the non ICP customers on life support and end of life products or features.
Many of these organizations are also sales or marketing led. They tend to be older and larger organizations. Sometimes they are industries of organizations.
These organizations focus on “controlled activities” limiting Risk and Exposure.
This is mainly driven by governance, accounting, and finance processes which are for sustainability rather than disruption.
The outcome is that innovation is slow or nonexistent. Furthermore, the focus on governance leads to a top-down culture. These organizations refer to themselves as "Agile Organizations" or have undergone some sort of “Digital Transformation”.
I call them Dinosaurs!
With a core focus on maintaining market share, their focus becomes survivability resulting in building feature parity or just making customers happy.
They are lagers in innovation and mostly treat IT as a cost center, with everything being executed in “projects” or if they are fancy, they even call them “products” with scrum teams.
Since they are output focused and not outcome focused, they measure their success based on how much they have delivered on a particular budget.
For example, velocity delivered to a team of 6 people or even the number of features delivered as per a planned roadmap.
Due to the focus on governance & control, the ultimate outcome is a culture of mistrust, blame, and toxicity.
But worry not, they say we are Agile and digital. We do retrospectives. We do scrum and SAFe?!
Product development starts with initiatives or projects or epics. The focus is on a feature.
Almost all development work starts with initiations and ends with closures. The cycle of product development is within a project or “feature build”.
As innovation is not part of their culture, process efficiency becomes paramount to these organizations. Releasing every week or two weeks is the keyway of working for their teams.
They may have prioritization and decision-making frameworks but rely on longer governance cycles and processes for approvals.
These organizations have delivery teams who are tasked with delivering an output (scope) by a certain time frame and budget, usually on a “ROADMAP”.
They hire product owners, UX designers, project/program managers, and business analysts.
As the work is in project cycles, they use Agile and Waterfall project methodologies and their respective frameworks. For example - PRINCE2 or PMBOK, Scrum, and SAFe.
These teams avoid Kanban and DevOps as that doesn’t give them any “certainty” which is what their stakeholders need when signing off on things.
They use business plans and cases to get approval for funding/budgets for their projects or features ultimately resulting in some bloated product or platform with unnecessary features no one needs.
As the teams are measured by how much is delivered rather than how they have shifted the paragon, these teams avoid their customers or potential customers and usually take ideas thrown over the fence. 5% of time is spent in the problem space on discovery, and 95% of the time is spent on solution delivery.
In conclusion, both Agile project organizations and Empowered product organizations have their own unique advantages and disadvantages. Agile project organizations prioritize flexibility and adaptability, allowing them to respond to changes and deliver projects efficiently and quickly.
On the other hand, Empowered product organizations focus on empowering individuals and teams to make decisions and drive the product vision, resulting in a more holistic and long-term approach to product development.
Ultimately, the choice between the two will depend on the specific needs and goals of the organization. Agile project organizations may be the better choice for organizations that require quick delivery of projects, while Empowered product organizations may be more suitable for organizations that prioritize product vision and long-term success. It is important for organizations to carefully consider the trade-offs between the two approaches and choose the one that aligns best with their goals and culture. By doing so, organizations can ensure that they have a well-defined and effective approach to product development that will lead to successful outcomes.
21 Sep 2023Your Guide to Backlog: Product vs. Sprint Backlog