Agile Journal Agile methodologies like Scrum are used widely to develop software products.

They describe key roles and responsibilities for the product development team with the aim of delivering products that are valued by customers.

What is not included by most Agile methodologies are the other activities needed to ensure products are successful, for example, optimizing in-life, pricing, and marketing. Without these activities, a great product, while it might be valued by customers, won’t maximize its commercial return for a business and may fail altogether.

So, what’s needed by businesses are the activities covered by Agile development methodologies as well as other product management activities.

The impact of Agile on ways of working

As discussed elsewhere, Agile enables the rapid validation of product ideas. It accepts that we can’t know the right answer upfront and that change is inevitable – so we are better off building iteratively and incrementally.

Agile vs PM

Successful products

If we’re managing a product, this impacts the cadence that we work at and our workload. We need to work closely with Development on a continuous basis, but we get fast regular deliveries that we can try with customers and there are fewer complaints when we make a change in direction.

It’s also about empowerment. Trusting product teams to deliver products that customers want and giving them the tools and authority to get on and do it.

What does product management include?

In the product world, we find that it’s almost impossible to guess what someone does from their job title. It varies from company to company and sometimes even within the same company.

So, it’s important to distinguish between job titles and the activities they actually do.

In our Product Activities Framework, you can see all the activities that need to be done in any company with products.

Product Activities Framework

Product Activities Framework


The framework is divided into three key areas – strategic product activities which are about working out the right product for the business. Inbound activities are about helping the business to develop and support the product. Finally, there are outbound activities that are helping the business to market and sell the product.

Product Managers take on many of these product activities for their products.

Product Owner or Product Manager?

In some product businesses that use Agile, there are Product Owners and no Product Managers. But, that doesn’t mean these product activities aren’t being done.

Product Owners, as defined by Scrum, are responsible for maximizing the value of the product resulting from the work of the Development team, which typically maps to the Inbound Activities in the Product Activities Framework, coupled with work on vision, customer insight, and planning. When there are no Product Managers, we often see that the Product Owner’s responsibilities expand to take on some of the other activities shown in the framework.

More often, we see the product activities split between a Product Manager and Product Owner role – with typically the Product Manager giving high-level product direction to the Product Owner.

You can see the organizational split of Product Owners and Product Managers in our annual industry survey.

What is the impact on organizational structure?

There are many different organizational structures for companies.

Most ‘traditional’ companies have a matrix organizational structure with separate functions and departments (Development, Testing/QA, Finance, Marketing, Product Management, etc.,) and then temporary cross-functional teams with a mix of different roles that come together to work on products and projects.

You can think of these as vertical and horizontal dimensions. These companies prioritize the functions which are shown as the vertical dimension in the chart below.

It makes sense to keep the experts from one function together so they can learn from each other, build expertise and the company can manage scarce and valuable resources. For example, now and again a Product Manager needs support from Finance to develop a business case but the product doesn’t need this expertise available full time, all the time.

In this structure, a Product Manager typically leads a virtual team with representatives from different functions. For example, when launching a product, they may be working with colleagues from the Development, Sales, Marketing, and Support functions. These colleagues don’t report to them directly but as a sports team, the Product Manager is the captain.

Resources, virtual teams, and silos

In this more traditional matrix-style organization, people are assigned from a function for the duration of a project to a temporary team. It is founded on the myth that people are fungible (exchangeable) and reinforced by using the word “resource” for people. Essentially the idea is that you can put a different technical architect onto a product, and they will be as productive as the last one because they have the skills. What this misses is that someone new doesn’t have the tacit knowledge (that only comes with experience) about that product and its domain.

Another problem with this organizational design is that although the horizontal dimension is deemphasized, it represents the value of delivering teams that are key to the company’s success.

Various techniques are used to support this horizontal dimension like cross-functional processes (e.g., for product development) and having objectives, reporting, and incentives for the product or project teams.

And of course, having separate functions can lead to a silo mentality – especially if each function has its own objectives. If you’ve got a Product Manager in one department and a Product Owner in another, it’s easy to see how they might start pulling in different directions.

Organizational structure prioritized by product

So, another approach is to make product teams the dominant vertical dimension.

Although not radically new, permanent cross-functional teams are a key tenet of Agile, and many digital Agile organizations (like Spotify), are set up like this. See the article on Scaling Agile.

Structure by product

With this approach, the product team (or squad) is designed to feel like a mini start-up. They have all the skills and tools needed to design, develop, test, and release a product. They can really become experts in their product area and feel strong ownership of what they develop. They all sit together in the same team, and pull in the same direction, and because of that, their performance is more predictable.

This resonates well in the digital age. Google and many other leading tech companies use this cross-functional or team-based organizational structure. It’s not about top-down orders but empowering teams to deliver. It helps maintain a small-company feel in a big company and promotes the notion that all employees play an equally important part in the company’s success.

Culturally, it places more importance on intelligence and ideas than on titles … ‘democracy and meritocracy rather than command and control.

All this plays well when you’re employing highly paid knowledge workers who can easily move to a competitor, should they want to. And more importantly, it creates great software products!

So what does it all mean for product management?

Most organizational structures are a mix

Most, if not all, organizations with technology products have a mix of product teams and separate functional silos. Development may happen in the product teams, but product management activities get done across the business by a group of people with various job titles, including Product Manager.

And there are always real-world constraints – resource and budget limitations. So Product Owners take on multiple scrum teams, scarce UX resource is spread across development and subject matter experts e.g., Agile coaches, are spread across the organization.

In our experience, organizational structures grow organically. Organizational design and Agile consultants come and go … empires wax and wane. That’s not necessarily bad as organizational structure (like everything else) needs to adapt and change as a business evolves.

Is Agile the same as ‘digital transformation?’

Digital transformation is the use of digital technology to help deliver more customer and business value. This implies using software and creating digital products. As Agile development approaches are almost universally used for software, the two go hand-in-hand.


But digital transformation can also apply to companies with physical products. It might be the digitization of their supply chain tracking or order in-take, just as much as digital products’ delivery. For example, Domino’s Pizza developing a digital ordering platform that gives customers visibility from their order through to delivery.

Product management should be at the heart of this as we are a key catalyst for this sort of change. With our focus on customer and business value, this is what we should be championing.


The reality for most product people is that they don’t get to choose what their organization looks like. Development introduces Agile development approaches; digital transformations are spearheaded by the CEO and the organization changes. If you’re a senior product person, you may be able to influence things, and even if you’re more junior, you can still influence best practices in your area.

But, we believe, that whatever your organizational structure or job title, you need to make sure you do the most professional job you can. And, world class product management is needed in organizations whether they use Agile or not.

Read more about Agile.