As a digital product owner, the odds are that from time to time you will need to engage outside partners in order to fill gaps in your product team. When those times come, the focus of the engagement is rightly the initiative and its goals. Unfortunately, while this focus makes sense, it can also create a type of tunnel vision that will ultimately hinder the results and cost effectiveness of these collaborative efforts. Often, the actual details of product team-partner collaboration get lost in the excitement; how these two teams will actually accomplish work together. If the collaboration between the two parties is inefficient, execution of the initiative is inefficient, most often resulting in diminished returns.

At Emerge, we’ve started calling this collaborative interface the “digital product collaboration model”. We hope that by naming this oft overlooked and underappreciated facet of working together, we can have better discussions, and ultimately better outcomes, in our work with product teams.

A collaboration model is much as it sounds; a definition of the collaborative touchpoints, the tools they require, the applicable governance and processes, and the ownership of each. The idea is to map out the collaboration points and have protocols in place before the moment they are needed. This will remove potentially inefficient impediments. In other words, planned collaboration. This is not a groundbreaking idea, but sadly it’s one we so commonly see overlooked.

Some Common Touchpoints To Ensure Smooth Collaboration Between Developers and Product Teams

As noted above, ideally, the digital product collaboration model encompasses the collaboration touchpoints between the two organizations which are required to deliver the initiative. This includes their owners, the protocols and the guiding principles. Here are some fairly common examples of the types of collaboration points the model aims to define:

• How is access granted to the design system library? How is the subject matter expert?
• What established UX patterns exist for your product? Who owns these?
• What guiding architectural principles should be considered in designing and executing the software and/or feature(s)?
• How many hosting environments exist, who controls each?
• How will code be delivered to the product team?
• What source control branching model/workflow is preferred by the product team?
• Are there any existing coding styles or linting requirements from the product team?
• How will local development be architected?  Are there external (private) dependencies that require consideration?
• What client systems will the developer need access to in order to facilitate work, and how will that access be provided (source control, CI systems, VPN, knowledge wiki, ticketing system, etc.)?
• How will documentation be shared (Sharepoint, Google Docs, Box, etc.)?
• How will the teams communicate (Slack, Teams, etc.)?

Those are just a few, primarily focused on delivery.  Again, the goal is to map as many of the collaborative touchpoints as possible for the project. Most crucially those on the critical path for development and delivery of your project.

The Common Pitfalls of Just In Time Digital Product Collaboration

When work begins in earnest (implementation phases, sprints, empathy mapping, user testing, etc.) without a well-defined collaboration model in place, we see a fairly common set of problems as a result.  When it comes time to perform actual tasks or deliver milestones (and often well before), we hear things like:

• We cannot access system ABC?  
• Where does the code get deployed?  How does it get there?  
• Who’s responsible for deployment?
• Who’s the subject matter expert for API integration XYZ?
• Oh, you used tabs, not spaces so we are going to reject this PR.  
• What’s your branching workflow?  
• What is your version tagging scheme?  

These questions have to be answered. Probably while work continues by the agency partner, pushing the inevitable integration work even further down the line (thereby increasing its complexity and level of effort).  The project manager on the product team side tries to figure out which people to pull into a room to have these conversations, only adding more time to the delay.  Maybe your organization doesn’t even have the governance in place to dictate an answer, so protocol gets created on the basis of a single narrow context (this project), rather than with an eye towards the broader context and the long term future of the organization and its efforts.  Regardless, the end result of dealing with these problems during the work phases is that budget and resources have been diverted to solving these issues, and your first milestone date target is already in jeopardy (or worse, missed!).

How a Customized Collaboration Model Drives Digital Product Success

All of this is why, at Emerge, we push to define the collaboration model upfront in the planning phase.  Our experience exploring and building software for 20+ years, across a variety of industries and client sizes, has allowed us to define a base collaboration model, encompassing the common collaboration touchpoints for such initiatives.  We take our base model and then work with the product team to understand their organization, its principles, protocols, and governance. From there, we create and customize a new model, specific to the client organization, and the project at hand.  The result is a mapping of how the product team and Emerge are going to collaborate when doing the work outlining the touchpoints and their owners and protocols for each.  This enables smoother delivery and an increased probability that things will land on schedule, with fewer surprises (as well quicker paths to resolve the surprises that inevitably will arise).

Mapping out a collaboration model is a service we can provide irrespective of whether you have a particular project in mind, or not.  In fact, the best time to define your collaboration model is well before you need it!  The investment in defining this model pays off, as it’s reusable.  It is something you can use anytime you engage an outside organization to work on your digital product, and having it ready will help to avoid wasting time and money on each of those subsequent initiatives.