This blog is part of a series that delivers insights from the monthly meetups of Bugsnag’s Apps + Coffee Connection (ACC) community.
Know what really animates development leaders? Talking about release cycles! The ACC meetup in March was a lively discussion about release trends and strategies for getting new code out the door with speed — without sacrificing quality and the customer experience.
Does anything cause more tension between Product and Engineering teams than roadmap planning? The ACC meetup in September tackled this complex topic, as participants discussed the gives and gets that often get hashed out between these two teams. The conversation also illuminated some creative ideas to help smooth out bumps in the road.
By nature, the roles and responsibilities of product managers and engineers can create an adversarial relationship. As one participant explained, “You have Product trying to define the broad vision and engineering trying to fulfill the goals of the product. Product will have these big ideas, and while Engineering’s role is not to shatter their dreams, it is to bring them back to reality.”
These reality-moments sometimes revolve around the need to address an engineering challenge before a new feature that Product wants can be built — especially if limitations with the underlying architecture and technical debt will impede development. In these situations, it becomes a fine balancing act between moving forward with new functionality, which is what Product wants, and tackling scalability and performance issues, which is what Engineering may need.
Not surprisingly, the gives and gets also revolve around the scope of deliverables. “Sometimes, the classification of MVP in a Product Manager’s head is ‘Maximum Viable Product,’ so they try to squeeze everything in,” stated a participant. “Then you have conversations where the PM realizes how much it’s going to cost, or how long it’s going to take, and you must work together to figure out a pared-down version.”
Remarkably, the stage of the company also impacts how Product and Engineering work together. Startups with huge upfront engineering goals may experience more inherent challenges between these two groups than organizations with a live product and strong procedures in place. “When you’re putting something out in the world for the first time, there's a lot more friction between Product and Engineering than when you’re iteratively delivering something that’s already in the market,” stated a participant.
Across the board, participants identified communication and coordination as two key factors that companies might focus on promoting, especially around bigger projects. “There must be consensus that you’re moving in the same direction, which is why communication is key,” explained a participant. “Frameworks can help coordinate at a higher level what you’re trying to do, and the benefit of that framework is that it should work beyond sprint iterations.”
Another aspect is making sure everyone understands the “why” and gets on board with the bigger vision Product is working towards. While Product needs to keep Engineering informed, the same holds true in the opposite direction. One participant emphasized this point when he stated, “Product may not know about engineering dependencies that exist if they don’t talk to engineers. There needs to be back-and-forth communication and strong coordination between the two groups.”
Another participant believed that engineers must step up and be vocal: “There’s a stereotypical divide that PMs are the extroverts, and engineers are the introverts, which can create an imbalance. It’s important to push engineers towards becoming better communicators so that they tell Product what’s causing issues, what’s slowing them down, or why something’s important to prioritize.”
From a planning perspective, time must be set aside for pre-planning and for defining clear goals, which generally starts two weeks from a quarterly meeting. “The most important thing to get out of those quarterly sessions is identifying the dependencies between the teams. Don’t focus on the details,” one participant stated. “For any good software delivery, you want to leave as many options open as possible for how you will evolve or solve a problem.”
Companies that use engineering squads must also address roadmap items that require multiple squads’ involvement. Because squads have differing priorities, this alignment is an absolute requirement. One participant shared that his company developed a council with members from each squad. The council’s role is to discuss and figure out what dependencies exist, and then scrum masters coordinate the work. This strategy helps everyone be mindful of other team’s work, coordinates efforts across squads, and communicates a shared vision, which contributes to a stronger company culture.
Transparency must be a company-wide trait. It’s what drives Product to share the vision and direction of the solution, and transparency should also be used by engineers to frame a story around what’s happening with development work. “Find ways to provide visualization around your backlog for Product teams. Be open about what you need,” stated a participant. “Tell Product that, if you want to deliver this business feature, you first need to deliver this technical feature. And show them why.”
Transparency also inspires a stronger sense of “one team” and combats the negative aspects of roadmap planning that can put individuals and groups at odds with each other. The goal should be to know that everyone is in it together. “It’s important to instill a culture where we all win together, or we all fail together,” one participant said.
Another participant demonstrated this point by showing empathy: “Product managers are under pressure as well, with business sponsors who are demanding that they deliver. It’s the engineering role who must say, ‘We understand you want to deliver business value, but we have to take care of our house. We have to make sure that it’s not going to fall over or have a security issue or performance issues.’ It’s all about getting that healthy balance right.”
While every organization, team, and company culture is different, what everyone should strive to do is make continuous improvements and always be getting a little bit better. One shared best practice that promotes this iterative approach is a “pain wall.” The idea is to document what the top ten pains are that really hurt the engineering team. The team then hammers at the top pain during a sprint until it’s no longer on the list and can be removed.
The pain wall is a visual and methodical approach for dealing with challenges such as technical debt, and it creates a story where engineers can see their pain points being removed. As the participant shared, “It’s your villain list, and you’re knocking them off, one by one. There’s no Product involvement necessary, other than coming to an agreement that there should be some time dedicated to it.”
Interested in participating in conversations like this? Join the monthly discussions with the Apps + Coffee Connection community by registering here.