Cross-Functional Teams: Getting Engineering, Product, and Design on the Same Page
First thing’s first, what’s a cross-functional product team?
Cross-functional product teams pull from the larger engineering, product, and design (EPD) teams and typically consist of one product designer, one product manager, and one or more engineers combining their superpowers toward building a either a specific or a set of product features. These multidisciplinary teams must work together to effectively assemble their skills in a way that enables them to build awesome products that satisfy both business and user goals.
So, what’s the value of aligning your cross-functional product team?
This group of engineers, product managers, and designers have come together from their larger teams to accomplish a goal toward the greater good, which necessitates a fair amount of autonomy within the team to trust that they’re working toward improving both the larger product and the organization. Making the space to have a conversation about the business value, user goals, and technical considerations of the problem helps to increase confidence overall that everyone is on the same page. Furthermore, ensuring everyone on the team has the same context surrounding the problem can allow early meetings to focus more on ideation and problem solving, rather than getting lost in the murky details, or laser-focusing on any one specific solution.
Questions to ask early on
Answering these questions should help to align your team in its understanding of the existing problem space and the value of solving the problem, as well as provide an opportunity early on to voice any concerns. The ensuing conversation should be documented and easily accessible by your team throughout the effort.
Question 1: Is this a new feature or a feature enhancement?
This question helps to frame the rest of the conversation by providing an initial scope of the required effort. If this is a new feature, what other areas of the product does this touch? How might we structure user or market research? What business goal does this fulfill? Do we already have the infrastructure in place to support it? If this is a feature enhancement, what are the gaps in the current workflow that this is intended to fill? What workarounds are there because this feature doesn’t exist? Are there technical constraints to consider in the solution for either case?
This part of the conversation can help to align the team on the expectations of the feature request and present additional questions that can help to clarify future work.
Question 2: Does this fit into a larger effort or OKR?
Does this work fit into a larger goal our team or our organization is trying to accomplish or is this a one-off request? Understanding how this effort fits into the wider landscape can help to frame the conversation during ideation. If this is a piece of a larger puzzle, how might the design or the architecture be flexible enough to allow for future iterations? If this is more of a standalone effort, how might we scope the solution to not bleed into other, more prioritized efforts? It’s easy sometimes when looking at a blank page to get carried away with possibilities, but being mindful of how an effort fits into the team goals can help keep everyone focused.
Question 3: What are the use cases?
This question is meant to start digging into context. Why are we talking about this effort? Is there existing user or market research that can be shared with the rest of the team? Are there any common threads across any of the use cases? Discussing and documenting relevant use cases helps everyone on the team conceptualize the problem and make it easier to start brainstorming possible paths forward and connect ideas and solutions to the user and business impact.
Question 4: What is the business value?
Based on the use cases, does this feature affect revenue, growth, user satisfaction, or some other metric that’s important to the organization? How so? What metrics will help the team understand if this project was successful or not? Do we have any benchmark metrics to measure against? Understanding how this work might impact the business is crucial both in measuring success and prioritizing this effort against others in the team’s queue.
Question 5: What do we already know?
Now that the team has a better understanding of the use cases, what do we already know that could help further align the team? Is another team working on an effort that could make this work easier or more difficult? Did the team look into this same problem in the past, and are any of those learnings still relevant? Are we using any third-party services that might impact how a solution is built? Taking the time to consider the team’s resources from multiple perspectives may save time in the future.
Question 6: What don’t we know?
Equally, if not more important, making the space for the team to be realistic about unknowns can help prepare everyone later on in the process. Think about which of these concerns need to be addressed before starting the work, and which can be answered as we go. Are there potential side effects of the work we’re doing that may impact our team or other teams down the line? Is there uncertainty about certain use cases? Does this effort touch codebases that the team is unfamiliar with?
It’s impossible to anticipate every single unknown while still working iteratively, but allowing the team to voice any concerns early on can help to avoid future scope creep or unforeseen issues, or at least more accurately estimate how long it may take to finish a task.
Question 7: What could this work lead to?
This question should prompt everyone to think about how this work may impact the team in the future. Will this effort increase the complexity of what users can do with our product? Will we gain an entirely new group of users? What would this mean for us? The goal isn’t necessarily to get carried away with possibilities, rather, to think critically about how taking on this work may affect the team in the following quarters.
After the team is more closely aligned in their understanding of the background and context, moving into a whiteboarding session can help the team ideate to solve the problem in a way that takes into account the user goals, business value, technical constraints, and future impact on the team. Encourage everyone to participate — drawing, asking questions, or documenting decisions are all helpful here!
Question 8: What is the estimated design effort?
This question is best asked after the team has started to whiteboard together. Given the conversation up to this point, is the designer on the team able to make a preliminary list of how they might approach the problem? Are additional user interviews required? Is there a design system that can be leveraged with existing interaction patterns, or are we starting from scratch? The designer on the team should pull from experience, being transparent with the team about what they may need to do on the design side based on the current conversation. Again, this doesn’t have to be an exact estimate, but think about the required design effort to bring this feature to life — given the user and business value, how does this impact the prioritization?
Question 9: What is the estimated engineering effort?
This question is also best asked after the team has started to whiteboard together. Given the conversation up to this point, are the engineers able to make a preliminary estimate as to how they might approach the problem? What code bases will need to be touched? Do all the engineers have an understanding of what those changes entail? Are there any security questions to consider? Is there a UI component library that can be leveraged to build this feature? Are there unknowns that may require some investigation before anything can be built? The engineers should speak candidly from their expertise to think critically about how easy or difficult this task may be. It’s especially helpful to other team members in the room that may be unfamiliar with how engineers break down tasks. Like the design estimate, this doesn’t have to be exact or final, but starting to think about the expected engineering effort based on the current conversation can help impact the later prioritization.
Question 10: What is the business/user value vs. effort?
This question prompts the team to look back at the conversation so far, and think about all of the factors that could impact the prioritization of this effort. Are there compelling user stories? Have we quantified the business impact, and what it would mean to be successful? What don’t we know that could impact the expected timeline? What are the design and engineering estimates?
After answering these questions, the team should be able to determine if this is an effort worth prioritizing.
Question 11: How might we release this feature to users?
Depending on how the team historically releases features or feature enhancements, there is likely already a precedent for communicating product changes to the organization and clients. Thinking about the “end” of this effort can have an impact on work that’s done in the beginning. Is this a new, fairly large feature that has a higher user impact? Maybe releasing it as part of a beta program to a select group of users may help make sure that the final product is more stable. Is this a smaller, less risky feature enhancement? Maybe existing support documentation can be updated.
Thinking about the feature’s release forces the team to think about who else may need to be part of early conversations. The answers to these 11 questions may serve as a helpful resource for those people to gain context as well!
When am I supposed to ask these questions, anyway?
Great question! This list can lead to lengthy conversations while the team works to gain alignment on a task. I typically like to break out the conversations into a few steps:
- Pre-meeting: Send out these questions to your team, asking them to pre-fill any answers they can. Typically, questions 1–7 can start to be filled out before a meeting, shifting the meeting focus toward discussing what’s been added and building on answers where needed.
- During the meeting: Spend the first part of the meeting discussing questions 1–7 as a team. Move into whiteboarding, making sure to take pictures of the board and document the conversation in a place that’s easily accessed by all team members.
- After the meeting: Designers and engineers should reflect on the previous questions and start to think about their responses to questions 8 and 9, respectively, making sure to document their thinking. In the next team planning meeting, answer questions 10 and 11 as a team. How does the business value vs. the effort impact the prioritization?
As a designer, I’ve found that when the team is aligned, I’m more confident that our strategy to work toward a particular goal will enable us to deliver value to users and clients. This question framework has helped me to gain this alignment, but I know there are tons of other ways teams come together to achieve amazing results. How does your team gain alignment?