Getting Aligned: The Contracts of the Centralized Partnership

Product Design and UX Beyond Agile Structures, Part IV

February 28, 2022

Scrabble tiles on a white background, spelling: ALIGNMENT

Over the course of the first three parts of the Product Design and UX Beyond Agile Structures series I’ve covered the importance of picking the right organizational model for your design teams. My recommendation based on experience is the Centralized Partnership model, where designers are aligned to the customer’s journey and Lead Designers closely partner with product managers and/or owners and technology leaders. With the Centralized Partnership and its benefits covered in great detail previously, the question becomes: how can design leaders actually enable the partnership, and do so effectively?

In the Centralized Partnership model, the need for design to be more proactive in overall operations and priority planning is far greater than in the Embedded model. No longer is it simply one designer to one team forever, working off user stories; suddenly it becomes a single team of designers supporting a group of product teams. Lead designers help load balance the overhead by being the “boots on the ground” for each product team, determining where junior to mid-level talent can be most impactful while also directly contributing. Sounds easy enough, but this can only be successful if a clear decision-making framework and operations plan is in place. The first step is making certain all teams are aligned to the right objectives, from the top level down to each individual product team.

Cascading Experience Alignment Documents

I’ve always been a fan of briefs for alignment purposes, especially simple ones. My fandom is not always shared; sometimes I’m met by naysayers likening an upfront alignment document to a vestige of waterfall process (how slanderous!) or the first step on the slippery slope to “wagile” or “Scrumfall” (which sounds like the worst James Bond movie ever). In a Centralized Partnership, alignment is more important than ever, especially at the beginning. Product Managers may feel their design needs will be neglected without having a designer 100% dedicated to them, who responds at every beck and call. An experience alignment document can help assuage these concerns by clearly stating the “rules of engagement” between design and product, including who the lead designer, responsible for making certain the needs of the product team are met, is. In a way, the alignment document acts as a commitment, or “contract,” between the design team and product team.

The lead designer assignment is only one part of the document, though, and arguably the least important when considering overall experience strategy. I suggest having three levels of alignment documents, starting at the highest level of the experience, then the journey phase level, and finally the individual product team level.

Here is the type of information I usually include in the alignment document template for all three levels:

  • Objective(s): At the highest level, this should be the primary outcome(s) that all product and design teams are aiming to achieve. The objectives should ladder up to the company’s goals and be time-bound. At the enterprise level the time box can be a year or a quarter; anything less than that can lead to more prescriptive objectives, while anything longer loses tangibility and urgency.

  • Target Customer/Persona: Who is the team trying to help or behavior-change?

  • Customer Problems to Solve: The most important part of the alignment document: what customer problems are we looking to solve with the objective focus? If it’s difficult to answer this question, the objective might need revisiting.

  • North Star metric: What is the “one metric to rule them all” to indicate whether or not the objective has been met? For a financial institution, it could be “percentage of profitable accounts opened digitally.” Sub-metrics that contribute can be outlined, as well, either at the experience-level or within the phase or individual product team level documents. Identifying the sub-metrics helps product teams understand the levers available to them that can be pushed or pulled to affect outcomes.

  • (At the Journey Phase level) Teams Involved: It’s possible you and your teams will need to work across more than one division or domain to support a single phase of the customer’s journey. Here is where all the product teams that support the journey phase can be listed, regardless of where they sit in the organizational structure. Brand/Marketing and Communications teams should also be considered here. If the work crosses more than one product and tech leader’s desk, those names should also be included below.

  • Lead Designer: Who is the designer responsible for supporting the objective and ensuring the success of the experience design? Note: If you are working with a particularly nervous Product Manager, you can also include details on which meetings/agile ceremonies the Lead Designer will attend. I’m not a huge fan of going to this level of detail, but sometimes it’s needed to build trust up front.

  • Lead Product Manager: Who is the Product partner for the Lead Designer?

  • Lead Technologist: Who is the responsible Software Engineer or Architect for helping meet the stated objective?

At the experience-level, the responsible designer could be you if you are the senior-most design leader in the organization. At the journey phase-level, a Design Manager responsible for one of your journey phase design teams would be that individual. At the product team level, a Senior or Lead designer would be the responsible party. With all responsible parties set, it’s clear who the “noses to touch” are in the matrixed structure, which will help inform meeting attendee lists and cadences. Example to take or leave:

  • Product team-level alignment and status meeting

    • Attendees: Product Manager, Lead Product Designer, Technical Lead

    • Cadence: Once weekly

  • Journey phase-level alignment and status meeting

    • Attendees: Product Design Manager(s), Senior Product Manager(s), Engineering Manager(s), and design, technology, and product leads from the product teams

    • Cadence: Every other week

  • Experience-level alignment and status meeting

    • Attendees: Senior-most Product Design, Technology, and Product leaders for the given experience, plus the senior design, technology, and product managers from the journey phase teams.

    • Cadence: Monthly

Additionally, the Product Design journey teams should meet regularly to share design work, research insights, and upcoming plans. This is where you can ensure your teams are keeping the bigger picture top-of-mind.

Diagram showing three levels of a product organization: customer experience journey, journey phase, product team in cascading order.

We are scientists

Each document should ladder up to the one above it. A product team, including its Lead Designer, can even go one level deeper: the hypothesis level, where experiments informed by existing or new research are planned. The hypothesis document inherits the target customer/persona from the higher-level documents, but should have a very specific customer problem to solve. The rest of the document consists of a hypothesis statement, which looks like:

  • We believe [building or changing this in the experience]

  • …for [customer type or persona]

  • …will achieve [this outcome or impact]. 

  • We will test our assumptions by [concept or usability study, A/B test, analytics data, or other experiment].

  • We will know we’re right if we see [quantitative or qualitative measure].

Building quality hypotheses and experiments can only be successful if the team has a solid understanding of the customer they serve and the challenges they face. This is facilitated by “signals” from analytics, customer service data, and other sources, but those sources only show that a problem exists, not why it exists. Thankfully the product team has access to design and user research through the Centralized Partnership! While analytics data, as an example, may uncover smoke indicative of a fire, the fire itself can only be identified through research methods, including but not limited to usability testing of the built solution. The resulting insights can then inform a solid hypothesis and experiment strategy.

What happens if we don’t know enough to hypothesize?

The above assumes a mature product or experience is in market. When a net new capability is considered, product teams may have some foundational or directional data, but not enough to know exactly what problem is best to focus on first. Or even if there is a problem at all! To help bring clarity, the Lead Designer along with a research specialist, or another designer with expertise in research methods, can work with the team to develop the last type of alignment document I suggest: the Learning Backlog.

The Learning Backlog is exactly what it sounds like: a list of questions we have about our users and how they experience our product(s). It can exist at any and all levels of the organization and inform agile releases up to top-level experience strategy. Anyone can contribute to the Learning Backlog, and how you set it up is totally up to you. I just suggest that the question itself and the associated customer persona are included in some way. With a list of open questions about your customers, you and your team can meet with peers on a recurring basis to determine where to best spend precious time and money on exploratory and generative research.

Aligned and ready to roll

The above documents are all suggested, primarily, to drive conversation and alignment between Product Design, Product Management, and Technology leaders as step one of entering into a Centralized Partnership. The three levels of alignment document help ensure all teams are rowing in the right direction, with Product Design coverage and responsibilities transparently set to reinforce trust outside the traditional Embedded model. Depending on how your organization sets and cascades goals or OKRs (Objectives and Key Results), you may not even need the top level document. The journey phase and product team levels, though, are highly recommended as they drive conversation and document agreed ways of working in the new operational model. How and where these living documents are written and stored for easy access and iteration is completely up to you and your teams. Confluence, Jira, Notion, SharePoint, Teams… It doesn’t matter, as long as everyone knows where to access them.

With critical conversations held and decisions documented, you have successfully entered into a Centralized Partnership with alignment across the organization. Congratulations! The hard part is done so you can now focus on delivering for your customers and the business.

Thank you!

And that concludes the first article series for Sonder & Rise. I want to thank all of you who have subscribed for your support. Please know this is only the beginning, and there’s so much more to come. If you have any feedback or questions, I’d love to hear from you. I can be reached on Twitter @justindelabar.

Product Design and UX Beyond Agile Structures Series