Another client meeting concluded. A few more important decisions were made. Incrementally, our team was inching closer to the right solution for our project.
Driving toward the airport, instead of satisfaction, I felt a sense of unease. I couldn’t help but worry that the general speed of this project wasn’t fast enough. By the time we would finally be able to deploy our ideas, the market may have changed so much that our work might lose some of its effectiveness.
Is there a way to avoid wasting so much time?
In Italian, tempo means time, and it is also a fundamental concept in chess. Tempo indicates that a player has made more effective moves than his opponent. For instance, a move that threatens an opponent’s piece leads to a gain in tempo when the opponent is forced to defend his piece without a gain in development.
Sound familiar?
Today, companies in the digital arena are often engaging one another in a sort of chess game where “tempo” plays a very important part. Big corporations move slowly. It’s their nature. Small companies are more nimble with their decisions. So they are able to innovate. But, I work for the big guys, and don’t like to loose tempo, or the game.
But what if big companies play against themselves? Just a little bit.
Of course a big company can’t disrupt their own markets with full scale testing. But what are the risks involved in deploying an agile, iterative prototype instead of the full-scale solution? This process would allow clients to release many new products or services, starting with a “minimum viable product (MVP) to get to the full scale solution much faster. Can big corporations ignore the illusion of perfection and start behaving like a startup gaining tempo?
Imperfection today is better than perfect tomorrow.
Now the question becomes how to minimize the risks? Maybe instead of doing the regular A/B testing, and splitting the audience in half, we give our clients a way to test that’s proportional to the risks – the higher the risk, the smaller the audience. It’s all about the algorithm. Good ones let us determine how to test in order to impact the fewest number of people and still get valid results.
Our large clients need to be free to let the market decide.
For each iteration or new design solution, client always go through some form of user testing to define the most effective choice. What if we allow the market to give us the answer instead?
Most likely, we’ll find that in-market testing does not compromise KPIs except in the most limited way. I feel it’s a fair trade off to accept a small decline in performance to gain tempo and move at a faster pace toward the final product or solution.
This article and myself owe a big debt of gratitude to Moria Deshpande who helped in streamlining my thoughts.