The early years at Meesho, between 2015 to 2020, were all about speed. In 5 years, we out-executed our own ambitions and competition in the social e-commerce market.
We became the largest social e-com platform in India, and the fastest growing e-com platform, commanding a $4.9 billion valuation.
At some point in 2020, we reflected that the speed with which we were executing had to also be channelised into levers that solved the biggest problems for our users.
We faced some challenges in making decisions as we grew rapidly:
• Time in Meetings: We were doing multiple, long updates but weren’t able to conclusively state insights needed to make decisions (the “so-what”).
• Feedback: We weren’t able to fully close the loop on important things, or course correct on mistakes.
• Prioritisation: We weren’t wholly confident of the way we were utilizing our time.
• Resourcing: We didn’t know exactly what it would take to get to our goals in time.
Over time, and a few iterations, we came up with a unique decision system that could solve these challenges. One we could easily replicate from the top to bottom.
Our Code for Meetings actually changed the way decisions were being taken in a big way.
What is our code for meetings? 🤔
Quick context first
Meesho is run under the system of few key company goals. We like to call them “Big Hairy Audacious Goals” or BHAGs (pronounced Bee-Hags).
BHAG is a concept developed in the book Built to Last. It is a powerful way to stimulate progress. A BHAG is clear and compelling, needing little explanation; people get it right away.
Here’s something to help you understand them further:
- BHAGs are big by definition: market or category defining, best-in-class, and BOLD.
- We don’t know how to reach them when we first take them.
- Once and only once the Company BHAGs are set in stone, we start breaking them down into manageable pieces and building a path to reach them (we like to call this phase our “Vision to Strategy”).
Vision to Strategy (V2S) 👓
In this discussion, teams at Meesho put on their thinking hats to decipher the biggest problems in getting to their goal.
For example, a larger team is charged with the L0 problem statement of bringing several million transacting users to Meesho (Yes, you read that right!).
They first examine the funnel of 600 million internet users in India. They then break key problems of acquisition, activation, habit formation and retention within the biggest target groups of users.
Within each part of the funnel, large problems (acquisition user cohort, channel mix, cost, etc.) are highlighted.
Within each such problem, teams would think what are the Pareto levers and resources needed to solve it, repeatedly asking the question: does the lever suggested unlock maximum impact?
Notice the pyramid way of thinking here: very top-down, very big picture focussed.
V2Ses are run annually at Meesho, and are a great way to align teams to big outcomes that we need to hit in the coming year.
We also tag big-ticket levers (not more than a handful) as 10x. 10x OKRs get a lot of attention downstream and will be discussed later.
By nature of the discussion, it is impossible to get to all smaller problems discovered and all solutions planned in the V2Ses. It is not even encouraged that we get to these, as in V2Ses, teams have to focus on the big picture all the way.
Problem First Sessions and Working Sessions 🧮
Problem first sessions (PFS) are focussed purely on L1 problems. It is here that the size of the opportunity is validated in great detail:
- Voice of Users: Is this solving a real problem for a user?
- Data: Does this problem reflect real data?
- Outside-in Benchmarks: Are companies other than Meesho solving this in? Why do they make the choices that they do here?
Continuing the above example, someone from the acquisition team may present why solving for a particular user cohort is the biggest opportunity in front of you.
These are then put through the rigour of questioning by the leadership team and others at Meesho. Usually, a lot of relevant attendees get to ask questions to the presenting team.
The reason: The earlier we punch holes in our thinking, fewer of late realizations we have. Each such decision to go-ahead has an ask on business, product and engineering time and resources. And therefore, needs to be weighed carefully.
Okay so, there’s a big problem to solve, but how do we go about it?
If the opportunity is decidedly HUGE, teams then focus on detailed solutioning in a ‘Working session’ (‘WS’). Here we build a crystal roadmap, with the most detail possible. We get into design principles, execution, wireframes, product screens, milestones, timelines and owners. We have a special section within the WSes titled “Need for Speed”, where teams have to suggest how we can create maximum impact in minimum time.
Examples include changing the MVP scope, scale or feature complexity, or solving for bandwidth (more or better resources), etc.
PFSes and WSes are run continually at Meesho, and scheduled as and when teams are ready to discuss.
BHAG Review 🧑💻
In BHAG reviews, rubber hits the road. We bring everything needed to update the company on progress: metrics, progress on 10x OKRs, highlights, lowlights, and next steps. We clarify delays and call out wins, with the aim of deriving collective insights that help us to do better the next time.
BHAG reviews are once in two months and frequency for these is changed up or down depending on the criticality of goals.
But even with all these systems in place, we realize we can make mistakes and there is a need for us to acknowledge them, correct them, and not repeat them.
Reflections 🙇
Once in 4 months, teams come together to identify stumbling blocks in planning cycles or execution cycles. Some themes that get covered include ineffective problem discovery, improper sizing of impact, wrong resource estimation, collaboration hiccups, bandwidth challenges, people problems, etc.
The best part about these meetings is that everyone is honest about their vulnerabilities and uses the forum to seek ideas from the group. It also goes a great way in creating empathy in cross-teams, who could otherwise misunderstand each other’s shortcomings.
And thus became the Code of Meetings at Meesho.
Teams across Meesho now use these frameworks to move ahead with thoughtfulness and speed. We recognise different things could become important in our growth journey in the future, so we accept these systems as dynamic and open to change 😊
If you enjoyed reading about the way we operate, you can do one of the following:
- Follow to our blog to hear more about our tech, culture and ways
- Apply to a role where you get to be part of Meesho’s ultra-cool operating system (in the scheme of all decisions, we believe this is an easy one 😊).
Credits:
- Written & Illustrated by Nikita Dawda (Twitter: @Nikdraws)
- Design: Prajeesh Panneri
- Special thanks to the former CEO’s office at Meesho for pioneering many of these concepts, and Prachi J, Vidit, Matthew D, Adithya V, Ankita S, Shreyas S for sharing useful inputs.
