What’s the Cross-Functional Team, and Why should I have one?

I’ve been contemplating the soft skills that Product Managers need to succeed. My last post touched on one of those skills – translating between the varied members of our team. Today, I’ve been thinking about the cross-functional team and Product Management’s interaction in it.

First off, you should have a cross-functional team for your product. This group can provide valuable support and feedback for all its members. For Product Managers, the team provides considerable benefits. It helps us communicate more broadly, gain alignment more easily, and build better products (hardware, software, and/or services).

When I talk with product managers, and “their team” comes up, they often begin by thinking of their development team – those who actually build the product. The Product Manager enables the development team to succeed, by doing and documenting great market research and writing clear, prioritized requirements. The development team is (obviously) important, building amazing solutions that make people want to buy. However, there is another team that we must consider. Today when I talk about the team, I’m referring to the “cross-functional team”. It’s a much broader concept than a development team, and rather than the pure technology that’s built in Development, it’s focused on the whole solution – technology, marketing, sales, support, professional services, production, localization….any department who spends time helping our product succeed. A cross-functional team can be a powerful tool for the agile product manager.

The cross-functional team is a group of people who collectively represent the entire organization’s interests in a specific product or product family. This team provides benefits for the individuals on the team, the product and its customers, and the organization at large.

For the individual, the team is a support group and cheer section. It’s a place where the individual can easily get updated information for their department, and it’s an environment where each individual is safe in bringing up issues or roadblocks that they’re encountering. The group can help solve issues that are impacting any department. And, when there is positive news to share (e.g., reduction in call volume in tech support, increase in sales revenue, development milestones completed on time within budget), it’s a group who will celebrate successes. All of this results in increased job satisfaction and motivation for team members.

The product and its customers will benefit from the cross-functional team as well, because it can inspire ongoing improvements in product quality. Team members provide input throughout the product life cycle, and also bring issues to the attention of the team for resolution. When the team is assembled appropriately, and meetings are run effectively, we see improvements in customer satisfaction due to increases in product quality and support.

A healthy team improves organizational alignment. Members are kept “in the know” regarding product status, including market research, customer feedback, product development progress, product-related financials, and promotional plans and events. Each member is held responsible for bringing that information back to their own department or team. In addition, they feed the team their own department or team’s feedback. The cross-functional team allows us to get one representative group aligned; in turn, they exponentially increase organizational awareness and alignment.

Assembling a cross-functional team and leading with market facts is the domain of the Product Manager. A strong team results in increased job satisfaction and motivation for the individual, improvements in product quality (and therefore customer satisfaction), and elevated awareness and alignment for the organization.

The Product Manager – Translator Extraordinaire

Whenever I travel outside the U.S., I am struck by the number of people who speak multiple languages fluently. On one particular trip, I was in the Brussels airport. The ticket counter agent was speaking at least 4 languages – and she knew them so well that she could quickly switch between them. She’d get someone checked in using French, then turn around and answer a quick question in German. She spoke to me in near perfect English, and as I was walking away I heard her speaking Spanish (or perhaps Portuguese) to another passenger.

For awhile, I would kind of beat myself up over this -- my Spanish is pretty rusty, and I would definitely not say I’m fluent. I often wish I knew at least one other language – it’s so much more personal to greet people in their native tongue, rather than expecting the whole world to speak English.

Upon further consideration, I decided I was being too hard on myself. After all, don’t we Product Managers translate constantly for our organizations? I may not know French, German, Chinese, Flemish, or Hindi – but I do understand Sales-speak, Development-dialect, Promotions-patois, and Operations-oracy.

We do translations all the time. The agile product manager is skilled at understanding each member of the team, so they can translate for others.

When Sales says “If I could only get this feature in the release, I’d close this deal,” they actually mean, “I feel like I’m losing here, and surely it cannot be my fault.” The Product Manager’s job is to help the team understand, and to keep them focused on their current work. If a Sales person makes a statement like that directly to development, without any translation, the team might believe the rhetoric, and quickly switch to satisfying one sales person. The Product Manager needs to help everyone see the market clearly and objectively.

When Development says “we’re delivering a new architectural layer that will dynamically expose all data elements”, the Product Manager needs to intercept, and ensure that the Promotions team understands the benefits of the release, rather than the technological miracle that happens under the covers.

The biggest battle in doing this translation is to give ourselves a moment to think. Where did the statement come from, and who else needs to understand it? Think about the Development explanation from above – they are speaking from their very technical viewpoint. Promotions, however, needs to understand the benefit to the buyer and/or user.

Early on in my career, I did a lot of this translation on the fly. Later, I learned that much of this translation can be ‘canned’, by anticipating the needs of each department and communicating to them so that their primary concerns are placed front and center. In the case of Promotions, positioning is the preferred method of translation – we use positioning to move us away from the technical, into laser-focus on the market’s problems and our solutions to those problems. We can do that translation up front, so the Promotions team can continue to focus on the benefit, without getting distracted by Development details. The secondary benefit is that we don’t have to spend quite as much time being personally involved in reviewing early versions of the Promotional artifacts. In fact, with a good positioning statement, MarCom is free to operate independently – creating high impact promotions with minimal daily involvement by the Product Manager.

We translate for our teams every day. When we focus on that necessity, we can do some of the work up front, and ensure that each member has what they need to be really good at their job. In turn, we can continue to create, market, and sell current products effectively…while we return to the market, analyzing its problems and prioritizing requirements for the next big thing.

Going agile? Consider this.

Companies are like machines. Each department plays their part, and together the thing somehow works. People within one department don’t always have to understand the entire operation – Sales people, for instance, are not required to understand how coding actually happens.

Certain organizational changes happen, and force the departments to understand a bit more about the machine. For instance – if Sales people are asked to begin selling a product that is delivered as an API, they’re probably going to have to learn something about coding (even if it’s just enough to explain the benefits of their solution).

Usually, Development can make adjustments to their process without needing the support or understanding of other departments. They change the process for controlling source code – but no one else has to deal with that, so it’s an isolated change within their department. Or, they go from manual testing to automation. Again, no one else needs to understand that change (as long as quality is positively impacted).

In most companies, changing to agile is not isolated. When the process for receiving requirements and estimating work changes, lots of areas in the company are impacted and must be brought on board. Basically, this change can cause stress in other parts of the company. If Product Management was having a hard time keeping up before, the change to agile will highlight that weakness, and sometimes stretch our process so far that it actually breaks.

If your development team is thinking of going agile, you have to stop and examine your requirements process. Are you ready to live in an agile world?

How are you preparing requirements? Do you constantly update the prioritized list of market requirements? Or, do you get to a point where you realize you have to deliver requirements, and quickly scramble your schedule so you have time to write stuff down before the team wants to review?

If I asked you to give me your top two requirements tomorrow morning, could you do it?

This is what Product Managers have to be prepared for! When your team goes agile, you have to constantly maintain the prioritized requirements, so you can give development more work at any time.

An agile team is going to ask for requirements more frequently, since they’re organizing their work into short sprints rather than a long waterfall release cycle. If you are constantly seeking market input, and organizing that input into a prioritized list of market requirements, you should be able to handle the transition fairly easily.

If your developers are transitioning to agile, take a look at your machine. Oil as needed, so that your team is enabled to succeed in an agile world.