Swiggy: Fast by design, not by rushing.
Swiggy promised food in 10 minutes by changing what can be ordered and from where, not by asking riders to go faster. Explore how constraints can make a bold promise both possible and safe.
See the idea in one picture ↓- the promise
- 10 min
- delivery radius
- 2 km
- cities by May 2025
- 500+
- food orders
- 1 in 10
Figures as reported by the company.
Independent educational analysis. Scenarios, people, numbers and illustrations on this page are original PMcademy practice material, not company research results or an endorsement.
A faster promise has to come from somewhere.
Faster means riders rush
Faster because there is less to do
Read the analysis
Imagine your team is asked to halve delivery time. The obvious levers are risky: push riders harder, or promise a time you cannot keep. Both break trust, one with the people delivering and one with the people waiting. The product question is not only how fast you can be. It is which parts of the journey you can remove, so speed comes from the design rather than from someone rushing.
Some hunger cannot wait for a feast.
Coffee and a sandwich. Nearby. Now.
What would help?
Something good, fast. And a promise that is kept.
What gets in the way?
Every restaurant in the city. Times that slip.
Fictional personRead the analysis
Our fictional learner, Arjun, has fifteen minutes between two meetings and wants a coffee and a sandwich. He does not need every restaurant in the city. He needs something good, nearby and quick. Ask which moments in your users’ day value speed over choice, and what they would happily give up to get it. A narrower offer can be the better one at the right moment.
Where ten minutes comes from
- 1A regular order
Most of the wait is the kitchen and the ride, and neither is easy to rush safely.
- 2Stay within 2 km
Showing only nearby restaurants takes most of the ride out of the wait.
- 3Quick dishes only
A menu of quick-to-prepare items takes out the kitchen time, so riders never need to hurry.
Animated illustration. Names, numbers and people are fictional teaching material.
Remove time from the kitchen and the road.
Illustrative data and simplified behaviour. This model does not represent a live company system or measured company results.
Read the analysis
Use the model below to compare three set-ups. In the first, any dish can come from any distance. In the second, only nearby restaurants are shown. In the third, the menu is also limited to dishes that take little or no preparation. Notice that the biggest saving comes from what you choose not to offer. The minutes in the model are illustrative.
Speed narrows the menu.
Read the analysis
A 2 km radius and a quick-dish menu make the promise realistic, and they also leave out slow-cooked dishes and restaurants a little further away. People who want those still need the regular service. Running both side by side adds complexity for restaurants, who must turn orders around quickly, and for the app, which must explain two different promises. Decide which promise is the default and how people move between them.
Count the promise kept, and the cost of keeping it.
- What Swiggy says
Swiggy reports Bolt in 500+ cities and more than 1 in 10 of its food orders.
- What it cannot prove
How often the 10 minutes is met, or the cost to riders.
- What you would measure
Promise kept, from the customer side
Rider safety and earnings
Repeat orders by Bolt users
Read the analysis
Swiggy reports that Bolt spread to more than 500 cities and more than 1 in 10 of its food orders within seven months. That is the company’s own account and does not show how often the 10 minutes is met. In your project, measure the promise kept from the customer’s side, and check the cost to the people delivering it: speed, safety and earnings should be part of the same dashboard.
What will you give up to be fast?
Your fictional team runs a grocery app and wants to promise delivery in 15 minutes. You can stock fewer items in more small stores, limit the promise to customers close to a store, or keep everything and ask riders to hurry. Choose the constraint you will use, explain how you will protect the people delivering, and name the metric that tells you the promise is honest.
Choose a next move
Leave with a promise budget.
Your artifact
Write a promise budget: each step of your main promise, what you will remove, what you will shorten, what you must not squeeze, and the guardrail that protects the people behind it.
Critique my project artifact using only the evidence I provide. Write a promise budget: each step of your main promise, what you will remove, what you will shorten, what you must not squeeze, and the guardrail that protects the people behind it. Separate observed facts, assumptions, proposed tests and missing evidence. Identify a failure mode and a cheap check. Do not invent company results or user research. Ask for my artifact before starting.
Read the analysis
Break your product’s main promise into its steps and estimate the time or effort each one takes. Mark which steps you can remove by narrowing the offer, which you can shorten with better operations, and which you must not squeeze because people would pay the price. Write the promise you can keep, the constraint that makes it possible and the guardrail that protects the people behind it.