Hellomeets - 15th November

Shipping high impact
products, fast
Abhijeet Gaur
Sr. Product Manager, Razorpay
Product Lead, Razorpay Thirdwatch

About the speaker
Joed z as  AP
Wal Gawa
Ingatos:
Gole y, Amon y
Raray co Si
Laced san Rens
Ma,
2018
Agut, 2018 Mot  2018 an
2019
Apl,
2019
Afrabit Patr
Pot-Pamt Patr
Rens, ec an
Setmet
Ocbe,
2018
Setbe 2019
- Pest
Raray hidth
Apl -
Setbe, 2019
@abhijeetgaur16
linkedin.com/in/abhijeetgaur16

This talk will be relevant for you if:
1. Are looking to transition to a Product Manager’s role and can’t decide if it’s your jam
2. Have successfully transitioned to Product and are questioning your life choices
3. Recently started working as a PM and impostor syndrome is running high

What I am going to talk about:
1. Writing and using OKRs for the Product’s beneﬁt
2. Using Data and building a discipline around the same
3. Writing good PRDs
4. Solving for Uncertainty: Taking Product to the Market
5. Learning new things at the job

Step 0: The PM Career Path
Time/Experience
Title
Associate PM
Product Manager
Sr. Product Manager
Principal PM/
Associate Director
Director
VP
CPO
Not really an effective way to internalise - Varies from companies and domains.
Good for HRs mostly and LinkedIn proﬁle views

Step 0: The PM Career Path - A useful way to look at it
Responsibilities
Building features within a broader
product or a platform
Features with significant complexity
or nuance
Multiple complex feature areas with
say on on overall product strategy
and outcomes
Multiple products or product lines
with company and industry-level
impact
Large product area with a
firm’s domain specific impact.
Also people management-101
starts here

Every PM’s appraisal discussion ever...

The Position of a PM
1. Communication => Coordination
2. Coordination => Timing
3. Timing => Product Success
Applies to all kinds of Product contexts

Making Sense of the Chaos: Designing your Arena of Operation
Product Metrics
OKRs
Communication
L&D

OKRs : Tenets of building an
arena for product success

Communicating Before you start anything: OKR Framework
Objective-Key Results Framework - First Principle
1. Simple to understand. LMGTFY
2. Quantiﬁable OKRs => Easy to understand and assess.
3. Solves for cross-functional dependencies before they arise
4. Also, quite easy to get wrong

Bad OKR examples
● Written vaguely, talk mostly about building and launching products
● Difﬁcult to quantify - impact assessment is a challenge
● Not-aligned to Customer success or happiness
● Not aligned to core Business unit goals

Example
- Build XYZ feature to improve customer engagement
- Introducing ABC capability in the system
- Launch and roll-out feature on X number of users
Why are they bad?
- Building is not an OKR. It doesn’t solve a business goal. The outcome needs to be
measurable to assess impact
- Launching and rolling-out is in your control. What does that launch and roll-out
achieve? What was your goal?

Product Consideration: Razorpay Thirdwatch and Instant Refunds

Core Instant Refunds OKR:
- Reduce end-to-end Refund time to X seconds
- Reduce 99th Percentile refund processing time to less than X minutes
- Achieve Y% coverage on total payment channels for Instant Refunds
Core Razorpay Thirdwatch OKRs:
- Achieve an overall X% Precision and Y% Recall for the Core AI Engine on RTO
Prediction
- Increase overall approval rate for Thirdwatch red-ﬂagged Orders by Z% on Core
AI engine
Good OKR examples

Okay, I’ve set the OKRs, now what?
1. Sell OKRs to stakeholders. Thump your chest. Shout. Mail people. Inform them. Get a
sign-off. Execution should only start till you get an agreement.
2. Do step 1 again till it’s clear to <i>everyone</i> what you’re doing.
Note:
Good product organisations rely heavily on OKRs for cross-functional alignment.
It’s a great way to ensure collaboration at scale in high growth products

Understanding your Metrics
Data is your best friend: Understand how it ﬂows in your product. Understand if it captures
your customer behaviour
Litmus Test of any Product metric:
● Question the existing conventions ﬂoating in the Org for the same
● Think in terms of levels of information conveyed by a Metric
● Movement of the Metric: True and False Impact Scenarios

For Example:
Refunds in Razorpay - Success rates of Refunds are always above 99.9%.
- Success Rate becomes a vanity metric
- Smarter Metric to Measure: 95th, 99th Percentile for total time of Refund
processing [L1 Metric]
- Align Operations and Tech to solve for reduction of TAT at Payment Gateway level
itself [L2, L3 Metrics]

Understanding your Metrics - (Contd.)
● Think: Alignment of Metric the context of Activation, Engagement, Retention and
Monetisation goals of the user/product
For Example:
Razorpay Thirdwatch: AI Engine Performance - How to measure?
- Effect of False Positives: Reduced customer trust on the product
- Coverage on total Frauds identiﬁed: Denotes reduction in cost by the product

Okay, I know a lot about Metrics. But where will that help me?
The Data Discipline
- Product Focus: Are we really solving the problem?
- Problem Discovery: Is there something that we are missing?

Okay, I know a lot about Metrics. But where will that help me?
Tip:
- Deﬁne dashboards for your key product Metrics:
- Set it up on your BI tool or redash or run a query yourself. Doesn’t matter.
- This should be a no-effort view of the key product metrics
- Most BI tools have a Slack integration. Leverage that.
- Publish Weekly Reports to all stakeholders on key metrics update

1. PRDs are not just meant for Engineers: They’re meant for everyone.
2. Lengthy. Bulky. Tough to gather a quick 10,000ft. View of the solution
The Problem with Product Requirement Documents
Length of your document
Likelihood that
your Sales
team will ever
read it

Introducing Concept Notes and User Stories
Concept Note
7-8 Page Doc that brieﬂy covers -
● Problem Statement
● Goals and Non-Goals of the Product
● Customers
● Assumptions
● Alternate Solutions
● Solution Summary in Flowcharts/high-level diagrams
○ Edge-cases to be handled
○ Happy/Unhappy Flows
● Impact Assessment and Metrics
● Future Scope
Note: This needs to be written in a highly readable language by ANYONE in the
Organisation

User Stories
Detailed Solution Requirements, broken down at an actionable engineering task level.
1. All conﬁgurations you’d want to see on the Product
2. User Flow breakdown in the format:
a. “As a User X I want to see Y Functionality in the product”
b. This is further accompanied by Acceptance Criteria of the Product
3. Easy for you to bargain with Engineering on execution

Advantages of User Stories - Concept Note Framework over PRDs:
- A small cluster of User Stories => Easy to Communicate
- A fast barebones MVP Launch of the Product
- Non-Technical folks in Company can consume Concept Note to understand
solution
- Incremental changes in the Product => Gradual Scale-up stories, added on top of the
MVP conﬁgs itself
- Direct Translation of a User Story into JIRA tickets
- [Engineers are deﬁnitely going to hate you for that tbh, but great for bargaining
on Timelines]

GTM - 101
That one thing that you’ll deﬁnitely get wrong at least
once in your career

Launching a Product
1. Product Launch Strategy needs to be part of your Product Conceptualisation
2. Heavily reliant on multiple things going right at the same time
3. Like OKRs, quite easy to screw up but with little or no chance of recovery

Tenets of a poorly planned Product Launch
1. Uncertainty in timelines
2. Lack of Awareness of Key product stakeholders : Marketing, Sales & Operations
This leads to:
● Release without Product being ready = High number of inbound requests and
angry customers, frustrated Product Operations
● Product ready but no GTM = Stagnant Product OKRs; lack of excitement; dull
release

Tenets of a good Product Launch
1. Everyone: Marketing, Sales, Operations, Engineering is certain on the timelines
2. Adherence to the GTM Strategy decided during conceptualisation
3. Channels for customer acquisition and product discovery are set
4. Relevant Knowledge Transfer sessions are completed before Product release
5. Channels for Product Feedback are deﬁned
a. Metrics are visible from Day-0
b. MVP/Pilot Customers

Tl;dr
It’s mostly about good communication. At all levels.

Next Level Lessons an executed GTM will teach you:
1. Understanding difference between Product-Marketing and Product & Marketing
2. Success of Product == Happy Users; How to avoid Vanity Metrics from Product
Launches
a. Early Traction != Product Success
3. Importance of Retention: Identify Secondary and Tertiary Retention Metrics
a. D-7, 14, 30 Activity of Users
b. Upsell of other products and core product usage
c. Understand Product Growth

Case Study: Launch At Scale for Instant Refunds
Strategy focused on fast scale-up:
1. MVP Launch for Key Client ABC - Barebones product launch with minimal features
2. Post MVP, Product components that were reﬁned for Phase 1&2 roll-outs
a. Alignment of Docs for Integration
b. No-Code Integration KTs for Sales and Key-Accounts teams
c. KT Sessions for Marketing and Operations to manage inbound traction
d. Post that, parallel execution on Social Media, Ad Campaigns
3. Selling to existing customers vs Selling to new customers
a. Product Discoverability
b. Self-serve enablement Introduction at scale in Product ﬂow

Case Study: Launch At Scale for Razorpay Thirdwatch
Key Product Challenges:
1. Diverse Customer Persona
a. SME
b. Mid-Segment E-Commerce
c. Enterprises
2. High Education product:
a. Figuring out correct branding language for Marketing
b. Sales Training: Keyword driven Sales pitches
3. Pre-Product Market Fit Problem Discovery:
a. Mainly driven by Customer Interviews
b. Bets on Ideas that increase early Product engagement

How to become a better Product Manager?
- Figuring out the Framework
- Figuring out the discipline
- Staying Motivated
- Awareness: The X-Factor

Framework Discovery
Ways of looking at the Problem:
- Discover Users
- Discover Metrics
- Set goals. With Conviction.
● Top-down vs Bottom-up Strategy
● Inside-Out vs Outside-In

Framework Discovery Examples
● Refunds Problem
● Reconciliation Challenges
● Thirdwatch User Persona Discovery

The Discipline
Toughest to Crack
- Start with Data
- Calendar driven day
- Limit extra communication
- Prioritise Execution time and Problem discovery time

Motivation
It’s easy to face a burn out as a PM. Avoid that at all cost.
● Work smartly - Efﬁciency is critical
● Mentally prepare yourself for the following scenarios:
○ Stagnant metrics
○ Bugs in Production
○ Angry customers
○ Internal Escalations
● Also, do follow Naval Ravikant on Twitter

Awareness: The X-Factor
Effective Modes of Learnings
- Twitter: Tech-Twitter has some really smart folks from the valley
- Easy to get recommended Blogs, Articles from Twitter itself
- Books: Learn to read fast and learn more
Note:
Exploring Podcasts these days. So, no recommendation yet.

People/Accounts to follow on Twitter for Product Management related gyan
- Shreyas Doshi (@shreyas)
- Eugene Wei (@eugenewei)
- Andrew Chen (@andrewchen)
- TheProductFolks (@TheProductfolks)
- Diwakar Kaushik (@Pentropy)
- Ankit (@ankitkr0)
- Palak Zatakia (@palakzat)
- Vindhya C (@vindytalks)

Some books that’ll really help you out [dynamic list]
- Good Strategy/Bad Strategy - Richard Rumlet
- Super Thinking - Gabriel Weinberg
- The Lean Startup - Eric Ries
- Crossing the Chasm - Geoffrey R Moore
- Sprint - Jake Knapp
- Don’t Make Me Think - Steve Krug

Hellomeets - 15th November

More Related Content

What's hot (20)

Similar to Hellomeets - 15th November (19)

Recently uploaded (20)

Hellomeets - 15th November