First and foremost, what is it? At a high level, cross-functional collaboration is just when a group of people with different functional expertise come together for a common goal. In the B2B SaaS world, this often translates to people from different departments working together to solve a specific problem. In this case, we’re going to be talking about cross-functional collaboration as it relates to the development of a new product feature.

So how do new features come about and who’s actually involved?

Hopefully this doesn’t come as a complete surprise, but there are a number of steps—and even more teams—involved in the making of a new feature. It can be thought of as a knowledge transfer starting at the most macro and moving through different teams to understand a feature at a micro level. There are really four key components to the development process. First being ideation: someone has to come up with the idea for the feature and understand the pain it’s supposed to solve. Then design normally steps in to help the product team flesh out what the feature should look like in-product. From there, it’s on to product to storyboard the requirements of the feature step by step so engineering has tasks to build. Once the tasks are laid out, there’s often a final review with engineering to identify any red flags and confirm timing of release.

Let’s break this down a little more.


This process generally starts at a super high level with the product strategist who has an idea for additional feature functionality that’ll provide value to the product (this may not always be based on the current capabilities of the product, it could be a down-the-line vision of the “perfect” product). Whatever that vision is, it needs to be communicated to members of the design and product teams so they can understand the function of the new feature, how it fits into the existing product, and what pain it’s designed to solve. Clear and effective communication between the product and design teams at this stage is essential to a smooth development process.


Once design and product teams have a clear vision of a new feature it’s time for design to start fleshing out how the feature will actually look in-product. Product helps this process by communicating the technical aspects required of the new feature so the design team can prototype aspects of the solution. Depending on the size/depth/lift of the feature in question this process could be a quick design asset handoff or a lengthy discussion between teams on specifications.


After the product team has the design assets in hand they can begin the process of creating development tasks for the engineering team. Essentially, this means that the product team gets to take everything they’ve learned so far and the acceptance criteria that’s been set to write a step-by-step guide for how the feature should work in-product. This is often where technical aspects and the realities of the engineering cost are uncovered for a portion of the new feature.

Final Review

Celebrations are in order, the design and product teams have finally finished the design specs, explored the functionality, and set tasks for engineering. Time to do a final pass and check for red flags. This is often a great time to bring in engineering to understand what aspects may take longer to fully build out to help create a timeline of versions to build and QA. Although incremental, using versions of new features can help speed up the QA sessions to release a smaller, but functioning feature.

Once new features make it through engineering and are released in-product, the end users need to know it even exists! This is where customer success and marketing teams come into the equation to help get customer excited and knowledgeable about using that new feature.

How Features Come About: Internal v External

There are two primary modes for new feature ideation: internal versus external.


Internal ideation was just covered briefly above. Design and product teams coming together around a vision related to a piece of the product; something foundational to providing value. This generally starts at a high level vision before moving to design assets, review of assets, storyboarding, and a final review, before a handoff to engineering who will actually build the feature. The beginning of internal ideation is often about the product team’s vision for the product and how they want to go about achieving those goals. Customer feedback is taken into account, but the ideas themselves are developed within the team.


External ideation is where things really get fun and the ideas for feature functionality come from the customers themselves. In this case, the product team surfaces common sets of customer feedback (can be from discovery calls, the sales team, Customer Success emails with customers, or support tickets) as a larger team to brainstorm how to solve these issues, pain points, and frustrations in the form of new features. Teams may have an idea in the backlog, but once they start hearing it from customers, it’s important to take into account the value of those customer, the potential impact on all users, and the speed with which the new feature could be spun out for prioritization. The process can be broken down into four key steps:

  1. Collect all feedback, pain points, and frustrations from customers and prospective customers.
  2. Surface those needs to the broader team to prioritize based on how they impact current customers and could make an impact on closing new deals.
  3. Once features have been identified and prioritized, close the loop and talk with those users to let them know the team is building a feature for them. Determine what base requirements they need in the first pass. The same process can work with prospective customers if there’s a feature gap in the product. Chat through their requirements for future functionality that they’d like to see and what steps can be taken to make that a reality for them.
  4. Then comes the internal portion of that cross-functional collaboration of designing the feature, reviewing functionality and engineering costs, QA testing and finally, release.

It’s important to note that there is a cost/benefit analysis that takes place to prioritize a feature, even when it’s not technically a customization, but an optimization, that isn’t specific to an existing customer. Product teams need to account for the potential revenue implications of adding on new customer when factoring potential new features into the roadmap.

New features don’t have to always be what a prospective or current customer wants—or their exact specifications. The reality is that most teams need to put their own spin on a new feature to better address the wider customer use-cases. Luckily, taking a moment to talk the effected customers through the product vision will almost always result in their support and excitement for the upcoming feature.


Cross-functional collaboration is always going to be an ongoing learning process for product teams. Juggling all that feedback from customers, sales, customer success, engineering, and marketing can be overwhelming at first. But the more teams can learn to communicate effectively—both internally and with customers—the faster new ideas can be developed and implemented into the product.

And this collaboration is valuable not just to the release of a new feature, but to creating growth opportunities for members involved in the process. As teams learn to understand the critical questions and technical requirements different departments consider when developing a feature, they may discover new ways of engaging with the product or even new areas of company growth. Cross-functional collaboration is just another opportunity for teams to quickly tackle specific problems and expand their collective product vision.