technology

Your iteration rate is the key to finding product-market fit for your app

For any entrepreneur launching an app finding product-market fit is a lot like finding the Golden Ticket; it’s rare, but when it happens it’s life-changing.

Unlike an enterprise business, when you build a consumer app your end-user can’t easily tell you what they want (vs. enterprise apps that are focused on solving a known problem or a pain point for clients). Think about it this way: Before the iPhone launched, no consumer research would point out the need for a touchscreen, keyboardless device. Before Snapchat, no consumer would say they wanted the ability to send ephemeral messages.

Consumers aren’t able to tell you what they want; this makes consumer products a shot in the dark. There is no guarantee if or when product-market fit can be found. It’s usually a long journey of continuous iteration.

And ongoing iteration is what gets you to product-market fit. Each iteration gives you one extra at-bat. Hitting a home run is easy if you can strike out 10o times instead of 3. Y Combinator’s Sam Altman said it best in this tweet:

Screen Shot 2019-04-01 at 4.14.45 PM

Finding product-market fit is hard. Look at how many consumer products Facebook and Google shut down even with their massive resources (remember FB Paper, FB Groups app, Google+ app?) Massive resources can help, but it’s not the most critical.

In the early days of Wattpad, despite only having a handful of employees, every day the product looked a bit different. We implemented new concepts in the morning, checked in the afternoon, measured overnight and killed it the next morning if it didn’t work out. That’s how we found product-market fit in many things. And that’s how we left our competitors in the dust.

Although finding product-market fit is freaking hard, it is also very fun and rewarding once you have figured it out.

Keep on iterating!

Out with the old (product features)

The new year means a fresh start. With that in mind, I urge product managers, designers, engineers and developers – anyone who helps develop a product, really – to think critically about the features they are designing. Have you thought about what features you’ll say goodbye to in January? Because killing features now means better business velocity for the rest of 2019.

As a product and its codebase grows, it is not uncommon to see an increase in technical debt. This debt may be because usage of a feature has scaled beyond its original design (you can’t expect a Toyota Corolla to reach 300 km/h no matter how many turbochargers you add) or because a feature, and subsequently it’s code, is used in more ways than originally intended (like a lawn mower turned into a snow blower – it works, but it shouldn’t). Often, technical debt accumulates because old or infrequently-used features aren’t retired.

There is a cost of removing these old features, of course, but removing features is significantly cheaper in the long-run than maintaining relic code. When you support outdated or unused features you’re also allowing security, performance and backwards compatibility issues to arise.

I remember reading an article about Evernote that claimed 90% of their features (and they have thousands of them) are used by less than 1% of their users. Eventually, the company’s velocity grounded to a halt because every simple feature update required numerous discussions across the company before the change could be implemented.

So make no mistake, it is desirable and even essential to purge old product features. Here’s how in three steps:  

  1. First identify a feature that you think should be retired. Then measure the usage of that feature. The data won’t lie. If usage is low, proceed to step two.
  2. The numbers may not tell you the whole story. Talk to some of the old-timers who have more context than you and understand why the feature existed in the first place. In many cases, you’ll be surprised by the reasons.
  3. Decide to purge, modernize or maintain the status quo. Make a decision and then execute your action plan.

Years ago, I was part of a team that dedicated six months to find bugs and purge unused features. On the surface, it seemed we were spending an inordinate amount of time and effort ‘looking in the rear-view mirror’ and not working on things that took the product forward. In reality though, those six months pushed the product much, much further ahead. By the end of it the product ran faster, the UI was cleaner because many unused features were gone, and annoying glitches were finally addressed. The app went from 1-star to 5-star in a few months without adding anything new.

It’s a good reminder: Less is more. Simple is good.