Miscommunication between Devs and PMs
Why do software engineers worry so much about Jira cards? And why won’t PMs translate business needs? Let’s understand the communication breakdown between Product Managers and developers
Hello, I’m Tiago Ferreira, Sr. Product Manager in Brazil with +6 years of experience crafting products. With The Next Movement, I want to share part of my product management experience with the whole world, but also talk about career more broadly, technology, good books, and - why not? - philosophy, music, culture, gossip, just like an open diary. If you enjoy reading my article, subscribe and share it with your friends 🤓
Most software engineers I work with knew about agile methodologies and believed Scrum is kind of the best middle-term possible to deliver value.
I usually argue against Scrum, but I realized that the discrepancy lies in the value term.
If you are an experienced product manager, you probably know that the company values revenue, growth, user acceptance, and not the number of tasks delivered on a sprint cycle.
It seems obvious to put it that way, but in my first years as a PM, I believed that the leadership expected, in reviews, all the Jira cards to be done on the sprint.
A lot of developers associate done cards with work well done, and, in most cases, it is because the PM doesn’t translate to the team the impact of their work.
Value and impact: different meanings?
So, value and impact could have different meanings for PMs and developers. Considering that the PM has been working with the business, they see impact associated with KPIs.
Developers have access to databases and analytics platforms, but they are more concerned about the functional aspects of the product than its business potential.
I respect that because thinking, coding, and bringing a solution constitute complex work for developers. However, many of them believe that the PM is kind of a messenger of what engineers often refer to as “business rules”: they determine the metrics; they demand the product team; they influence the roadmap.
Who are they?
The product manager knows; the developers, well, don’t need to care. In fact, it is better for them if they stay aligned only with the PM.
But, do they care about the number of cards delivered? Depending on the context, some PMs could report Jira cards in their status reports, but most developers ignore a key factor: product manager uses storytelling and, if the audience includes stakeholders from different areas, he/she probably adapts the speech to report progress of the product.
And Jira cards aren’t equal to product progress: the PM could break a complex activity into two or more user stories and communicate that this demand will take two or more sprints (I don’t even use the term sprint in status reports).
On the other hand, developers worry about the quality of the code. PMs don’t ignore that and respect the need to include technical debts on sprint cycles. This difference of points of view results in quality convergence: the developer justifies exceeding the deadline due to some refactoring, but the estimation is critical to PMs because, well, that’s the common language with stakeholders in any context.
The four meanings
To avoid this miscommunication, I recommend engineers and product managers must be aligned about:
Meaning of value: doesn’t matter if your team works with Scrum or Kanban (or Scrumban). It would be exhausting to attribute KPIs to every Jira card, but a good practice could be determining the sprint goal or the release goal - considering that a bunch of Jira cards could form a release. In this case, the PM has to specify the value expected (that’s OK if it doesn’t connect to KPI).
Meaning of impact: the PM should bring the impact the team delivers to the business, always attached to KPIs. Usually, I share those KPIs in our daily meetings, but you can create your cadence or elaborate a detailed report of the product. Good engineers want to know about the product, and they certainly will bring important questions, evolving the way you (and they) analyze the product.
Meaning of progress: Jira tasks are important, but progress is often related to the roadmap. If your company works with quarter roadmaps, you can relate the objectives with Jira epics. Certainly, Atlassian has a product in which you can relate roadmap, epics and even discovery, but if it’s not the case for your company, you can use a whiteboard to relate roadmap and user stories to show progress.
Meaning of quality: engineers know more about quality than PMs. If your tech lead or a senior developer told you that the code isn’t well, do your homework and try to relate that to open bugs or customer service tickets. The danger zone lies when the developer decides to refactor part of the code without any estimation. To stay aligned about quality, refinements are crucial. Write all the details you need on your user story, and try to get feedback from quality engineers. And, at the planning moment, stimulate them to use story points (or T-shirt size estimate, or whatever artifact your team prefers) considering healthy time for the developer, to bring the solution, run unit tests, review the code, and deliver to QA validate. Probably the cycle will be longer, but you’ll see stronger work from engineers and, shortly, a more reliable product.
You don’t have to formalize all these four meanings, because some teams organically build their alignment. To strengthen them, however, I recommend weekly conversations with your team’s tech lead. After a couple of sessions, the communication gap will reduce, and all daily, refinements and reviews will be more productive.