Skills for managing cross-functional teams

Being a product manager can sometimes feel like you’re trying to juggle flaming torches while riding a unicycle. You’ve got to keep engineering, design, marketing, and other teams in sync, all while pushing the product forward. It’s a wild ride, but with the right skills, you can navigate the chaos and keep everything on track. Here’s a look at some of the must-have skills to lead cross-functional teams effectively based on personal experiences.

If there’s one thing that’ll keep everything from falling apart, it’s communication. Seriously, being able to clearly explain the product vision, set goals, and make sure everyone’s on the same page is crucial. But it’s not just about talking—listening is just as important. Different teams have different concerns, and being able to translate between them is like having a superpower. The better you are at this, the smoother things will run.

While gearing up for a big feature launch, things started to spiral. The engineering team was focused on the technical build, while the marketing team wasn’t entirely clear on the product’s benefits. To prevent any confusion, I organized a kickoff meeting. I made sure to walk everyone through the product vision, using simple language and visuals to illustrate how this new feature would impact the end user. After that, both teams were aligned, and the project moved forward without a hitch—marketing knew what to promote, and engineering had a clear understanding of the priorities.

Product management isn’t just about managing products; it’s about managing people. And people come with their own sets of challenges, motivations, and quirks. That’s where empathy comes in. If you can understand where your team members are coming from, you can build stronger relationships and get everyone working together more harmoniously. It’s about more than just getting things done—it’s about making sure everyone feels valued along the way.

During one project which I led during my time as a product manager in the Finance industry, I noticed tension between the design and engineering teams. The goal was to implement a data controls system for a large investment bank and create a robust audit trail for data used in financial models, which would help the bank avoid hefty audit fines.  The designers felt their input wasn’t being considered, while the engineers were feeling overwhelmed by tight deadlines. I took the time to have separate chats with both teams to understand their perspectives. After hearing them out, I restructured the workflow to create more frequent feedback loops between design and engineering, and adjusted some deadlines to ease the pressure. This not only improved communication but also boosted morale, and the project moved ahead much more smoothly.

One of the trickiest parts of being a product manager is that you often have to lead without having direct authority over the people you’re working with. It’s a bit like being a Jedi—you’ve got to influence people and guide them in the right direction without being their boss. This means building trust, understanding what motivates different stakeholders, and finding ways to align their goals with yours. When you get this right, it’s magic.

During my time as a product manager in the Finance industry, I led an initiative to automate a credit portfolio assessment process for a large investment bank. The goal was to develop a system that could identify high-risk counterparties in real-time, which would significantly enhance the bank’s ability to manage credit risk. This project was essential because it would streamline the work of analysts, reduce exposure to risky loans, and ensure better regulatory compliance. However, not everyone was immediately on board.

Some senior analysts were concerned that automating the process might undermine their expertise or make their roles less relevant, while the IT engineers were hesitant about the project’s complexity and the ambitious timeline. Both teams were unsure about fully committing to the initiative, which created a roadblock.

Without having direct authority over these teams, I knew I had to approach the situation thoughtfully. I began by having one-on-one discussions with key members from each group to understand their concerns. The analysts worried that the automation might oversimplify their work, and the engineers felt that the scope was too large to manage effectively in the given time.

To address the analysts’ concerns, I emphasized that the automation wasn’t designed to replace their expertise but to relieve them of routine tasks so they could focus on more strategic, high-value activities. I shared examples from similar projects that demonstrated how automation had freed up time for analysts to deliver deeper insights, reinforcing that their knowledge was still vital.

With the engineers, I broke the project down into more manageable phases and reassured them that we would prioritize features based on feasibility and impact. I highlighted how successfully delivering this system would position them as leaders in technology innovation within the firm. I also tied the project’s success to the company’s broader objectives, explaining how improving risk management capabilities would enhance the bank’s reputation and support its long-term goals.

By aligning the project’s goals with their individual motivations and demonstrating the value it would bring to the company and their teams, I gradually earned their buy-in. Through ongoing communication and collaboration, we turned initial resistance into enthusiastic support.

The project was ultimately a success, with the automated system enhancing the bank’s credit risk management processes and allowing analysts to focus on higher-level work. Both teams felt a sense of accomplishment, and the initiative became a key milestone in the bank’s risk management strategy.

If you’re going to get cross-functional teams to work together, you’ve got to be a master collaborator. This means setting clear expectations, making sure everyone knows their role, and keeping the lines of communication wide open. When things get messy (and they will), you’re the one who has to step in, untangle the knots, and get everyone back on track. It’s like herding cats, but it’s all in a day’s work.

Midway through an important project, it became clear that different teams weren’t on the same page. One group was moving ahead with new features, while another was waiting on information that hadn’t been shared. I stepped in and introduced daily check-ins to make sure everyone had the same information and understood their roles. I also set up a shared project management tool so tasks were visible to all. When any confusion popped up, I made it my job to jump in and clarify things. It took some effort, but in the end, we got everything back on track and delivered the project on time.

You don’t need to be able to code (unless you want to), but understanding the technical side of things is a huge asset. If you can talk shop with the engineering team, make informed decisions, and spot potential issues early, you’ll earn their respect and make your life a whole lot easier. Plus, it’s always nice to know what’s going on under the hood.

I once worked on a product to develop a loan forgiveness tool for a financial institution. The tool was meant to process large volumes of loan forgiveness applications, automating workflows and calculating eligibility based on complex criteria. Given the high stakes of this project, especially around regulatory compliance, we had to ensure that the system was efficient, scalable, and accurate.

Even though I’m not an engineer by trade, I knew it was important to understand the technical landscape of the project to contribute meaningfully. As we moved through the development phases, I noticed that the tool’s performance could be affected by the way the data was being pulled from multiple sources to calculate eligibility. The volume of applications was far greater than initially expected, and this had the potential to cause performance bottlenecks, especially during peak periods when users would access the tool simultaneously.

Because I had taken the time to understand the architecture of the system, I raised the potential performance issue early. I initiated a conversation with the engineers, asking specific questions about how the data pipelines were set up and how the system handled concurrent requests. This led to a deeper discussion about how the tool’s algorithms processed data in real-time and the potential for delays during high usage.

By understanding the basics of how the system worked under the hood, I was able to help the team prioritize performance optimization before it became a larger problem. We decided to re-architect the data ingestion process to improve efficiency, ensuring that the system could handle the expected volume without slowing down or crashing. This change not only avoided a last-minute scramble to fix the issue but also improved the overall scalability of the tool.

My ability to speak the technical language and ask the right questions earned me respect from the engineering team, and it made the whole process run much smoother. In the end, we successfully launched the loan forgiveness tool, and it was able to process a significant number of applications efficiently, helping our client meet regulatory requirements while also improving their internal workflows.

At the end of the day, it’s all about the customer. Everything you’re doing should be aimed at delivering something that makes their lives better. Keeping a laser focus on the customer’s needs, gathering feedback, and using that to guide your decisions will help ensure you’re building something people actually want. And let’s be honest, there’s nothing more satisfying than seeing your product out in the wild, making a difference.

During the development of the loan forgiveness tool for a financial institution, we were nearing the final stages of user testing when I noticed something alarming—many users were dropping off during the application submission process. This was a critical step, where users were supposed to review their loan forgiveness eligibility and submit their final application. However, the data showed a significant abandonment rate at this point, which was a red flag, especially considering how important it was for users to complete the process.

I noticed this trend during one of our final rounds of internal testing, just before we were about to conduct external testing with a small group of customers. Rather than pushing forward with the rollout, I decided to dig deeper. I reviewed user behavior data and conducted a few quick interviews with some of our test users to understand where the friction was happening. The feedback revealed that the process was too complicated—the steps weren’t as clear as we thought, and users were becoming frustrated with unnecessary form fields and overly technical language. Many felt unsure about how to proceed, leading to a high drop-off rate right before the finish line.

Recognizing that this was a critical issue, I worked closely with the design and engineering teams to simplify the experience. We removed non-essential fields, reworked some of the confusing language, and made the overall flow more intuitive. We also added tooltips and inline help to guide users through the more complex parts of the form, reducing confusion and friction.

After implementing these changes, we ran another round of testing, and the results were immediately positive. Users were able to complete the process without hesitation, and the drop-off rate at that critical step significantly decreased. This not only improved user engagement but also ensured that more applications were successfully submitted, which was a huge win for both our client and their customers. The project’s success hinged on staying focused on the customer experience and making adjustments that aligned with user needs.

It’s easy to get caught up in the day-to-day grind, but a great product manager always keeps the bigger picture in mind. Strategic thinking means understanding the market, anticipating trends, and making decisions that not only solve today’s problems but also set you up for success down the road. It’s about playing the long game and making sure your product is aligned with the company’s broader goals.

While I was working at a consulting firm as a product manager, I noticed a significant shift in customer behavior among financial institutions. Clients were increasingly looking for ways to automate and optimize their credit risk assessments using more advanced, data-driven models. The traditional, manual approach to assessing credit risk was becoming outdated, especially with the rise of machine learning and real-time data analytics. It was clear that the market was moving towards automated solutions that could provide faster, more accurate insights to reduce risk exposure.

Rather than waiting to see how this trend would evolve, I proposed that we adjust our strategy to proactively develop an automated credit risk product for our banking clients. This product would leverage machine learning to analyze large datasets and identify high-risk counterparties in real-time, offering clients a faster, more scalable solution to their credit risk challenges. Even though this meant pivoting from our current approach, which was more focused on manual processes and traditional data models, I knew this shift would position us as leaders in the market.

I collaborated with several teams to make this happen. The data science team was essential in building the machine learning algorithms that would power the tool, while the IT and engineering teams were responsible for developing the infrastructure to support real-time data analysis. I also worked closely with the product and compliance teams to ensure that the tool adhered to regulatory requirements and met the financial industry’s stringent standards. It was a cross-functional effort that required clear communication and alignment across departments.

After months of development, we successfully rolled out the automated credit risk tool, and the response from clients was overwhelmingly positive. They appreciated the speed and accuracy of the tool, which allowed them to make more informed decisions and reduce manual work. The tool also gave them a competitive edge by enabling faster risk assessment and better compliance with evolving regulatory standards. This feature not only enhanced our value proposition but also shifted the perception of our services in the market—we were no longer just a consulting firm providing traditional risk management solutions but a forward-thinking partner offering cutting-edge technology.

As a result, our clients saw us as leaders in innovation, and this new feature helped us attract a broader range of financial institutions. It solidified our position in the market and opened up opportunities for further innovation in other areas of risk management. By anticipating the trend and adjusting our strategy early, we were able to meet evolving customer needs and strengthen our competitive advantage.

Product development can be a rollercoaster, with sudden twists, turns, and the occasional loop-de-loop. Being adaptable and resilient is key to staying on course. When things go sideways (as they inevitably will), you need to stay calm, regroup, and find a way forward. It’s about turning challenges into opportunities and keeping the momentum going, no matter what.

One of the most challenging moments I faced was during my time as product manager in the financial industry, when we were in the final stages of launching a regulatory reporting tool for a large investment bank. The tool was designed to automate the generation of compliance reports, ensuring the bank could meet strict deadlines and avoid potential penalties. Just days before the scheduled launch, we received last-minute feedback from the regulatory body indicating that new requirements had been introduced, which meant our tool’s existing setup would not be compliant.

This could have completely derailed the project. The engineering team had already finished development, and the testing team was wrapping up final validation. The new requirements affected core features of the tool, and it seemed impossible to meet the launch deadline while making the necessary changes.

Instead of panicking, I quickly gathered the cross-functional team, including engineering, compliance, and business analysts. We needed to find a solution fast, so we began by breaking down the new regulatory requirements and identifying the most critical updates that needed to be made. By refocusing on the key compliance elements, we were able to reprioritize our efforts.

We adjusted the roadmap and divided the team to work on multiple fronts—one group focused on reworking the compliance logic, while the other handled less critical enhancements that could be delayed for a future update. We also set up a direct communication line with the regulatory body to ensure we were interpreting the requirements correctly, avoiding any back-and-forth confusion.

By concentrating on what we could control and staying flexible with our priorities, we managed to complete the core changes just in time for the launch. The tool went live as scheduled, fully compliant with the new regulations. In fact, the updates we made in response to the last-minute changes ended up improving the tool’s overall functionality, and the client was impressed with how we had turned a potential disaster into a stronger product.

This experience demonstrated the importance of adaptability under pressure. By staying calm and focusing on solutions, we were able to avoid what could have been a costly delay and delivered a better product than originally planned.

Being a product manager is tough. You’re balancing the needs of different teams, driving towards a common goal, and making sure your product is the best it can be. It’s challenging, but by sharpening these essential skills, you’ll be better equipped to handle whatever comes your way. And when everything comes together, there’s no better feeling than seeing your product out there, making an impact.