Table of Contents
In the previous post, we spoke at great lengths about Uber’s tech and it truly is mammoth (now). But you might wonder why this should concern you as an early-stage entrepreneur or a product manager building a new feature/ product? Should you account for all of this upfront and start building tech along these lines, right from day one?
The answer is quite obviously, No.
Even Uber started off as a simple monolithic app (one app performing all functions) and eventually moved to a complex SOA (service-oriented architecture) to tackle scalability, reliability and maintainability among others. However, where exactly does someone like you or me begin?
Build tech to solve a business problem
I believe the very first thing any entrepreneur or PM should do is to identify the core business problem. Your aim should be to solve this problem and use tech only as a facilitator.
Let’s say you decide to build user profiles in the first version of an Uber-like app. Think again. Is this something that satisfies a business need or a feature your users really need?
When you are building a service like Uber, the core problem you are trying to solve is efficiency in transportation. Your primary focus, at all points then, should be to onboard as many drivers and riders into your community and to have as many successful ride completions as possible.
In terms of the product, you should always only build the components that are most critical to achieve your business goals. When building a product or adding new features to an existing one, you should at all points question what underlying business problem it aims to solve.
Build tech smartly and efficiently
It is also critical to realise that the success of your first product doesn’t depend on how robust a tech you build from scratch. But rather how efficiently and smartly you build it.
Let me substantiate this with an example. Say, you want to build a service that provides effortless and reliable transport to the airport and you are testing it out in the city of Bangalore, India.
You should probably be spending most of your energies onboarding and screening drivers, sending the word out about your service to as many people and having maximum successful ride completions. Starting by building a set of mobile apps, a robust backend and a smart matching engine is a recipe for disaster.
Instead, why not use simple forms to capture user bookings. To start with, you will surely only have a handful of bookings to fulfil. Your matching engine (connecting drivers and riders) then should simply be on pen and paper.
You might think of this as a trivial solution but we can actually break down use-cases and point out the exact (existing) tools/ products you can use to cover these use-cases. You will be surprised to see how effectively all our problems get solved using existing solutions, which are in fact capable of tackling 1000s of users and associated data. More on this in the next article (coming soon).
In effect, smartness and efficiency is in using existing solutions or products to your advantage.
Speaking from personal experience
You might wonder why am I so sure that one shouldn’t build tech unless absolutely necessary. Have I done something otherwise myself and failed?
You bet I did and wasted quite some time in the process.
We made this huge mistake when building the first version of Flexiple. We were convinced that matching the right freelancer to the client basis a number of parameters is extremely critical. So, we brainstormed, figured out the parameters, attached weights to them and had the entire recommendation engine ready on paper.
It looks perfectly fine till this point, however, we went a few steps ahead and built a service on Ruby on Rails which fetched freelancer data from our DB and pushed out recommendations in priority order. Yes! We actually had a small version of SOA/ microservices architecture you read about earlier live for Flexiple, even before having a single paying client!
The right thing to do, should have been to match freelancers to clients by hand, manually, at least for the first 100 or so successful engagements. Even post that, it makes sense to leverage existing tools/ products than building something entirely from scratch.
We were busy building a sophisticated matching engine when we should have focused on having as many successful engagements as possible.
The irony of the situation is that many reputed VCs we were speaking to, at that point, were also keen on seeing the recommendation engine in action rather than the mechanics of successful client engagements!
As opposed to this, I remember being a part of the early discussions on Adobe Knowhow (consumer offering now discontinued). This eLearning platform was built to primarily deliver quality handpicked courses around Adobe’s creative suite of products.
It was decided that the platform would be launched with ~75 courses and naturally, the platform would have user recommendations. Now, it is not so tough for an engineering team at Adobe to build a recommendation engine into the product. Yet the PM for the platform was keen on having manual recommendations in the first version and the recommendations cloud was entirely hand-drawn on paper!
There’s definitely a lot of sophisticated tech we see around us and it is natural to fall for building the same things in your product, even if you know something simple could work.
Hence, it is critical to take a conscious step back and rethink if you really need to build a particular feature or even the entire product. The golden rule is,
“Unless you realise that the absence of a certain feature has created a bottleneck in business outcome, it is surely an unnecessary feature.”
As promised, the next post would entirely focus on how exactly our first version of an Uber-like app will look like – features, different components and use of existing solutions.
Until next time!
Do reach out to me on Twitter if you would like to discuss anything.
I also write regularly about products, startups and tech. If you would like to hear from me more often, you can subscribe to my newsletter here.