A recent Slack change prompted conversation in my circles that echo some of the writing about Twitter as it was beginning its precipitous decline. To wit: sure, we don’t like these changes, but we’re early adopter or excessive adopter or otherwise not representative of the mainstream user so we should suck it up and stop complaining.
While it’s probably true that a randomly selected Slack user is much less active than me… I like to think the idea that heavy users aren’t the design target is wrong, or at least not-always-right, on two fronts:
- The excessive user cares a lot more about the design than the non-excessive user because they’re using it a lot more
- The middle-of-the-bell-curve average user is less influential to purchase decisions than the far-to-the-right excessive user
The first one of those ideas… I’m pretty sure it will hold water. It’s excessive users that demand the weird stuff after all, using products in tasks they weren’t intended for. As an excessive user of Slack, I am a champion for using it in my organizations, maybe even in ways that aren’t optimal fits. But the second idea, well, that depends.
Like many other product managers, I’ve over-satisfied the excessive user. After all, they’re engaged! They make time to talk to you, they’re trying to do the things you imagine need doing, they’re interested in the same things you’re interested in. They’re a champion of your product within their organization. This can be ideal when that user is also the target buyer, or heavily influences the buyer. When you’re doing something new, these users are the brave pioneers who actually do drive budgets and select products. We once landed a new product in three global scale banks largely by doing what the two consultants that were helping those banks wanted, and it was all bleeding edge feature work. Those features are now table-stakes bullet points in a Gartner magic quadrant, of course, and therein lies the rub.
Sooner or later, a successful product crosses the chasm — within a given organization it’s used by a lot more people, there’s a lot more organizations using it, and the body of champions becomes relatively smaller (even though it’s growing too). That leads to the target buyer becoming more distant from the champion, and their interests. Gatekeepers become part of the picture, which aids the use of bundling by larger competitors. One might argue that at this point the champion no longer matters to purchasing decisions at all, but that’s not true. The actual problem is that a different champion is now the proper subject of product management interest.
- Landing: When you want the new product to be used, its users are the champions.
- Expanding: When you want the existing product to be used for new projects, its users and its administrators are both champions.
- Defending: When you want to maintain the product’s footprint against a bundled competitor, the administrators are the champions.
Administrative features like integrations with other products, management-by-API, fine-grained RBAC, and compliant data management become the differentiators that matter, while day-to-day usability takes a back seat. The funny thing is, this pivot unexpectedly destroys usability. You might expect it to lead to a touch of stagnation in usability, but that’s not the outcome: instead, you get a train wreck. Why? Elizabeth Ayer has a great answer in this blog post: the software must keep moving, but no one wants to put their highly productive star product on a starvation budget. So there’s product team looking for work, designers doing design, people looking to make a mark, and none of them are talking to users any more because the customer contacts are now administrators and gatekeepers. Are they reducing quality? Who even knows how to measure that? Are they hurting product sales or renewals or other metrics? Probably not, because that’s being driven by champion administrators instead of champion users now.
And that’s whycome there is opportunity for a new product to approach the problem differently in the future.
Monkeynoodle.Org 