Procrustean Beds of Product Management

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, . On the other hand, a small void or even a domain that we’ve managed to exclude from our road-map can bring havoc when a client merely hints the fact of nonexistent work in that regard. Instead, we should take our notes and seclude our selfs, for a moment, where we can summon our creativity and muster our planning abilities towards a well-designed solution. On the spot, thinking and instant client fitting is the moments where we start amputating the prospect expectations and with the best of intentions in mind but ignoring the prospect client true needs and creating product fragilities. Doing this we fall into an uberous mind trap. Let’s delve into one type of this situations. The dreadful and pernicious Workaround.

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.

Future Feature

The second one, the Phantom Feature, is definitely more dangerous in a long run. While the Workaround may create a local problem with a specific client and with time and patience, the debt that the Workaround created may be paid in installments, the Phantom feature can put the product road map and vision at risk. Usually this will only happen after a product end to end trial seemed successful. The trial prospect found the product suitable enough to engage in the real proposition that he expects tho be solved. Our shiny product withstood all of the uses and abuses from our trial prospect and we may even have fallen into the Workaround trap…one or more times…because the feeling of a closed deal is too strong to ignore. In the end the client remarks. “This is great, but if you guys want to ( reading between the lines: have the privilege of ) work with us, we need this small ( hint: it isn’t small ) customization/feature/migration”. Done deal, let’s get to work and get paid for it. But, when the work unfolds it’s multiple facets in the face f the product team, we realize that we need to put alll of our chips in this client and few resources will be available to grow and implement what it was initially our project of greatness.

Sometimes is the star feature that the potential buyer doesn’t really need and we push him for a test use case that makes the product shine, but the user motivation wither. Sometimes is the closing anxiety that over-stretches the benefits of a particular module in the overall product experience and makes it seem more prominent than the product core features. And, sometimes is the dramatic paradigm shift that the user needs to endure if he wants to take advantage of the brilliant future that we promise him in a vision that isn’t always quite clear to him.

We’ve created future expectations on the mind of our trial prospect. Expectations that probably aren’t the real deal when we manage to create extra plumbing for the new and exclusive Workaround. Expectations that this is the modus operandi with him, because he his really special when the first monthly payment arrives.

As the client base grows, one needs to attend the customer’s requests properly so that extensions or newly additions don’t have a negative impact on your existing user base and don’t create commercial valleys that prevent roaming into unexplored prospects.