Why the product team has to say NO (sometimes) 🚫
The process 🖇️
Product Managers are confronted every day with an essential conflict between:
- The need to remain agile, to be responsive in developing what is important, with short cycles between input and output.
- The amount of requests, more than the team can handle.
Let’s see an overview of the process that certain items go through before going into development, and then deepen certain points of this flow.
Feedback and data 💁🏻
The team, consisting of Product Managers, Designers, Developers, continuously listens to consumers, analyzing data, and collecting feedback through interviews and other practices to understand how they cope with the product, the needs, the whole market.
It’s not just consumers who are listened to: internal stakeholders are equally important and the business is a great source of insights, innovation, and ideas to better serve the needs of our customers.
So whenever someone comes to the product team with feedback, a request or an idea, the wheel starts spinning and the product team starts working on the process above.
Analyze Data📊
Once input is received, the Team will start working with the stakeholders to refine the theme, to understand its impact, priority, sustainability, effects, and issues that may arise in the process or after the release of the feature/product.
With the exception of smaller themes that impact the product with priority, as with customer-facing bugs, the product team has developed processes and documents such as PSK (Product Scoping Kit) to refine the feature or the product and then put it into the pipeline.
Confidence 💪🏻
An essential element to define if, when, and how the feature is developed is the degree of confidence you have about the theme.
As you can see from the graph developed by Itamar Gilad, the higher the level of confidence, the more it will be possible for the team to prioritize and better define whether the feature should be prioritized over others or whether it should be postponed to others.
Sandbox or Backlog? ⚠️
First of all, it is necessary to give a definition of sandbox and backlog:
- Product Sandbox: is the place where ideas are suggested, waiting to be discussed and moved to a relevant “box” (backlog) or deleted.
- Product Backlog: according to the Scrum guide, it is an ordered list of everything that is known to be needed to be developed in the product. It is the single source of requirements for any changes to be made to the product. Things on the top are cut really small, certain, and well refined. The team knows exactly what to do with them. The items farther back are rough, large, not well defined.
Once, therefore, an initial analysis of the subject under discussion has taken place, the decision to be taken is:
Does this item go in the Sandbox or in the Backlog?
If it goes in the backlog, does this go on top of this, or at the bottom?
This decision depends on the factors taken in the analysis above, in particular:
- Degree of Confidence
- Degree of refinement of the topic
- Ease of development
- Impact on the business
- Impact on our customers
- Priority in reaching the OKRs
- Domain Area
Wrap-Up ✅
As we have seen through all the above-mentioned steps, there are many times when it is possible to come up with ideas or proposals and then add items in the pipeline.
Although the tendency would be wanting to satisfy all the requests and needs of our customers and stakeholders, sometimes it is much more important to be able to firmly say no.
This is in order to meet the most important priorities of the entire company and of our consumers, something on which a well-structured product team has the broadest and most complete vision.
