Anuj Rathi (VP for Product, Revenue and Growth) is a senior product and growth leader at Swiggy. Anuj joined Swiggy in Aug 2016 when Swiggy is handling approximately 1.5 million deliveries per month. In Oct 2019, Swiggy announced that they were handling 1.5 million deliveries per day. In other words, Anuj has been part of the journey when Swiggy achieved 30x growth in 3 years!
Swiggy has been able to achieve this rapid growth not only with the help of exceptional talent (across engineering, product, marketing, operations, etc. teams) but, more importantly, with the help of a culture that is strongly anchored on “customer-backward thinking” (with high customer empathy), first-principles thinking, fast execution focused on raw problem-solving skills (complemented by strong data-driven experimentation), insane passion, and grit” (in Anuj’s words).
To understand Swiggy’s product and growth formula, we invited Anuj for the 2nd Masterclass by ProductGrowth.org. Before the session, we requested community members to tell us to know what they wanted to hear from Anuj and got the following response:
Based on the community feedback (and specific questions from the community members — both before and during the session), we had a conversation around building habits, driving scale, and effective growth architecture. It was a power-packed conversation, full of insights and suggestions about how other companies can drive efficient and sustainable growth. You can listen to the full conversation below:
Or, if you prefer, you can scan through the summary below. If you have any questions or suggestions, please do let us know by responding to this story below.
Reacting to the Covid19 crisis
Mindful of the fact that the startup community (indeed, everyone across the world!) is grappling with the unprecedented Covid19 crisis, we started the conversation by discussing how Swiggy was responding to the crisis.
This is an important question because, in the times of crisis, both the JTBD (Jobs to be Done) and GTBA (Goals to be Achieved; the “why” behind the JTBD; for example, the importance a person attaches to JTBD and other deeper requirements; see here for more details) can change dramatically. Given this, how can a startup or company respond quickly?
In this context, it is useful to highlight that Swiggy has reacted very quickly during the current crisis: starting with “zero contact deliveries”, Swiggy has launched new services to meet evolving customer needs. For example, Swiggy Stores for groceries and Swiggy Genie for instant pickup/drop service (to get groceries and other essentials from nearby stores). Given this, it is interesting to understand what has enabled Swiggy to iterate quickly and respond effectively to the rapidly evolving Covid19 crisis?
Anuj provided a two-part answer to this question.
The first one was related to customers-backward thinking. Swiggy uses a framework called “Accepted Customer Belief” (ACB) for this purpose. ACB is typically used by the marketing teams to understand how customers look at a product (and the broader product category). ACB is used to understand whether the company understands customers or not — especially, the target consumers’ frustrations of their unmet needs.
Swiggy has found that ACB is a wonderful tool for imbibing customers-backward thinking in the product teams. ACB also enables product teams to capture evolving customer needs and wants quickly. For example, before the Covid19 crisis, ACB for college students (to pick a specific persona) included: need for not-expensive food, extremely fast delivery, and desire for discounts. However, after the spread of the Covid19 crisis, their ACBs changed and were instead focused on safety (of the delivered food and the delivery partners). In addition, the speed of delivery became less important though the need for not-expensive food continued. In other words, though JTBD remained the same, the underlying requirements (GTBAs / expectations) changed significantly. In some sense, the changing environment needed a “new product” and Swiggy, indeed, iterated quickly to validate the PMF for this new incarnation of the product.
ACB framework, therefore, provides a quick and methodical way of understanding customer requirements — esp. the non-functional requirements underlying the tasks/activities they want to fulfill.
The second part was related to how to structure and organize teams so that the startup has the agility required to react quickly to a crisis (as well as the changing market dynamics, in general). We will take a look at this towards the end of the article.
We started the conversation on habits by pointing out the inapplicability of the popular Hooked framework (by Nir Eyal) for building habits for a majority of companies. The Hooked framework suggests that there are four levers for creating habits: Trigger — Action — Variable rewards — Investment. However, some of its levers (such as “action” and “investment”) can’t really be tweaked around much for a majority of the usage scenarios. Moreover, “variable reward” is also not typically available — in a lot of use-cases, the certainty of results (for example, “food delivery within 40 minutes”) is more important than the variability of rewards. In fact, non-variability and consistency of delivery is the “reward” that is valued by the customers. So, one is left only with a “trigger” as the habit-building lever! Perhaps this is the reason why Hooked framework inadvertently triggered a deluge of much-too-frequent and bordering-on-spam push notifications (“external triggers”) that did more harm than good to the companies trying their best to create the elusive habits.
Anuj pointed out that “growth hacking” — another Silicon Valley fad — is not useful either; it is typically associated with the narrow definition of growth: tactical growth focused on increasing DAUs, MAUs, etc. by running incremental experiments.
So, how can one build habits?
The starting point for building habits is to understand customer requirements deeply. As discussed above, this needs the company to understand both the JTBD and the “core assumptions” (ACBs) of the customers.
Based on this foundation, the first step is to build a product that works for consumers. This is critically important because several companies rush to increase usage by 20–30% (via growth hacking, etc.) before doing this.
Once this has been achieved, the next step is to understand the natural frequency of the activities under consideration. Now, Swiggy can consider itself to be either in the business of delivering restaurant food to customers (for example, as a substitute to eating-in at a restaurant; this would happen, say, 5–10 times a month) or in the business of delivering food (which can happen much more often because customers eat meals 3–4 times per day or 90–100 times a month).
In fact, one needs to look at the natural frequency together with the target persona (or segment). Target persona can incorporate not only behaviors and segments but also the customer’s value (i.e., CLTV). Note that the CLTV should not be the value the persona is providing right now but the maximum value they can ever provide (which, itself, depends on the maximum frequency of usage for the persona). Swiggy, for example, understands that there is a large difference between students and young professionals who are Snapchat users versus those who are not — these two sets vary significantly in terms of their CLTV (or “aukaat”, the colorful term used by Anuj). Swiggy goes further and understands that the same user can have different behaviors at different times: a user can be “speed seeker” on weekdays (while ordering food from the office) or “discount seeker” on weekends (when ordering lots of food for the whole family)!
Once the natural frequency for each persona is understood, the next question becomes: how can we help each persona increase their usage so that they get close to their natural frequency (which is the maximum usage frequency for the persona)?
In this context, Nir Eyal’s “triggers” become just one way of getting there. Another way could be building the best possible product and consistently delivering on the brand promise. This, then, gets people to start talking about the product/service and help spread the word. This can help make using a company’s product a social norm and, therefore, lead to building a habit!
With this view, habit is all about increasing the frequency of product usage until it reaches natural frequency. Habit, therefore, becomes a means to an end; the end remains to deliver value to customers and making sure their needs and goals are fulfilled.
Anuj used the example of the Super subscription program to explain how Swiggy actually leverages the above approach to habit building. Let’s look at the journey in detail.
The first question Swiggy asked was: what is preventing customers from ordering at or near natural frequency? For this, they spoke to customers who were “super users” — that is, who had been ordering fairly frequently (say, 15–20 times a month). With the help of user research, they discovered that almost all of them hated the delivery fee: either they didn’t like the very idea of delivery fee (especially because they realized they were giving good business to Swiggy) or (worse) they hated the bill shock they got at the end of the ordering session — especially when Swiggy levied higher surge delivery prices.
Second, while starting to explore a subscription program, Swiggy also looked at several variants of subscription programs: from a single-tier (paid) membership program (like Amazon Prime), multi-tiered membership program (like airline miles programs), earn-and-burn programs (like Flipkart Plus), and so on.
Third, with the goal to increase the frequency of usage, Swiggy looked at possible benefits that the membership could offer. For example, these were: faster delivery promise, higher discounts from customer’s favorite restaurants, higher overall discounts, free delivery without surge fees, etc.
Fourth, to understand how customers would react to these, Swiggy designed landing pages for various options and used them to simulate experience. Swiggy then tested various options with a small set of representative customers. Swiggy not only looked at the quantitative data to analyze how super users engaged with the simulated options but also interviewed them to get a qualitative feel about their reactions.
Finally, to choose between these options, Swiggy applied the RICE framework (where R = Reach, I = Impact, C = Confidence, and E = Effort) to perform a cost-benefit analysis and to pick the best candidate. For example, RICE analysis revealed that “faster delivery promise” not only required a lot of effort but also implied that faster delivery for super users might worsen the experience customers (because the delivery partners would get allocated to serve the super users and, therefore, might increase the delivery times for other customers). This implied that this option not only had high ‘E’ (effort) but also low ‘C’ (confidence).
Based on the above sequence of steps, Swiggy designed and launched with the current version of Swiggy Super with unlimited free deliveries, no surge fee during rains or high demand, and “free delights”.
How was Swiggy able to scale 30x in 3 years? What are the frameworks and playbooks that might be useful for others?
For the sake of the context, it is worth recalling the market landscape for the “food delivery” business in 2016. Following on the heels of the rapid growth of e-commerce adoption in 2015 and 2016, “food-tech” industry was super hot in 2016. There was strong competition amongst several energetic and skillful players. For example, there were companies such as TinyOwl (which provided beautiful user experience), Ola Cafe (which had the reach of Ola), FoodPanda (which had strong financial backing and access to international knowhow), etc. Also, UberEats was around the corner. The “incumbent” was Zomato, which had built India’s largest platform for restaurant reviews and ratings (and, therefore, had built strong network effects with “insurmountable moats”, using Warren Buffet terminology).
Therefore, there was an immense pressure on Swiggy to scale fast — while also trying to carefully balance the growth of 3-sided marketplace consisting of customers, restaurants, and delivery partners.
So, how did Swiggy grow 30x in such an intense environment?
Anuj explained that Swiggy did this by first figuring out the growth drivers and then deeply understanding the growth equation of its business.
What does this mean?
For Swiggy, its growth equation indicated that supply-side capabilities needed to be built and stabilized before unlocking the demand. More specifically, Swiggy discovered that the demand (and conversion rates, for example) was correlated with the density of restaurants in an area. For example, conversion rates were low when there were less than 80 restaurants in an area, the conversion rate increased as the restaurants increased from 80 to 225 and beyond; and, interestingly, conversion rates started falling if there were too many restaurants in an area (due to additional cognitive load as a result of too many choices, it turns out)!
Therefore, to launch in a new zone, Swiggy needed to first onboard ‘x’ number of restaurants and ‘y’ number of delivery partners and then kickstart the marketing engine to generate demand (which needed to generate at least ‘z’ orders for the engine to continue working smoothly). Doing so ensured that the customers had a great experience right from the start!
For a new zone (and a new city) launch, Swiggy uses a framework that Anuj referred to as ADS where:
Other marketplaces might also find variants of ADS to be useful to connect the supply-side drivers with demand-side drivers. This is because ADS facilitates a combination of supply-side analysis with demand-side behavior. Swiggy has found that ADS is strongly correlated with business metrics and helps to predict consumer behavior.
Anuj emphasized that Swiggy has always taken a customer-centric approach while scaling; Swiggy had resolved to scale only when the company was sure that it would not provide a poor experience to customers. This is why Swiggy had limited its operations to only 7–8 cities during the first few years of its journey.
How can other startups mimic Swiggy’s exponential growth trajectory? Anuj mentioned that once the growth equation is understood by a startup, its scale equation and growth roadmap would become clear as well. It becomes clear which levers need to be pulled to achieve scale.
Anuj also pointed out that startups should keep going back to their growth equation in order to continuously improve it. A startup’s growth equation keeps evolving based on customer behavior changes, macro-economic changes, market dynamics changes, etc.
We didn’t explicitly discuss Swiggy’s product-led brand activities. However, as part of Habit and Scale discussions, a few things did emerge that are relevant from the brand perspective.
It is important to highlight that brand should not be treated as synonymous with the brand logo or brand marketing campaigns. Brand, instead, should be considered as the tangible and verifiable promise that a startup makes to its customers and, subsequently, the product, operations (logistics) and other activities that the startup does to ensure that it consistently delivers on the promise.
ACB, that Anuj referred to, is one of the tools used in the marketing function to gain insights into why consumers do what they do. By acknowledging consumers’ point of view with understanding and empathy, startups can put together a tangible promise that not only highlights the benefits of the product but also gives them Reasons To Believe (RTBs, in the marketing speak).
Swiggy, right at the start of its journey, realized that the food delivery product needed a clear and simple articulation of its brand promise. Swiggy realized that consistency of delivery (within the promised delivery times) would help it build an early differentiator. Towards this, Swiggy launched the “Swiggy Assured” guarantee with “on time or on us” promise backed by “25% cashback” if the food wasn’t delivered within the promised duration (typically 30–40 minutes).
By consistently delivering on its promise, Swiggy had laid the foundations for building a strong brand. By ensuring awesome customer experience, Swiggy was able to build trust and unlock growth in its initial years. Anuj pointed out that Swiggy didn’t need to do any digital marketing for the first few years.
One of the observations that can be made based on our conversation was that brands can be strengthened by understanding the ACBs of the “super users” (i.e., the most engaged users). Swiggy did this while developing the Swiggy Super program; Anuj pointed out Swiggy spoke with several loyal customers while exploring options to recognize and reward the super users in the most effective manner.
An insightful side story shared by Anuj during the conversation was the unexpected benefits of running an India-wide brand marketing campaign in 2017 (when Swiggy was present in only 7–8 cities). The highly visible campaign resulted in “market spillage” and the company received eyeballs and visibility in the cities where it was not present. As a result, the campaign triggered consumers across India to download the Swiggy app to explore the service. The number of downloads from various cities, in turn, revealed latent demand across different cities. This provided useful signals for Swiggy to decide the order and priority of launching its operations across cities! Combining this demand-side metadata with a replicable go-live playbook (based on the ADS framework), Swiggy rapidly expanded to more than 500 cities by the second half of 2019.
Growth Team Architecture
How can a company structure and organize its teams so that it not only it can unlock and achieve its growth potential but also be agile and respond quickly and thoughtfully to the changing market dynamics? What has helped Swiggy to react quickly to a crisis such as Covid19?
Anuj explained the team architecture that provides a strong growth-oriented foundation to Swiggy (despite having grown rapidly over the last few years) and helps Swiggy to be extremely agile. To build and organize the teams, Swiggy looks at five parameters:
Depending on the variation of needs across these five parameters, Swiggy has five different types of teams within Swiggy:
1. Core teams: work on platform capabilities (for example, search and logistics capabilities, for example) and drive medium-term projects (such as Swiggy Pop, Swiggy Super, etc.).
2. X teams: churn out quick, incremental experiments (for example, Swiggy “takeaway counter” at airports).
3. Growth teams: explore adjacencies and other growth avenues. Growth, for example, can come from category adjacencies (for example, grocery delivery), geographical adjacencies (for example, international expansion), JTBD adjacencies (for example, bike taxis), and so on.
4. Big bets (new businesses): explore new business opportunities and respond to evolving (macro-economic, competitive, etc.) climate.
5. Labs: explore moonshot initiatives and very long-term strategic projects; for example, exploring using drones, noddle-making machines, etc.
Note that the above teams are not “two-pizza teams” or “agile pods” or “scrum teams”. Unlike these team structures (which are used to provide agility within product-tech teams), the above is more deliberate and thoughtful team architecture that provides both short-term agility and long-term competitive edge to the company.
Anuj highlighted the differences with two-pizza teams, et al by explaining that each of the above teams has different DNAs. For example:
Core team, for example, works with lots of data and thorough while Big bets team has to work with much less data and lot of intuition. Due to different charters and different focus areas, each of these five teams, naturally, have different DNAs. Since there is clarity in each team’s charter and clear expectations from each team, it is possible to pick the right processes and right metrics for each team.
Swiggy Pop and Swiggy Super, which were handled by the Core team, were thought-through and tested products when they were launched. On the other hand, Swiggy Stores and Swiggy Genie were built and launched quickly so that the product/service offerings could be quickly iterated upon and improved based on customer needs and feedback.
This team architecture makes it easier to staff various types of teams appropriately. To allocate resources appropriately across different teams, Swiggy decides annual and quarterly goals/targets and, depending on that, figures out initiatives and projects needed to meet those goals. This, therefore, helps to decide how to allocate product-marketing-tech resources across various teams. Anuj recommended referring to “Team Topologies” (link) book for more details in this regard.
This team architecture is what enables Swiggy to respond quickly to evolving marketing situations. And, it is this team architecture that enabled Swiggy to move so swiftly during the Covid19 crisis: it was able to make sure that the relevant teams were resourced properly and supported appropriately.
There are only four levers of growth for any company [link]:
In order to devise a growth roadmap, first and foremost, a company needs to understand its growth equations. Anuj repeatedly emphasized that PMs should strive hard towards figuring out and refining their growth drivers/levers as well as the growth equation. Anuj explained how Swiggy uses ADS framework for this.
Next question is: how does one come up with the right growth roadmap?
Anuj pointed out that organizations where business goals are set by the “management” and then cascaded down to teams across the organization are not able to perform optimally. If the goals flow only from top to bottom, the company is not able to leverage full potential of PMs (as well as engineers and other operators in the company) that work in the trenches and have a more accurate understanding of the ground realities as well as more realistic view of future possibilities.
Anuj emphasized that the best teams (especially, product and growth teams) build roadmaps and set goals using a combination of top-down and bottom-up discussions. Swiggy, for example, starts with a bottom-up process where teams come up with their ideas and suggest possibilities. Product leaders collate these ideas and convert them into projects. The projects are used to devise various growth scenarios. These scenarios are discussed with the senior leaders where they are considered in the context of strategic directions (such as customer experience goals, future goals and targets, competitive pulls-and-pushes, fundamental requirements, etc.). Based on the strategic directions, all the proposed projects are classified into different buckets, their tradeoffs are discussed, and prioritized appropriately.
OKR is one of the most popular techniques used by companies worldwide to merge top-down cascading and bottom-up project propagation. In this context, we discussed Swiggy’s experience with the OKR process.
Anuj pointed out that OKR planning doesn’t work well for Swiggy. This is because the growth equation at Swiggy is not simple — various growth levers are dependent of each other; in fact, various growth levers are deeply intertwined with each other.
Given that Swiggy is a 3-sided marketplace, its growth equation depends on all three moving parts. The three sides of the marketplace themselves are highly interlinked — metrics of different sides are closely tied to each other and every metric has potentially large impact on the overall success metric.
Anuj suggested that OKRs work well if a company has simpler growth equation with independent growth levers. Independent growth levers make it possible for different teams to have independent and complementary goals. Independent goals and metrics — especially when the metrics are additive (and not interlinked and interdependent) — make it possible to split company-wide goals into sub-goals and to cleanly distribute the sub-goals to different teams. Recursively, each team is also able to map its goal (the sub-goal owned by it) into smaller goals (and subsequently into potential projects). Of course, if there are some dependencies, it is possible to ensure that the teams talk to each other and resolve the dependencies.
Marketplaces with interlinked parts (and interdependent metrics) render OKR process ineffective. Anuj referred to this as the “butterfly effects” and, as an example, mentioned that a small variation in earnings per hour of delivery executive has been observed to have an impact on conversion rate (on consumer side)!
Due to the intertwined nature of its products/projects, Swiggy looks for win-win-win while evaluating possible projects. Each project is evaluated from the perspective of whether it would provide a ‘win’ for consumers, a ‘win’ for restaurants, and a ‘win’ for delivery partners.
Consider the example of Swiggy Pop, which is Swiggy’s offering of single-serve meals. Customers ‘win’ because of fewer choices and the ease-of-use. Restaurants ‘win’ because Swiggy provides predictable order requirement with partner restaurants in advance. Delivery partners ‘win’ because they are able to batch more orders and do more deliveries. And, by delivering value to each of its stakeholders, Swiggy ‘wins’.
Anuj pointed out that it is not easy to pick one or two metrics for projects such as Swiggy Pop. This is because the success of Pop relies on all parts of the 3-sided marketplace. Moreover, it is not possible for any single PM to own such a product. Projects such as Swiggy Pop needed end-to-end teams (and not just ‘two-pizza teams’ spread across product and tech teams).
Finally, Anuj suggested that it is good to consider product roadmaps with three different horizons: