BigBasket: Defying the Odds to Grow Beyond $1B GMV Sustainably

October 1, 2020

Context

One of the hottest companies before the Dotcom bust of 2000 was Webvan. It raised $800 million from Sequoia, SoftBank and several other Silicon Valley investors. Webvan had a successful IPO at $1.2B valuation in 1999 (as compared to Amazon’s IPO of $440M in 1994). Webvan was the original “Blitzscaling” company – it expanded to 26 cities across US without waiting for the business model to get validated. Webvan was touted to be the shining example of the then-unfolding Internet era. Unfortunately, Webvan’s collapse was as spectacular as its rise; it failed within a few months of going public!

Webvan was building an inventory-led online grocery business. Webvan’s failure pointed out that inventory-led grocery business (with perishable inventory and razor-thin profit margins) is hard to build. Webvan’s failure left a huge scar in the psyche of the entrepreneurs and investors in the Silicon Valley – such a big scar that no online grocery startup was built for the next 10 years! Even when the entrepreneurs started exploring this space again (such as Instacart, which started in June 2012), it was with inventory-light model – not the inventory-led model that Webvan had visualized.

Bigbasket was one of the first companies to defy this conventional wisdom and showed how to build a sustainable inventory-led grocery business. BigBasket started in December 2011 and was one of the earliest companies (across the globe) to unlock the magic formula to leverage inventory-led model to deliver great value and experience to users.

Incidentally, Amazon did start Amazon Fresh in 2007 – but it was an experimental launch that was limited to Seattle (and users had to pay $4 per delivery). Amazon Fresh expanded beyond Seattle after six years – in 2013! Users had to pay $299 for Prime Fresh membership – just to get the privilege of ordering groceries online. Amazon Fresh slowly expanded to other cities over the next 3 years (in US and Europe). Even then, users had to pay $15 / mo (over-and-above $99 for Prime membership). If someone orders groceries every week, this turns out to be $4 per order of delivery fee – more or less the same price that was validated in Seattle.

To find out how BigBasket succeeded in building an inventory-led grocery business, we had the privilege to talk to Tejas Vyas, who, incidentally, was the earliest technology employee at BigBasket. Over the last several years, Tejas has worn many hats. In the beginning, he was the lead engineer / architect; subsequently, he moved to the Product side for the entire back-end system (which played a crucial role in BigBasket’s growth). More recently, he heads the Product and Design at Bigbasket.

BigBasket journey

Tejas mentioned that BigBasket started with the “mission statement” of being one of the top 3 grocery players in India (not online grocery business – overall grocery business; though online was clearly the initial / preferred acquisition channel). From this mission statement, BigBasket identified two focus areas:

1. Build trust by providing superior customer experience to users and, based on that, become one of the top brands that customers love.
2. Grow sustainably and economically so that BigBasket can build a profitable business at scale.

Tejas pointed out that the mission statement and focus areas have helped BigBasket navigate through different phases on the journey so far. Tejas divided the journey into 3 phases:

· 0 – 1 phase: Tejas referred to this phase as the “Market-Product Fit” phase (as opposed to “Product Market Fit” phase) because it is important to understand the market before defining the product. Deeply understanding the market (i.e., the target users) and building/adapting the products based on their needs helps to optimize on time, money, resources, etc.
· 1 – 10 phase: the stablilization phase, where the startup onboards more and more customers while building products / features to cater to more use cases.
· 10 – 100 phase: the scale phase, where that startup broadens its offerings to cater to the needs of the “masses”.

Each phase has different requirements and expectations as well as different variables. To navigate through these phases, BigBasket uses the WWWH Framework.

WWWH Framework

The WWWH stands for the Who, the Why, the What and the How.

Who corresponds to the users and the stakeholders of the platform. BigBasket uses this to define and understand the target segment and its needs.

Why corresponds to deeply undersanding user needs and wants. This is an ongoing exercise because user needs and wants are not static. They keep evolving. Moreover, as a company expands its offerings to more user segments (personas), the needs and wants of new sets of users needs to be understood as well.

What corresponds to identifying the correct problems to solve. This, in turn, needs the startup to prioritize effectively. This is need to avoid going down the rabbit hole of endless engineering tasks.

How corresponds to various mechanisms and solutions by which one can convert the possibilities into reality. These include user research, Learn-Build-Measure-Iterate model, quick experimentation, etc.

Tejas provided an outline of each of these  during the three phases of BigBasket’s journey.

[Who] Users

In the 0 – 1 phase, BigBasket started off by targeting early adopters who were looking for convenience. This also matched the profile of users who were open to buy groceries online in 2012. In the 1 – 10 and 10 – 100 phases, BigBasket expanded to cater to masses as well.

To draw an analogy, BigBasket’s initial customers were similar to Nature’s Basket customers. However, as the company scaled, they started drawing in Big Bazaar customers as well. However, Tejas emphasized that, in reality, BigBasket is somewhat in between Nature’s Basket and Big Bazaar and, really, has created a completely new segment which is a mix of broad range and superior customer experience of Nature’s Basket and value-for-money offered by Big Bazaar.

[Who] Farmers and the “Spinach”

Besides end-users, BigBasket has one more set of important stakeholder: the farmers. BigBasket has been very conscientious about farmer’s needs and wants as well.

To highlight this, Tejas spoke about Spinach’s Journey. (We often hear about customer’s journey; the understand the operational complexity involved in the backend supply-chain operations, it is good to view the journey of fresh produce as well.)

Before BigBasket, spinach used to take 3-4 days from the time of harvesting to landing on consumer’s plate. The steps involved were: farmer harvests from the field and goes to a neighbourhood village where the produce from different farmers gets aggregated. It is then transported to the nearest APMC market, which potentially takes half a day or so. At the APMC market, there's an auction, which typically takes a day or so. After being bought there, the spinach is shipped to the local city hub (and each city has two or three such hubs). From there, it is bought, transported and sold to grocery stores and other retail sellers. In all, spinach’s journey used to take 3 – 4 days before it could be consumed.

BigBasket deeply analyzed and understood spinach’s journey and worked to make it more efficient. With the help of an integrated supply chain platform, BigBasket informs the farmers about the expected demand one night before the harvest. Based on this, farmers are able to harvest the right amount of spinach in the morning (say, at 6am) and hand over the harvested spinach to the collection centers (which are located close to the villages) by mid-morning (say, by 10am). From the collection centers, spinach is transported to BigBasket warehouses which are at the outskirts of a city. Typically, these warehouses are within 50 – 100 kilometers from the collection centers. From the warehouses, spinach is shipped to the small warehouses (or local spokes) within the city. Spinach reaches these warehouses by 4pm or 5pm. The delivery agents are then able to pick up from spinach from these warehouses and deliver to the customers by (say) 8pm. And then, if someone decides to cook spinach the same day (or next day morning), it is possible to consume fresh spinach within 24 – 30 hours of it getting harvest from the fields!

On top of this intricate backend supply chain system, BigBasket has been able to build a service that is able to deliver unmatched quality of fresh fruits and vegetables to consumers. This is not only good for consumers but it is good for farmers as well: they are able to monetize their produce more effectively and to get the best yield from their farms. Finally, this is good for BigBasket as well: fresh produce has very short shelf life and wastage of the produce (due to rotting, spoiling, etc.) has been the bane of the grocery business resulting in razor-thin margins.

[Why] User needs and wants

Tejas emphasized the need to separate “needs” from “wants” (pain-killers versus vitamins, in the typical startup parlance). In the initial days, BigBasket’s target users were looking for the convenience of getting fresh groceries delivered to their homes. BigBasket focused on the “needs” in the beginning (and deferred working on their “wants”).

Tejas pointed out that user needs and wants are not static; they keep evolving. Moreover, as BigBasket expanded its offerings to new set of users, their needs and wants had to be handled. In other words, it is important to recognize that the “Market Product Fit” also keeps evolving; as a result, startups need to constantly evolve the product / service to stay on top of evolving user needs and wants.

In the 0 – 1 phase, early adopters were more forgiving about the freshness and the price competitiveness of the “spinach” (in general, fresh produce) because they indexed more on convenience. But the 1 – 10 phaseusers were more demanding in terms of the quality of the spinach – which required BigBasket to evolve and improve its supply chain systems. In other words, clarity of user needs and wants provides right direction to the company in the initial stages.

In the 1 – 10 phase, understanding user needs and wants is necessary to prioritize tasks. But this requires understanding user needs and wants at a deeper level because often several seemingly unrelated requirements have a common underlying root cause. It is important for product managers and organisations to spend time to uncover the deeper triggers and to define the requirements in a simple and clear terms based on the Why. This helps to understand the issues / problems better and to resolve the issues better (instead of patch-fixing the problems).

In the 1 – 10 phase and 10 – 100 phase, it is necessary to start focusing on “wants” as well. For example, BigBasket realized that users want organic spinach. Also, they want green packaging and traceability of products.

When the loyal customers express their requirements and expectations, it is important to consider them because retaining loyal users is very important. Even then, it is necessary to understand the importance of this “want” and whether it has become a “need” for the loyal customers. If the market has evolved (and the original needs are now taken for granted), it is important to build features that cater to these wants. This, once again, reiterates the need to understand the market in terms of the needs and the wants of the rapidly evolving users. Catering to these “wants” can provide a differentiator to a growth-stage startup.

[What] Prioritisation

In the 0 – 1 phase, BigBasket initially focused on building a fast and efficient supply chain and making sure that the fresh spinach can be delivered at the right price with the right experience. In order to focus on this, BigBasket de-prioritized the UI / UX of the website. The website was kept simple with focus on ease-of-use (and basic features such as product details with image and price, add to cart, and checkout page). There were no bells and whistles. Besides supply chain, the focus was on grocery delivery experience. For example, delivery partners were empowered to accept returns immediately if the customer was unhappy about the freshness of the vegetables. This helped BigBasket achieve the delight that customer’s best neighbourhood grocery store provides.

In the 1 – 10 phase, BigBasket continued to focus on the holistics “customer experience” instead of the digital-only “user experience”. For example, BigBasket built a simple, no-frills app that followed the same philosophy as the website. Instead, BigBasket continued to invest more on adding a lot more automation and sophistication in its backend systems to provide superior farm-to-fork experience. This helped BigBasket to expand its product catalog to approximately 20,000 SKUs (from 2,000 SKUs in the 0 – 1 phase, which is the kind of variety a typical small supermarket grocery store offers). It also helped BigBasket to focus on delivering fantastic experience to users (such as 90 minute delivery) and to ensure that customers were happy with BigBasket.

How did BigBasket make the right calls during these phases? For this, BigBasket used the following prioritization framework to prioritize objectively but ruthlessly.

The prioritization framework depends on two parameters:

· Impact of the problem.
· Effort required for the solution.

First, every “problem” is rated in terms of its impact. Impact, in turn, depends on the customer impact and the business impact. Impact is rated with a score between 1 and 10 (10 being the highest). Also, by incorporating business impact, the framework takes care of business requirements. If the impact is unknown, the impact can be marked as “Experimental”.

One can visualize that the weightage associated with business and customer impact can be adjusted based on the stage of the company and the vertical/segment that it operates in. In the grocery business, for example, it is critically important to give high weightage to business impact because it is a low margin business (and, as a result, all tasks need to have a bottom-line impact).

Second, every “solution” is rated in terms of its effort. Effort is estimated more broadly – in terms of S, M, L, XL. One can also look at the bandwidth availability of different teams for this; for example, if a task requires a module that depends on a engineering sub-team that is overloaded, then the Effort can be marked as high.

This exercise can be made tighter by tagging each problem-solution pair via relative rating (so that not all problems are marked with “10” impact; likewise for effort). If this exercise is done for all features in an objective and fair manner, it can help quantify the ROI for all the possible tasks/features and, therefore, helps to pick the right tasks to perform.

Another option is to classify the tasks into four quadrants defined by Impact x Effort parameters (by classifying Impact as High or Low; likewise, Effort can be classified as High or Low). Based on this, the four quadrants are:

· High Impact, Low Effort: these tasks should be done first (e.g., features built and shipped fastest); they correspond to low-hanging fruits that can give huge wins quickly.
· High Impact, High Effort: these are typically strategic tasks / features. They need more thinking and detailed discussion to figure out if they are worth doing.
· Low Impact, Low Effort: these correspond to low effort experiments that might yield relatively lower benefits; these are worth doing, if there is bandwidth.
· Low Impact, High Effort: these tasks / features can be safely rejected.

BigBasket used this framework to make the right priortization decisions.This helped BigBasket to make rapid progress while avoiding the pitfalls (engineering and tech overheads) that had plagued Webvan and resulted in its downfall.

Experienced product managers would recognize that this is a variant of the more-popularly-known RICE Framework. Not only is this simpler than the RICE Framework but also provides a way to explicitly incorporate business impact and, thereby, handle long-term strategic tasks / projects more naturally. By stack ranking Impact and Effort and with the help of 2x2 matrix (across Impact and Effort), it also makes it easier to prioritize and pick the tasks / features that can provide better ROI.

[How] User Research and Lean Approach

Though this deserves a separate conversation, Tejas touched upon the following during the course of the discussion.

User Research

Tejas poined out that it is important to undersand user needs and wants by doing first-hand user research with the target personas. In the initial days, BigBasket did this by talking with several potential customers in the upper middle-class localities (such as Whitefield in Bangalore).

During the User Research, BigBasket understood both “needs” and “wants”. In the 0 – 1 phase, BigBasket focused on the “needs” and deferred working on the “wants”.

In the 1 – 10 phase, BigBasket started validating product offerings based on customer feedback. To ensure that BigBasket could iterate quickly, BigBasket teams had frequent conversations with the early adoptors and actively solved the problems/issues they pointed out.

Tejas emphasized the importance of continued User Research even after achieving Market Product Fit. In the 1 – 10 phase, for example, Tejas pointed out that it is necessary to ask sharp and probing questions in order to get to the bottom of the problem. A lot of post-PMF companies stumble here – they don’t dig deep enough to uncover the Why underlying the issues (and, as a result, don’t build the right features / products).

Tejas used the following example to highlight this point:

Let’s say a lot of users go from the homepage to the fruits and vegetable section but stop their journey there. In other words, the conversion on the fresh produce section is low.

One possibility is to hypothesize that this could be due to pricing and, to test that, run experiments by placing discount-related banners in the fresh produce section. Even if this results in better conversion, the question is: was price really the only cause? Or was it just a manifestation of a deeper cause?

In other words, it is important to dig deeper to understand the reason for low conversion. There could be other reasons: not clear return policy (which makes people uncertain about whether they can return the “spinach” if its not fresh); or, perhaps, not clear cash-on-delivery support (especially if people associate cash-on-delivery with trust), etc.

Even after formulating various hypotheses internally, one should not start building and running experiments. It is important to talk to users and find out why they are not buying fuits and vegetables. It is possible that they might want it quickly – within 45 minutes, for example. In other words, it is important to get the clarity about hypotheses by talking to users. This can help to uncover not-explictly expressed needs and wants of the users.

Moreover, talking to the loyal users is critically important. Loyal users are more likely to share how their needs and wants are evolving (such as “90 minute delivery for topping up their orders” or the unhappiness with late deliveries). This is important to not only ring-fence good users but also to continually iterate in order to ensure the continued Market Product Fit.

Learn – Build – Measure – Iterate Model

In the 1 – 10 phase, BigBasket started complementing customer feedback with the data collected by the platform. It is important to collect multiple signals about user behavior – not only the qualitative user research but also the quantitative clickstream data. Together, they help to uncover various product areas that can be improved to increase user engagement.

Multiple signals and multiple possibilities are a real challenge in the 1 – 10 phase and 10 – 100 phase; as a result, it becomes important to use a good prioritization framework to select the right tasks / problems to solve.

Tejas also pointed out that before “building”, it is better to run quick experiments to validate the hypothesis – even if the hypothesis is derived from usage-based data patterns. This is because usage patterns reveal what users are doing but not why they are doing (or not doing) certain things.

The experiments themselves can be in the form of doing surveys, calling up and talking to customers, doing a sales pitch to get a sense from customers, or building a mock-up product to observe possible user behaviour. In addition, the A/B testing is a good way to determine if any of the approaches are helping achieve the outcomes. Too many times, companies build products that don’t end up solving the core problem fully. In other words, it is important to understand the potential impact of a feature / product before starting the Learn – Build – Measure – Iterate cycle.

Conclusion

I had observed the rapid rise and spectacular fall of Webvan from close quarters. During the heady days of the initial dotcom wave (1996 – 2000), I was working at Oracle Corp (in the Silicon Valley) and a few of my colleagues had left Oracle to join Webvan (which was located in Foster City – quite close to Oracle’s Redwood Shores’ office). Peter Relan, an ex-Oracle person, was the technology head at Webvan. He identified two main reasons that caused the downfall [Techcrunch article].

· First, Webvan was offering WholeFoods experience, while the users wanted the Safeway prices. In Indian terms, Webvan wanted to offer Nature's Basket like experience but at the Big Bazaar prices.
· Second, Webvan spent too much time over-engineering and building complex backend platforms.

Conversation with Tejas helped clarify how Bigbasket avoided these mistakes. BigBasket avoided the first mistake with the help of “Who” and “Why” of the WWWH Framework and avoided the second mistake with the help of “What” and “How” of the WWWH Framework. In the process, BigBasket became one of the first companies across the world to crack the toughest e-commerce problem – inventory-led grocery business with perishable goods!

Speakers
Tejas Vyas

Check out similar topics

October 29, 2020

Driving 100 million users to adopt digital payments

Know More