Building PhonePe | Shreesh Vurutha & Sudhanva Rao (PM Directors at PhonePe)
All about building in fintech with a product first culture
Welcome to another edition of The Product Roadmap!
Today we speak to Sudhanva Rao and Shreesh Vurutha from PhonePe, an iconic Indian company in the payments and financial services space. Both Sudhanva and Shreesh have been part of PhonePe’s journey from early on, and offer unique insights into the fintech space in India, working with regulators, being a PM in fintech, and PhonePe’s tech and product first culture.
We chat about
Building capabilities vs building use cases
How PhonePe thinks about building reusable systems - building for scale from Day 1
Why PhonePe is a great place to work - product & engineering culture
About patience in building products
PMs getting independent charters - how pods are set up, PM responsibilities & evaluation
PM Hiring Process - shortlisting, interview process, skills to look for
Working with business teams - how metrics are shared
Working with regulators - examples of innovation under constraints
—
Introduction and Building for Scale from Day 1
Mithun: So, first question: When did you guys join, what did you build first, and what are you working on now? Go for it."
Sudhanva: I joined PhonePe 7 years ago. When I joined, I was essentially the app product manager for PhonePe. At that time, the product team at PhonePe was pretty much non-existent. Our CEO, Sameer, who is also the co-founder, was doing a lot of the consumer product work. So, in terms of consumer products, actually converting our platform capabilities (like payments systems) into user-facing products, there was no one in that role, and I was just shoved into it. I started off by working on a bunch of very basic features for PhonePe, like getting our notifications going, structuring the app, syncing of transactions, filters, new category launches, autopay launches, a bunch of basic things just to get the product working. That happened for a good one and a half years.
Mithun: So essentially you built the initial set of consumer facing flows.
Thinking capabilities and use cases
Sudhanva: Right, like whatever feature you saw on the app, I was somehow involved in it.
The way products are built at PhonePe is - capabilities first, then translated into consumer flows. For example, the core payment system itself was a server capability. The way autopay is built is - entity 1 has to make an automatic payment to entity 2. Getting user inputs on what those entities are, how that thing is managed, minimum thresholds, maximum limits, notifying users - all of that was the consumer product. The autopay capability had to get translated into a consumer feature. So, that was the role I was playing for the largest part.
For example, if we were launching electronic gift vouchers (EGVs). So, what does that mean for a user? Where do they go? How do they top up their card? How do they redeem it? Where does it show up in the payment path? What is the first debit algorithm - which instruments do you debit first, which ones do you do later? All of those capabilities have to get translated to something that a user would actually see on the PhonePe app. So while the server teams are building core capabilities, they tried to make sure these capabilities were always built in a generic manner, going beyond the single use case that they might be building for at that particular point in time.
And at least in my opinion, that's what really helped PhonePe scale. Because whenever we picked up a capability to build on the server side, it was never 'Hey, there's this problem statement I want to solve' or there's this use case that I want to solve. It was always made into a more abstract problem statement. And that’s why our core systems from back in the day are still in use right now.
Mithun: That’s interesting - it throws up a question about prioritization though. How did you prioritize features in PhonePe at that time?
Sudhanva: I think a use case would make folks start thinking about what capability needed to be built. But once you identify a use case, the thought process then was - ‘how do I make this a little more generic and extensible?’
Building tech systems at scale was a prerequisite at PhonePe. Today, we have so many users that we have to build for scale, but even back then it was clear that if you do not build for scale, you will face critical problems later on.
Mithun: That’s very strange - that’s almost the opposite of the approach that is popular today which is to hack together something and see if it works before building for scale. What do you think prompted that?
Sudhanva: A lot of it was down to the founders and the early team; they were very engineering-focused. The founders and the early engineering team were adamant about building it once and building it right.
Don’t get me wrong, both of us have faced tough feedback from our team. We had to be very sharp about the problem statement that we were solving for. In my area, it was largely about customer acquisition. And then the server-side team was very strict about scalability. If a solution didn't scale from day zero, they simply wouldn't build it. It wasn't a matter of 'let's see in 3 months'; it was 'I won't write a line of code until you change the flows to prove it can handle 100 million users.' This was a strange concept because we were at 1 million users back then. Coming from Urban Ladder, where a few thousand transactions a day was significant, this scale was unimaginable. These guys demanded solutions for 100 million users.
Now, over time, I've realized that founders need to have a certain level of irrationality. Sameer and Chari, for instance, never doubted they were building a product for hundreds of millions of users. They were unwavering in this belief. They pushed for quick, effective development, focusing on a tight MVP. But they never criticised us for taking the time to build something the right way.
Building reusable systems
Sudhanva: Now of course we have moved from customer and capability views to the pod structure. In the pod, the thought process is that the PM owns the end-to-end product, from the user flow to the actual capabilities. That's when I started working on two new problem statements for PhonePe. One was defining the identity of a user on PhonePe. Things like login, authentication, the profile of the user, consent and privacy more recently. And just managing the life cycle of that user, you create a user, you have them active, you deactivate that user, all of that. So that is one part of the product I managed. And the other part was P2P transfers, like entering a mobile number and making a payment using UPI.
And in that path, whenever we had a use case, we would still build capabilities. That's how a lot of the work that both Shreesh and I have done have kind of intersected. For example, for the P2P product, we built out this entire chat interface. And the system that powers the chat interface is the same system that also powers a lot of CRM flows which Shreesh has been responsible for at PhonePe. That's something that came out of our discussions with engineering. Our engineering team said - there are two entities and a message has to go between them. I don't care what those entities are; it could be a user, an app, a business, or two servers for all I care.
So now, that same system powers chat, notifications , and what we call app instructions where the server tells the app a bunch of things to do. Like, sync this thing, drop this DB, block these flows, update a bunch of things. So config updates, all of it, is the exact same system that is powering it in the backend.
Mithun: That is some fantastic reusability of core systems.
Now switching quickly to Shreesh - tell us a little bit about your journey at PhonePe?
Shreesh: Yes, so I have been here six years now. And, through the course of these six years, I've been working on the PhonePe marketing technology stack. One of the problems we had in the early days at PhonePe was that we needed a lot of inorganic growth to kickstart the business - specifically cashbacks and incentives were the primary lever of growth to seed and drive behaviour. I initially joined to build the offers program, which includes their offer backend platform, their rewards loyalty program, their referral program, all of that kind of stuff.
Then afterwards, we started getting into the other side, which is retention. So we've got all these offers to try and acquire customers and seed behavior, and now you need systems to retain them, which is what we internally call a CRM. It is like our own internal version of MoEngage or CleverTap. We ended up building that, and that's the second part I was in charge of. Over the course of the last three years, I also worked on advertising solutions.
Why is PhonePe a great place to work?
Vibhav: I had a question, which is unrelated to your product work. What has made you guys stay for so long at PhonePe?
Sudhanva: Very honestly, whenever I get bored, I have been given a new problem statement that I can work on, which has kept me excited. I was doing the app flows, then I worked on the core platform side on the user account, which was completely new for me, I had never worked on any platform product back then. I then got complete ownership of the whole P2P module as well. Very importantly I also got a lot of backing, from the team and the leadership, both Sameer and Chari. And again, I was getting bored, and then I moved to Pincode, which has been a completely new problem statement.
Shreesh: I think I can +1 on what Sudhanva said. I would add that it’s actually a great team to work with. I think it has the triad of: a great quality engineering team to really build good stuff; founders who've been doing this for 20 odd years, which means they're patient about product vision, they're impatient about execution, which is a good and tough balance to find. And the third thing is that it's always been interesting because there are always new problems thrown at you, be it scale-related problems, or functionality-related problems. Both me and Sudhanva started off as the product noobs just thinking user flows and technology capabilities, and we've come to a place where we can sort of tie it together all the way into actually running a business.
Patient about vision, impatient about execution
There is almost like this sort of sagely patience about how products and markets are created
Sudhanva: I just want to add on to the patience aspect. I think the chat product I've been talking about took a year or a year and a half to launch. For most transactional companies that build such products, that's usually the start of the demise. But we scaled after that. Today we have a lot of users using chat. This is all coming from the founders; they're okay to spend a year, a year and a half on products.
There is almost like this sort of sagely patience about how products and markets are created. That being said, both of us have had to make sure we deliver on metrics while we are taking our time to build stuff. We've always come up with small hacks and features and updates, whatever trick we could pull to make sure our monthly metrics are met, and outputs do matter.
Setting up Product Teams
We try to give PMs very meaty, independent, fully enabled, fully sponsored charters.
Vibhav: Can you talk us through a little bit about how your product team is set up?
Shreesh: Ok one thing that product folks find great about PhonePe is the kind of roles we have and how we set people up. We've seen different companies say things like, you're part of this part of the funnel, and you're part of this part of the product. At PhonePe we don't build it like that. We try to give PMs very meaty, independent, fully enabled, fully sponsored charters.
Vibhav: Can you give an example of something that is like that in your team?
Shreesh: Yeah, I can. When we were building the marketing automation platform, I was the one who seeded it and built it for about a year, and then I hired someone, and she's been doing that for about two and a half years now. One of the interesting learnings this individual had was - how do you use the same marketing automation technology and not just serve one app but serve the three or four apps that PhonePe's launched recently? So you always have this very interesting learning between financial first learning, technology first learning, stack first learning - if you're really technologically inclined. So the learning never seems to end; that's number one.
And number two, there is also some degree of independence of working. I think the horror stories in product / tech are most often that people in the product team are given the problem, but they really don't have the resources or technology to solve it because it's spread between ten things. At PhonePe, we try and reduce the dependency as much as possible, so that the PM has access to 80% of the resources required to solve their problem. They're in control most of the time.
Sudhanva: This is not just the engineering, even the design team, and the alignment from the business teams, and even budgets when it comes to it. We've not obviously got it right 100% of the time, but we really try to make sure that every PM is the owner of a problem statement and not a feature. There's no feature that a PM ever owns; it is a feature that they come up with to solve a problem statement.
Within Pincode, for example, we have catalog management as a charter given to a particular individual, and what they're expected to do is come up with the right metrics to measure success. That’s where as a PM manager I come in saying, 'You know what, your metrics are off; this is not the best way to think about it’. But once that is aligned, it's the PMs job to make sure that he comes up with the roadmap to actually improve it. This is one thing that the early team did really well - on ownership and the structure to enable that ownership for PMs. So in interview panels for example, we give a hard time to hiring managers in our debriefs if they cannot articulate clearly what that person is going to work on.
Shreesh: If you're a product manager in PhonePe, we almost frown upon what I call this pure metric-driven product management. The funnel is a means to an end. If you can't think about the problem, then you have almost forgotten that the funnel can change. A lot of people just start thinking with blinkers, 'I must optimize the funnel.' But what about outside of that funnel? Did you ever think of changing it?
Hiring approach and skill sets at PhonePe
One of the things we're very clear about is that product managers in PhonePe need not be domain specialists
Mithun: So what kind of skill sets do you look for in a PM you're hiring?
Shreesh: For a very long time, we didn't have a well-documented product competency matrix. But one of the things we're very clear about is that product managers in PhonePe need not be domain specialists. They could have had experience and expertise in a domain, but that does not mean you will be interviewed or hired only for that domain.
The reason we took that approach is because what we figured was that there are a few domains which are extremely specific. Let's say hardcore data platform problems or cybersecurity. There are a few technical domains in software which require some degree of expertise and experience, and even a background. But that's maybe 15 to 20% of all software problems. 80% of problems are not R&D problems, if I can call them that. They're generic problems and that's what we are looking for - great product professionals. We would often meet people who have spent a lot of time in the domain and would find it very hard to actually empathize or even find analogies outside of that domain. It's almost like it's the only muscle you have, and you will rinse and repeat that muscle.
Now once we decided that that was the kind of individual we wanted, we would do a product thinking and problem-solving round, which was evaluating different problem-solving skill sets. For us, product thinking was the ability to actually truly put yourself in the shoes of the end customer. Who are the customers? Genuinely talk about what's the objective of the product, what is the utility you're adding, what is your right to play, what's your right to win? Talk about the dynamics of the industry if it's needed, and things like that. It's a hardcore product discussion. This round is meant to be a sort of pure play product discussion.
The other round is what we call a problem-solving round, which is - now that you've zeroed in on what's the right product to build, how are you going to build it? Are you taking all of the parameters into consideration? Are you worrying about all of the cases that are coming in? Are you worrying about all of the interaction points? Are you thinking extensively enough? Basically a lot of depth-related handling.
Over and above that, there are a couple of rounds in PhonePe where engineering leaders do look at the product manager. Because at PhonePe, you need to be a good engineer. You don't need to be a good “software” engineer; I think that's a big myth, but you need to be a good engineer.
Mithun: Can you explain that a bit more?
Shreesh: To put it very simply, if someone comes and says, 'I can't do this in System A,' and if you can't understand that, then you're going to have a difficult time building at the scale that we are at today.
And I must confess, I don't think anything that's happened in the recent past has caused us to really change this methodology because it genuinely helps us find great product people. In fact, some of the most interesting product rounds we've had have been with the most junior people because they come with no biases and no chips on their shoulders; they're not one-trick ponies.
Mithun: So I'd say then mostly similar to product interviews in that sense, except there is a very heavy bias towards systems thinking in technology products.
Sudhanva: Yes. In one of the meetings, I remember the term that was used was, 'You don't need to know your way through how to build systems per se, but you should appreciate where technology can play that role. There is a brute force way of doing things and very often that is the right way of doing things. But you have to understand the role that tech can play in making that difference and how you can use it to your advantage.
In PhonePe, the expectation of the PM is that with a PM and a Dev, it's not an Us Versus Them thing; you're usually on the side of the dev more often than not.
So, PM is a PM is a PM, that has been a very core belief in hiring for most roles in PhonePe.
Vibhav: How do you shortlist? Would you consider somebody from McKinsey or BCG for a product role? Or if somebody is an engineer said they want to move to PM?
Shreesh: We don't have a bias. We don't mind people from any background, but some of the engineers who have harbored maybe any PM aspirations in the past, once they see someone like me doing the grind of PM, they're like, 'No, this is just a very thankless job. Don't want to put yourself through it.' Because it's like all accountability, no control.
Mithun: Specially in an organization structured like PhonePe where it's actually a tripod (engineering, product and design), which is what product teams are supposed to be. Versus what typically product management in India is like, as a PM you'll do a bunch of business plus project management, and the engineer just ships features. I think there's a much more equal relationship in PhonePe.
Sudhanva: I think engineers are more empowered in PhonePe than the average. And I think that's why no dev wants to become a PM in PhonePe.
Shreesh: But I will say this. We've always found that engineering folks at PhonePe who are not just code writers but genuine problem solvers. In the sense that you could literally have a thought about a problem to solve, you pull them aside quickly, and iterate with them. They will partner with you to solve the problem. Questions like 'Hey, how are you thinking we can make it work?' So we have to think more. Which is quite honestly a luxury, in terms of quality engineering.
Working with business teams
The next thing is, people keep saying things like ‘it's a business decision’. I always respond, 'I don't build products for charity.'
Mithun: We talked about working with the engineering team. Let's talk about how you folks at PhonePe think about working with business teams. What does that model look like?
Shreesh: I’ll start by saying that if you're building digital products in the country, that business function is actually many different things. It could be sales functions, business development functions, account management functions, marketing functions. So, first of all, you have to understand who this individual is.
The next thing is, people keep saying things like ‘it's a business decision’. I always respond, 'I don't build products for charity,' because I also want to deliver the business metric as a PM. So practically at PhonePe what ends up happening is that the product manager is enabled enough in the company and they're encouraged and actively expected to be the experts of the domain and do a lot of first principle dialogue with the business teams. As long as the business teams get confidence that the product is being built in a way which doesn't hurt any financial or operating metrics, I think broadly we are good.
Mithun: You said the business owns the metric. Now if it's on their head, then how do you as a product function partner with them? Then what is the extent to which you can push back, and how are those relationships managed?
Shreesh: The way this works is that you usually start from what the problem is and whether you can actually build the funnel in a certain way. You learn to live with the constraints. The business team in PhonePe also has built a muscle of what it means to build digital products. So in some sense, it's almost like a skill and capability that the company has developed on how this works.
Working with regulators
But what also becomes very cool is, once you start adding these constraints, you start innovating around them.
Mithun: Let’s also talk a bit about working with regulators? Because in the fintech domain it's part and parcel of a PMs life.
Sudhanva: I’ll say one thing, and I don't know if it's a popular opinion or not, is that both NPCI and RBI, both those organizations specifically, have been very progressive in the way they thought about building out the entire payments landscape in the country. They know their jobs really well. The RBI, for example, is extremely consumer-first. It's painful to build products very often based on these regulations, but once you start understanding where those regulations come from and whom they're meant to protect, you appreciate them much more.
For example, you will start by saying, 'Hey, a 2FA payment path is so much friction, why should I tokenize cards?' and so on.
There was this regulation where PhonePe and every other payment player had to re-tokenize cards. It was a pain and a half. You can't save a card; it has to be a token per merchant. From the outside in, it would just seem unnecessary.
But the RBI comes from the point of view that people are using UPI a lot, and they have to protect all the users. So even if it is a problem that affects 0.5% of the population, but it is a money related problem, they have to step in. So, that is the lens that the RBI takes."And when you're trying to build a product, and you want to get that basis point improvement, tokenizing a card is the worst thing that could happen to your funnel.
But what also becomes very cool is, once you start adding these constraints, you start innovating around them. I gave you an RBI example, and the same thing is true for NPCI.
NPCI takes UPI frauds very seriously, and a large part of my life in PhonePe has been around the whole UPI registration process as part of the user account management.
I don't know if you have actually observed this, but whenever you install a new UPI app, there's an SMS that gets sent from that device. I'm kind of proud to say that, you know, me personally and PhonePe in general, has had a very large role to play in how that process has been shaped for the entire country.
It's a very elegant way to do two-factor authentication (2FA). If you guys don't know how that works, I can explain why that is such a cool thing.
Very often, folks think that UPI is not 2FA. You just put in a pin. That is not true. UPI is a very elegant 2FA mechanism where the pin is one of the factors, and the other factor is the actual device that you're on, and that's why that (registration) SMS gets sent. Whenever an SMS is sent from your device, what a company like PhonePe is doing is binding the device, the SIM, and this phone number together. Now, this tuple which forms one of the factors of authentication. And using that, we fetch an account, and using that account, you use your debit card to set a PIN, and in each of the steps of UPI, that 'what you have' and 'what you know' is just followed down to a T. It is extremely elegant and is working at population scale.
Now as PMs we have to think about how we can make this device registration process faster, simpler, easier to understand, and more secure for users? So if you put those hard constraints in place, you're able to build smarter, more interesting, innovative solutions. And like I said, this is not necessarily the fun or the glamorous part of product management, and it requires a special kind of PM who enjoys that pain of optimizing that bit. I’ll give you some more examples.
That SMS gets sent in the background to something called a ‘virtual mobile number’. And while we are waiting for this SMS to get delivered, the user experience was blocked - it would make you wait while registering. So, what we started doing was sending multiple SMSs in the background. We started processing them asynchronously. But we also had to think about what to show on the screen - like the whole 'put a mirror in the elevator' philosophy?
And one of the cool things I've learned is that if you show a longer timer, people just wait longer. The first time I was building this, I put a 15-second timer there (because I assumed people wanted to retry sending the SMS faster), and then a 30-second timer, and the success rate sucked. And then, for whatever reason, we increased the timeout to 45 seconds, and people waited. Because there was a countdown timer on that screen going from 45 to 0, just making people wait. And then, you know, finishing at the 20 mark, and users went, 'Awesome, it got over before it should have gotten over.' We set expectations and over delivered - which makes for a great customer experience.
So the point around all this is there are real constraints while building in fintech. But as long as you appreciate that the constraints are there for a reason, you can start working in fairly cool ways around them.
Shreesh: In my experience regulators are just extremely thorough and heavily expertised. And the other thing is that what we've come to realize, is that you have to understand the regulation and also the spirit of the regulation. That's super important. And if you do, you'll be quite surprised how regulators are actually amenable to feedback if you can engage them on their terms. We've also seen situations where we've had a conversation with them, and they've been willing to reassess parts of it. Now, the change does take time because they've got due process to follow. But it's incredible how well they do it because, for them, everything is population scale.
Vibhav: Ok this was a great conversation. Thanks to both of you for sharing these insights!
Next edition in 2 weeks!