BACKGROUND

About a year into working at LiveRamp, I was asked to take on another workstream which resulted in me leading a cross-discipline workshop focused on solving for the prototypical experience of customers looking for additional capabilities offered by partners to help them achieve their business objectives. I was initially approached by two different stakeholders, each of whom had different solutions in mind: the company’s Chief Strategy Officer approached me with a quizlet he liked, which initiated a sales motion through a flashy UI; the Director of Business Development came to me asking for a marketplace storefront for the company’s partners to market their services and solutions. Both wanted to increase revenue through new integrations and retain current customers. While I have a good amount of experience in the partner space, I didn’t understand the scenarios in which our company’s customers engaged with partners, nor where we could make this engagement more seamless.

Though both stakeholders were jumping straight to solutions, they had helped me identify business challenges LiveRamp was facing: some amount of client churn was resulting from the platform missing very specific functionality that would be prohibitively expensive to custom build for a small number of clients. And from there I had a user problem to start with: some of these churning clients were happy with our core capabilities, but also couldn’t justify staying with us when a competitor has a weaker graph but has their specific need (for example).

So, I proposed the Design Sprint format as a way to quickly understand the problem and put together a prototype to get customer feedback and shape strategy going forward. It was also a good reason to get out of the house and build some camaraderie with folks across the company.

Though I had a starting point, I dug a little deeper on the customer issues in the lead-up to the sprint. I worked with UXR to synthesize customer responses from the Persona survey question, “What capabilities do you wish LiveRamp products had?” Then, I held a Lightning Decision Jam to source additional customer problems from internal stakeholders. These exercises were valuable in order to figure out what we would go after, and just as importantly, what wouldn’t be in scope.

THE DESIGN SPRINT

Sprint Day 1 features the most individual activities, all in the name of aligning on the problem we’ll tackle with the rest of the week. We need to start by establishing a goal (optimism) and ask the hard questions (pessimism). We established the long-term goal: “Customers can seamlessly discover and engage with solutions and partners that meet their needs.” And asked the difficult questions: How could this fail? What does our prototype need to answer? Will Customers be able to find the right solution? How Does LiveRamp Stand Out? Is this really worth Investing in?

Next, the team identifies all of the actors and begins to map the existing journey. Our first map was super messy, but helped us zero in on something more attainable by Sprint’s end.
While all this is happening, the team begins conducting subject matter expert (SME) interviews. Throughout the interviews, the team refines the goal, questions, and map.

We focused on the needs assessment portion of the journey, and for the sake of scoping the prototype, the persona of “Analytics Lead.” The team hypothesized that here is more value in bundling partners with their solutions and the company’s products vs. just viewing the Partner’s info.

Sprint Day 2 is all about sketching. Every exercise builds towards sprint team members getting their best idea on paper. The multiple exercises culminate with each participant self-selecting their best idea to be elaborated on and sold to the rest of the team. The solutions need to speak for themselves and stand up to criticism.

On Day 3, the team decides on what will be developed into the prototype. The solutions are reviewed and critiqued. The team votes, then the decider supervotes. “Must-haves” are separated from “maybe-laters.” The team develops the storyboard of the prototype. Gaps are filled in with pieces from the “maybe-laters” and the story emerges for what will be in the prototype.

On day 4, the designers went “heads down” to get the prototype ready to show to customers the following day (and week, due to scheduling constraints). Meanwhile, our research and PM leads helped craft the interview script. During this process, the decider and other stakeholders are consulted on gaps that are identified or areas that don’t make sense. When in doubt, it’s worthwhile to go with a riskier choice, since we’re so close to validating with users.

Over the two weeks following the sprint, we conducted user research sessions on five different participants across different industries. Some of our higher-level feedback and insights:

• Customers need help discovering partners.

• Customers collaborate with multiple internal and external teams for partner discovery / selection. Marketing, Legal, Procurement, IT typically work together for partner selection / vetting / onboarding.

• In selecting a partner, customers look closest at pricing and relevant experience.

• Matching partners to use cases is valuable.

• LiveRamp’s revised information architecture wasn’t immediately obvious to customers. Customers were confused by “Access, Manage, Act, and Analyze. (The feedback on the proposed IA resulted in making the nav clearer and object oriented.)

• Picking the right initial partner attributes is key … and they often vary across partner types.

• Transparency is important for any subjective partner labels (e.g. preferred, premium, etc).

• Pre-populating customer info and enabling sharing with stakeholders are winning features.