This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.
I bet we can agree that too much complexity can be ruinous for a product. Yet why do so many products suffer from this? The root of the problem lies in that one additional small feature doesn’t necessarily make a product a complex one, just like one gray hair doesn’t make someone a gray-haired person. But when change happens gradually, we fail to realize it’s happening until it’s too late. As a result, at any given point in time, we are disproportionately more incentivized to ship features rather than to keep our product simple.
With Yammer having been around for over ten years, it’s natural to accumulate excess complexity over such a long period of time. As a Product Manager, I'm aware of the consequences that complexity brings. And as a team, we're focused on simplifying and modernizing our product.
One way we are doing this is by leveraging the Office 365 suite for anything that’s not core to our value proposition. Last year, for example, we removed Yammer notes so that we could leverage Word Online. More recently, we decided to leverage file management from SharePoint. It doesn’t make sense for Yammer to develop and offer these services that add to our product complexity when we have world-class products who could otherwise solve that need.
However, we’re conscious that the effort should not only be targeted towards removing features. As product managers, we must also act as guardians to prevent complexity resulting from new features that creep into our product. But here's the challenge: after releasing a new feature that impacts our metrics in a slightly positively way, if we were to just look at that snapshot in time, it would make sense to keep the new feature. We are deciding between a slightly positive impact or no impact at all. But we must zoom out and look at the whole movie, rather than the individual snapshot of time. It’s the accumulation of all these small features that individually add to our metrics but together could do more harm than good.
An example of this challenge came up as we were building “rich text formatting” in Yammer. We were adding bold, italics, bullet points, links, and numbered lists to the posting box. The bulk of the work was in laying the foundation. After we had the infrastructure in place, we could add all sorts of styles like emojis, quotes, header 1 and header 2, and underline. We decided to start with just the basic five: bold, italics, links, bullet points, and numbered lists.
It’s very tempting to release more features when the cost of adding them is low or null.
In this case, it’s tempting to release rich text formatting with as many styles as possible. The cost of including more styles is almost null, and more features would definitely “wow” users and make them somewhat happier.
Now let’s look at the snapshot in time and then see the whole movie.
We start with the basic five styles:
Two months later, our eyes have become used to these styles, so we decide to add one more style because it’s almost free. By looking at the snapshot it makes sense to add this option, since more styles will likely lead to more usage at least by some small amount. So we added one more:
Soon it snowballs until we end up with a laundry list of styles...
The end result is an agglomeration of components that drown the most valuable ones in an ocean of secondary ones that add little value.
The takeaway is not to block features from being released. Instead, it's about being extremely intentional and raising the bar high enough so that the benefit of every new feature surpasses the hidden cost of creeping complexity.