Would you consider this success or failure?
Dealing with unexpected feature use cases from a product leadership perspective
Imagine this situation: you’re a product manager and your squad is responsible for solving a problem. You work together brainstorming solutions, lean hacks to validate the source of the problem and what you could build to solve it. You decide on an MVP, a small set of functionalities that you believe will test if the issue is fixed.
The team builds it, couple weeks in and it’s ready to be tested in the wild. Deploy it to staging, QA it, make sure it doesn’t break production and you’re ready to push it to live.
A few weeks go by and you’re keeping an eye on metrics, it gets significant traction! People are actually using it. But… they use it for something else. Something you 1) didn’t expect to be used for and 2) maybe thought it could happen but hey «it will be an edge case». Except now it isn’t.
The problem your squad aimed to solve, isn’t solved yet. People are actually using what you built, maybe even enjoying it, but the main issue is still there…
Would you consider this success or failure? If you were the product leader of this PM would you commend her on a great work, or offer feedback on how the problem wasn’t solved therefore the feature is not successful yet? Or maybe both (which is paradoxically interesting)?
And now the million dollar question: would you iterate and improve what you launched and change to a V2 that *might* solve the issue, but risk killing something people are actually using OR go back to the drawing board, design more options to test while leaving your unplanned feature in production? If you choose #2 (which seems more logical) isn’t that going against continuous iteration & improvement? Against problem-solved as success measurement rather than feature shipping?
How (I think) this happened with Slack’s “Set a status” 🚌🌴 🏡 (at least in my company)
Now I don’t work at Slack (and disclosure: I am a complete fanboi of their company, their products, their culture and pretty much everything they do), so all I’m writing below is an assumption (and if you do work there and read this, or even better if you were the PM of this feature, I would love to know if any of it is true) but I can’t stop wondering if this was exactly what happened with “Set a status” feature.
Launched in April 2017, “Set a status” aims to let your “teammates (…) get a quick read of what you’re up to — without cluttering your conversation” as the launch blogpost says. They even got the API to integrate with other apps to automatically update the slack status. All to let others know what you’re up to, with no hassle.
Except this is not how I’ve seen this feature used. I want to reinforce this is observation from my company only. Let’s get into data: in my sample we have 154 slack users (so we could say there is statistical significance on the observation). 55 of them display a “Status” in front of their name 100% of the time. That is 36% of all our slack members using the feature. I would call it a major success in feature adoption. Even if our company was a complete outlier and the average adoption was 3x lower, that would still be more than 10% of the user base engaging with a feature. Do you realise how rare and magical this is for any PM?
The thing is, only 4 out of the 55 are actually using the “status” emojis with the original intent:2 are 🚌 commuting, 2 are 🏡 working from home. One of them has the 🌴 vacationing, but he was in the office on yesterday so I am assuming he just likes palm trees. All of the remaining 51 (33% of the company) are using the “status” as way to personalise their own name, make themselves unique, show their own digital personality. And as you can upload your own image or gif, everyone takes it to a whole new level.
It actually brings back the good old memories of MSN Messenger and the expressive array of nicknames, handles and emotional explosions of sentiments. I wouldn’t be at all surprised if defaulting to this use case is a trip down memory lane.
But let’s get back to the original goal of using Slack’s example. Again assumption here, but let’s say the squad’s job story was:
When I am doing something that might affect my responsiveness on slack, I want to easily communicate it to others, so they can manage their own expectations.
The team needed to build something where anyone sending a message and expecting a quick answer could readjust expactations depending on external variables (someone on vacation, commuting, on a meeting…). So the team built it. And people started using. A lot. But not to let others know what they’re doing, but who they are. So the problem is still there. Yes people can use “status” to solve it, but they don’t see the feature as the solution to solve it, as it already occupies its place: an extension of you on slack. And I wouldn’t trade that just to let others know I’m on a plane. Again, this is based on observing my company use Slack, and my own relationship with the feature. I know of companies who enforce rules and etiquette so they might actually use “Status” properly.
So if you’re the PM of “Set a status” (or even her PM lead), would you consider it successful OR a v1 that still has room to improve? Would you iterate until the problem is solved but risk killing something 30% of people use or would you go back to ideation and build something new?
Do you know any other features or products going through the same? If you enjoyed bring on some 👏 and share with others so they can contribute.
