Teams may have self-isolated for speed. Conflicting incentives within individual departments may push teams in diverging directions. A recent acquisition or merger may have affected internal alignment.  

Whatever the cause, silos in delivery teams can lead to duplicative engineering work and disjointed user experiences. 

Getting all teams set up to work quickly and efficiently starts at the top, and the up-front work is well worth the payout. Step one is to align all team members around a “Jobs To Be Done” (JTBD) Framework that outlines what your customers are hiring you to accomplish. Helping customers achieve their underserved, high-value needs raises your product’s potential value. 

Step two is to visualize the desired customer experience through an Experience Vision. An Experience Vision shows how your business goals and customer insights from the JTBD research are brought together to focus on creating a valuable experience for your customers.

An Experience Vision provides a north star and guardrails in crafting an end-to-end product experience that will help you to enhance your user’s experience and, ultimately, your bottom line. The devil in achieving this bigger picture is in the details.

The opportunities uncovered through your Experience Vision may take three to five years to realize, which is okay. Ambitious visions take time, which makes an Experience Vision even more essential to informing the planning process and bringing optimization and clarity to your product teams. 

You have to know where you want to go and work backwards to ensure everyone knows how to get there. Workstreams often require reevaluation about every six months, but if you don’t have an Experience Vision driving the conversation along the way, you may find teams filling that gap on their own.

Let’s use a familiar example to demonstrate how an Experience Vision can inform the process and keep multiple teams on the same page. Uber is now a well-known company, but it wasn’t long ago that people relied on taxis – or friends – to catch a ride to the airport. 

Uber had the vision to make requesting a ride from your smartphone easy. The founders imagined an experience that leveraged technology customers already had (their smartphones) and made the “job” of finding a ride whenever you needed one more convenient.

For simplicity, let’s imagine that Uber used their Experience Vision to pull out two product themes: requesting a ride and paying for your ride. These themes could have served as a North Star for the product teams to plan and build. Themes provide direction on what outcomes the organization wants to achieve but don’t provide the product solution. 

Defining these guardrails, but not the solution, allows teams to visualize success while maintaining autonomy to innovate and feel ownership over what they build. It keeps everyone focused on the question: 

How can we best create this experience for our users?

To prioritize your planning, you’ll want to revisit the JTBD research that helped you uncover your Experience Vision. List your jobs by user type that fall within your product themes. Going back to our example, Uber may have identified the jobs (to be done) by user types for the product themes to look like this:

Product theme: Requesting a Ride
Jobs by user type:

• I need to get from point A to point B (rider)
• I need to take someone from point A to point B (driver)

Product theme: Paying for a Ride
Jobs by user type:

• I need to pay for my ride (rider)
• I need to be paid for giving someone a ride (driver)

Ideally, you would have one product roadmap responsible for executing each “job by user type.” You’ll work with other product teams to create a journey map for each product theme representing all applicable user types. In this example, key stakeholders from two product teams work together to understand the steps the passenger and the driver would take for someone to request and get a ride. 

Product Team 1 would focus on the passenger’s experience getting from point A to B, while Product Team 2 would focus on the driver’s experience of taking someone from A to B. You can see how those two jobs would have touch points that overlap. These are prime opportunities where teams can optimize the experience and the code base. It’s where your solutioning, validating, and prioritizing comes into play. 

You might wonder if this approach is a sure-fire way to create dependencies. It’s true your team may feel like they can’t move forward with work that requires another team’s effort. 

I’d argue that depending on another team forces healthy codependency that encourages constant communication and prioritization. It may be an opportunity to collectively develop a leaner approach to the problem or swarm on an essential overlapping experience. 

Both teams must be incentivized to deliver the complete journey, not just their individual parts. Encouraging and rewarding a win-as-one approach is vital to making these types of changes to how teams work. 

There should never be enough dependency that would result in a bottleneck for anyone. Good team planning, prioritization, and communication should be a priority and should alleviate any big blockers. And isn’t that the goal at the end of the day? 

Following this process can take effort since most enterprise organizations don’t work this way. But it will ensure you’ll reach outcomes that benefit both the organization and its customers. It will bring teams closer and align them towards common end goals, helping to optimize both the experience and the work of delivery teams, ultimately resulting in more efficient, streamlined processes.