Of course, we could go back to 1986 when Hirotaka Takeuchi and Ikujiro Nonaka published The new new product development game, a paper with a strong product imprint considered a foundational milestone that gave birth to development with Scrum.
But since this thorough study on product is well known, let's not delve into it. However, let's emphasize that the essence of their ideas remains relevant today despite the speed at which things change.
For someone in charge of advancing a product, it's common to have to deal with many issues along the way. Sometimes it seems they should include in their skills description that they also possess forecasting abilities, and that's not the idea.
In reality, if the appropriate practices that Agile Product Management offers are carried out, we can experience fewer shocks. Let's look at some of them and how they make a difference.
What is Agile Product Management?
Let's start by briefly defining what the discipline of agile Product Management is. First, Product Management is the set of practices that allows us to know and understand the problems that the user is going through and to design the best strategy and tactics to deliver the most valuable product possible as it best responds to their needs, within the scope of the business.
The attribute of agility for product management offers us the necessary flexibility to constantly respond to changes that occur during the product's creation.
It's important to keep in mind that Agile Product Management is not applicable to the development of any type of product. However, many benefits can be found when we talk about technology-based or technology-driven products.
What are the benefits of moving away from the delivery mindset?
Now let's look at some of the most relevant keys to success in agile product management. If we overcome the mindset that makes us focus exclusively on delivery, we are already taking a vital step towards a much more innovative and customer-close development experience. In fact, I notice more and more how many companies have already overcome it.
The delivery mindset appears when, among other issues, teams are characterized by producing deliverables without paying attention to the value they bring to users (we will see this later) and, often, with a work organization in silos.
A common example of this work scheme occurs when the action of the Scrum Product Owner is reduced to managing the backlog, even lacking the autonomy to prioritize User Stories (Scrum PBIs). However, moving away from this work model, we see that the responsibilities of a Scrum Product Owner include, among others, defining the product strategy and coordinating Discovery.
When the team leaves behind the exclusive focus on deliverables and their acceptance criteria and commits to the results of what they are creating and not just doing "what was requested" new opportunities for creation and satisfaction open up.
Another way to see it is in the kind of conversations that occur in sprint reviews. When we move away from the primary focus on delivery, we notice that not only is it assessed whether the increment meets the specifications of the user stories, but multiple product success factors are also considered.
Certified Scrum Product Owner (CSPO)
What is Product Discovery and why is it strategic?
When we empower product teams, we are giving them problems to solve, and we are giving them the context required to make good decisions.
Marty Cagan (EMPOWERED: Ordinary People, Extraordinary Products)
Product Discovery or Product Discovery are exploration activities carried out to identify the solution that best solves our users' problems, especially in complex and unpredictable contexts such as those involving human behavior. A typical example where Product Discovery is practiced is in the creation of digital solutions.
To do Product Discovery, it's essential to start from the basis that all product design decisions have a high probability of deriving from erroneous assumptions and that following them can result in a waste of time and other resources. Although it may initially cause us a sense of contradiction, Product Discovery activities are allies that show us it's necessary to validate the beliefs we have about users' needs to avoid offering fruitless solutions through our products.
What else is Product Discovery useful for? Its benefits are very broad and we can summarize them in that it mainly helps us mitigate four types of risk: usability for the client, business viability, technical feasibility, and the value that the user will find compared to other proposals.
In all this, it goes very well with agility because it also teaches us that in complex contexts we are not mistaken if we believe we can know in advance what we need to build. But beware, doing Product Discovery is not a guarantee of agility.
Traditional teams and product teams
Linked with Product Discovery, let's see another fundamental criterion of the product team and why this comparison with traditional development teams is so important when it comes to being successful with our business objectives.
The product team is the one that performs Delivery and Discovery activities at the same time. It's known as agile dual-track or agile dual-track to the combination between development and discovery activities that occur simultaneously within the same team. A team with these practices is at a level that proves to be more attentive to outcomes, that is, it not only cares that what it builds is of technical quality and based on the schedule (the outputs) but also wonders about the meaning of what it is creating and the result that users and the company obtain (the outcomes). It actively seeks the possible means to approach the best results and tests them to verify them.
The fact that we differentiate between outcome and output is very important because it's what will mark the horizon of the business value that the team is providing. A particularity of the outcomes is that they are based on assumptions that the team must validate through exploration.
A growing trend is to validate assumptions directly in production through what is known as production data tests techniques to survey the behavior of a particular feature. A transit feature, intermediate feature or transit feature can be something as simple as a google form, a switch, or a pop-up that is used for a certain time to verify that users use it
Another fundamental aspect of the difference between a traditional team and a product team is that the former measures its performance solely based on generating product increments. The purpose of a product team is not to deliver features but to generate results, changes in the behavior of the product's users, etc. It's not enough to deliver user stories. Beyond the Sprint Review (that the feature meets what was expected, with the expected quality and meeting the Definition of Done) it's necessary to take the step of corroborating that the delivered increment generated a real impact in production.
This perspective opens the door to experimentation. For example, A/B testing allows us to compare two features through audience segmentation in order to survey their interest in each of them.
Of course, for this to happen, the organizational conditions that allow teams to dare to explore and learn from these exercises must be given.
How to carry out the relationship with the client
From the business point of view, an atmosphere of distrust that promotes the idea of "us against them" with clients is very harmful but frequent within the work culture. This type of context, sometimes more evident than others, results in a lack of transparency to avoid conflicts, a Scrum Product Owner who is excluded from the team for representing the interests of the client, a sense of purpose absent from what is being built, and even a lack of motivation, which is limited to strictly delivering what was requested, without an interest in exploring the real needs.
This predisposition in the long run ends up playing against us, among other things, because it generates more rework, the products do not end up having the desired impact and clients do not return if they had a negative experience. For those who prefer to escape from this type of behavior and move within a product-oriented paradigm, thinking about the type of link they maintain with the client plays a central role. Just one of the advantages that fostering a close collaborative relationship brings is the closeness to better understand the real problems of the client within our scope of business to surprise them with what we have to offer.
What is the job of the Scrum Product Owner?
Scrum Product Owners have been growing in trend for some years as a result of the explosion of digital products or technology-based products. It's an exciting job for those interested in product strategy, and that's where Agile Product Management as a discipline plays a central role.
The Scrum Guide tells us that the function of the Scrum Product Owner is to be responsible for maximizing the product's value and efficiently managing the Product Backlog, thus ensuring that the increments delivered by the Scrum Team are of the greatest possible value in each Sprint.
Regarding the management of the Product Backlog, the Scrum Product Owner has four major responsibilities: making the Product Backlog known to all, making everyone understand the same thing from the Product Backlog, determining the order in which work is done, and setting product goals.
When it comes to maximizing the product's value, in an article called "Retos que enfrenta el Product Owner más allá del Product Backlog", you can learn about four major challenges this role faces today.
It must be kept in mind that the Scrum Product Owner is the only one responsible for making decisions about the product (it's not a collective job). The lack of compliance with this premise brings problems of altering the Product Backlog that impacts the product design.
On the other hand, let's keep in mind that the typical image of a Scrum Product Owner is that of someone who deals with external clients of the organization, but it's increasingly common to find within the same organizations the possibilities of a career as an internal Scrum Product Owner. Considering the 3 similitudes y 3 diferencias entre Product Owner Interno y Product Owner Externo, the fundamental distinction between the internal and external Scrum Product Owner is that the internal Product Owner's client works within the same organization. But let's keep in mind that the nature of the function of both roles does not change.
What are the similarities and differences between the Product Owner and the Product Manager?
Another key point in a fluid practice of agile Product Management is to clearly understand the difference between discipline and role.
Of course, like everything in life, there are no absolutes. In addition, teams evolve at different speeds and not everyone does things the same way, nor do they choose the same path towards continuous improvement.
It's also important to keep in mind that, depending on the size and structure that companies have, they may call these roles differently with different expectations.
The role of the Product Manager emerged in the 1930s. The first evidence comes from Procter & Gamble and then became popular with Hewlett Packard. Although it was a minor role for much of that history, in the early 1980s, with the advent of many start-ups in Silicon Valley, it began to gain popularity and about 17 years later, with the advent of Scrum, what is known as the Scrum Product Owner appeared.
Before Scrum, the Product Manager was responsible for maximizing the product's value and solving the users' or customers' problems.
It is said that the name change has to do with reinforcing the emphasis that the Scrum Product Owner has regarding owning the product. That is, there is no one who makes decisions for him/her, there is no one who changes things from place if it's not him/her, there is no one who defines a strategy if it's not him/her. Just as at the time they changed the role of Team lead or Project Manager to Scrum Master at the time to differentiate, the same happened with the Product Manager when converting the name to Scrum Product Owner.
In fact, the Scrum guide in 2010 mentions the role of the Product Manager anecdotally and says that if the product is developed outwardly the Scrum Product Owner can be the Product Manager and if the product is developed inwardly (if it's an internal product) the Product Owner can be the line manager of the client area of that product.
However, a few years later, scaling frameworks emerged and, for example, in the world of SAFe (Scaled Agile Framework) two different roles were identified to fulfill these responsibilities: the SAFe Product Manager is in charge of building a product that solves the needs and problems of the users and the SAFe Product Owner is the agile team member responsible for defining the stories and prioritizing the Product Backlog.
If we delve a little into the essence of these activities, we will see that we are talking about Product Discovery and Product Delivery. So, while in Scrum the Scrum Product Owner takes care of Discovery and Delivery, in SAFe this does not necessarily happen, but the SAFe Product Owner only takes care of Delivery and there is a SAFe Product Manager who takes care of the Discovery and strategy part.
Outside the world of agility, many have taken SAFe as a reference for being the most commonly adopted framework and we then find the definition that the Product Manager is the strategist, the one who does the Product Discovery, and the SAFe Product Owner is the tactical of Product Delivery. When from outside the world of agility or the world of Scrum SAFe is taken as a reference to define these roles, we are making a mistake.
The mistake mainly consists of understanding the responsibilities of a Product Manager outside of agility. Within Product Management, we talk about product vision, product strategy, making roadmaps, communicating, prioritizing, setting goals, having insights from both data and users, and validating hypotheses. It's also part of the expectation of a good Product Manager to be able to build products that are ethical but generate this "sticky" and this need to keep using it, complying with the norms. The Product Manager also has to do with marketing, product launches, and product marketing.
The Scrum Product Owner in the definition of maximizing value also has all these same responsibilities. In addition, some specific to doing Scrum such as ordering the Product Backlog, doing slicing, and making the Product Backlog transparent are added.
In other words, Product Management is the discipline and is an integral part of the role of the Scrum Product Owner. Product Owner in turn is the specific role of doing Scrum. If we weren't doing Scrum, we would be Product Managers.
We hope these key points of the practice of Agile Product Management have provided you with useful information in your product vision.