In the Greek Mythology, Procrustes posed as a gentle caretaker, offered accommodation to any passing traveller. After an invitation for a satisfying meal, he provided a good night’s rest in his exceptional bed. Procrustes described it as having the unique property that its length exactly matched whomsoever lay down upon it. What Procrustes didn’t volunteer was the method by which this “one-size-fits-all” was achieved, namely as soon as the guest lay down Procrustes went to work upon him, stretching him on the rack if he was too short for the bed and chopping off his legs if he was too long. (Adapted from Procrustes — MythWeb (http://www.mythweb.com/teachers/why/basics/procrustes.html))
In a Product Management position, one can imagine the many procrustean beds that are built for the private residents, i.e., engineering, quality assurance, operations, sales, etc. or for the passing traveller such as prospect trials, consultants, brokers and, existing clients. Let us refer to them as internal if they are to be fitted for in-house stakeholders, or external if they “accommodate” visitors that aren’t part of the company inner circle. In this series, I’m going to focus on the external ones and mostly derived from my experience in B2B environments. The ones that may hinder revenue goals directly and create friction in the overall evolution of the product.
The prospect client’s trial is a moment of utmost importance and, especially when a product or service has a broad and/or complex feature base. It doesn’t stand for itself. It needs an attentive caretaker that invites the freshly arrived visitor to have the best possible experience and, that can steer him on how to take advantage of the available amenities. Eager as we are, to make an excellent first impression and, to close the deal in the shortest amount of time ( because trials always have a cost ) we invite the user to feel at ease and at the same time we push him to experiment our star features. With the least amount of effort, we show him how to achieve our product promised outcomes. While the caretaker and the user roam around, showcasing the product end to end and iterating over the feature spectrum, we fall into the mistake of force fitting the client to the feature, whether the use case applies or not.
As it should be expected of a product team, we want and need to be creative. We seek inspiration in every problem that we face but sometimes, repeating empty metaphors such as “thinking outside the box”. And regrettably, we try to find solutions on the spot, for the prospect client workflows, habits and, tools, that are allegedly defective, unorganised, inexistent,
The Workaround
It is a well-known term in the Engineering class and many times used ad nauseam. Whether it is the best option at a time of need, laziness, schedule compression, damage control or just a temporary patch. It is a well-known term in the engineering class and many times used ad nauseam. Whether it is the best option at a time of need, laziness, schedule compression, damage control or just a temporary patch. A seasoned Software Engineer evidently used it on several occasions and sometimes wakes a night, shivering with the memories of some that still work on a machine somewhere.
In Product Development, the Workaround has a very similar set of characteristics. It is some process or small addition that will leverage an alternative pathway of one or more features to attain, what we believe to be a quick win. Sometimes with the objective of solving an unexpected user need or capricious desire. Sometimes it’s a cover up of an edge case that the product team did not address correctly or just ignored because they’ve fallen into a pseudo-statistical fallacy.
The Workaround trigger usually occurs in a commercial or technical tour of the product. May it be a sincere question that has a genuine need behind or a more technical person that wants to show off his wits. Occasionally can be a snarky remark that may compare his current work environment or another tool that he tried recently with our own, and something is definitely missing in his eyes. The fear and anxiety of not being able to entertain the user, makes us create a parallel thread with a request that the product team scramble the issue searching a way to meet our client expectations. It should not be a problem if at that moment a backlog entry is dutifully filled with a good picture of the issue, that popped up from the conversation, and a reasonable amount of time is taken to consider the proposition. It is a problem when we bypass our product development processes, and the proposed solution involves small feature adjustments that didn’t pass a thorough impact analysis. It is a problem when even avoiding the most minor alteration, it is the result of a collage of one or more features, or maybe, just making use of a feature quirk and painting it as a fully fledged product of human ingenuity. Unfortunately, the Workaround, most of the times results in a non-fluid and/or semi-automatic action plan, requiring the user to withstand some pain or to exert himself to do the same thing that he did or have seen in action before. At the exit of the Workaround, we claim victory if a significant amount of work that the user already does in a streamlined fashion or seen it being executed in the same way can be achieved in our product. We think that we’ve kept the user going, but we don’t see that the user is limping on its way. It may take just a small extra effort to vindicate the capabilities of our product but at the cost of an amputation.
For the attentive and sharp reader, another Procrustean Bed can be found A Posteriori. At the exit of the Workaround and this one with the bed and victim roles switched. This one can kill our product vision and eventually our product. Remember that for the Workaround to be put in place, some small change in our product had to be made. Even when we’ve just managed to pipeline a feature output to another as input, and with some caretaker good will. We’ve adjusted our product to fit that particular prospect or even client need at that precise moment in time without measuring the consequences of those actions. Expectations were created, and new plumbing was added disregarding our architecture, use cases and requirements. To do this, we’ve amputated, rearranged, bypassed and plug it again changing our product morphology. Again, with the best of intentions, to show how exceptional is our team and product. If we exit the Workaround multiple times, it is granted that our product will die in the bed that was made with our client’s hands.
The Workaround is avoidable, and it should be considered an anti-pattern in product development and management. It is damaging for our client prospects, and it is deadly for our product. Take the necessary precautions when you meet with the prospect of a Workaround and make time for fixing it before the product vitality seeps out from all of those newly created ins and outs.
Do you know more Procrustean Beds in Product Development and Management? Leave your comments and let’s have a chat.
Procrustean services and products on the wild
After reading this piece one might wonder that no procrustean bed should be a success since it destroys vital parts of the client work, team, company, etc. The reality is quite different and a quick inspection of our surroundings with this thought in mind will show us that sometimes people jump into those beds and accept the punishment in exchange of some promise of greatness.
Twitter is an excellent example of a procrustean bed. In this type of services, critical mass has a bandwagon effect that, most of the users aren’t even forced to lay their content on it, while amputating themselves in colorful headlines that the arbitrary 140 character limit can contain. All of them with the fear of missing out the short exposure and afraid that they will not be a part of a vaporous and fleeting zeitgeist.