Building a product requires a lot of different skillsets. First you need to understand the problems you’re trying to solve, then you need to design a good solution, then you need to build that solution and finally you need to deliver that solution to the people who are experiencing the problem. Cross-functional collaboration is the execution and culture of managing this process.
For a PM, it’s vital to execute this process the right way so that parts of the puzzle don’t get lost in translation, negatively affecting the quality of the final product. There’s a lot of PM work involved in doing this, from user-stories to writing requirements to sales training.
As a PM, I care about the culture of this process. I’ve learned that the best ideas, and therefore the best products, come from the creativity cross-functional collaboration can unleash. Instead of individual steps, cross-functional collaboration thrives as a network. A strong culture of collaboration improves quality, accelerates delivery and boosts team morale.
In this blog post I’ll be exploring my journey as a cross-functional collaborator and how I learned to become a connector in this network. I’ll cover the lessons I learned throughout this journey that shaped my approach to cross-functional collaboration.
Since I had a passion for design throughout my time in university, I built a special working relationship with the design team as a frontend engineer at Nylas. I spoke directly with the design team to understand their goals and standards for the design of our products.
This relationship allowed me to lead the effort to align design and engineering goals for the design system while taking minimal bandwidth from the design team. Our team’s designer was able to dedicate only her Friday mornings to designing for the design system. She was able to leave design gaps because I could fill them.
As I began transitioning to Product Management, I also began expanding my collaborative network within the company. I used my insights as an engineer to find existing code or architecture that could be leveraged in different use cases. One of those use cases were customized demos that could show the ability of our product. The marketing team showed some interest in this use case but eventually elected to go in a different direction.
At the time I may not have quite understood, but in hindsight I think the lesson I learned here was that engineers are great sources of cross-functional ideas. The stereotype that engineers want to be left alone with their code is not true for many engineers. In every engineering team there are people who want to deliver value to users and these engineers can help PMs establish a culture of collaboration. This seems to be the foundation of my understanding of cross-functional collaboration as a network.
My first product in a PM role was to build a Developer Hub. The vision for the product was pretty clear, since there were many examples from other companies. I made a plan and gathered the leads from the technical writing and developer advocate teams to discuss and get their feedback.
The technical writing team lead was onboard, this change was actually her idea and she had been asking the product team to dedicate the resources to do it. The developer advocate lead seemed suspicious of me and my plan, he gave vague feedback that I was not being authoritative enough and cast doubt on the project.
I believe that not advocating to solve a user problem led to being perceived as passive. A product leader needs to create clear problem statements, with evidence, to anchor cross-functional collaboration. Aligning collaborators around a clear problem enables the network culture of creativity to flourish; without it, collaborators will either push their own agendas (like the technical writing lead) or will be disinterested (like the developer advocate lead).
Throughout my first time as a PM, I naturally built good working relationships and friendships across multiple teams. In the chaotic culture of a hyper-growth startup, the strength of these relationships became a powerful tool in collaborative communication and problem solving.
When the new VP of Product spun up a big new onboarding project, a bad miscommunication formed around between the VP Product and Engineering lead resulting in stalled development and team tension. The VP Product began to get frustrated and the Engineering lead was confused about which of two development directions to build. I held 1:1 meetings with both the VP Product to understand his vision and the Engineering lead to understand his confusion, with a third group meeting with the IC engineers. I led each meeting with curiosity, ears open and asking questions. I was able to resolve the confusion with the Engineering lead pretty quickly, and hearing the concerns from the engineers created a safe space for us to debate and improve the VP’s vision. There was a particularly critical ah-ha moment for me when one of the engineers who had a reputation of being difficult to work with, grinned ear to ear with happiness when I challenged his ideas with my own critical-thinking. The VP was happy with the critically thought-out improvements and even took the blame for the confusion and miscommunication! With the issue resolved, development regained momentum and the team felt more aligned.