Large and small companies differ in many ways. However, all companies are the same in one respect: they can be categorized as product-driven or project-driven. - Apple — product-driven - Microsoft — product-driven - Nike — product-driven - Roofing Company— project-driven - Individual software manufacturer — project-driven

I have worked in both project- and product-driven companies. Most recently I have been working in a company that I am helping to transform from a project-driven world to a product-driven world. We have learned a lot in the process. I would like to share these insights with you and give you some best practices that you can use to drive the transformation of your company towards a product-led organization.

Before we start we have to define some terms, if you are already familiar with these terms you can skip these sections and scroll down to Learnings and Insights.

You can also read this article that provides another deep dive into Projects vs. Products:

Why are so many companies transforming themselves into product-oriented organizations?

The difference between a project-led and a product-led company lies in scaling. Developing products and selling them has huge scaling potential. When developing projects for customers you always have a 1:1 ratio between invested resources and financial gains. When developing and selling products you develop the product once and sell it multiple times (1:n).

This scaling advantage helps companies to grow and improve in many different fields.

1. Increased Customer Focus: By longer developing the product and having a continuous feedback loop product team can enhance their understanding of customer needs.
2. Better quality: by having this scaling effect product-led companies can improve the quality of their products by iterative development of the product and leading on the way.
3. Faster Time-to-Market: By building on existing products, product-led companies can easily use these scaling effects to invent new similar products or expand to new fields/services.
4. Better Services: By using scaling effects companies can invest in support, customer success, and other services that enhance customer experience and customer satisfaction.
5. Data and Insights: By having steady products, companies can collect insights and data about their product and their customers and analyze customer needs, and user behavior leading to improved products and user experience.

Understanding the difference between project-led companies and product-led companies

Definition of a project-led organization:

A project-led organization is a company that organizes its work around individual projects rather than products. In such organizations, the focus is on completing specific projects for customers within a defined timeframe, budget, and scope.

Definition of a product-led organization:

A product-led organization is a company that places the product at the core of its strategy. Operations and decision-making processes are focused on the product. In such organizations, the product itself becomes the primary driver of customer acquisition, retention, and expansion, rather than traditional sales efforts.

Key Differentiators between the two organizational forms

Although there are several similarities between the two forms of organization, we can also identify some important differences.

Mindset: In a project-led organization, the team focuses on completing predefined tasks and execution plans to meet the agreed time and budget. This leads to a focus on short-term goals such as project milestones rather than long-term goals such as improved user experience. Because the focus is on agreed-upon constraints such as budget and schedule, project-centric organizations tend to be risk-averse. On the other hand, product-led organizations focus on customer value and long-term objectives. They see their work as an investment today to gain on a scale tomorrow. The primary mindset in the product-led organization focuses on delivering continuous value to the customers. Since no one knows exactly what the users, the customers, and the market needs, product-led organizations take risks in experimentation and learn on the way.

Goals: In a project-led organization, the main goal is to complete projects on time and within budget. To measure the success of the organization metrics such as on-time delivery, budget adherence, and scope completion are used. On the other hand in product-led organizations, the primary goal is to maximize customer satisfaction by delivering high value through the product. To measure the success of the organization metrics like user engagement, customer retention rates, Net Promoter Score, or revenue growth are used.

Processes, structure, and roles: In project-led organizations, projects often follow a sequential process, with detailed planning and a design phase at the beginning and extensive change control to keep the fixed scope or negotiate scope changes. These processes require specialized roles from project managers to designers and architects. The key player in such organizations is the project manager who invests their time to plan and manage the whole project. On the other hand product-led organizations work in iterative prozesses. They adopt agile frameworks like Scrum or Kanban and follow a continuous development strategy that is focused on gaining insights from users and the market and integrating these insights into the product early and often. This makes the plan and the execution of the plan flexible and adaptive. Which leads to a dynamic product scope that evolves over time based on customer needs, market trends, and feedback.

Risk Management and Change Management In project-led organizations, risk management focuses on the identification and mitigation of risks during the planning and design phase, and there is a huge change resistance since every change leads to changes in the project plan and therefore to additional resources being consumed. This leads to heavy change request processes, discussions, and even conflicts. On the other hand, product-led organizations embrace risks as part of the innovation process. They use iterative cycles and product increments to quickly address and adapt to issues because they welcome changes and new ideas to leverage customer feedback and market trends to their advantage.

Learnings and Insights

The main reason why companies try to change to a product-led organization is that with products you can scale better. Especially in the technology sector, you have limited resources but very complex problems to solve. One of the most limiting resources is experts with the right knowledge. Even if you can afford them, you often just don't find enough technical experts to scale linearly. Switching from project-led (linear growth) to product-led (exponential growth) is therefore a necessary step to grow the business and make more money.

The problem is that such a change is a huge stress for the whole organization and needs proper change management. The risk of failing is high but the rewards are also very high.

So the question is, how can we mitigate risks, what tools, methodologies, and frameworks should we use to ensure that our investment in the transformation leads to the best results?

Working on the Why — the Fish Model

First, let me introduce you to the Fish Model.

The Fish Model shows that during the transformation your costs may rise and the revenue may drop, but this is something you should see as an investment. After the transformation process your revenue will grow faster and even exponentially and the costs will be decoupled from your growth. The Fish Model will motivate you and your management to decide on the transformation and help you to go through the change process.

Who will be affected — Stakeholder Matrix, RASCI & Expectation Management

When you introduce the Product Owner role in a project-led company you start having a lot of discussions about the role and its purpose. On the one hand, it makes sense to reduce unnecessary discussions and conflicts by mapping out the stakeholders of a Product Owner. But the transformation is not only about the Product Owner's role. Other Roles like Sales, Project, Customer Successs and Development also have to change their behavior and act in a product-led way. To understand these changes better we used different tools like a Stakeholder Matrix, a RASCI, and a Expectation Management Matrix. The best practice we built was that we

• first mapped the different stakeholders,
• then we create a draft of a RASCI matrix
• we talked about the RASCI matrix and then
• created an Expection Management Matrix on top of that RASCI matrix.

Stakeholder Matrix

The Stakeholder Matrix shows how to engage with each type of stakeholder. The stakeholders are ordered in the matrix considering the Influence every stakeholder has on the product development (y-axis) and the interest every stakeholder has in the product development (x-axis).

Based on the Stakeholder Matrix we developed a Communication Plan to keep every Stakeholder on a satisfied information level or involve them directly in our work.

RASCI-Matrix

We made use of the RASCI Matrix. With the RASCI Matrix, a team defines the responsibilities and accountabilities of the various roles that are actively involved in a task. This method is primarily used for tasks that require collaboration, but you can also use it to visualize other tasks where only one person is involved. This will make it more transparent to everybody and will avoid conflicts. We used the RASCI Matrix to make the process and behavior changes transparent and to discuss the new way of product-led working.

Expectation Management

Although the RASCI Matrix defines every task in detail, we also made use of the Expectation Management Matrix. We mapped out our personal expectations and wishes this helped to better build the team and to avoid conflicts by discussing different expectations upfront.

Yes — the RASCI Matrix defines the tasks and responsibilities of each role. But in the Expectation Management Matrix, we take a closer look at the personal collaboration level. With this method, everyone has the chance to express their expectations and wishes for each other person.

By filling out the row a person states what he/she expects from the other roles/persons. In the following example, John fills out his row, and explains what he wishes/expects from Lisa, from Anna,…

To understand what other people expect/wish from you, you can read your column. In this example, John can read his column and read what Lisa, Anna, … expect and wish him to do.

Of course, we discuss the expectation matrix together and see if we can meet the expectations and wishes of everyone. You can even describe the offerings and services, you like to provide to your colleagues in your cell next to your name.

Working on the Vision — Product Vision Board

We model the RASCI Matrix with the first line being the Product Vision and a Product Strategy. The reason for this is that a Product Vision and a Product Strategy help the team to align their work and forces in the same direction. To develop a great Product Vision and Product Strategy we use the Product Vision Board.

The biggest learning we had when using the Product Vision Board is, that it is a great kickstart to think about the most important topics of a great product strategy. It is a start but not enough of course. As a Product Owner, we expect you to dig deeper into every topic of the Product Vision Board and come up with data, facts, ideas, and insights.

Working on the Business Model — Business Model Canvas

Based on the Product Vision Board you can build many other things. With The Product Vision Board, you create a basis to develop a Business Model, a Product Strategy, a Roadmap, and a detailed Product Value Proposition.

The Business Model Canvas is a great tool you can use to build on the foundations of the Product Vision.

At its core, the Business Model Canvas helps you to think about the most important elements of a Business Model. The focus of your business should be the product. That is why the Product Vision Board already helps you with filling out some of those fields.

The fields you have to fill out are:

• The Key Partners of your business.
• The Key Activities you have to do in your business.
• The Key Resources you need to run your business.
• The Key Propositions your product is providing.
• The Customer Relationships you build for your business.
• The Customer Segments you address with your product and business.
• The Channels you are actively communicating about your business and your product.
• The Revenue Streams you have within your business.
• The Cost Structure you plan for your business to run.

It is ok to initially fill the Business Model Canvas with your best guesses. However, the Product Owner and the Business Owners must further evaluate each field, execute learning experiments, and add more details over the lifetime of the product and the company.

Working on the Value Proposition

One field of the Business Model Canvas deals with the Key Propositions you want to offer to your customers and users. Also, the Product Vision Board focuses on the value proposition of the product. It deals with the needs of the users and how the product provides features to satisfy these needs. With the Value Proposition Canvas, we take a closer look at the Value Proposition of the product. On the right side, we focus on the user Profile. which Pains do the users encounter and which Gains do the users get from executing the Jobs. On the left side, we focus on the product. Which Services do we provide with our product and how do these features and services help to create gains and relieve the pain of our users?

The Value Proposition canvas can initially be filled out with your best guesses. However, the goal is to identify the underlying hypothesis of each statement and sticky note and to come up with experiments to falsify or prove that the hypotheses are correct.

This will lead to much better insights into the market and their needs and create a great product market fit. The product Market fit is symbolized by the two arrows in the middle of the diagram.

Working on the Roadmap

Roadmaps are an important tool to present your strategy to the stakeholders. They are not detailed milestone plans.

Good Roadmaps are a visualization of a Strategy. They describe strategically important goals the team wants to achieve. That is why good roadmaps focus on outcomes the team needs to achieve and not on outputs the team creates. So in other words good roadmaps are used for communication and discussion they are therefore flexible and adaptable and help the team to welcome change by also giving them the direction of what is important.

A good practice is to order the Benefits you want to create with your product in must-have, performance, and excitement benefits. To craft your product roadmap you can then choose from the performance and excitement Benefits and create a product roadmap.

I like to order the Roadmap in the following way:

For more insights on crafting good roadmaps read this article.

Additional points to focus on:

In addition to the topics above it is wise to introduce a Scrum Master and work on the understanding of agile methodologies and the agile mindset. This will help everybody to move from a plan-driven world into a product-driven agile world.