Agile methodology, an

Industry Perspective
Aditya Jain

For IIMK EPGP participants, not for public distribution

Overview

- My professional journey
- Why Agile ?
- What is Agile ?
- Mental models
15 min Break
- Experiences from my Product Management stints
- Shaadi.com
- Amazon
- Snapdeal
- Google
- Dual Track Agile - The “solution” ?
 The 2 inconvenient truths about product development
1. 50-70% of your ideas are just not going to work
○ Customers just aren’t as excited about it
○ It’s so complicated that it’s more trouble than it’s worth
○ More expensive or complicated to build than anticipated

2. For the rest, it typically takes several iterations to get the implementation of
this idea to the point where it actually delivers the expected business value.

https://www.svpg.com/the-inconvenient-truth-about-product/
Why Agile?

● Waterfall, actually great for building buildings

○ Stable requirements: Blueprints rarely change drastically mid-project.
○ Tangible progress: Building phases are visually evident.
○ Linear dependencies: Foundations must be laid before walls go up.

● What changed with Software

○ Evolving requirements: User needs and technology change rapidly.
○ Intangibility: Code isn't concrete; functionality emerges gradually.
○ Iterative nature: Features can be built independently, then integrated.
60-80% of features are rarely or never used
Why Agile?

● Waterfall, actually great for building buildings

○ Stable requirements: Blueprints rarely change drastically mid-project.
○ Tangible progress: Building phases are visually evident.
○ Linear dependencies: Foundations must be laid before walls go up.

● What changed with Software

○ Evolving requirements: User needs and technology change rapidly.
○ Intangibility: Code isn't concrete; functionality emerges gradually.
○ Iterative nature: Features can be built independently, then integrated.
What is Agile?

● Agile is an iterative approach to software engineering

● Agile delivers value faster
● Agile teams deliver often but in small deliveries
● Agile teams deliver something useable after every iteration
Agile principles

● Individuals and interactions over processes and tools

● Working software over comprehensive documentation
● Customer collaboration over contract negotiation
● Responding to change over following a plan
My mental model: Choosing what to build

- Most of us overestimate our ability to understand consumers, take correct

decisions and build what consumers want
- The longer the planning cycle, the bigger the risk of investing in things that won’t
work, or will give much lower ROI than possible
- Testing small hypothesis quickly helps you get smarter about what to build
- Observing users react to something new is first hand knowledge
My mental model: Building software

- It’s very hard to estimate how long something will take to build
- Software engineering is more like a surgery than building a house
- Assumptions turn out to be not true
- At the start, anyone with a bigger estimate will be shut down
- Rule of thumb is that it takes 2X the estimate in general
- Co-ordination costs increase faster than the square of total no. of people building
something
- Adding more people to a project makes it grow slower as new people don’t have
the context
- Building together across timezones makes things 5-10x slower
My mental model: Building software
- Executives will lose patience and people are likely to move on to other companies or
projects if it doesn’t deliver some value within a timeframe
- Something will change externally: competition, regulation, investment etc that will
necessitate changing priorities
A better solution : Dual track Agile
The most expensive way to test your idea is to build production quality software (Jeff Patton)

● 2 tracks for 2 kinds of work, and 2

kinds of thinking
● Development track focuses on
predictability and quality
● Discovery work focuses on fast
learning and validation
● Discovery work happens
concurrently and continuously
with development work.
● The whole team is responsible for
product outcomes, not just on-time
delivery
https://jpattonassociates.com/
dual-track-development/
A better solution : Dual track Agile

Discovery is a process that precedes Discovery is a necessary part of product

agile development. development. Practice it with the same agile and
lean principles in mind

All work moves from discovery to If we’re doing discovery right, we substantially
development change and kill lots of ideas

The discovery team is different than the While a product manager, designer, and senior
development team engineer may lead and orchestrate discovery,
they must Involve the whole team in discovery
tasks wherever possible

Once you move from discovery to Keep measuring and learning even after you ship
development, discovery work done
Shaadi.com

- 2011 - 2012
- Initially PM for user sign-ups and profile completion (growth!)
- Delivered high impact in first 6 months, unexpectedly promoted to Sr. PM
- Later managing search, discovery and apps
Shaadi.com

- 3-4 week sprints

- Robust tracking of conversion funnel from site visitors to Paid users,
daily conversion report
- Important steps in conversion
- Added a photo, phone, description etc
- Sent an interest
- Received an interest
- Received >3 replies
- Converted to paid user
- Lots of wins driving up conversion
Shaadi.com

- Not everything can be done in 3-4 week sprint, some things like developing
an app, take months
- Big decisions on what to build will still be made by CXOs and VPs
- No evidence that this approach can “move the needle” for the business
- Ultimately, the business could not grow faster than internet penetration in
India or stay relevant as online dating became mainstream
- Matrimonial business model is fundamentally limited as you acquire the user
at a cost, but can monetize them for max 6 months
 Amazon Appstore

- 2012 - 2014
- Appstore was important for Tablets, which were important for Amazon’s content business,
vision was to beat Google Play on Android
- PM for Amazon Appstore App content moderation and verification, later for competitive
intelligence etc
- Learnt a lot about building products, still refer to the Amazon leadership principles mentally
- Spent a lot of my time writing about what the team has done in last X weeks
Amazon Appstore

- 3 week sprints with more of the Agile methodologies and artefacts

- Agile user stories and requirements format
- Sprint planning, lock and retrospective sessions
- The sprints were not to launch features, but more of a process with lots of
checkpoints
- The high impact launches were still planned in terms of quarters
- The small team in India was still looking for something more impactful to do,
compared to reducing developer wait time for App approval
- The sprint process ensured a lot of small organic requests came in from other
teams, but did nothing in terms of aiding learning for what to build next
Amazon Appstore

- Overall the idea of beating Google Play on Android did not succeed
- Tablets fell in importance
- Some of the software developed was then used in other parts of Amazon
Snapdeal stint 1

- 2015-2016
- Product lead for Seller Listings
- Mix of young people who joined early and got promoted fast and
experienced people who were hired more recently
- Leadership was mostly making it up as they went along
- Delivered significant impact to Marketplace health and listings, turned down
a promotion to do an intrapreneurial stint at Crisil
Snapdeal stint 1

- No sprints
- “When is it getting released” being the question PMs were asked every couple of hours
- Not enough focus on what’s getting built, more on how fast
- Projects ran over by 200-300%
- Freedom to make changes to the product, start work on new features by selling the
idea to the engineering team
- Direct managers disengaged or clueless, but could make allies within the company
with shared incentives
- Smart and driven engineers will build things, process not withstanding
Snapdeal stint 2

- 2018-2021
- Extremely data driven, all new features must prove statistical impact through A/B
testing
- Focus on profitability and selling to Tier 2 cities and low income customers
- As a whole the company almost succeeded in this period, but could not overcome the
lack of investment despite near-profitability
- Good work/life balance, not many meetings
Snapdeal stint 2

- 2 week sprints, most of which released something valuable

- Freedom to experiment, take up new initiatives, responsibility to show attributable
impact on business metrics
- Focus on data meant that bad ideas failed early and good ideas got more investment
- Connecting directly with customers led to many successful outcomes like a Pricing
engine to help sellers
- Getting feedback on what’s working, kept the engineering team motivated
Google

- 2021- to present
- Maps is a model of everything that exists in the physical world
- A lot of that data is provided by users
- What are the opening hours of this shop ?
- Does this place serve pizza ?
- Is this ATM actually here ?
- Users are merchants, contributors and consumers and have their own needs
- Contributors want to see the changes they made either reflected quickly or explained to
them why they were not made
- Merchants want to correct information for their places on Maps, also would like to
remove -ve reviews
-
Google

- Fraud and Vandalism used to be a lot more rampant on Maps

- Users trust what they see on Maps
- Fraudsters initiate the fraud by changing phone numbers and/or taking control of
the listing on Maps through social engineering etc
- Merchants pay agencies to post fake 5* reviews
- People vandalize listings by adding 1* reviews, as a way of expressing political
opinions, abusing someone etc
- With 2 Bn monthly users, it’s a great way to get your content “out there” but it does
not always meet our T&C
- Machine Learning models are the best solution to a growing volume of User
Generated Content
Google

- Maps team is 3000+ , with other partner teams in Search etc having
interdependencies
- Annual planning cycle with some correction in middle of the year
- “Sprints” still exist but are more of a status update by the engineering teams
- If a big change happens, re-prioritization typically happen among Directors and
VPs and trickles down to my level
- Aligning is the big challenge when working with multiple teams, each having a
different goal
- With Billions of customers and high govt scrutiny, downside of something bad
getting released is high and therefore a lot of approval processes
 My experience

- Most companies try to adopt some form of “sprint” driven process, like releases every 2-3
weeks, daily standups etc
- Very common to emulate the process without understanding the intent
- Most companies are still doing “waterfall”
- Important considerations
- Can you learn something new every sprint cycle ?
- Do you have the data collection and A/B testing built in to help attribute impact ?
- How will you manage executives who want to know what will get delivered this year ?
- How will you work with N other teams who all have interdependencies with you ?
- Will your technical architecture allow you to iterate rapidly ? Is it decoupled enough ?