Build It, Break It, and Repeat: The Yammer Hit List

Ryan Braastad

What’s your favorite city? …New York …Paris …Tokyo …San Francisco?

We love our cities for the character, the layout, and the feel they bring to us. Urban Planners make the strategic decisions that mold the very cities we live in and love, improving the effectiveness of a community’s infrastructure and land use. They need to consider a huge number of issues, enforce chosen policies, and take input from many sources such as local government, businesses, and—most importantly—the residents, before any major changes are made.

This isn’t easy to do.
The great city of Yammer has many wonderful features. As city planners, the product team needs to consider the many intricacies, buildings, layout infrastructure, their uses, and who is using them. All things age, and often need to be upgraded or remodelled… Maybe a building’s location doesn’t work as previously placed, maybe roads need to be widened, parks renovated? When this is the case with Yammer, our urban planners need to get to work.

There can be many benefits to restructuring a city like Yammer:

• Creating better experiences (for users)
• Building new efficiencies
• Decreasing technical debt (for engineering)
• Saving money
• Improving speed and velocity

So how do we go about changing and removing features that have impact to thousands of companies and upwards of nine million users? Moreover, how do we account for the users or internal stakeholders that are attached to them? This is our four-part process for dealing with what we call the “Yammer Hit List”:

1. Analysis

Since we’re a data driven product organization, we have the advantage of reviewing the specific impact of individual features. If a feature fails to drive successful core metrics such as increased engagement or user retention, and is used by a small subset of users: see you later! It’s usually never this straightforward though: we need to look at paid user engagement, and not just all time usage, but also over the last few months. In addition, we run everything by key departments in the org (Engineering, Customer Engagement, Design, Marketing) to make sure we’ll be simplifying the product or decreasing our technical overhead but not detrimenting the product by taking out something our customers love. In the final part of this step, we pull together defensible reasoning to justify the change. If we can’t justify “why” this removal should happen, we halt the process here.

2. Coordination

Once we decide to move forward, we will communicate and coordinate with all of the relevant internal teams. Typically it’s the customer facing roles such as our Sales, Community, Customer Engagement, Partners and Support teams that we will need to work closely with to discuss the process, roadblocks, user synopsis for impact, analytics and timing. In addition we’ll work with our customer champions to test the waters. At minimum, we try to give four weeks’ notice to prepare for the change, but depending on what we anticipate the impact is for our customers, we may give upwards of two to three months.

3. Preparation

Next, we pull together the broad communications that will go out to our partners and customer base. The anticipated impact of the removal will drive the cadence of communication. The bigger the feature, the more messaging and change management resources created. In these communications we typically reference the subject, the current state of the feature, timing, and reasons for the change.

4. Removal

Once all internal parties are ready, educated, and prepared, we communicate externally, executing on our plan. Typically we will start with our customers. A key advantage we have in Yammer—in particular our Yammer Customer Network (YCN)—is that we get to work with our customers, hand in hand, addressing concerns, questions, and gaining critical feedback. We often find that a network of thousands of smart users are much better than a few internal teams, enabling us to learn, iterate, and provide better assistance in the future. The best part is, these conversations act as a knowledge repository for future changes. Once the date arrives, we work with our engineering team to make the necessary change.

Over the past few years we have removed dozens of vacant buildings, and made countless changes to improve the look, feel, and engagement in the city of Yammer. The product team needs to make difficult decisions every day, and because the decisions we make account for every user, very often we are making tradeoffs to guide Yammer to be the best possible product for the most number of people. As hard as we try to only build things that are useful for everyone, sometimes needs change, priorities change, and users change. So we change.

In a companion post, Yammer Product Manager Kevin Davis discusses why features get removed from Yammer, and why it’s important.

Ryan Braastad is a Senior Manager of Enterprise Strategy at Yammer. He is as adept at enterprise strategy as he is at shredding the slopes in Stowe, Vermont.