Twitter’s #fixreplies Boo-Boo

Update: Twitter founder Biz Stone has posted exactly the explanation we (all 3% of us) wanted, and I completely understand the hurry to rush out without fully thinking through the loud ramifications of the squeaky 3%. Kudos.

You’ve probably heard about the Twitter @replies fiasco by now.

Marshall has a good recap and explanation of the “fix” they’ve implemented. If you thought the feature was hard to understand before, the subsequent changes have made it even more difficult to understand.

Personally, I have to pile on the dis train. I’ve always touted the discovery feature of following all the @replies; I used this feature a lot–to find new people and find people I know (or know of) on Twitter. It helped foster and grow the community. Plus, it’s hard cheese for early adopters who have used the service for a long time before the n00bs overran it.

No early adopter, no Twitter.

As a product manager, I’ve followed the story with interest because it has been an interesting case study that is directly applicable to our work on Connect and the recent redesign.First off, it’s always tough to remove features, even if usage percentage is low. It’s product management’s job to make sure this doesn’t happen lightly. Once you release a feature, you have to assume it’s being used by someone, and that someone will miss it.

Frankly, you have to question why you built it at all if you’re going to pull it, but it’s impossible to avoid this conundrum.

Case in point, we used to provide a group activity log that wasn’t really group activity, but rather, the collected activity of the members of a group, not constrained to activity within the group. Personally, I thought this was of little value and cluttered up the UI.

But, when we removed it leading up to the redesign, one of the groups came out of the woodwork to ask why. They had found a use for it, albeit as a workaround for a gap that we needed to address with a real feature. Still, we should have looked more closely at usage before cutting it. The good news is that we could replace their use with a real feature.

In this case, Twitter initially bailed on @replies and didn’t say why, aside from, it’s confusing the n00bs. Typically, wouldn’t you address that with documentation?

I would know. We have huge issues with documentation because we just haven’t had the time to document every feature properly. So, I can relate, but still, in this case, I think documentation could have done the trick.

Then, we find out that there were technical architecture issues behind the change too.

This is valid reason for the change, but you wonder why they didn’t lead with that as the root cause. Most users can understand that, but at the very least, it’s more palatable than just removing a feature because it was confusing.

Another case, we made a change that removed the ability to post to multiple groups. This was due to an overhaul of our data model and due, in part, to a particular use case.

If you posted an item to a mixture of public and private groups, people who did not belong to the private group could not see the post. The could see the link to the post, but clicking it silently failed and redirected to a main page.

Plus, there was no way to tell from the posting form which groups were public and which were private.

When we designed the change, Anthony did an analysis to determine how many posts were affected. He found a small number, less than 10 I think. So, we made the change, and I documented it and the reasons why.

During beta-testing, we were asked why the feature was gone, and I had a real reason to give them. They accepted its lose and understood why. Easy, breezy.

Not so with Twitter, which is a bit odd, considering how open they have been in the past about their architecture concerns. I suppose with more users and more security concerns, they didn’t want to reveal architectural specifics, which makes good sense.

Even so, vaguely referring to an issue without explaining it or why it’s an issue isn’t very satisfying.

Finally, they caved and pretty quickly too. The resulting “fix” turns out to be even less intelligible than the original feature.

It also makes me wonder if the fix they released is just a janky band aid that will lead to more issues in the not so distant future.

All this muddies the water and leaves the disgruntled users feeling, well, disgruntled.

With a change this significant, assuming the architectural issues were substantial and could have negatively affected the entire Twitter user base, I would have expected more backbone from Twitter, especially in the wake of the recent OAuth story.

Something like:

We know it sucks, and we hear you. Trust us, it’s for the best. We’ll bring it back in some form soon.

Not that listening to your users is bad, it’s not, but you have to balance what they want with the effects on the overall product and everyone’s experience with it.

And in this case, you’re hitting the squeaky wheel sweet spot, i.e. bloggers, so they had to expect a loud revolt. Right?

The message here is if you make a change or remove something for a really good reason, stick by your decision and share the reason in as much detail as you can. I’m reminded of omelets and eggs.

Anyway, it’s very easy to sit here, judge and critique. I just thought I’d add my thoughts, since I’ve had the same scenario a few times, on a much smaller scale.

What do you think, of the feature removal, of the way it was handled, of product management tips in general?

Sound off in the comments.