The Efficiency Paradox (or, How to Maximize Value Through Inefficiency)
Most products are designed to make our lives easier — to make our everyday tasks more efficient, if you will. But a weird thing happens when “efficiency” becomes part of your brand: It becomes a hallmark not only of finished products, but of the ways in which they are created, too.
And the result is almost always an inferior product.
My team and I have collectively worked on hundreds of software products, for dozens of different companies across many different industries. We have discovered that many companies commit this fallacy. They assume that, if you want an efficient end-product, the method by which it gets made must be ideally efficient, too. And as it turns out, efficiently made software is often not very good software.
It never occurs to these companies that the most efficient products might actually be made by the more inefficient means. And yet this might be the product manager’s secret weapon: Harnessing the power of inefficient methods that nevertheless produce quality.
We Get It When It Comes to Eating Out. Why Not When Building Something?
We seem to understand this principle in other parts of our lives — eating out, for example. We put fast food, which is quick and efficient, in an entirely different category than fancy sit-down restaurants. Advertisers even play on this difference; there’s a great old Steak ‘n Shake ad (“Scenes from a Work-aurant”) where a server — played by Heather Donahue of Blair Witch Project fame — admits that the way other restaurants make milkshakes is more efficient…but then she asks, “When was the last time you sipped a shake and said to yourself, ‘mmmm, that tastes efficient’?”
Steak ‘n Shake has a point: People care about how good a shake tastes, not how efficiently it was made. Efficiency is something only the execs worry about. That does not mean efficiency is bad, or that it shouldn’t be a priority. It simply means that the efficiency of the process is rarely what we are selling.
Even when a product is designed to make us more efficient — like planning software, or an Echo device, or even an Instant Pot — what is being sold is the convenience and efficiency the device affords in our daily lives. That’s different from the efficiency in the process of making those devices. That kind of efficiency is invisible to the end user…until, of course, it begins to affect the quality of the product.
How a PM Can Harness Inefficiency to Make Better Products
There are tons of articles here on Medium about how PMs can be more efficient and effective. I’m going to go against the grain and suggest ways in which you can be inefficient, but in ways that might actually benefit products in the end.
So let’s say that, as a PM or PM leader, your goal is to try to maximize a product line’s value to the end user, and that you are open to doing this via methods that, to all appearances, seem really inefficient. What would that look like?
You’d be a stickler for testing. If you want quality, you need quality control. Testing should be built into as many phases of a product roll-out as possible. Yes, testing might slow things down…but if you don’t have time to thoroughly test, do you really have time to troubleshoot shoddy implementations of products and features?
You’d be OK with more frequent and more open-ended meetings. Common wisdom says to pare down the number of meetings and make them as efficient as possible. But consider: What happens when you get frequent feedback from users and other stakeholders? What perspectives get brought to the table when all the stakeholders are in the room? Granted, some meetings should be emails. But some should be workshops, too.
You’d always be ready to pivot and start from scratch. I’ve personally been involved with several software projects where we showed the client an early version of the working software, and it became clear that either we misunderstood something, or the client was not fully clear about what they wanted to begin with. Now, we could have simply tweaked the solution, or maybe defended the product as it stood. Instead, we scrapped what we had and started again. Wasteful? Sure. Did the client end up with a product that was 100% more valuable in a shorter timeframe? Absolutely.
You’d produce several versions of the same thing simultaneously. Sometimes you just know, ahead of time, that your team will need to pivot because there are simply too many variables that are up in the air. Time to double-down on inefficiency and create multiple versions. Yes, you will end up scrapping several versions. Maybe all of them. But working on different versions allows clients (or users) to see several versions, understand the range of what is possible, and further guide development. (Graphic designers do this all the time, by the way.)
You’d be skeptical about deadlines. Don’t get me wrong: It’s important to get to market quickly, especially when the competition is breathing down your neck. But if we’re honest, many deadlines are arbitrary, and it is in the nature of most product work that we simply can’t know, at the outset, how much time and effort a project will need. Instead of focusing on “Done by this date,” why don’t we focus on “Here’s what’s workable, and here’s what’s next.”
The Takeaway
Again, efficiency is not a bad thing. But efficient processes do not always yield the highest-quality products. Too many companies fall into the trap of assuming that, because the brand is all about selling efficiency, that includes efficiency of the production process.
Take it from someone who has trashed and restarted more software applications than I care to admit: Whenever I focused on what the final product needed to be, and not on how to do my job more efficiently, I was able to get to a satisfactory product more quickly, and with better results. It’s paradoxical. But many products in the current day and age just work like that.
