Gamifying Context Sharing

When a product has been in active development for many years, like Mingle has been, it has hundreds of features and no one knows all of them.

A new team started working on Mingle when the product was moved from San Francisco to Bangalore a year ago. There was no reliable way to transfer years of context to a new team. At the time, we decided it wasn’t necessary — as long as we had enough context to work on new features, we were okay. So while there were onboarding sessions on broader aspects like architecture, outstanding tech debt and product direction, we didn’t invest time in exploring every feature.

Occasionally, however, we’d get a customer ticket through our support channels to answer a question or solve a problem in a feature we didn’t even know existed. Thankfully, the code is clean and we have some help documentation to quickly get some context, and respond to the best of our ability.

So it wasn’t a burning issue that we didn’t know everything. But it’s nice to know what our product offers, rather than be surprised by a customer’s query. I pondered over what might be a painless way to do that. That’s when I thought about having everyone participate in a quiz. Thus, the Ultimate Mingle Quiz was born.

Who participated?

All the developers and the tester, two product support specialists, and a sales executive.

Anish (a product support specialist) and I (the product manager) prepped and ran the quiz.

How did we form teams?

Ahead of the preliminary written round, we came up with a fun way to form teams of two. We didn’t want folks to pick their own teammates because there were some folks with an obvious advantage.

We made it a jigsaw challenge. Everyone was given pieces of a 16-piece puzzle and a roll of tape. The completed picture was a screenshot of a view on Mingle.

We filled in the names of folks in this table in the order that they completed the jigsaw.

This was interesting because a participant could still wait for a teammate they were keen to pair with, but they’d have to time it just right.

What did the questions cover?

We had a preliminary round where all teams participated. Four qualifying teams made it to a more challenging final, held a few weeks later.

Through both rounds, we covered a whole range of topics — from little-known features to key customers to history of the product to eccentricities of the codebase. Given the participants each played different roles in their day job, there was something new for everyone to learn.

We had a challenge in the final round where the teams had to respond to made-up support tickets. Points were given based on the quality of the solution provided, as well as the language and tone they used in their response to the “customer”.

What did we learn from having this quiz?

1. A little competitive spirit gets everyone going

Now that the element of competition was introduced, everyone was really keen to learn as much as they could in preparation for the quiz. For the first time, we saw everyone poring over the Help documentation, trying out features they’d never seen before, and badgering the Support team with questions.

2. Developers aren’t the real dons

We tend to think the product team who works on the codebase everyday would have most context and be at an advantage. What we learnt, however, was the strongest contenders were the people who talk to customers everyday — Sales and Support.

3. Great for product manager onboarding too!

This wasn’t just a great learning experience for the participants — I learnt a ton from just prepping for the quiz. I’d been a long time user of Mingle and was product manager for about 8 months at this point, but still didn’t know everything about it. Anish, who deals with customer tickets on a daily basis, knew a lot more about the product than I did, and came up with challenges and questions that I’d never imagined. This was a great way for me to learn more about the product as well, and feel a lot more confident about it.

4. Working on a product is like riding a bicycle…

..you never really forget it. This was proven by David Rice — MD of ThoughtWorks Products, who was a developer on the Mingle team many years ago. He and his teammate went on to win the whole thing, not only because he remembered what he’d built many years ago and is aware of features built since, but also because he applied the fundamental concepts of the data models and the product philosophy to make intelligent guesses.

Would I do this again?

Absolutely. I think gamifying the process of learning made it feel like a lot less work for everyone. I believe there’s even value in doing this again for the same team, so that we discover more about the product. I’d recommend this highly to any team that’s taken on a large product with lots of past context and no single source of truth.