Pods, Not Pyramids

Meesho’s real edge has always been execution. As a student of startups, I have had the privilege of closely observing what makes India’s best entrepreneurs succeed. This is not a post IPO celebration note. It is a reflection on how a young company deliberately designed an execution operating system that allowed a small team to move mountains.

Enduring companies are not built by luck or timing. They are built by design. From day one, Vidit and Sanjeev were clear that value truly mattered to Indian customers, and they organized the company to deliver on that single proposition. Over 10 years of relentless pursuit of this goal, Meesho did not try to become a behemoth organization. Instead, it built hundreds of small teams that behave like startups inside the company. These teams, called pods, turn discipline into speed and structure into freedom.

I hope this helps other young founders reflect on the type of culture they want to build, and how organizational design can unlock speed at scale.

Small teams, big outcomes

A pod is intentionally simple: one Key Result (KR), one accountable champion, and a lean five-to-six-person team, typically a Product Manager (PM), two to three engineers, a designer, an analyst, and a business owner. One important aspect of a pod is that the team is given all the resources it needs to solve the problem. They are not dependent on additional engineering, data science resources, or any other central team to make progress. If a pod needs an ML engineer for the cycle, that person is added into the pod. This full stack gives autonomy and speed to the pod.

Pods are intentionally small so that trade-offs get decided where the work happens, not after weeks of handoffs. Shared measurement also changes incentives. Everyone in the pod is evaluated on the same KR, which makes winning collective rather than individual.

Every Meesho-ite is part of a pod. Every pod has one accountable champion, and the buck stops with this person.

For example, when a pod owns ‘seller-onboarding’, the PM, engineers, designer, and analyst sit together and iterate onboarding flows, run tests, and watch the same dashboard to make decisions Instead of throwing requirements over the fence to another function, this team experiments in real time and ships improvements in weeks. It is the exact opposite of siloed structures where accountability is diffused.

How pods develop: the horizon lifecycle (H2 → H1 → H0)

Pods grow and mature through a deliberate life cycle. Meesho uses three horizons to allocate resources and structure this journey.

Horizon 2 – Experiment. For an H2 pod, the goal is a learning leap. At the start of the cycle, the team defines the hypothesis that must be proved or disproved for the opportunity to become real. The pod’s success is not measured by business output but by whether the learning leap is validated. Proving or disproving the hypothesis is considered a success, because it shapes what should move to H1.

Horizon 1 – Scale. When a thesis proves out, pods move here. H1 pods take on business goals such as NMV, revenue growth. The focus shifts to measurable growth and economic value, and pods must clear financial and impact thresholds.

Horizon 0 – Maintain. Once a capability is built and scaled, maintenance and automation move here so that H1 pods can focus on new levers.

This separation prevents the common pitfall of teams trying to experiment, scale, and maintain at the same time. Two practical rules protect the horizon model. First, no one can sit in both an H1 and an H2 pod in the same cycle. Second, numeric guardrails such as IRR thresholds, H2 caps, the one-KR rule, and headcount ratios keep autonomy disciplined.

You are either in the line of fire executing the here and now, or in a reflective mode shaping what comes next. That separation is what preserves intensity and perspective.

Example: Valmo across horizons

Most companies trying to create a nationwide logistics platform would add layers of management and create a large team. Meesho did the opposite. It created small, cross-functional pods that stitched together unused logistics capacity to deliver outcomes end to end. In three years, Valmo (Meesho’s in-house logistics platform) became Meesho’s by moat using India’s existing logistics capabilities to scale deliveries nationwide.

In FY25, Valmo handled roughly 764 million orders. In Q1 FY26 alone, it handled approximately 296 million orders.

Valmo began as an H2 experiment. Multiple small pods were created to test routing, station setup, driver-supply models, and customer promise. When those experiments repeatedly outperformed external logistics partners, the work transitioned to H1 with clear IRR and impact thresholds. As hubs matured, they →moved to H0 for maintenance, freeing H1 pods to find the next set of gains.

That H2 → H1 → H0 arc reflects how Meesho disrupts with discipline. The structure allowed Valmo to scale fast with discipline, without creating bloat or slowing down decision-making.

Composition and the one-KR rule

Meesho defines who can anchor a pod, how many pods a mentor may subscribe to, and product to tech headcount ratios, all to keep pods small, balanced, and effective. And each pod owns exactly one key result.

The one-KR rule is non-negotiable. It prevents split focus and forces clarity.

The pod anchor

Each pod has one anchor who is responsible for running pod rituals. This includes leading pod stand-ups, preparing for pod reviews with mentors, highlighting blockers to mentors, and ensuring those blockers get resolved. The anchor also helps measure and report progress so that the pod operates with full visibility. The anchor is the day-to-day force that keeps the pod moving.

The pod mentor

The pod mentor layer is made up of the managers of pod members, such as the director of product, business leader, engineering manager, or design manager. Mentors meet the pod weekly or biweekly to provide strategic direction, help with problem solving when the pod gets stuck, and unblock any issues the team cannot resolve on its own. Mentors give guidance and protect the pod’s ability to move fast, without taking away its ownership.

Example: Delivery promise pod

An H1 pod owning the KR of reducing delivery time by 20 percent included product, engineers, and analytics. With this full stack co-located, the team rewrote warehouse algorithms, tested routing logic, and shipped end-to-end changes in one cycle. What used to take months happened in weeks because the KR served as a single forcing function.

Rituals, visibility and the data backbone

Pods succeed when rituals make ownership human and visible. Each cycle begins with a simple kickoff, often just a tent card on the table with the KR printed on it. Teams meet weekly to review progress, adjust priorities, and celebrate small wins.

Most importantly, dashboards show pod-level trendlines. When a pod wobbles, the signals surface early. Mentors and champions can reallocate people, re-anchor priorities, or review experiments before issues escalate. Measurement, not meetings, is what underwrites delegation.

Cross-org problems and pods that combine disciplines

Some challenges require multiple disciplines to come together. Pods allow those trade-offs to be made inside the team, not in a long chain of approvals.

Example: Search and discovery

Search problems span ranking, catalog quality, and personalized feed infrastructure. A single pod owning the KR of improving personalized conversion by a validated percentage can change ranking logic, improve catalog signals, and track downstream NMV without a month-long handoff.

Example: Seller financing and smartphones EMI

Merchant credit requires product, risk modeling, underwriting, and BizFin economics. Smartphones EMI began with H2 experiments on underwriting and offer design. Only after the economics cleared BizFin thresholds did it graduate into H1 where scale became the focus. The horizon system prevented premature scaling of a product that did not yet have validated performance.

When pods miss: learning happens fast, surfacing mistakes

Not every pod succeeds. One initiative failed because the team split attention across too many objectives. The remedy was simple: sharper KRs and strict limits on cross-pod membership.

In another case, a pod hit its own KR but unintentionally hurt a downstream metric. Leadership adjusted the operating system so that the pod champion became explicitly responsible for downstream impact. These corrections are not signs of system failure. They are signs that the system learns.

Why this matters: Compounding outcomes at scale

Pods concentrate decision-making at the team level and replace micromanagement with transparent measurement. They allow hundreds of small teams to act like founders while staying aligned to company BHAGs. Super-pods and champions absorb cross-team trade-offs so pods can stay focused on one KR.

The result is speed without chaos, autonomy without drift, and ownership without ego.

Discipline creates freedom

As Meesho goes public, I think back to when the founders were just a handful of people chasing a bold idea. Ten years later, that audacity has transformed into an entrepreneurial system that lets thousands of people act like founders.

The Road to Red Bull (internal project name for IPO) marks a milestone, but the real achievement is this: Meesho proved that with the right structure, it is possible to serve two hundred plus million customers across India.

What I have learned from watching this journey is simple. Discipline is not the opposite of creativity. It is what sustains it. When the rules are clear, people can run freely. That, to me, is the real story of Meesho.