Getting our Story Straight: Reflections on VMware Design’s End-to-End Story Process

One of the tools we use at VMware Design is the End-to-End story process (E2E). The process is designed to help align product teams and ensure that the entire customer experience is considered in our solutions - from the initial learning about a solution to using it at scale.

When I joined the company, the E2E approach was new to me, and I've since found them to be immensely helpful. Kevin McBride, a design leader here at VMware, wrote an article about some of the ideas behind this process and how to employ it. In this blog post, I share my experience using this methodology for the first time as a product designer for Tanzu Observability, including the challenges and benefits I discovered going through it.

The starting point

At the start of this project, the design team had three separate tickets in our backlog with different product managers associated. One of the skills that designers can bring to the table is the ability to see the big picture. On Tanzu Observability, product managers tend to focus on a specific product area, while designers tend to be less specialized.

Because designers are less focused on one area, we are in a good position to think holistically and make connections. From the perspective of the product managers, they created tickets to address needs they were hearing from customers. From the design side, we could see a thread connecting the needs and pain points identified in the individual tickets. We would use this E2E approach to follow that connecting thread to help others see how these things were connected and to ensure that the solutions we came up with took the bigger picture into account.

The product managers had done some interviews with customers to understand their needs and what they wanted to be able to do. We also learned about these needs from sales deals we lost because the lack of these capabilities played a role in the decision not to purchase. Additionally, I met with our technical pre-sales and customer success team members to understand the problem from their perspectives. Some of these issues were ones the customer success team always dealt with, so they were a powerful resource.

The workshop

After digesting the work that had been done already, we decided that it would be helpful to understand how the different pieces may fit together. So, we ran a workshop with representatives from design, product management, engineering, and customer success to understand the ecosystem around the problem. From this workshop, we were looking to address the following:

1. What were the pain points and desired outcomes of our hands-on users and their stakeholders?
2. What were the outcomes we wanted for our company?
3. What specific use cases could help users' pain points and lead to the desired outcomes?
4. Were there technical constraints that we were working within?

Through the workshop, we uncovered themes that suggested a coherent story, confirming our initial suspicion that the tasks we started with were indeed related.

The script

With this journey in mind, I set to work on a script to tell that story from our customers' perspectives. The E2E methodology uses storytelling to illustrate the goals and pain points from the user perspective. The goal is to create a shared understanding of the customer and market problems and to map out the buyer's journey for our users: How do they learn about the new capability? How do they try it? Why do they decide to adopt it? What is it like to use it? And how will they scale up their usage?

Going through the script-writing process, I realized that we already had some of the pieces we needed in the product, but some of those pieces were incomplete. They weren't connected in a way that would be obvious to a user - they would have to go to different places to find the information they needed. For example, we had a feature called Ingestion Policies that should allow users to track usage for an application or team, but in our research, we heard that they were not useful because they were too restrictive and didn't allow customers to segment the data in ways that were meaningful to them. And we had several dashboards related to overall account-level consumption, but a user might have to look at multiple dashboards to get the complete picture.

After completing a first draft of the script, I set up a meeting with the Product Manager (PM) to review. My initial work was clearly incomplete, but I felt like it was heading in the right direction. During our discussion, the PM questioned the value of going through this exercise at all. After all, they had done a lot of research already. Was that not sufficient? While I was not necessarily going to be blocked in continuing this effort, the PM was palpably unenthusiastic about it. I would need to demonstrate this process's value or change how I was going about things.

A big challenge for me at this point was that I had similar concerns to the PM. I had not gone through this end-to-end story process before, so I also genuinely questioned its value. Neither of us wanted to get stuck on some idealized process if it was not going to be valuable. So I continued but was prepared to change course if the process looked like too much overhead or wasn't providing value.

The storyboard

The script is a crucial piece of the process, but it is not one of the main artifacts shared broadly as part of this process. The script helps us focus on telling a story. But we tell this story through a presentation; a storyboard is the visual component of what we would ultimately present.

I created a mostly-complete version of the storyboard. It was fine, but admittedly, not very exciting. At this point in the process, another designer joined me on the project. She was new to the company and the domain. Her first task would be to give the storyboard a little more pizzazz. And to my delight, she ran with it! Coming in with fresh eyes helped her see where things could be improved and where there was background information that would be super helpful for a listener to understand. Being deep in the project, I had taken some of that information for granted. This new perspective improved the presentation significantly.

Feeling good about what we had done, we set up a time to present the story to the PM once more. While we already had a date scheduled to present to the leadership team, we knew we needed to have the initiative's PMs' support and additional input first and foremost. They needed to agree that the story we were telling was feasible, data-informed, and accurate based on their understanding of our customers' needs. Given the skepticism I faced about the end-to-end process, I was nervous about how the presentation would be received. Would this type of storytelling help everyone align on what problem we were solving and why? Or would this entire exercise have been a waste of money and time?

It turned out, my worries were unfounded. The presentation went very well. The PM not only liked it but appreciated how we were able to bring the initiative's workstreams together into a story that was relatable and easy to follow. Success!

The prototype

As a next step in the process, we needed to create a prototype to illustrate the solution described in our story. The plan was to present this prototype along with the storyboard. From there, assuming that leadership liked what we had come up with, we could also use this prototype in discussions with customers.

When working on the storyboard, I sketched rough versions of my ideas with very little detail to communicate the concepts. Still, for the prototype, we needed to move to a higher level of fidelity. The challenge here was that now we needed to think about actual data. As designers, we had some vague ideas about what might be useful based on what we had learned, but at this point, we really started to lean on the customer success team. They had already been helping customers on a case-by-case basis to solve some of the challenges we were looking to solve more generally.

We had several working sessions with the customer success team to better understand what specific information customers were looking for. My colleague did most of the hands-on design work, and we went through several iterations and rounds of feedback before getting to something we felt confident presenting.

The presentation

Sharing the overall story with the larger team went well. The storyboard format helped ensure that the presentation had a narrative flow and kept the focus on the users' problems and desired outcomes, as well as those of the end users' stakeholders. We presented the prototype after establishing the story and ensuring that the audience had the appropriate context to understand our solution.

Make no mistake, though; the presentation was not all sunshine and rainbows. We still faced some tough questions. Some of those questions were about things we were deliberately vague about, perhaps because we still had questions about feasibility or some use cases we had not really thought through. That is not a problem, and in fact, uncovering those things is the value of presenting. The goal of the presentation was not to have all questions answered but to create a shared understanding of the problem space and align on a vision. By that measure, the presentation was a success.

The next steps

At the conclusion of the E2E process and we achieved what we set out to do: we had aligned on a vision for how to solve customer challenges holistically. However, this was not the end of the design process. From here, we needed to make sure that the vision we had created resonated with our customers. These customer conversations would be critical in helping us validate assumptions, uncover more questions, and further improve the experience we came up with.

Fast forward several months, and the Usage and Subscriptions capabilities we designed through the E2E process are being rolled out to Tanzu Observability customers in phases, with some of the first pieces already available in the product. As customers begin taking advantage of these new capabilities, we expect to learn more and continue providing new tools to help users understand and manage their consumption.

The learnings

This end-to-end process is now part of our team's process. And since doing this end-to-end story, our team has gone on to do several more. It's a great tool for aligning the team and ensuring that the customer is at the center of what we do. Along the way, we learned too many nuggets to share here. That said, we did manage to boil our learnings down to four key points:

1. The E2E story process was helpful for this project to unify different aspects that were initially viewed separately and to get the whole team aligned on a vision.
2. Having design, engineering, and product management all collaborate on the E2E story creates buy-in across the team.
3. This process is most useful when done early. If implementation has already started, it may be too late.
4. The process is fairly involved, so it is probably better suited for larger design efforts where there is more ambiguity.