From the Archives: “Stories from the Front line of Product Operations”

A product team’s journey into their users’ world

In 2019 our team needed an enterprise-ready app that helped our users grow their businesses. We were tasked with re-creating the legacy application that was in use for the past several years, and we were on a mission. While we couldn’t start development until mid-May, in January the team embarked on a journey of knowledge sharing that we all grew from. We experimented with a process based on the Google Design Sprint that I call “continuous learning sprints.”

Top four thoughts and takeaways for teams (see the rest at the end)

Here are the lessons I learned as a Sprint Master, a Sprint Doer, and a Product Owner during this time:

  1. Using continuous learning sprints to learn about users helps your product and everything around your product. The ROI from knowledge gained alone is huge for the backlog owner.
  2. All teams have problems they need to solve. You don’t need to build a new app to include continuous learning sprints in your regular work process. You can still use this process if you’re not building software. You can start this process with an existing product. Continuous learning sprints don’t have to apply to prototype tests of a user interface. They can work for any team if you define “question” as any question in the world. You could define “users” as people who have a stake in the question, like other coworkers, teams, or leadership. This is a way to quickly learn, solve problems, manage work, radiate knowledge across teams, and apply the knowledge to your backlog decisions. Got a problem? Explore it in five days with a continuous learning sprint.
  3. Participating in this process helped create a mindset of curiosity and empathy for user behavior on the teams we worked with. Instead of running with assumptions in development, they started saying “Wait, what you said is an assumption. Let’s test it first.” We empowered them to become better builders of software. We’re better product teams today because of it.
  4. Bring snacks.

This is our story

A long time ago in a war room (not too) far, far away…

General was upset. It was cold and we had problems. They were the same problems all product teams in the world face at every point, but especially at the beginning of an app’s life: how do we know we’re on the right track? How do we provide value to our users? We had nothing but ideas to work with. We wanted to get rid of the big hairy assumptions we had about different subject matters of our product. And we needed to do it quickly. We decided to start in the months before we were able to begin development.

Google Design Sprint roles

Google Design Sprints and Scrum have similar roles.

  1. The Sprint Master facilitates and guides the team on user research best practices.
  2. The Decider makes the decisions and tough calls in-sprint.
  3. Customer Experts, Business Experts, Design Experts, and Technical Experts give their advice and considerations. You don’t need them in all sprints. And you may only need one of them. Choose wisely.
  4. The Doers create the tests, perform the research, and present the demo.
  5. The planning and demo could have outside teams or leaders who have a stake in the question you’re answering.

Google’s Design Sprint process

Lean UX process proposed by Gothelf

Our process of continuous learning sprints

Sprint 1

You’re probably wondering, “Why is ‘bring snacks’ in the top four?” Well…we didn’t bring snacks to sprint 1 tests and it’s something we learned. So be forewarned, listen to your and your users’ stomachs when you’re testing in continuous learning sprints. Everyone loves to be rewarded. Everyone loves snacks.

  1. Do we need to support mobile device and tablet usage? If we do, how should we prioritize what we build for a responsive app?
  2. Is the current navigation of the legacy app confusing? Do we need to change the information architecture of the new app?
  1. A Google Design Sprint is a full time job for a week. That’s great if you’re a UX practitioner, but our sprint participants had other full time jobs (running the products!). We needed to be sensitive to the sprint participants’ time outside their teams. We included this in our first sprint retro.
  2. Our users don’t think in the way that we the product team think. This became clear from the card sort and even in the interviews. It grounded our team in the old saying “You are not the user”.
  3. We formed new strategies for the app after this sprint. There were opportunities to reduce confusion of our app’s menu. We had no idea about some of the devices and browsers that specific job roles relied on. We were able to account for both of these things from the first initial deployment in May because of this sprint’s research. This proved the theory that you can go straight from an idea to making decisions in a week. Just like Sprint said.

Sprint 2

Sprint 2’s process:

  1. What problems do people experience when creating/editing/copying things in the current app?
  2. What are the different ways that our users perform a specific business accounting workflow? When do they do it? What problems do they have with it today? How could we improve it?
  1. This process forces a team to answer a question quickly; it doesn’t define what “question” is. While we answered a future product question in sprint 1, sprint 2 focused on finding a solution to a complex business problem. Before it gave us a solution it gave us a candid picture into user behavior and the business problems that went beyond users. We saw the current state of their world first-hand. It gave us direction. It gave us empathy. Ever since then, the team has used the “observe current state in the wild” method as a first step to understanding a problem (referred to as “ethnography” in research circles).
  2. When other teams participated they heard the same things we heard. They made their own conclusions about their products after hearing our results. The information we learned radiated to other teams and they were all the wiser for it.

Sprint 3

Sprint 3’s process:

  1. How intuitive is the experience of the other team’s app for technical users who are seeing it for the first time?
  1. We found our stride as a sprint team in sprint 3. The team finished all the work they committed to with less strain. Two days of whiteboarding and two days of testing helped the team a lot. We decided to give ourselves flexibility to test any day in the sprint if the opportunity arose. We reflected this starting in sprint 4.
  2. Spending six hours watching new users perform tasks on their own informed the entire year of our roadmap. I still get flashbacks of those moments in backlog refinement. They help ground me in the decisions we make for future development. I’m not saying Product Owners need to run tests, but the knowledge of what the Doers learn in this type of research is priceless and the information can easily be radiated to the PO.

Sprint 4

Sprint 4’s process:

  1. How do people use mailing systems in their marketing workflow today? What are their workflows around it?
  2. What problems do people have with current mailing platforms that we can learn from?
  3. What important workflows and features do we need to be able to support in the future for our two teams?
  4. What is the best way to structure user accounts, roles, and permissions in a new mailing platform based on the businesses we serve?

Sprints 5 and 6

Other team members starting Sprint Mastering in sprint 5. They felt confident running them after Doing in them.

  1. How do people currently perform a particular workflow and how should we build it in the new app?
  2. How should we adjust the prototype we created from sprint 2’s results?
  3. Do users really need “real-time” statistics data in our app? What do they define as “real-time”? When do they need “real-time” stats and when do they not need it?
  4. How far back do users look at stats in the current app, and how long should we keep stat data in the new app?

The journey continues

We started development with an informed backlog of ready work and the team went into “Get ‘er Done” mode.

Additional takeaways and thoughts for teams (read the top four in part 1)

  1. The process teaches the Doers of the sprint how to perform the best research and experimental Design practices. They can take that back to their teams and apply it on their products. My coworkers are better contributors because of the work they started in these sprints and the lessons they continue to apply today.
  2. Sprint Master is a tough role in this process. The Sprint Master coaches the sprint team in their work. It takes experience to create unbiased experiments and to lead teams in the right direction. This is especially true if this is the Doers’ first continuous learning sprint.
  3. The Sprint Master has to reduce scope of the questions being tackled. Especially if the team realizes they’ve committed to too much during the sprint. Keep this in mind, it will allow your team to adjust goals with agility and get a workable result without completely failing in-sprint.
  4. This process can work for teams who aren’t dedicated full time to the sprint work, but be sensitive to people’s time and workload. You may need to change the process around like we did to make it work for the Doers.
  5. If you have someone who can act as Sprint Master, give it a try. Experiment with these sprints while having an open mind and flexibility. Bring your assumptions to the table. You’d be surprised what you think you know and what you have no idea about by answering questions in these sprints. You’ll come to rely on the insight you get from these sprints. If you don’t have someone who can act as Sprint Master, the books and resources mentioned above can help get your team there.
  6. Boy are we glad we starting bringing snacks.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store