This essay discuss the basics of a well-functioning product organization, including trust, strategic alignment, autonomy, and transparency. It also covers common missteps in product organizations, such as confusing discipline with value-creating teams and adopting processes without targeted and continuous adjustment. The document further describes the roles of product managers, UX designers, and software engineers, as well as the importance of the team in a product organization.

Summary

The basic concepts for a well functioning product organization:

• Trust - a catalyst for speed and creativity. Trust is both a belief in others as well as an acceptance that others can solve the problems and challenges at hand.
• Strategic alignment - It should be crystal clear for the teams what the main strategic business objective is, and what business objectives are supporting that strategy. Conflicting strategies is a recipe for failure.
• Autonomy - Autonomy in practice means that the leaders lead with measurable goals and clear direction whereas the teams are tasked with finding the solutions to identified problems and the strategic direction to solve them.
• Transparency - everyone should have equal access to information relevant to their role and their work.

Common missteps in product organizations:

• Confusing discipline with value creating teams - a discipline is not a vehicle for value creation itself. The discipline exist to power the cross functional work to achieve business outcomes.
• Process adoption without targeted and continuous adjustment - The rhythm and the context of each product and organization is unique which means that all processes needs to be experimented with, adapted, and (often times) broken down and rebuilt.

The roles

• Product Manager - responsible for the overall vision and strategy of the product. They take a holistic view of the business, opportunities and resources and, depending on the company, can be responsible for the value creation in the team or area. They are equipped with KPIs to measure success and are tasked with what problem to solve, when to solve it and the appetite we have to solve it.
• UX - The UX role is responsible for researching, designing and testing the user experience of the product. The UXer is tasked with how to optimally solve the problem within the constraints of the given, or potential, user experience of the product.
• Software Engineer - The software engineer is responsible for building and maintaining the product. The software engineer is tasked with technical feasibility and implementation of the solution in the product.

The team

• The team is the main nucleus in a product organization. One should adopt a team first approach to remove dependency on individuals from the equation and have the team responsible for their shared value creation. This energizes whole teams, elevates the cross-functional collaboration and allows for distributed ownership of highly complex problem areas.
• The illustration explains the team dynamics, the cross-functionality and the individual responsibilities that constitute the team. Team roles’ efforts are directed towards the center of the “flower” which highlights the iterative process of the team and team dynamics.

• The product manager is placed at the top as the PM is tasked with the responsibility of the value creation and thus naturally will take a leadership role in the team. For optimal results the PM should co-lead the team with the Engineering lead.

Reporting lines

• Line management and value creation are two separate reporting lines. Whether the discipline line management is anchored at C-level depends on the individual skills of the given C-level representative. CxOs without skill within a reporting discipline need a strong VP or Director-level people to secure growth within the given disciplines.

ㅤ

Product Organization

The basics

For a well functioning product organization to function there are a few key elements that need to be in place. You can call these the basic concepts that allow for effective and successful product development to happen. Without these concepts in place you will have to employ counter measures to compensate to avoid wasted time, wasted effort and loss of focus and direction.

Trust

The concept of trust is the most important foundation to build a product organization on top of. You can argue that in a Scandinavian context we have trust embedded in our culture and that we inherently employ the concept in all our processes. And while that is true, the concept of trust in the context of a product organization is much deeper and needs nourishment and constant attention.

Trust in a product organization is what fuels speed and creativity. Trust is both a belief in others, but also an acceptance that others can solve the problems and challenges at hand.

• As an individual you trust in your peers, you trust your team, the people in the neighbouring teams and most of all you trust in yourself and your own skills and craft - and see them in relation to the other skills and crafts of the organization.
• As a team you trust the combined skillset of the team to make the best effort possible, to voice all concerns and resolve team conflicts in the open.
• As leadership you trust individuals to lead teams based on a shared strategy, to find the best solutions to the challenges and problems. You trust in that the teams use the power of a diverse skillset across the organization to maximize the outcome of the work. You hold the teams accountable for the teams’ decisions - with great power comes great responsibility.
• As an organization you trust the teams and individuals to own and get rewarded for the wins, management and leadership to own the failures and everyone to help each other in times of need.

Strategic alignment

The worst enemy of an effective product organization is conflicting strategies. If the product teams do not know which strategy is the most important strategy the team is set up to fail. You can of course have multiple strategies for different parts of the business, but if all strategies are equally important drivers for success the organization would be better off without common strategies. As a general rule multiple strategies are inherently confusing for product teams. It must be clear how the teams priorities and actions are building towards the business objectives, which in turn builds towards the strategy. With multiple strategies you will, in most cases, find that teams will chase several of them at the same time.

The given strategy a product organization works within needs to be aligned all the way up to a CEO level and it needs constant communication and attention from the CEO and the management teams responsible for execution. It should be crystal clear for the teams what the main strategic business objective is, and what business objectives are supporting that strategy. A clear and aligned strategy remove ambiguity in prioritization and allow the teams to navigate and engage the business for support instead of being run down with conflicting demands.

Autonomy

Autonomy is the result of deep trust. A product team and organization needs to own the mandate to seek out the problems to solve, how to solve them and when to maximize the chance of fulfilling the strategy. Autonomy in practice means that the leaders lead with measurable goals and clear direction whereas the teams are tasked with finding the solutions to problems they have identified, and deciding on the strategic direction to solve them.

Autonomy does not however mean that everyone else is hands off. Quite the opposite. Everyone else must be actively supporting and helping the teams succeed by providing them with knowledge, skills and context that the team naturally lacks. But it does mean that the team defines how to use that context for creating products that work. From a management point of view this does mean that you allow for deviations from the standards if the outcome is positive and points towards the strategic north. It also requires management to allow, and in fact encourage, extensive experimentation to find the best route towards the ultimate goal. In encouraging experimentation you inherently allow for failure. But with allowing for failure you build trust and autonomy, and that should be considered a win for future gains.

Transparency

Transparency means that everyone should have equal access to information relevant to their role and their work. In essence this is to avoid information silos, internal politics and unhealthy organizational practices. Usually this is solved by ensuring open documentation, frequent and accessible internal communication, insistence on public conversations in slack/teams/etc and approachable management. A transparent culture needs nurturing and constant attention as people always pull towards closed environments for various reasons. Management and leadership need to set examples and guidelines and practices needs to be enforced.

Common misconceptions in product organization

When setting up a product organization you do that to combine the strengths of different skillsets. Those skillsets are usually represented in different disciplines that individually have their own convictions, pride and craftmanship. The balance between the discipline and the organization is a delicate one. On the one hand you want people to succeed and grow in their discipline, and on the other you want to focus all efforts on the strategic outcome you want to achieve.

In building a product organization it is vital to separate what is a discipline, what is value creation and what is the desired outcome.

Discipline, value creation and desired outcomes

A discipline in the context of a product organization is a means of people management, personal growth and responsibilities within the product development process. But a discipline is not a vehicle for value creation itself. The disciplines exists to power the cross functional work that achieves business outcomes. A desired outcome is (most likely) never to create a discipline for the sake of creating a discipline. Following this the discipline should not mandate the work delivered by the individual members of a discipline or prioritize their work. That is the privilege of the value creating context of the team, the area or the product organization as a whole.

In organizations that use the OKR framework for aligning prioritization of value creating efforts this means that a discipline does not set their own OKRs in the context of the discipline alone. The value creating teams however have the privilege of setting OKRs and assign work accordingly across the disciplinary boundaries.

Process dragons and framework monsters

A product organization does not become a product organization by adopting a pre-defined process or a framework. The rhythm and the context of each product and organization is unique which means that all processes needs to be experimented with, adapted, and (often times) broken down and rebuilt. In large organizations this takes time. And each time the organization is being disrupted (as in re-orgs) the balance shifts and new processes needs to be adopted. Too often, the assumption is that a meeting here or a checkpoint there is good enough to patch a broken process, when in fact the best possible action to take is to remove as much of the process as possible and rely on the basic concepts of trust and autonomy mixed with strategic alignment, transparency and clear (and accessible) goals/KPIs.

The best product organizations limit the time spent on reporting and build automated and transparent communication lines that continuously inform the organization on progress (or the lack thereof).

The roles

In a product organization you usually talk about the product trio of the product manager, UX designer, and software engineer. In data heavy products you usually also include data roles and expand to a quadrant. All are critical roles in a product team, each bringing unique skills and expertise to the table. Here is a breakdown of the three most common roles and responsibilities:

Before we dive into a breakdown of the three most common roles and responsibilities it should be noted that teams are very much the product of the people that sits in it. People are different and thus each team should come together and agree on a team specific version of how the roles interact and share responsibilities. But as a main rule, these are the responsibilities of each roles.

Product Manager

The product manager is responsible for the overall vision and strategy of the product. They are responsible for researching and identifying market opportunities, defining product requirements, and managing the product development process. The product manager also communicates with stakeholders to ensure that their needs are being met and prioritized accordingly. They take a holistic view of the business, opportunities and resources and, depending on the company, can be responsible for the value creation in the team or area. They are equipped with KPIs to measure success and are tasked with what problem to solve, when to solve it and the appetite we have to solve it.

Some of the PM responsibilities:

• Identifying market opportunities and defining product requirements
• Developing a product roadmap and setting priorities
• Working with cross-functional teams to ensure product delivery
• Communicating with stakeholders and ensuring their needs are being met
• Conducting research and gathering customer feedback to improve the product

In essence the PM role is a leader role, although it might not have leadership responsibilities per se. But the level of informal leadership responsibilities is huge. Often the PM is also responsible or accountable for the product performance as well and thus acts as the face of the value creating team.

UX

The UX designer is responsible for designing the user experience of the product. They work closely with the product manager to ensure that the product meets the needs of its users. The UX designer is responsible for designing the user interface, conducting user research, and testing the product to ensure that it is user-friendly and intuitive. The UXer is in other words tasked with how to optimally solve the problem within the constraints of the given user experience of the product.

Responsibilities:

• Conducting user research to identify user needs and preferences (unless you have a dedicated researcher role)
• Creating wireframes and prototypes of the product (unless you have a dedicated designer for it)
• Designing the user interface and user experience of the product
• Conducting usability testing to ensure that the product is user-friendly and intuitive
• Collaborating with the product manager and software engineer to ensure that the product meets the needs of its users

Software engineer

The software engineer is responsible for building and maintaining the product. They are responsible for writing code, testing the product, and ensuring that it is functioning correctly. The software engineer works closely with the product manager and UX designer to ensure that the product is built according to the requirements and specifications.

In other words the software engineer is tasked with technical feasibility and implementation of the solution in the product.

Responsibilities:

• Writing code and building the product
• Testing the product to ensure that it is functioning correctly
• Troubleshooting and debugging any issues that arise
• Collaborating with the product manager and UX designer to ensure that the product meets the requirements and specifications
• Maintaining the product and making updates as needed

Relationships between the roles:

The product manager, UX designer, and software engineer all work together to create a successful product. The product manager sets the overall strategy and vision for the product, while the UX designer focuses on designing the product/user experience, and the software engineer focuses on technically de-risking the building of the product as well as building the actual product. They work collaboratively, with each role bringing their unique skills and expertise to the table.

The product manager communicates the requirements and specifications to the UX designer and software engineer, who work together to design and build the product. The UX designer ensures that the product is user-friendly and meets the needs of its users, while the software engineer ensures that the product is functioning correctly.

In summary, the product manager, UX designer, and software engineer all play critical roles in creating a successful product. They work together collaboratively to ensure that the product meets the requirements and specifications, while also being user-friendly and intuitive.

The Team

The team is the main nucleus in a product organization. One should strive to adopt a “team first” approach to remove dependency on individuals from the equation and rather make the team responsible for their shared value creation. This has the benefit of energizing whole teams as opposed to nurturing creation of individual rockstars, it elevates the cross-functional collaboration as the true success criteria and it allows for distributed ownership of highly complex problem areas.

But for a team first approach to function the team dynamic needs to work and a team leadership needs to be established. And the one role with the sole responsibility of having a holistic view of everything is the natural center to position a team leadership role.

A few years ago, Espen Sundve (then CPO in VG) wrote an article about the need for product management in media. His illustration on the context of the product manager (the bullseye in the middle of the flower) set the standard for how a lot of companies positioned their PMs.

As time has passed this concept still holds true. I have also used the flower illustration as a means of explaining the team dynamics, the cross-functionality and the individual responsibilities that constitutes the team. In the illustration below the team roles are present as well as additional specialists that a given team needs. All their efforts are centered towards the middle of the “flower” which emphasize the iterative process of the team and team dynamics.

The positioning of the product manager at the top of the flower is intentional as the PM is tasked with the responsibility of the value creation - aka the combined efforts of all the team members - and thus naturally will take a leadership role in the team.

This does not however mean that the PM runs all the things. Development and design processes are usually led by the respective disciplines, people responsibilities and personal growth are led by line management etc. But the value creation, which is the main task of a product org, is the PMs responsibility to oversee.

So who reports to whom?

Line management and value creation are two separate reporting lines. In matrix organizations line management is usually within the discipline up until a certain point - usually the C-level. Often the PM, UX and data report to the CPO or CxO unless they have dedicated C-level representation. The CPO would then need strong VP or Director-level people to secure growth within the given disciplines. In other contexts PM, UX, Data and SWE report to the CTO or COO with strong VP/Director support.

In essence this really depends on the individual skills of the given C-level representative. The most important thing is that the discipline health is taken care of and that it does not interfere with the cross-functional value creation that takes place in the teams.

So, does this solve all the problems in my product organization?

Creating high performing product organizations is really hard and require relentless effort over a long period. This article introduces key concepts that are prerequisites to even start. Once you have control over these concepts you have the foundational building blocks in place to become a high performing product organization.

---

Want to learn more?

Oschlo is home to product leaders with 15-20 years of experience in building high performing product organizations. And we love to share our experiences. Reach out to us for a chat to learn more.