Product Management is a newer “function” and many companies don’t employ it from the beginning. Instead, it tends to emerge over time as companies start focusing on making their software products better. I’d like to describe a common pattern I’ve seen that shows how organizations often introduce Product and related functions in an Agile environment. Of course, not everyone will follow this pattern: the sequence may change or some may jump straight into later stages, but the main progressions is typically similar.
The starting point often looks like this:
“IT”/Technology is developing and operating software applications. Agile Product Owners (POs) exist, but they are typically part of the technology organization and often have less of a true Product background, but tend to have job titles like Business Analyst, etc.
As the organization doubles down on making the software products actual commercial products
and is ready to start emphasizing product as an actual craft and independent function of its own right, Product Management is introduced into the organization:
Subsequently, the POs are replaced with individuals with product management background and corresponding titles. Aside from working within their team, these POs tend to start to engage external users, customers and stakeholders more. Given their experience, focus shifts away from technology-driven applications to actual products. (“IT” – often perceived as a legacy term and mindset – may also be replaced with “Engineering”, “Product Development”, etc. to denote the shift in thinking.)
Soon the organization realizes that its products are lacking from a UI perspective and front end developers appear on the teams:
As focus shifts towards the UI, the organization realizes that UI developers alone will not be able to take the products where they need it to be, the next gap that needs to be filled is around UI design as well as user experience (UX). These are the next functions introduced to the Agile teams:
This paves the way for better design and increased usability as well as early beginnings of user research and prototyping. This is a critical and impactful step resulting in significantly better products.
The next evolution, for those organizations who see the benefits and want to invest more heavily in this area, is threefold: 1) POs are often overwhelmed by the demands of working with the teams and internal stakeholders as well as users and the market. Therefore the PO role may get split and wee see both internally-focused POs as well as Product Managers who focus on the external market, product marketing, etc. 2) For larger efforts and new features, User Experience starts to work ahead of the teams and focuses on quick learning iterations via prototyping and other techniques. This is often referred to as “dual track development”. This approach may also necessitate that 3) individuals focus solely on user research.
With this evolutionary step completed, the organization has reached a high degree of technology and product maturity and will reap the benefits.
With products experiencing a large amount of traffic/use and especially in the B2C / consumer-facing space, additional sophistication around A/B testing, experimentation and quantitative analysis may require to also bring in individuals with special analytical skills.
The progression described above focuses on how an organization and within it its Agile teams adapt to different areas of focus during the evolution of the Product Management function. If we’re taking a step back, the following maturity stages emerge:
- Technology – product as a function and discipline doesn’t exist yet and technology drives development.
- Product – the organizations shifts to and emphasizes product management approaches and techniques.
- Design/User – the users and their experience takes a central role.
- Learning & Optimization – very mature product organizations focus on deliberate and iterative learning using techniques from the Lean Startup, Lean UX, etc. as well quantitative and data-driven approaches.
Inspired by Pendo’s concept of Product Stack, the following capabilities, supported by various, applications and SaaS offerings, are needed during the various stages:
This is my attempt to crystalize a Product Maturity Model from my experiences. Your mileage and environment may vary. What are you seeing “out there”?
Love this article! I think you’ve nailed it in terms of maturity, it often happens what you say – specially with companies with a heavy traditional business function.
Do you have an article which speaks about the product team structure approach?
Thanks, Camila! With team structure, are you referring to the structure of individual development teams or the product organization in general? For the development/Agile teams, I tend to agree with Marty Cagan, i.e. PO, product designer, and tech lead play a critical role, especially as they engage in discovery activities in addition to traditional delivery work.
More like mission teams, or how would you divide product teams within an org – per feature, per platform, per technology?
Lots of options here and “it depends” type of stuff. One thing to consider is how can a team regularly and frequently release value on its own without being bogged down by external dependencies?