When Your Product Teams Should Aim to be Inefficient – Part 1

A Story

Have you ever done the wrong thing really well? Whilst I’ve done many things that fall into this category, a clear-cut example comes from meeting a friend in London. I loftily declared I could meet him in 15 minutes at his favourite restaurant – Wahaca near Waterloo station – despite still being on the train and a good distance from a restaurant I’d never been to before. I rushed and ran, scooted and sprinted, and – proud of myself – arrived just 18 minutes later.

A text message exchange ensued. “I’m inside, near the back” I declared, promptly receiving the response “Can’t find you”. Realising there were two floors, I clarified that I was downstairs. Awaiting a response, I pulled up Google Maps – how could my friend be having such difficulty finding me? This is the point at which I realised there were two Wahaca restaurants near Waterloo Station – one to the North, and one to the South – and I’m going to have to sprint between them during one of the hottest summers recorded in London.

I did a very good job of being at the wrong destination at the right time.

Be Effective Before Efficient

As Peter Drucker states “there is nothing worse than doing the wrong thing well”, with Russell Ackoff clarifying: “the more efficient you are at doing the wrong thing, the wronger you become.”

The meaning of effectiveness is perhaps most clear in product teams, where there is nothing worse than creating an undesirable product. Let’s look at a few examples that can help us better differentiate between effectiveness and efficiency.

Zappos Concierge Test

In 1999, Nick Swinmurn was interested in starting an online shoe store. He recognised that one of the riskiest assumptions that stood in the way of a successful business was that people would want to buy shoes online.

To validate this assumption, Nick ran a concierge test: he walked into a shop, took a photo of some shoes, and posted the photo on craigslist to see if he could find a willing buyer. When an offer was indeed made, Nick returned to the shop to purchase the same shoes, and mailed them to the lucky buyer. Zappos was born.

Can you think of a more inefficient way of selling shoes?

Amazon Wizard of Oz Testing

Amazon chose a similar approach when designing their Echo device and Alexa virtual assistant. There was no such device on the market, so how could Amazon understand what questions people would ask the device, how they would word it, and what they’d like in the response?

Amazon realised that they didn’t need to have the answers upfront, and could instead let them emerge through Wizard of Oz testing. Customers were sat in a room with a dummy device containing just a microphone and speaker. This let a ‘wizard’ in a neighbouring room hear the customer’s requests, and type responses which were synthesised into speech, maintaining the illusion of a real working device for the customer.

Whilst this is an incredibly inefficient method of servicing customers – I’d be concerned if each Alexa device required a person answering my questions – it maximises learning, allowing Amazon to confidently design a desirable product interaction, even before one line of code was written.

Pets.com and Blockbuster

In my mind, two examples of organisations that were efficient but ineffective were pets.com and Blockbuster. Pets.com failed for the reason that Zappos succeeded – customer preference. People did not wish to buy pet supplies online and wait for delivery when they could instead walk down the road to get the pet supplies they needed now. Blockbuster was efficient at charging late fees (comprising ~16% of their revenue), something that frustrated customers and contributed to the founding and success of Netflix, where late fees do not exist.

It is important for product teams to quickly and cheaply discover the features – outputs – that can best help achieve the desired outcome (a meaningful and measurable change in customer behaviour). This discovery period is a time to be inefficient in the pursuit of learning. Only when confidence increases does it make sense to invest in building efficiency through software.

Be inefficient until proven effective – whatever you build until that point may be discarded.

Summary

As product teams, we should aim to be effective before efficient. During a discovery period it is okay – even preferable – to be inefficient in servicing customers. Our focus should be on learning. A ‘wizard’ manually answering questions posed to a dummy Alexa device allowed Amazon to discover which features – outputs – were needed before solidifying them into software.

In part two of this article we will discuss the – often unexpected – implications of turning to technology to bring about efficiency, and how there are deeper considerations that must be addressed first.

Thinking of applying these concepts in your organisation, or want some guidance on how to get going? Reach out to us here for a chat.

Learning More

• Continuous Discovery Habits illustrates how product teams can interweave discovery and delivery.
• Platform Engineering as a (Community) Service suggests how a solid platform can underpin and empower development teams to build great software.

This blog is written exclusively by the OpenCredo team. We do not accept external contributions.