Collaborative Product Development: How to Structure Your Team

The launch of a new product represents a huge leap, but it’s really just the first big step in a series of many. Over the course of a healthy product’s lifespan, your team will continue to work inside the product for years to come, fixing bugs, pushing out updates, making UX improvements, and adding new features.

All of this work will likely require the ongoing attention of your entire organization in some form or another. But new features, in particular, require an orchestrated effort across all internal teams. This is especially true for larger features, which may rival a new product build in terms of scope and complexity. In order to successfully develop and launch new features, you need to bring your team into collaboration. Collaborative product development means making sure that members of product development, UX design, and engineering teams are involved at each stage of the process, taking leadership positions at various stages from kickoff to launch.

The classic waterfall approach to product development includes a series of predetermined pass-off points between internal teams. You know the story: Product has an idea that they give to UX. UX designs the idea and hands it off to engineering. Engineering builds the design according to spec, and the product or feature is launched.

In theory, this linear process sounds sensible. In reality, though, it opens the door to a lack of internal alignment and investment, limits the exploration of possible design and technological solutions, and increases the likelihood of scope creep. Worst of all, the waterfall approach puts you in danger of designing a new feature that engineering can’t realistically build — or that your customers don’t actually want (qualitative user testing is also key to avoiding that outcome).

There’s a better way to structure your team’s approach to new product features — one that brings your team in sync and produces superior results.

Collaborative Product Development: Pivoting, Not Passing Off 

If your firm follows the classic waterfall approach, then you’re probably accustomed to taking a new feature through a series of pass-offs between internal teams as it moves from ideation to launch. Our recommended approach involves greater collaboration from start to finish, even as different teams take the lead during different phases of the project. Instead of pass-offs, we like to think of pivots. Leadership responsibilities change, but all hands stay on the ball through each of a project’s multiple phases.

Throughout, each team brings a unique and necessary perspective to your project, which may look something like this:

• Product: Does the proposed feature make sense for our market? Will it make our stakeholders happy? Where does it fall on the roadmap? Is this a high priority?
• UX: Are we asking “why” rather than just building a prescribed feature? What problems are we solving? Are there multiple approaches we could take in building this feature?
• Engineering: What technology can we explore? Is there something we haven’t thought of yet? What is the effort level or time to build the ideas being explored?

Taken together, these unique perspectives give your team a wider, more seasoned perspective that’s greater than the sum of its parts.

The collaborative product development approach that we recommend yields many additional benefits that apply to new products and features alike. By structuring your development process this way, your team will:

• Create internal unity and a sense of shared ownership as all teams align around a singular vision. Including the whole team from the beginning gives each member of the team a sense of ownership as they are encouraged to share their perspective and expertise (rather than being handed a directive to build something they didn’t help curate).
• Foster innovation by including multiple perspectives during ideation. Including the perspectives of all teams during ideation leads to more creative, out-of-the-box solutions.
• Gain a better understanding of the technical options, possibilities, and costs of your proposed feature. Including engineers from the outset ensures that you choose the most appropriate technological solution to your problem.
• Avoid scope issues and address possible roadblocks upfront. Scope problems often crop up when internal teams don’t communicate well about project specs on the front end. With all teams in ongoing collaboration, you’ll keep your project scope in check and proactively tend to possible issues.
• Create unity so that everyone works together harmoniously. When all teams work collaboratively on a project, they work smarter and more efficiently. Another plus? They tend to feel more invested in the project and its successful completion.
• Solve problems more quickly as they arise. When issues do crop up, your whole team will already be in the know about what’s happening with your new feature, allowing you to address problems with speed and agility.
• Keep projects on track more easily. When your whole team is familiar with a project and where it stands at every turn, it never falls off the radar.
• Avoid costly communication breakdowns. Involving all teams in an ongoing way means you’re better positioned to avoid costly mistakes and miscommunications.

All Together Now: A Communication Roadmap for New Product Features and Updates

Creating a truly collaborative product development process means structuring your workflow to allow for regular checkpoints and cross-team contact. As the project shifts from stage to stage, the leadership role pivots, but the entire team stays in tune.

1. Kickoff phase: The product team leads at the outset of the project, with input from UX and engineering. Major checkpoint: kickoff meeting.
2. Design, ideation, and research phase: UX leads this phase while checking in regularly with product and engineering. Major checkpoint: design and research presentation to team and stakeholders.
3. Build. The engineering team is now in a leadership role. Rather than waiting for the entire feature to be built before assessing it, the UX and product teams weigh in as the engineers complete each subtask related to the build. Major checkpoints: completion of each ticket.

You can structure your internal checkpoints in a way that makes sense with your project workflows and internal meeting structures. The main thing is to keep in mind that a new feature should never be passed off from one department to the next as it moves through the development pipeline. You want to keep all hands on the ball, and your meeting cadence and communication processes should ultimately be structured around that goal. Do that, and you’ll strengthen your team as well as your final product.