Introduction
As a Product Owner, I want to build a good product so the organization receives value. This is a simple but powerful statement for Product Owners, as we are usually the value maximizers in the organization. To achieve this, we need to collaborate with stakeholders on many levels, prepare the mission and vision, compose a roadmap, and oversee delivery.
There are many tips for Product Owners starting their careers, and plenty of articles discussing Product Owner responsibilities and role models. Most of them are correct, but they are not necessarily right in every situation. Even within the same organization, we may understand the Product Owner role differently. The area of influence, product scope, and importance in the overall landscape can change rapidly.
Over the last year, I noticed that expectations of the role may lead to consequences that organizations, stakeholders, and development teams rarely think about. These expectations can have a profound impact on the product, the employee, and the entire development team.
User Story Writing
Recently, I had plenty of conversations about writing good user stories and spent hours discussing what is, and what is not, part of a good user story. We also had many valuable discussions around user story syntax. Our organization followed a very well-known structure.
Theoretically, we do not have to follow any specific syntax. A user story can simply be a card, a conversation, and confirmation. In practice, however, we need to ensure that the story is written in a way that is understandable. The devil is in the details. How do we write a user story that is easy to understand while still explaining the business need behind it?
This simple agreement is key to overall project success. A poorly written story can mislead the entire team and push them in the wrong direction, even if nobody notices it at first.
A common user story structure looks like this:
As a role,
I want functionality,
So that business value.
I like to use comparisons in my work and visualize digital products in more tangible ways. For example, I often use a pizzeria analogy when explaining business needs related to technical implementations. It helps everyone understand the problem from different perspectives.
Let me translate the user story syntax into a pizza restaurant example:
As a customer,
I want to place an order,
So I receive pizza.
In this user story, we have a hungry customer entering an Italian restaurant and wanting something to eat quickly. To achieve this, they need to place an order, either directly with the waiter or in another way. In the end, however, they simply want pizza.
The customer is not telling us exactly how they want to place the order. They may not know HOW to do it, but they know WHAT they want. This user story gives the team more flexibility in choosing the right solution. It also emphasizes trust that the Scrum team can self-manage and internally decide who does what, when, and how.
The further we are in product development, the more we understand what we need. Because of that, we can narrow requirements down over time, especially when the product foundations already exist and the solution is operational.
As a customer,
I want to place an order in a self-service cashier,
So I receive pizza without contacting the waiter.
This user story provides more details about how the work should be executed. We no longer have flexibility in choosing the environment because the solution was already specified in the requirement.
This approach is suitable for products that already have something tangible. It would be difficult to develop a self-service cashier solution if no cashier exists yet. In such situations, the team may insist on creating an enabling user story for the cashier first.
Waterfall 2.0
Over the last couple of years, many people in my professional bubble have said that we should work in Agile. At the same time, I often heard people saying, “this is not Agile.”
Many organizations consider themselves Agile-driven without truly being Agile. Others follow Agile principles carefully while understanding that full agility is rarely possible. It is also common for development teams not to fully understand the assumptions behind Scrum or Agile methodologies in general.
This may quickly lead to a modern hybrid approach often called “Waterfall 2.0.”
This methodology is sometimes explained using a baking analogy. Less experienced teams are often willing to approach development with Waterfall 2.0 while still calling it Agile. This helps manage anxiety around technical debt and skill gaps because the team knows all required work upfront.
There is nothing wrong with Waterfall 2.0, and it is broadly used in organizations that are too large to be fully Agile, corporations operating in regulated markets, or companies with firmly established boundaries.
We just need to understand the trade-offs. Hybrid approaches often require more preparation upfront. This affects team utilization and assignments throughout the development lifecycle. Understanding this is a crucial step toward building an effective team.
Conclusion
I truly believe that Agile is a great methodology, but it is not the only valid option. There is also nothing wrong with hybrid approaches. In reality, most of us already work in hybrid environments, even if we do not admit it at first.
We simply need to be aware of the consequences. Hybrid approaches usually require more preparation upfront, which often creates a more sequential workflow rather than coordinated development circles.
Edit
I still do not understand why user stories like the following sometimes appear in backlogs:
As a Product Owner,
I want to do something,
So something is done.
or
As a Data Team member,
I want to implement something,
So something is implemented.
From my perspective, this feels like an anti-pattern in user story writing.
First, a Product Owner or team member is usually not the direct beneficiary of the work. Second, these examples do not represent any clear business need or business value. Third, this is not really a user story at all. Lastly, it becomes a tautology.
Let us use the pizza restaurant example again:
As a pizza chef,
I want to make pizza,
So pizza is made and served to customers.
As a waiter,
I want to serve customers,
So customers are served.
As a pizza place owner,
I want to produce and sell pizzas,
So I can make money.
All of these examples are tautological. A pizza chef is already expected to make pizza. A waiter is expected to serve customers. A restaurant owner naturally wants to sell pizzas and earn money. That is the core purpose of their role.
Because of that, these user stories could be added to the backlog almost at any time and would still “fit” the picture, despite having little direct influence on actual product development.
To me, a good user story should explain who benefits from the change and why the change matters. Otherwise, we risk creating backlog items that describe responsibilities instead of value.
Leave a Reply