Project Overview

The original request was to help our client [Client A] understand their sister company’s [Company E] marketing teams problems, understand the users, and create design prototypes that would be used to design a new system to help them become more productive, using a tool [Client A] had already pitched and sold to them. The UX designer and I went to [Company E’s] site along with our [Client A] and listened to their current processes and their long wish list of future functionality requests.

Challenge: At the time we joined to help [Client A], we had not been a part of the original 8 months of current state assessment, vendor demos, and discussions that led them to their decision over the tool they chose. We were also brought in to understand their process and users, which was not documented during the 8 months of assessment, and there weren’t any requirements documented from the work done in order for them to choose the final solution.

Initial Discovery Phase

While onsite, we talked to the various representatives from the teams within the marketing team and gathered data which we found to have 3 primary personas and 6 secondary personas. We gathered users behaviours, needs, jobs to be done, and current tools.

I then led, with primary stakeholders; representatives from all teams a discussion around the marketing process from initiation to end results. Based on the information from the previous day, listening to the various groups talk about their pain points, I had shown my initial assumptions in groups of phases of work in digital form that I sketched out, which led the discussion on what I wanted to capture and how, starting with Initiation and Discovery . . .

. . . because we didn’t have a white board, we used large post-it sticky easel pads on the walls to capture through discussion the end to end process flow. Red post it’s were for pain points, yellow for tools and data (touch-points), blue for personas from the previous exercise, and green for the Salesforce tool opportunities we heard.

This session was very important for all of the teams involved, learning how their processes affect others, and for understanding their internal processes between teams.

From this white boarding session, I was able to re-create it in a digital version while it was fresh in my mind that evening, and get feedback from the group the next day.

During the process mapping session, and when we got feedback from the [Customer E] teams during other collaboration meetings, they would keep mentioning that they learned more about how all of the teams work together from this visual process map.

Design stories & Initial Story Mapping

The UX lead and I then started creating design stories based off of the initial process information we had and by talking with the teams within [Company E] and using the personas we had captured.

Taking the feedback we heard, as the design stories were being defined, I was able to start an initial story map, marking functionality from the design stories, as well tracking requirements defined from the kickoff that might not have been in the design stories, but still needed tracking.

I was able to also map some of the reports artifacts the team sent me, and matching it to what areas in the process they applied to.

Defining the Process and Deliverables

While, we were contracted to assist our customer in gathering data, understanding the process, etc. Some of the work was also around trying to understand what our [Client A] had promised to their [Customer E] , creating presentations on how we work, how we get story maps from design stories, how we use story maps for helping to prioritize, and how defining MVP should solve the right problems, but won’t have all of the functionality, what we planned to accomplish, validation on the goals of the project, explaining how releases might be affected, understanding what the tool they had chosen could already do, and what would be net new.

Challenge: Our [Client A] was not leading the project, communicating wants and needs, setting and defining goals, or consistently available. A lot of work was spent trying to pull out information from them and waiting for feedback, which caused a lot of bottlenecks, and fine tuning to set expectations about what was promised to the [Customer E] versus what can we accomplish. It was especially tricky because our [Client A] felt that most of the work was already existing in the tool, not taking into consideration integrations and a certain level of “customization” specific to [Customer E’s] processes, but not wanting to do too much customization.

Understanding the Business [Customer E]

Some of the work done was also around documentation of the [Customer E’s] current tools (internal and external) and how they interacted with each other and what areas they affected.

I created a terms dictionary and a tab for tools, also tracking if they were used by domestic or international teams to help with onboarding new team members

Challenge: The domestic team and international team have some similar processes, but then also differ in processes, tools, and the available resources doing certain tasks. Their goal was for both teams to follow the same processes and use the same tool where all important information is compiled into a single source.

Having discussions around the various terms (such as tracking numbers) and how they were used today. Some were specific to the domestic and international teams, some were specific to the type of channel, and some were interchangeable terms.

Defining the Roadmap and MVP

The story/feature map started to grow, and a lot of data was being captured, including the outlines of stories. The goal was to do quadruple duty and have enough information for our team to size the development effort, be an end to end functional view of the process options, be flexible for prioritization, and have copy/paste-ability for future stories.

Challenge: Change management and new processes were needed by [Customer E] but there was a lack of input as to how they wanted to deal with these options. There was no one product owner or decision maker on the [Customer E’s] side, so we could not make decisions on what options were feasable or not. They were also not brought along the journey by [Client A].

While documenting processes, I also made sure it would translate to the documentation needed for stories.

Challenge: Our [Client A] did not want to “waste [Customer E’s] time on multiple reviews without understanding the sizing”. It was difficult to get enough detailed information for a sizing for all possible options, and ideally there would be a decision maker that would be involved along the way, instead of waiting until the end to show the options. Since it was our [Client A’s] role to have these discussions, we did voice concerns but ultimately it was their decision on how to work with their customer.

I noticed that it was harder to get a high level view of what was in scope and what was out of scope, as well as see how many integrations were needed. Therefore I created a Phase 1 Features by System view, which showed what actions would be done outside of the system, what would be done within the tool, and what integrations were needed. Through this discussion, it was easier to see at a high level what would be in phase 1 and high level priority by phase . I then went back to the features map and adjusted some of the features that would be included, and what would not be for Phase 1.

One challenge was that the executive leadership of [Customer E] did not prioritize the project go live to the team, so the go live dates moved multiple times.

We were able to get enough information to set up a cross functional development team to work on the MVP and launch successfully. I lead the change management effort through training and documentation to the end users, and informing the executive leadership of the release updates.