Comic Agilé no. 48 - The PO from the Business (reshare) POs (especially with a business background) and Developers must learn to speak the same language, and what that language is varies from organisation to organisation (e.g., for Developers to learn the business lingo of their end-users and stakeholders). #agile #productowner #comicagile
Everything team does whether functional or NFR is directly or indirectly impacts business. Language and communication is so important working in a team. PO and teams should learn to communicate using language that each other can understand that is ,benefit to end user and/or business. Untill they can start doing that they will have differences in comms. I coach teams to see all tech debts and NFRs as business/user impact items and should have similar business case as a PO will have for functional items. That will allow to have like to like comparison and allows POs to prioritise appropriately.
This problem affects the entire organization. Each division in each functional group speaks its own lingo. Sometimes even within "Developers" there are different "lingos". The situation is further aggravated by the fact that each division of each functional group has its own time flow. For some, every minute is precious, and for others, a week is a short time. Therefore, GTM (among other things) starts by compiling a Thesaurus (a Single Dictionary) and synchronizes the time flow for the entire organization.
Doğan Şengül
1w
Great comic! It really demonstrates something important: Product Owners often function like business analysis professionals. For example, in the comic: “Should we prepare our backend for future vertical scaling, or focus on normalizing data to improve performance?” This question is a typical challenge. A PO with strong business analysis skills would: ✅ Asking questions to understand the value-added business need behind it. ✅ Working with the team for value engineering, what is with more value now (performance) and what holds for the future (scalability). ✅ Using cost-benefit analysis or (thre are a lot in BABOK) prioritisation techniques (BAs are tough prioritisation benders) for what to do first. Good Business Analysis helps the PO to: ✅ Explain business priorities ✅ Make sure developers and stakeholders understand the decisions. ✅ Balance solution requirements with NFRs to be ready for the future. When we speak a common language with analysis techniques, it becomes easier to focus on what is really important—delivering value for all.
Ulrik Gade
1w
I see the finger pointing being the problem here, not the different perspectives that are key to value creation in complex domains. For instance, addressing any of the problems raised in the third frame of the comic involve tradeoffs that can be clarified through a conversation including both business and technical perspectives. Working toward sufficient mutual accommodation and understanding may be bothersome. But it is necessary labor - for everyone!
Marc Geelen
1w
In this scenario, the PO could be supported by a "Product Owner by Proxy" https://nl.linkedin.com/pulse/product-owner-proxy-add-tech-marc-geelen
The PO should ask the developers to explain how their suggestions benefit the end user and the business itself. The PO should also use these conversations to learn the basics at least of how their product is constructed. Gaps are to be bridged
Bry WILLIS
1w
A PO should over-index toward the business side. Otherwise, they should be augmented with a translator like a good BA, perhaps masquerading as a Scrum Master so as not to bog down the Devs with nonsensical prattle.
David Neale
1w
POs need a solid tech lead to work with. This is especially true for POs that haven't yet had years of technical exposure.
Carlos Hung
1w
The team should ideally most of the time use ubiquitous language
Product Manager & Owner Network Infrastructure LVNL (Air Traffic Control The Netherlands)
1wThis captures a key challenge of the PO role: bridging the gap between technical and business domains. A PO must not only possess a solid understanding of the technical landscape to communicate effectively with developers but also maintain a clear focus on the business objectives to ensure the product delivers value. Striking this balance is what makes the PO role so pivotal and, at times, difficult.