In Defense of Smallness
Talos just started developing our first mobile application, and we have some pretty small goals for our first version.
The project itself rests on the idea that a small change to the industry standard product, and how we produce revenue, will have a huge effect on user experience while sufficiently differentiating us from peers in the market. There are A LOT of these peers in the market, making this an important point.
The design and development team we contracted, however, has had a hard time getting on board with the smallness of the change we want to make, wielding the very convincing argument that it wouldn’t be big enough, or visible enough, to elevate us above other more established players in the market.
I have to admit I myself almost got pulled across the point of no return at the black hole of doubt. It is something people so rarely talk about, the line between a foolhardy belief in your idea and grounded support for a concept. The usual thoughts clawed their way out of their cage.
“Is this idea really as unique as we thought it was?”
“Have we overestimated the effect of the problem we have highlighted? Does anyone even care about the problem?”
“Will that even matter if we can’t convince people that we actually are different or better? After all, we are paying these people to spend hours in meetings with us, and they aren’t convinced!”
In the end, the time we had spent working to find the best place to start solving our problem, paid off, and the doubt began to wane. But the experience left me thinking about why our little solution was so hard to sell. After all, we have worked on several other projects with much bigger goals, which all received significantly less scrutiny and skepticism.
In technology, we are surrounded by people who have big ideas about making drastic changes. We engage with the belief that big ideas mean loud and visible changes, or that progress needs to involve chucking everything we arrived with into the rubbish and starting from scratch.
But is this actually true, or is it just a better narrative?
How much do we rely on the fact that big change is exciting and easy to rally behind, while fixing something small and broken is so often undervalued even though it is often a much more realistic pursuit?
I was sitting here staking out the corners of our identified problem, and it is small; our solution, too, only involves some small changes to the status quo. But next to those small things was a rippling effect, touching everything in the peer services we were trying to change. Our problem defines how users interact with the services, and the moral consequences from it hang ominously over the entire market.
Our small problem and equally small solution are not big in size, but they are dense enough to have a gravity all their own. They leave nothing else in the product and user experience unaffected.
I now have several more weeks of defending this smallness ahead of me. Only time will tell if this is a smart choice, but in clawing my way past the doubts raised by our very capable developers, I realize that it shouldn’t matter how big a change you are making to solve a problem; the effect is what really matters.
Let’s not fall victim to yet another conjunction fallacy. Making a big change doesn’t inherently mean big results will follow. Don’t accept that small problems and equally small solutions can’t be meaningful pursuits, or that they less often have big effects. To do so is to look at a 2,000 year old redwood and believe that since it is big now, it must have always been such. Or to look at the Grand Canyon and say, “This is an impressive hole in the ground. It must have opened up all at once with a loud bang.” It just isn’t true.
This isn’t only something Silicon Valley could do some soul searching on; what more could we accomplish every day if we carefully let a few more small, important things draw our focus and energy?
In defense of smallness, of the idea that sometimes doing less very carefully results in accomplishing more, we have a few TED Talks to get you started: