Every new tech product starts with a simple idea. But in the brutal battle of creation, things can get complicated fast. The focus shifts from the big picture to the details, new ideas keep coming, and the scope starts to inflate like a hot-air balloon.
When it comes to product development, I’ve made more mistakes than I care to admit. I’ve over-complicated, over-built and over-promised — sometimes with disastrous results. But every failure pushed me one step closer to figuring out what works.
Over time, I’ve formulated a set of principles that underpin my decision-making when it comes to deciding on and prioritising, what to build. These principles developed organically and became things I tend to repeat. And they’ve been very helpful in guiding me to simpler and more effective products.
I recently used a new service called Homie in London, that finds you an apartment to rent in less than 48 hours. The founder, a friend of mine, emailed me to apologise for a design ‘bug’ in one of the pages. I responded with, ‘If you can find me a great place to live, I don’t care if you have all the bugs in the world.’ Valuable outcomes are a hundred times more important than the interface.
If you have features located in footers and drop-down menus, they’re invisible to the majority of your users. It’s a bit like selling chocolate bars from the janitor’s closet of a hotel. It begs a couple of questions: (i) wouldn’t it be better to sell them in the foyer, where everyone can see them?; and (ii) why are you selling chocolate bars in a hotel anyway? Focus on the main screens and kill the drop-down menus whenever possible.
Most feature ideas turn out to have little or no impact on important metrics.For every feature idea we have, we identify which metric the feature is intended to affect — and brainstorm at least five different ideas that could also affect that metric. More often than not, this uncovers a simpler way to achieve the same thing.
Limited resources mean you have to be ruthless about where you spend your time. Don’t agonise over sign-up forms, forgotten password flows, and other details that aren’t related to your user’s primary goal — that time could be better spent on learning from your users. Whenever possible, I give myself permission to borrow from other products. Hey, if it works for Facebook . . .
Little moments of delight are what separate a good product from a great product. I measure delight by the number of smiles during user testing. It cancome from something as simple as a tweak to some copy, an animated GIF, or some other detail — but if it creates a smile, I think it’s worth the extra effort.
Taking shortcuts can allow you to speed up the learning process — but building on top of those shortcuts is like building on quicksand. The issues that arise from a weak foundation lead to painfully slow iteration cycles later on. ‘Quick and dirty’ hacks to learn quickly, and ‘labours of love’ to build solid foundations, are fine. But ‘long and dirty’ work is banned.
Everyone is entitled to an opinion and customers are no exception. However, I believe that understanding users’ actual behaviours is more important than understanding their opinions at the early stage. On top of metrics, I reach out to real users and conduct detailed interviews in order to find out how they behave.
Loading times matter — even at the early stage. Therefore, I ensure that users never wait for more than one second (yes, I know Google has the 100ms rule, but we’re talking early-stage here). It’s not just about blisteringly-fast algorithms; it’s also about button feedback and appropriate loading behaviour. Holding our users’ attention is paramount.
The pressure to optimise comes from all angles — from users, teammates, and investors. A few tweaks over here, a quick A/B test on some copy over there.In retrospect, the effort needed to optimise is substantial, and it often distracts us from the bigger question: is this product even in the right ballpark?Holding focus on ‘discovery’ is hard, especially given our perfectionist tendencies.
Writers know that one of the secrets to great writing is ruthless editing. A great sculpture is defined as much by what the sculptor removes as by what remains. And similarly, simple products are defined by what features are killed. If less than a quarter of users are using an unpaid feature, it’s probably time to kill it and focus on more important things.
Defining your principles helps your team make decisions in a similar way to you, thereby scaling your decision-making. As a leader, it’s your job to stick to your principles and say them out loud as often as possible.
These principles are not universal truths. I’m sure other product teams can succeed by following different principles — that’s why every product is different. If some of these principles work for you, great! If not, I hope they help you to crystallise the principles behind your own best decisions.
Thoughtful essays on growing teams, building products and raising money by Serial Entrepreneur and Investor, David Bailey.