Just Say No to Mixed Up Chameleon Products
On a shiny green leaf sat a small green chameleon. It moved onto a brown tree and turned brownish. Then it rested on a red flower and turned reddish… When the chameleon was hungry, it sat still and waited. Only it’s eyes moved — up, down, sideways — until it spotted a fly. Then the chameleon’s long and sticky tongue shot out and caught the fly. That was it’s life. It was not very exciting. But one day the chameleon saw a zoo!
The chameleon is a remarkable lizard. It can move its eyes in two totally different directions, shoot its tongue out at speeds up to 8500 feet per second, and change colors on demand. Yet in Eric Carle’s beloved children’s tale, The Mixed Up Chameleon, the titular character isn’t content to just be a chameleon. As he enviously wanders the zoo, lusting after the fur of the polar bear, the wings of the flamingo, and other covetable features of the inhabitants, he begins to change. Slowly the chameleon becomes very mixed up, a little of this and a little of that, incapable of performing any of his own remarkable abilities. When he is unable to catch a passing fly, he realizes that he was pretty great just the way he was, and he wishes to return to his original form.
The Mixed Up Chameleon is typically read to children as a way to teach self esteem, but there are also valuable lessons for product professionals as we decide what features to build, and more importantly, what features to say no to. In fact, the most important job of a product professional is to decide what not to build. It’s not enough to tell our stakeholders “maybe” or “later.” The only word is “No.” If we say yes to every customer request for a new feature, it’s easy to assemble a mixed up chameleon product, confused about it’s identity, unable to do anything particularly well and destined to confound our users.
Mixed Up Chameleon Products in the Wild
Let’s look at some examples. First up, Microsoft Teams. Microsoft markets Teams as “The hub for teamwork in Microsoft 365.” It was built on the backbone of Skype for Business, and actually, its virtual meeting functionality is better than many other collaboration tools I’ve used. However, in true mixed up chameleon fashion, Microsoft wasn’t content to just create a great chat and video conferencing platform to compete with products like Slack. Teams is also a document repository that automagically syncs with SharePoint. Sometimes. Usually. Assuming you can remember the name of the team (or is it site?) were you uploaded the file. Hopefully, you didn’t upload the file to one of the pseudo-teams created for every meeting you’ve ever participated in, because then that file is truly lost forever. If by some miracle you can find the file (search is basically useless, so this can be a herculean endeavor), you can edit it with a built-in Microsoft Word, PowerPoint, or Excel editor without ever leaving the Teams application. Haven’t you always wanted to build a pivot table within your chat application? Don’t ask me how permissions for documents are managed. I’ve been working with Teams for seven months and still can’t figure it out.
Microsoft Teams also has a built-in wiki editor, because every user wants a limited-functionality text editor within the same product as a fully-functional Word application.
Did I mention Teams also integrates your Outlook Calendar, but has a completely different interface for managing calendar events than Outlook itself?
There are at least four ways to initiate a video call within Microsoft Teams. At least. I wouldn’t be surprised to learn I missed a few.
You want intelligent notification settings on a team or channel level so you only get alerted about conversations you care about? Ha! Good luck! Teams will, however, email you by default every thirty minutes if you dare to not empty your unread queue 16 times a day.
My team regularly jokes that Microsoft Teams is where information goes to die. We have Slack and Teams running, and almost all important conversations happen in Slack because nobody has the time or patience to figure out the Frankenstein of a product that is Microsoft Teams. Lord help us when corporate IT puts the hammer down and takes away our Slack.
Lest you think I’m only hard on Microsoft, let’s also talk about the iPhone. An iPhone is, first and foremost, a phone. Yet people feel the need to write numerous help articles on how to use an iPhone to make a simple call. This one from dummies.com lists seven different ways to place a call using the device, and that doesn’t count emergency calls or installed applications like Facebook Messenger, Signal, or others. Seven! Why?! We’ve bolted so much additional functionality onto our phones we no longer know how to use them for their original purpose.
How Do Mixed Up Chameleon Products Hurt Our Initiatives?
Mixed up chameleon products are no longer true to their original product vision. They become a little of this and a little of that and therefore lack the clear purpose they were initially built to serve. Their diluted product or organizational mission makes it challenging if not impossible to rally your team around a shared vision for how your product will make people awesome.
A large feature set stresses the capacity of our product development teams. It hinders their ability to limit work in progress, crippling the ability to focus and deliver. Feature bloat contributes more technical debt and maintenance requirements, damaging your ability to quickly deliver your next big innovation.
Saying yes to new features is inherently risky. Features are like puppies. There’s a reason you don’t adopt every one from the pound. There are no small features. Every feature, like a puppy, requires long term attention and support.
Do you know how to use every smart setting on your microwave? Can you manually set the power level to 50%? Some products hide infrequently used feature complexities behind preferences or configuration settings, but too many customization options can quickly overwhelm a user, your support team, your engineers and lead to death by preferences. The feature may be hidden from a default interface, but it still exists in the code, the configuration screens, your onboarding process, your customer support training guides, and the nightmares of your dev team.
So Why Do We Build Mixed Up Chameleon Products?
In short, because complexity sells. High end devices and tools with endless lists of fully customizable features and every integration imaginable seem like a great deal on paper. Don Norman, renowned user experience designer, says it best in his article Simplicity is Highly Overrated:
Sorry: it is the apparent complexity that drives the sale. And yes, it is the same complexity that frustrates those same people later on. But by then, it is too late: they have already purchased the product.
However, the Software as a Service (SaaS) model tilts this conversation back in favor of simplicity. As more and more of our software products shift to recurring revenue subscription models instead of one time purchases, the overall user experience of a product becomes a critical component of maintaining user engagement and preventing customer churn.
How Can We Avoid Creating Mixed Up Chameleon Products?
First, learn to say no. Practice it in front of the mirror. Use the funny gifs from this article. Paint it on your forehead or put a post it note on your monitor. Spend a weekend with a toddler (my two year old has this No thing down pat). Do whatever it takes to master the art of saying no.
Focusing all our efforts on building new features results in a product that is miles wide and inches deep. To quote Mark Zuckerburg, “You can’t just 80/20 everything. There have to be certain things that you just are the best at. Things where you go way further than anyone else does, to establish this quality bar and have your product be the best thing that’s out there.” Before you move on to a new market, a big new feature, or adding another product to your suite, make sure your product is the best at something first.
Next, focus on building products that meet real user needs, not perceived customer wants. My four favorite product discovery questions whenever considering a new feature are:
- Will the user buy this or choose to use it?
- Can the user figure out how to use this?
- Can our engineers build this?
- Can our stakeholders support this?
The answer must be a resounding yes to all four before I’ll even consider adding it to my backlog.
If your users truly need you to build an integrated suite of tools, clearly define the boundary of each. Give each product line their own distinct mission and vision statements for the teams to rally around and own. Then, invest in a comprehensive Design Language System (DLS). A DLS makes your suite feel more cohesive by providing guidelines on a consistent look and feel for user interface elements. The consistency makes your products easier to use and navigate. A DLS is typically supported by a front end component library of reusable interface elements to speed development efforts. These are well worth the time and effort to build. The earlier you can establish a design system and component library, the better. Retrofitting a large legacy product with new components can be an arduous task.
Finally, analyze your usage data regularly and don’t be afraid to kill unused features. Sometimes, we need to admit defeat and remove the maintenance cost associated with keeping old features on life support. Just like Eric Carle’s chameleon didn’t need 5 sets of feet / flippers, your product can also live without a few extraneous features.
I Wish I Could Be Myself
The chameleon quickly learned that being a little bit of this and a little bit of that was far inferior to being the best version of himself he could be. Our products can be the best versions of themselves too, they just need a little help saying no.
Do you have additional tips for preventing mixed up chameleon products? What mixed up chameleon products do you love to hate? Have suggestions for additional product management topics inspired by children’s books? I’d love to hear from you on these topics and more.