One of the worst work architypes that I have experienced over my years as an educator, a developer, and a Product Manager is one that mostly goes unnoticed. It might be your coworker, someone in another department, or it might even be your boss. These people don't mean any harm, and they are trying to do their best in speaking up for the company and the product. However, in my experience, whatever the problem is, Henny Penny will make things so much worse.
Channeling Chicken Little
I've experienced this problem quite a bit, so I'll just assume that this is a problem that many companies experience. It begins when one or more members of a team seem to channel the children's story character, Chicken Little. Maybe it's just the former Elementary school teacher in me, but it seems like they should have learned this lesson long ago. However, some wires got crossed in kindergarten and here we are with a full-on poultry possession.
For those unfamiliar with the story, Chicken Little (or Henny Penny) is the story of a simple chicken who is just enjoying a day outside when suddenly an acorn falls on her head. This, of course, takes her by surprise and she begins to freak out. She gets the idea in her head that the only logical conclusion for why she got hit on the head is that the sky is falling. She then proceeds to run around, telling everyone she can find that "The sky is falling! The sky is falling!" She amasses an entire army of fowl who march with her to see the King in order to inform him that the sky is indeed falling. The story then takes a dark turn when they meet a sly fox who invites them all to his lair for dinner. He then eats all of the members of the party, bringing to mind the question of why this is a children's story.
Modern day Chicken Littles
Nowadays, a person can easily shift their mindset to that of Chicken Little. Someone at the company hears a piece of valuable customer feedback and misinterprets a feature request as a "do or die" situation. This leads to a somewhat expected snowball effect at the company as this apparently urgent task moves up to the product team. Leadership gets involved and speaks about how important this customer is, and therefore how important this feature is. Hands are wrung and brows become sweaty as the perceived implications of not building this feature begin to take on a life of their own.
Now any Product Manager could take this feature request and fit it into a timeline for the Development team to accomplish. I mean Customer Success, those in the C-Suite, AND an important customer are all asking for it. What else do we need to greenlight this process? So, the feature falls into a Sprint and internal work is hurriedly begun in order to draft the mockups and UI/UX for the request. Precious hours are spent figuring out what we can do to create this feature in the timeline that someone is sure the customer expects.
Other features are put on the backburner and the project is 'fast tracked' because the customer really needs it. Proper procedures are almost never followed during this process, so most Product Managers don't have time to gather requirements or even talk to customers extensively. The Development team rushes to get the feature built and tested, and then it is shipped to the customer. Everything is right with the world again.
A few weeks go by and the Product Manager decided to get on the phone with the customer to see how they are liking this amazing, must have feature. The expectation is that there will be a celebration on the other side of the phone as the customer gushes about how much work this is saving them. However, more often than not, the fanfare is markedly less than expected. Most of the time, the customer doesn't even realize that the feature is there. Yes, they did express a desire to have the feature, but they didn't really think it out and were just mentioning it offhand. This is a nice new addition to the product, but they probably won't be using it anytime soon.
Fool me once...
These sorts of situations bring to mind a quote by George W Bush
There's an old saying in Tennessee, I know it's in Texas, it's probably in Tennessee, that says 'Fool me once, shame on - shame on you. Fool me... you can't get fooled again'.
Truly, words to live by. Most Product Managers let a Chicken Little do this once and only once before they begin putting guards in place. Let's take the previous example and walk back through what could have been done differently.
- First of all, the very premise that one customer should completely take control of your product roadmap is troublesome. Putting more importance on the opinions of your highest value customers is fairly normal. However, the moment that you begin forgetting about everyone else just because one customer wants a feature is the moment that you go down a road that you can't easily walk back.
- The next issue with our previous scenario is that no one thought to reach out to the customer to gather more product requirements. This is a central piece of a Product team's process, and is important for a reason. Had someone taken the time to reach back out to the customer, further clarification on importance and requirements could have been found. If the feature perceived to be at DEFCON 1, then you only have one chance to get it right. So why not take a few extra days to gather requirements from the customer and involve them in the product-making process.
- This is also tied to another problem with our example story, processes weren't followed. Now, I'm not advocating for rote following of processes just for the sake of following a process. However, plans and procedures do have a place in making sure that quality isn't sacrificed for speed. Even if the feature was highly important to the customer, what went out the door in the above scenario probably wasn't the most well thought out. Taking that extra week or two to strategize and plan for the future can make a huge difference when facing a task that could (or could not) make or break a customer relationship.
- No planning was done as to the cost/benefits of the feature outside of the single relationship that was in 'peril'. Every time you see a decision like this come up, the idea of a cost/benefit analysis just goes straight out the window. Everyone just forgets that a feature can easily create no new revenue for the company, and that supporting the feature can cost numerous hours of support and development time. What is even more frustrating is when that feature isn't even that important to the customer. What you end up with there is some orphaned portion of your platform that just gets shelved since only one person wanted it. And they didn't even really want it that bad...
Taking the time to look up
We've all made these sorts of mistakes. Whether you were the Chicken Little in this story, or just one of the other fowl along for the ride. It's important to remember that there is always time to simply stop and look up at the sky. Taking that simple moment to refocus on priority, process, and product thinking will allow you to not make major mistakes. Simply by looking up, you'll notice that the sky is still firmly in place and the world isn't coming down around you.
Do you have a horror story with a Chicken Little at your company? How have you handled these sorts of situations? What do you recommend for others who find themselves in similar product conversations? Leave a comment below and share your insights. I'd love to hear them.