Story of how Swiggy POP was built…
… from idea to go-live. In a record of 100 days!
What is Swiggy POP?
Imagine a typical user journey on Swiggy — first, you have to scroll through a list of restaurants to find ‘the’ one, second, you’ve to look through the menu to select the dish you want to eat, finally, you have to order quantities per your requirement. All this, when all you wanted to do was satiate your hunger. :)
Too much hard work?
Welcome Swiggy POP — where we curate 20 to 30 different, single serve meals from various restaurants within a fixed radius around the customer. It lets customers order a meal-for-one, at a flat price, free of any delivery, taxes, or packaging charges. POP was also Swiggy’s first Big Bet which went from an idea to go-live in a record time of 100 days.
But what’s a Big Bet?
Very briefly, Big Bet is a sharp initiative that we estimate can be done within a quarter with a visible impact on our bottom line. The idea is to have all teams focus on these chosen, few important projects each quarter and make them successful. POP was one of the first projects to be taken up as a Big Bet. POP was special not just because it was one of the first big bets we took up, but also because it required changes to all the 3 vertices of our 3-way marketplace.
And
So here begins the story of these 3X challenges; the story of POP!
Day 0: Ideas, problems, (and solutions) were discussed!
Not only do we work at Swiggy, but we’re also hardcore Swiggy users (and fans!). And hence, much like an end customer would, we also experience aspirations, disappointments, wishes, and the feeling of having that one extra feature on Swiggy! This means that many of us are very passionate about many different problems we wanted to solve for Swiggy. Some of these were:
- The complications of ordering for one person — for example, you shouldn’t have to go through the pain of choosing bread, then curry (which is usually sufficient for and priced for 2 people) if you’re ordering only for yourself!
- Delivery fee was a big hindrance for people who were ordering food only for themselves. They didn’t seem to like paying 35 bucks of delivery fee for their 100 rupee meal
- Generating predictable orders for certain dishes from certain restaurants
- Maximizing earnings for delivery executives during a day
- Having the construct of a flash sale on Swiggy! Where everyday certain dishes, from certain restaurants went on sale for a limited period of time
- Paradox of choice! How does one make a decision from hundreds of available menus?
- Unpredictable demand for restaurants leading to preparation time going higher, and hence the delivery time
- And more...
Out of all of these, one theme that came out strongly which everyone wanted to solve for, was improving the experience for people ordering meals only for themselves, remove the paradox of choice for them, and make it an affordable & quick experience.
This kernel of idea was always there when we brainstormed i.e. to solve for paradox of choice, but this was the first time we were trying to dig deeper to find a solution.
To find out the impact we could make by doing this, we looked into certain data.
So, first, we tried to understand what exactly was a one-person meal. The definition we arrived at was a combination of a certain item count and the type of items being clubbed together in the cart. To understand if there was a market for single serve meals, we found out various data points. Some of these were:
- average item count in a typical Swiggy cart
- % of orders which fit into our meal-for-one definition
- % of orders which fit into our meal-for-one definition AND were made from a restaurant offering free delivery
- % of order flows which fit into our meal-for-one definition BUT had a delivery charge applicable AND were abandoned at the cart
To build further on these insights, we conducted an experiment: giving free delivery coupons to users who were ordering a “meal-for-one”, to see if they would come back & order. Unsurprisingly, the repeat order rate for these users went up by a sizeable percentage.
Problem statement was clear — how do we make ordering a meal-for-one a quick and affordable experience?
We then broke the problem statement down into a number of smaller problems that all needed to be solved, together. These problems were:
With an unbiased mind, we decided to marry the problem, and not any one solution in particular.
To understand how our customers were solving these problems today, in part, or completely, we did a number of user interviews. We got on calls with hundreds of people and even called some of them to our office for in-person interviews. Not just our customers, we also went to our restaurant partners to get their perspective on how these problems could be solved.
In parallel, we looked at the food-tech space and tried to understand how others around us were solving these problems. Interestingly, none of our competitors or others in the space were solving it really well for single person meals. More often than not, everywhere, it was a blanket experience, whether you were ordering only for yourself or for a group of 20!
We decided this had to be solved; and POP was born.
To make it clear to the reader, it wasn’t as straightforward as finding a few problems and merging them together to form a feature. :) We did fiddle with a lot of different problem statements along the way, and we also made certain trade-offs and tough choices.
Day 9: PR & FAQ was written
What’s a PR & FAQ?
PR & FAQ stands for Press Release & Frequently Asked Questions. With a PR-FAQ, the expectation is for PMs to go in the future, imagine their product was already launched, and write down a Press Release the way they imagine newspapers will cover it when their product really launches. To keep this realistic, PMs actually add quotes from their ideal customer, from business & ops team at Swiggy, and various impact numbers they intend to achieve on launch.
(Credits to Amazon for this, from where we picked this practice)
Each line of PR is thoroughly critiqued before presenting it to the leadership or the wider audience as it ultimately becomes our decision to make the blueprint when building products. Things like value proposition, price-point, the GTM plan which includes expected date of release, areas in which we’ll be launching, and more, are all put down in this PR-FAQ to help us come up with an exhaustive list of product requirements.
From this PR-FAQ, POP was finally conceived as a dish-first product offering a menu full of single serve meals at a flat price inclusive of all charges. Through POP, we wanted to solve for affordability, discovery, selection, and ease of ordering of single serve meals. It was decided that POP would sit inside Swiggy at a prominent position and would surface 20 to 30 different, affordable, daily changing, single serve meals, with no extra charges, and a quick checkout experience.
We went to solve one problem, ended up solving three!
For POP meals, we wanted to give free delivery to our customers. This meant that we had to find a way to make POP meals economically sustainable for Swiggy. So instead of opening up just about any meals from any restaurant, we decided to make manual polygons in the entire city such that distance between any two farthest points in these polygons was less than 3 kms. The next thing we did was that we manually curated certain dishes from certain restaurants within that polygon. This did 3 things for us:
- Choice making for customers became super easy!
- Since restaurants got predictable orders, they were better prepared to handle these. This also meant that a Delivery Executive’s wait time at the restaurant reduced down to just 1 to 2 mins, cutting the total delivery time for customers significantly!
- Also, since we were getting multiple orders from the same restaurant during pre-defined time slots, the probability of batching two or three orders together went up.
How the 3-way marketplace benefit from POP?
For customers, POP took away the paradox of choice. Everyday, on POP, we curated tens of different dishes from a variety of restaurants in the customer’s neighborhood. Not only did this reduce the hassle of sifting through a list of restaurants and menus, but it also removed all doubts around the portion size.
Since, for POP meals, we got rid of any extra charges (delivery fee, packaging, or taxes), this was also an affordable way for customers to order meals all day, every day.
As far as restaurants were concerned, they were happy that something like POP was going to be up there soon. It gave them:
- A dedicated real estate to showcase their dishes
- A way to build predictability in demand (and hence inventory) for certain dishes at pre-known time slots
For our delivery executives, POP served as a boon too! Since the serviceability radius was reduced, Delivery Executives could do more deliveries in a single hour. Also, since we were getting multiple orders for the same dish from the same restaurant, POP gave us the ability to batch orders allowing our Delivery Executives to do more than one order in a single trip. Additionally, given that we had struck a deal with restaurants for these dishes, restaurants were better prepared to keep these semi-ready and hence the preparation time and in turn the wait time at a restaurant for Delivery Executives went down to less than 5 minutes. All of this helped optimize for a Delivery Executive’s time, allowing them to do more deliveries per hour, in turn helping them earn more.
Win, win, and win! :)
Day 15: We started sketching the solution…
For POP to become successful, it was important that we were able to communicate its value propositions through the in-app design.
To make the ordering experience quick & seamless, we designed in such a way that it took an average customer less than a minute to order on POP. For that, POP’s discovery on app had to be right at the launch, and the experience just one click away.
And so, POP found its place on the bottom of the home screen, in form of a big circular button within the footer.
Second, to help customers make quick decisions, we had to help them with more visuals — it was decided that each POP meal would have an accompanying image.
Third, since we didn’t intend to add any packaging charges, taxes, or extra delivery fee on POP meals, we didn’t require a separate cart page. And hence, to make the checkout experience super convenient for our customers, we also auto picked their preferred payment method. This meant, that they could place an order for a POP meal just by swiping one finger.
All this done, an average POP ordering experience was a total of only 3 clicks.
Day 32: A wall was put up!
Every product review meeting at Swiggy starts with one sentence,
“Show, Don’t Tell”
Which also happens to be Anuj’s (VP, Products) favorite sentence. His next favorite being
“कस्टमर को क्या दिखेगा?”
And so, a huge wall with cuttings of the entire POP flow was up. It was there for anyone & everyone to come view what a customer would see at each step in the funnel and be able to visualize the complete journey. Also, as a rule, no lorem ipsum copy could go there. The wall had to mimic exactly what the customer would see — each dot, each comma at its exact, correct place.
The wall was also used to get the leadership and other stakeholders alignment on the design and information architecture of POP. If anyone had a question on the user flow of POP, one look at this wall would answer all their queries, with ease.
Day 34: Metrics (and check metrics) were defined!
As a culture, we don’t celebrate launch of products, we celebrate their success. Hence, even before a project goes into development, its success criteria is defined. For POP, we put together an estimation of the various metrics we intended to move and the metrics we wanted to keep a check on.
As an example — one of the success metrics for POP was to increase the repeat rate by 10%. And one of the check metrics was that in a single order the preparation time should be less than or equal to 5 minutes (this, for the entire batching math to work).
Day 35: A 70-page PRD was written!
And hundreds of comments & questions were posted on it within a few hours by everybody from leadership, engineering, design, PMs, and even those who weren’t working directly on the POP product! Some comments were resolved, some were scoped out for later releases, and some were marked as misses in thinking which were immediately accounted for.
Day 39: MVP was scoped
Not everything that was mentioned in the PRD needed to be coded right away. And neither did we want it to happen like that. Here, we sat down with our super talented engineering team who helped look at all our requirements from a tech standpoint, helped us through the edge cases, and in understanding various trade-offs and where it was ok to cut corners. During this process, many a times, we consciously also chose speed to market over the perfect product which could have otherwise taken 6 to 10 months to build. It was necessary to define what is the minimum that we could build which would delight the entire ecosystem to the maximum extent possible.
What helped us scope the MVP right were two things:
- The PR-FAQ which we wrote long back! It became a blueprint for our prioritization process — anything which we talked about as a benefit to the customers, the delivery executives, or the vendor partners in the PR & FAQ had to become a part of the first version.
- As a rule of thumb, customers trumped internal users. Against each requirement, we identified whether the particular requirement would make lives of our internal users better or our customers better. Anything that made customers’ lives better was always chosen over internal team requirements.
Day 40: GTM was defined
As part of our Go-to-market strategy, among many other nuanced details, we also clearly identified the launch city and area, our first set of restaurant partners, and the exact dishes from them.
This meant that even before development started, we had the exact view of how the POP menu page would look like on the day of launch.
Day 45: Engineering began!
And this day marked the starting of the most important part in the journey — the actual building of POP.
With a bias for action, this being one of our core values at Swiggy, engineering team put the cooker on stove, and the baking started in the ovens. Coding began! And a huge engineering gantt was prepared which exactly accommodated for each pod’s effort, analytics & data instrumentation requirements against each moving part, relevant QA checks, and also the frequency and pace of various milestones and internal demos for the entire POP program.
After a rigorous job from our engineering team, who ultimately gave life to all the ideas, theory, and designs, POP was ready to be launched.
Day 90: Bug Bash Happened
For the first time, we also did a company wide bug bash. In this, everyone was given a demo build with POP on it and was asked to go through the end-to-end flow of POP, find bugs, and report them. Of course, there was bounty for those who logged the maximum number of bugs and for those who logged the most pesky bugs. :)
The philosophy behind a bug bash being that QA in a B2C company is everyone’s responsibility. After all, all of us at Swiggy are not just building Swiggy, but also using it day in and out, much like our customers, to order for our meals.
Day 100: And finally POP was born
On the day of launch, we opened up POP only in Koramangala, Bengaluru, and for just 5% of the customer base. At 2.5% adoption rate of the app, when the first POP slot went live, we got 20+ orders within a few minutes. :)
Today those numbers stand in multi-thousands of orders per day. And here’s Swiggy POP team celebrating the launch ;)
Day 101: And the journey continues…
POP continues to be launched across India, one polygon at a time :). And we are also continuously optimizing various funnels in the POP journey to improve the offering.
Now you must be wondering that POP was a Big Bet one quarter, what now? How do the various optimizations get prioritized for POP now? And how do we even get alignment, resources, and people to work on POP?
Well, a few months after we experimented with the Big Bet way of prioritizing, we realized that only having a few Big Bets, each quarter, was not enough. Given the name and stature, without really communicating explicitly, Big Bets became the de facto way of getting things done. If something had to find attention & resources, the only way was the Big Bet way. Of course this wasn’t the most optimal thing to happen. And a lot of long term initiatives, tech scaling and optimizations were getting ignored because of this. Hence, to give visibility and opportunity to various kinds of projects, we have revised our prioritization structure to now include 3 more BBs, making it a total of 4 BBs, namely, Big Bets, Bread & Butter, Brilliant Basics, and Breaking Bad.
Any smaller tasks that are improvements, optimizations, and features that take 1 to 2 sprints are all added in a Bread & Butter backlog. These are prioritized separately, and added into engineering sprints periodically. Brilliant Basics are any optimization or platform improvements to make technology powering all our systems, robust, scalable, and powerful. These run for anything from 3 months to a year. The last, Breaking Bad, are projects that can be classified as anything outside of current Swiggy scope — yes, interesting things are being cooked here.
Today, POP optimizations form part of a steady stream within the Bread & Butter backlog and are prioritized across different teams within their sprints as and when required.
In closing, here’s some Twitter love we gathered ❤
Bonus section:
Wondering how Swiggy POP got its name?! Here’s how:
The idea behind POP was to make meals-for-one an affordable, quick, and seamless experience. In more crude words, the idea was to make it as simple as putting a slice of bread in a toaster and waiting for it to POP out a warm & crisp toast. :)
Hence, we wanted a name which was short, crisp, and had the feeling of simplicity, and agility attached to it. “Why not call it POP?!”, someone in the team had a hallelujah moment. And it immediately struck a chord with everyone in the room. :)
POP being a short name, went well in our branding, in-app buttons and various promotions we did. Also because POP is a single syllable word with vowel sound of o (as in /pɒp/), it was also easy to pronounce and it rung beautifully well with Swiggy with vowel sound of e (as in /ˈswɪɡi/)
Try it in your head, say Swiggy POP, and tell us how you like it. Or better yet, order a meal on Swiggy POP, and tell us how you like it. :)
P.S. If you read through the article, we are hoping you learnt a thing or two. Do tell us the favorite product management lesson you picked from this story in the comments section below.
P.P.S. We are on a lookout for super awesome product folks to become part of Swiggy’s success story and help us build even more amazing products. If you’d like to join us in the mission, do reach-out.
Here’s a quick slideshow of the story, which Anuj, Swiggy’s VP Product, recently presented at a HelloMeets event.
