Developers should avoid jargon and learn how to speak a business-focused plain English with their business counterparts.
The problem
Sometimes I see developers trying to communicate with product owners using a strictly technical task-based jargon. That often translates in misunderstandings and frustration on both parts.That’s not a good result for the product owners, for the developer’s career, and for the organization they are working with neither.
That’s not limited to the Product Owner/Dev communication, tough. Technologies are constantly emerging and communication can also be a problem within specialists with different skillsets. You could be a strong Senior Java Dev, but you could easily have no clue about what I’m saying if I tell you: “I defined the CamelContext using custom XML syntax, but without the route definition” because you don’t know the Camel Framework.
But back to our Product Owner/Dev information flow. While Product Owners should have a clear understanding of the business implications of the technologies at the core of their products, developers and engineers should be able to clearly communicate the reason of the tasks they are performing daily and the relative business impacts.
Devs usually need to present difficult activities performed on complex data and processes. Attention spans of Product Owners are shorter than ever, and the situation gets even worse with remote working. So, how can techies translate their activities in short and concise plain english concepts? While some devs are more incline than others to communicate without jargons, what I suggest here is a simple two steps process that can be adopted by anyone.
Here’s it.
- Know your Audiences. What’s their attitudes, needs, and expectations. How technical are them? Are they impatients? In a hurry? Willing to get into details? Based on the Audience you should decide for
- A direct, deductive approach where you push the key message (i.e. we must improve the quality of our code) at the beginning and then you could optionally give supporting evidence to convince them that it’s important. If they trust you, that’s usually the best way;
- An indirect, inductive approach. You start with the problem (i.e We can’t deploy the product on Nexus) and then you develop the steps for the solutions. That’s usually more appropriate in a technical environment, with a common shared culture and skillset.
- Have a clear key Message. When speaking to a business counterparts, always focus on business impacts (i.e. we can’t test the product) instead of technical aspects (i.e. it does not build the pipeline with Gradle)
So, let’s see a practical example, with fictional characters: Mark the junior developer, Jeff the product owner, and Marcello the client. I adapted the code from Tkinter GUI Application Development Cookbook, by Alejandro Rodas de Paz.
At the planning meeting
Let’s imagine we are at the backlog refinement meeting of a Scrum team. They have been using Scrum for over 12 months now. The new product owner Jeff has a strong marketing background, but weak technical skills. Stories are discussed from the backlog.

When it’s Mark turn, he starts to talk about a new “technical” story he would like to have on the backlog in order to reduce technical debt about the “Ciao Marcello” app. Jeff, the Product Owner is confused: the functionality already exists and performs well: when you click on the “click me!” button, it prints out to the terminal a “Ciao Marcello” message, so that the client is happy.
So Jeff asked about the reason for the new story. Here’s Paul’s answer.
OK, the story on the “Ciao Marcello” button. I want to define a class to wrap all the global variables in the app, enclosing the variables in a specific scope. I also need to move the command function in a specific method and replace the wildcard import with the “import … as” syntax. Finally I will define an App class as a Tk subclass, referenced via the tk namespace. I’ll initialize the __init__ method of the Tk class with the built-in super() function.
What’s wrong with that? Nothing, except that the business impact of Mark’s activities is missing, and the reason why he’s willing to employ his time, paid by the business, in these activities remains unknown. The jargon is totally obscure to Jeff, and there is no clear message that could make sense to him, just a series of technical tasks. Jeff starts to suspect that Mark has a different agenda, not aligned with the business objectives.
So let’s break the message down, and let’s refactor it with a more plain-english business-oriented focus
Task oriented | Business oriented |
No overall objective | I want to improve the quality of the app, maintaining the same functionality |
1a. I want to define a class to wrap all the global variables | 1b. I will improve the quality and modularity. 1c. I tell you why I want to use local variables instead of global ones. Each variable adds a bit of complexity, but global variables add complexity to the whole program, while local variables add complexity only in the portion of code where they are defined in. So maintenance of the app will be easier, and we’ll experience less errors |
2a. I want to enclose my variables in a specific scope. I also move the command function in a specific method | 2b. I want to avoid that future changes in the code here will disrupt other modules and vice versa |
3a. I want to replace the wildcard import with the “import … as” syntax | 3b. That’s a known best practice. I want to avoid errors caused by clashes with other modules/variables. That’s why I’ll change the import strategy |
4a. I want to define an App class as a Tk subclass, referenced via the tk namespace. I’ll initialize the the __init__ method of the Tk class with the built-in super() function. | 4b. I want to easily reuse the functions I create |

With the business focused explanations, business impacts are now much more evident. When Mark explained the story in business terms, he convinced Jeff to put the story in high priority on the backlog. Here’s the refactored app with all the best practices applied. Jeff also learned something new.
It is now a win-win situation, the app is a better one, the business value of the refactoring is clear and the Team communication has stepped up a bit. The story has been written with focus on the business impact, technical tasks added, and it has been closed in the first sprint available. Great Job!
So, I gave here a simple approach on how to structure technical arguments according to their business impact. The approach can be used by anyone. If you are unsure about your communication skills, prepare and rehearse your talk according to the audience/key message. It will improve your skills and your relationship with non-technical counterparts.

Marcello Del Bono is coaching and leading Agile Teams, supporting Transformation programs. He has multi-year experience as a Product Owner, Scrum Master and Agile Coach in e-commerce, IT, Marketing and Decision Support Systems in Media, Telco, Finance, Fashion industries.
Contact him on LinkedIn.