Tag Archives: product development

“I could have built that in 2 weeks!”

Posted on by

Yes but did you? That’s the point. You’ll often hear an over zealous programmer or engineer exclaim that they could have built [insert hot startup] in no time so what was the fuss about?

The key that they’re missing out on is that it’s simple to clone, but extremely difficult to innovate.

It’s a decision tree. Every node represents a set of decisions available to you with all the possible permutations as below.

decision tree

What is visible to everyone is the path travelled, not the paths forgone. Once you know your destination, tracing the tree back to the root is relatively simple. However, starting from the root without knowledge of your destination is where true innovation happens. That is a process filled with trial, error, failure, and course-correction over and over again till you reach your final destination.

Conceptually speaking there are several startups that are in the same space – most fail but some do better than others, with one becoming a market leader. Path, Instagram, Oink, etc are all relatively similar, but you’ve heard of some and not the others. Why? They’ve all taken different paths in the tree which has enabled some greater success than the others.

First mover advantage is real. Reaching first on the scene with a product that scales gives you a distinct advantage to becoming the market leader no matter who you’re competing against. Take the case for Facebook, a company with near infinite resources and the top destination for the web. They were late to the ephemeral photo space behind Snapchat. Facebook released a Snapchat clone called Slingshot in an attempt to beat them. Despite Facebook’s resources behind Slingshot, which one do you have on your phone? They also released a Flipboard clone with Facebook News (yes they had/have a separate news app), an Instagram clone with Facebook Camera (before acquiring the former), and a Foursquare clone with Facebook places (now defunct) amongst others. They failed in every one of those cases for the exact same reason that they succeeded in out-competing Google+: they were there first.

Switching costs in networks ensure that network effects are always in play. If a user is on a hot app with his friends, he’s not going to switch to a clone that does the same thing and also convince his friends to switch, even if the second one is slightly better. The only way to convince the user to overcome the switching cost is to offer something that is 10x or an  order of magnitude better than what he is using.

Success always looks easy from a distance. That’s because it’s only the path travelled that is visible, not the entirety of the tree. The next time someone says “I could have built that in 2 weeks” simply ask “then why didn’t you get there first?”.

 

 

 

Solving a user problem vs a technical problem: the difference between creating value and wasting your time

Posted on by

What is the kind of problem you are working tirelessly to solve? Are you actually working to create value or simply wasting your time? The difference is in the end goal of what solving the problem accomplishes. Some very big user problems have fairly simple technical solutions. They are easy to use, solve an actual need and fairly simple to interact with. On the other hand, some very big technical problems really don’t end up doing much for the end user. The former gives you something that people want, while the latter gives you an extremely beautiful piece of crap.

Engineers are particularly susceptible to this. It is natural to fall into the trap of believing that just because something is challenging from a technical perspective, it must be a valuable problem to solve. From a user’s perspective, all that’s important is that the product does what it is meant to. “How” really doesn’t matter. If you are selling mousetraps, does it get rid of the mice better than everyone else? If yes, that’s great. Users aren’t going to care much of what happens within the product as long as it works. You can spend all your time trying to create a very advanced, state of the art, nuclear powered mousetrap that creates mini fission explosions to obliterate the mice, but at the end if it doesn’t get rid of the mice, is unwieldy or uneconomical, no one’s buying it. It’ll be an extremely cool project no doubt, but at the end of the day, a fairly useless one!

Every problem that you solve should tie back to the user and/or to enhance their end experience. Be careful of not getting stuck in your own technical world that is insulated from the user completely. Though it does vary by industry, for consumer facing products more specifically – it is the end user who is king. It is easy to get lost in day to day technical, legal, product, financial, investment problems, but if what you’re working on doesn’t help the end user – you’re not moving forward.

Expressed in slightly broader terms, whenever you look at a hard problem, you need to assess its value independently to determine whether it is truly worth your effort. Becoming the top restaurant in the city: Is it hard? Of course! But how valuable is it given that the next 10 best restaurants are almost always going to be head to head with you?

Passionate engineers, by nature, get excited by challenging technical problems. However, take care that you never lose sight of the user so you don’t end up spending all your effort on creating something which doesn’t end up doing anything.

On the flipside, thinking from a user’s perspective brings focus, where the complicated tasks that you were dreading, often no longer seem to be relevant or worth pursuing. It simplifies things! Not everything is wrong with the world… 🙂