(5 minute read)
Finding a way to communicate technical solutions in a way that everyone can understand is one of the most difficult parts of being a Product Owner. During our Sprint Reviews, we have people that have no experience with web development and experts in the field all in the same room and everyone wants to understand what is happening. I have found that relating the technical information to a tangible example people can picture in their minds makes it easier to understand what is happening. Framing the situation as a story helps to bring the situation to life and makes it memorable. Plus it is a lot more fun! Here is an example of how I explained how we implemented third party software to our websites and how we had to change our original plan.
Situation
Our development team was asked to implement a new marketing communication platform that would allow the marketing department to customize different email and marketing campaigns based on customer data captured on our two websites. As customers were using the websites, event-driven triggers would capture that information and send it to the marketing platform. Then our marketers would be able to see that data and tailor customer journeys in order to increase conversion and keep them engaged.
We had refined all the stories and we were ready to begin the work when in our final walk through of the plan with the main stakeholders I heard them say something that had never been mentioned to us. They wanted us to use Google Tag Manager to implement it on one of our websites. It was not a huge change but it meant that we needed to schedule an emergency planning session so that we could regroup as a team. Once we altered our approach, the developers were able to get to work. And that’s when I was tasked with the trickier task of finding a way to explain where the miscommunication had been, how it impacted the team, and most importantly what happened. As I was peppering the developers with questions to understand what needed to be done, a picture started to form in my head. I quickly grabbed a pen and paper and drew what I heard. That was how the API train was born!
Story Time
Our Goal: Get the Passengers from the train stations to Central Station
We were tasked with the goal of getting the passengers (customer data) from the train stations (websites) to central station (third party platform). Central station already had a train (API) that could transport the passengers (data) back to them. The main thing that we needed to focus on was how to get our passengers onto the train. The original way that we planned was going to have to build the platform and make sure that the passengers got on the right trains.
The curveball that we were thrown was that the other website already had a passenger staging area (data layer) and a PSA conductor (Google Tag Manager) that would help make sure that all the passengers were able to get on the right trains at the right times. Overall, it made implementation easier because all we needed to do was to build a walkway for the passengers from the station to the staging area.
Results
The main benefit of using this train story to explain what happened was that it made the information easier to understand and more approachable. Framing the impediment as a story, allowed me to explain exactly how we had to alter our approach but also allowed for a little fun for what was a frustrating sprint. We had more engagement than usual in the Sprint Review, which made the development team, myself included, feel like the stakeholders heard what we were telling them and appreciated how we were able to adapt. After the meeting, I received several compliments about the story and how much more approachable both the plan and the difficulties we faced during the sprint. And to this day when I mention APIs, people smile and says “oh you mean the trains!”