Facilitating collaboration on a new product

Lots of people seem to agree that outcomes are important. But sometimes, before a team can achieve an outcome, they just need to figure out how to work together.

I was part of an agile team working on a new product that lets you insure everyday items like computers, cameras, and bikes. The people funding the product mapped out how they thought it would work with sticky notes, then hired a large number of people to build it.

How I helped

Many team members had no experience with agile development or were completely new to consumer-facing products. Here’s what happened when we got started:

  • Developers were being asked when it would be “done,” but didn't have any meaningful information (like user stories or acceptance criteria) to go on

  • Product owners wanted to write user stories and acceptance criteria, but didn't know specifics about how the product would work

  • Designers were brought in several sprints late, and hadn't designed how the product would work or look

"How long will it take you to build this?"

There was a lot of friction. The overall picture of the product was helpful for setting vision, and leadership understood that an agile approach meant their vision was just a starting point, but we needed a lightweight way to understand how the product would work so we could start breaking it down into chunks we could design and build.

I made an iterative series of object-oriented maps, showing details about the experience, without being too prescriptive about how we designed or built it. These maps gave our team shared understanding of what we were trying to build, and made our conversations much more fruitful.

I created a low-fidelity, click-through prototype of the web app to keep everyone on the same page.

I created a low-fidelity, click-through prototype of the web app to keep everyone on the same page.

Next, I began coaching team members on how we could work together more effectively, giving us space to explore and achieve our desired outcomes:

  • I encouraged business analysts and developers to work on integrations while designers tested prototypes

  • I guided the team through breaking the work into small user stories we could finish in a sprint and coached them on writing flexible acceptance criteria that allowed for learning

  • I established a regular cadence for getting our experiments in front of intended customers—giving the team a clearer picture of who we were building the product for

The results

I helped our team see how we could work together and fostered a product mindset across disciplines. We went from from being stalled sprint after sprint to shipping pieces of a testable, working product sprint after sprint. We went from having no contact with customers to being reminded of their needs every day.