Product Teardowns at Yammer
31 March 2016 ‧ 5 min read
At Yammer, we believe that product curiosity and product sense are two of the most important traits of a good PM, and that these skills must be continuously exercised. That’s why every Friday afternoon, the product management team and other interested folks from the design, research and analytics teams sit together for an hour and “tear down” an interesting mobile or web app. By “tear down”, we don’t mean “criticize”, but rather investigate and reverse engineer the thinking and experience underlying a product. This gives us inspiration to improve our own product.
In our teardowns, we don’t just look at directly competitive products, but instead cover a wide variety of apps. Some are new and exciting (recent examples include Quartz News and Facebook Live Video), while others address problems similar to the ones we solve at Yammer (typically in the communication and team collaboration space). Our goal is to build an understanding of how the app onboards and engages users, how it solves the users’ problems, and what the company’s underlying strategy seems to be. In addition, we always ask ourselves what we can take away from the app for Yammer. This might be something as simple as a nice UI interaction, to broader ideas around user onboarding and re-engagement.
How we do product teardowns
Our teardowns are a fairly informal affair. We gather in a conference room, often with a bottle of wine (it is almost the weekend, after all!) and usually start by installing the app or creating accounts. One person typically projects their screen, but most of the attendees also try out the app on their own. Since many of the apps we tear down have a social component, this has the added benefit of being able to directly try out and test those interactions, which is difficult to simulate when looking at an app by yourself.
One of the first things we evaluate is the user onboarding experience, specifically, how the value proposition and the UI of the app are conveyed to the user. To do that, some of us sign up for the product during the teardown meeting, so we can experience the complete onboarding experience. We try to understand not only what we are seeing, but also why the product was designed as it was — what were the goals and which tradeoffs were made.
After the onboarding, we experiment with a broad a set of functionality of the product. We try to observe the interactions, whether we intuitively understand how the product is meant to work or whether we are constantly surprised by outcomes we didn’t expect. We also try to identify which UX paradigms the app adheres to and which it deliberately breaks. We look at whether interfaces are simple or complex. And lastly, we try to see how the product re-engages users (e.g., through push notifications, emails or an in-product notification mechanism).
In the second half of the teardown we turn to strategic questions: Why did the creators of the app build it? What goals were they trying to achieve, and what hypotheses are at the center of how they are trying to achieve it? Who will use this and why? What tradeoffs were made? Do we think the product is going to be successful and why? How could that be measured?
The teardowns have an open, ad-hoc discussion format where people call out things they noticed, or raise questions that come to mind. At the end of the hour, though, we wrap up the discussion by asking some pointed questions so that we can both capture a summary of what we learned and also think about what we will do with this information.
Specifically:
- What did we like and enjoy about this product? What “wowed” us?
- What questions and doubts do we have?
- What other, broader observations did we make?
- What can we take away from this experience for Yammer?
Some examples
To provide a taste for our teardowns, here are a few (condensed) examples:
Quartz News
Quartz News is an app that delivers news content in the form of a chat.
What we liked: The Quartz app does a great job at onboarding users. In exchanging messages with the app, users are educated about how the app works and can set their preferences, such as notifications. It is extremely effective, and users get to the content of their first news within 10 messages. We also really liked the simple, slick interface (with just two different screens). Also, using the messaging paradigm that users are already familiar with helps them intuitively grasp how the app works.
Questions we had: Does the fact that the user has to make a lot of yes/no decisions lead to “decision fatigue”, going against the “snacking” concept that the app promotes? How effective and quick are users at scanning the content of messages? Is that more or less effective than the traditional headline / article format?
Broader observations we made: Whether the conversational model is a viable way to deliver and consume this kind of content is a longer-term strategic question that will probably take a longer period of time to get the answer to.
Anchor
Anchor positions itself as “true public radio” — it is an app that allows users to record and broadcast short audio clips, called “waves” and respond to other users’ waves with their own waves.
What we loved: We think that Anchor is positioned in an extremely interesting space, since there are a lot of “dead times” like commuting etc. where audio is the type of content that is easiest to consume. From a product perspective, we thought that the product onboarding and user education was great, getting the user to create their first introductory wave in the process. We loved how Anchor, as an audio centric app, makes extremely good use of sound throughout the app, using aural feedback for a lot of interactions.
Questions we had: We thought the product decision to encourage recording by holding the phone to your ear was interesting, and we were wondering whether that increases or reduces friction to record — especially given that so few (particularly young) people actually talk on their phones anymore.
Broader observations we made: The more traditional format in the audio space is podcasts, and one of the biggest challenges with podcasts is discovery of new content. For Anchor, being the content aggregator could help solve the discovery problem, but could also lead to challenges. For example, Twitter, which similarly aggregates short-form content, still has not fully solved the problem of discovering the most relevant content, particularly for new users.
Conclusion
For the Yammer product team, engaging in regular product teardowns is a way to stay on top of recent trends, hone our product and UX skills, and engage in a debate around product strategy. It helps us challenge our assumptions and ensure we get some fresh perspectives on how to solve users’ problems. Last but not least, it is a fun way to discuss a topic that everyone on the Yammer product team is passionate about: How to build successful, engaging products that create value for the user.
Further reading
For more ideas on how to do a product teardown by yourself, read Julie Zhou’s excellent article “How to do a Product Critique”.
This is a great resource that explores user onboarding in a lot of depth: [http://www.useronboard.com/]
This article was originally published on the Yammer Medium blog