At the same time, in digital product development, many teams still find that an iterative, user-feedback-driven way of working provides the greatest flexibility. That’s why we were curious to hear how a Product Owner sees this in practice.

We spoke with Ádám Siegler, Managing Director of Topolisz Ltd., who has previously worked as a Product Owner in several organizations and can be considered a true “black belt” in Agile project management. We worked together with Ádám on rewriting and extending his service, Utvonalterv.hu, with additional functionality.

1. Agile Today: Trends and Reality

Recently, there’s been a lot of talk about “Agile is dead.” As a Product Owner, how do you see this discussion based on your own experience?

I believe that no methodology should be applied dogmatically or for its own sake, and this is true for Agile as well. Throughout my career, I’ve often encountered situations where the textbook-style, “overdone” application of Agile methodologies significantly reduced efficiency—especially in large corporate environments.

At the same time, these experiences helped a lot later on: by keeping the core principles but applying them flexibly—while still maintaining structure—we can run development effectively. And this doesn’t only mean holding ceremonies, but also adopting a business mindset, such as always prioritizing the development tasks that deliver the highest customer value.

In your opinion, what does Agile still do particularly well in today’s digital product development—something other operating models struggle with?

I think a straightforward SCRUM framework provides a very useful structure to keep product development on track from both a business and a technological perspective.

Breaking down the full envisioned scope of a product into smaller pieces that can be delivered in short iterations—and then essentially forming a new “contract” every few weeks, reviewing together whether that “contract” has been fulfilled—helps all stakeholders better understand what value each feature or change delivers, to whom, and on what technological foundations and constraints it is built.

I see these as key factors in the quality, marketability, and success of the final product.

In short: Agile helps create commitment among participants toward the product.

2. The Product Owner Role in Practice

As a Product Owner, how would you describe your role in an Agile project? Where does your responsibility end and the development team’s begin?

I’m currently in a special situation because I am both the client and the product manager/owner of the next-generation Utvonalterv.hu application.

Earlier in my career as a PO, I always wanted to be much closer to the client—to better understand their needs and the problems they wanted to solve with the product. Now this has been realized to the fullest extent, as I embody both roles in one person.

That said, my responsibilities are not that different from the classic PO role: understanding the business problem, translating it into technological requirements, prioritizing and scheduling tasks based on value and return, facilitating shared understanding around development tasks, and ensuring that the final product actually solves the original problem. These are what I see as the core responsibilities.

Which decisions or contributions do you think were truly decisive for the project’s success from the PO side?

One of the most important qualities of a Product Owner is not falling too much in love with their own solution ideas.

Working with the Digital Natives team has been a great experience because everyone proactively contributes to the product’s success, asks good questions, and makes valuable suggestions—regardless of their formal role.

As a PO, I always welcome good ideas and valuable suggestions, and I’m happy to admit when I approached a problem incorrectly—I enjoy learning from others’ experience.

Of course, it’s also important to evaluate ideas from an ROI perspective to keep the backlog healthy, but many times we’ve experienced shared success after implementing a developer’s idea.

Backlog prioritization is a challenge for many teams. What helped ensure that the most important items came first?

The fact that my own wallet suffers the consequences of bad decisions :)

Jokes aside, in my previous work I often used the WSJF (Weighted Shortest Job First) method for prioritization. Even if I no longer calculate it precisely, the mindset remains: evaluating each user story by considering its (sometimes hard-to-quantify) business value, risks, complexity, and estimated effort.

This approach helps in planning sprints and ordering backlog items over the longer term.

3. Collaboration with the Scrum Team

Collaboration between the Product Owner and the development team is often key to project success. What worked well in this project?

I think a healthy atmosphere and, most importantly, trust characterize the entire project. This is critical because, as I mentioned earlier, everyone can freely ask questions and suggest ideas, which drives product development forward.

It’s also important that we continuously measure development speed, defect rates, estimation quality, etc. This also strengthens trust, because if any anomaly appears in the process, we immediately see it and can discuss it.

This way, hidden conflicts or lingering negative feelings don’t build up within the team.

Was there a moment when the iterative approach proved especially valuable—e.g. during a pivot or when a new requirement emerged?

Of course—especially since several external partners deliver different components for our digital product. These are external risk factors (e.g. an API endpoint differs from documentation, or a service doesn’t work properly), and they need to be handled.

Agility provides a relatively good framework for reacting quickly to such issues.

4. Agile Collaboration with Digital Natives

From our side, what stood out to you as particularly effective in Agile collaboration? What I would highlight is how our joint project combines precise planning with flexibility in the development process.

Maintaining the balance between these is crucial, and the experienced Digital Natives team understands and senses this very well—and it shows in the quality of the product.

Was there any method or practice in the collaboration that particularly supported effective teamwork? Agile product development consists of repeated iterations and examining problems from multiple perspectives.

While this may not sound efficient at first, it actually ensures that we don’t only discover after implementation that features fail to achieve the original goal.

So ultimately, this is the most cost-effective and rational way to build our digital product.

5. Outlook – The Future of Agile

If you were to start this project again today, would you do anything differently in terms of Agile practices? Looking back, there were obviously a few dead ends and solutions that were ultimately unnecessary. However, I don’t consider these wasted time or money, because they helped us find the right final solution.

Of course, if there had been too many of these, that wouldn’t be something to be proud of. But in both greenfield—and [Check: “barnamezős” = brownfield] development, as in my case—it’s inevitable that sometimes you don’t choose the optimal solution on the first try.

How do you think the Product Owner role will evolve in the coming years in digital product development? There is a lot—sometimes it feels like too much—discussion about the technological revolution driven by artificial intelligence and automation, which is affecting nearly every profession.

However, I’m optimistic. I believe that the purposeful and thoughtful use of these tools will not make humans obsolete. On the contrary, it will make already creative roles—such as the Product Owner—even more exciting.

Instead of repetitive or low-value tasks, more focus can be placed on user needs, UX, planning, and ideation—which ultimately makes the work more enjoyable.