A Year without Deploying Code

Last month I completed 4 years at Razorpay. For 3 of those years, I was part of Razorpay’s incredible engineering team. We built cool stuff, hacked cooler stuff, etc, etc. It was great.

Then last year, I acted on a hunch and switched over to a product management role (and Razorpay let me). It’s been…interesting. This article does not aim to cover the pros and cons of making such a move. But if you’re considering it for yourself, here are some observations about what life is like for a techie-turned-PM.

“What credit?”

This is the simplest difference, and the one I usually bring up when asked over drinks how things are different now that I’m not in engineering.

In teams beyond a certain size, most engineers have their roles fairly well-defined. When joining a new company, you’re given a pretty good idea of what your responsibilities are, what areas you’re expected to be competent at, and, by extension, where you can reasonably draw the line.

If you had the good fortune of joining a company relatively early (I was employee #49 @ Razorpay), then you’ll likely have an excellent understanding of how the company functions, specifically what the different teams do. In that kind of setting, it’s easy to step up and do more than what is strictly expected of you.

Once you’ve built your piece of the product, you could go ahead and write public documentation for it, or send out notifications to the rest of the team announcing it and telling them how to use it, or even offer to write copy for the campaign mailers that the marketing team will be sending out soon. And if you ever get around to opening a support ticket, wow, you are essentially a Messiah. Your teammates will love you and walk away impressed by your commitment to the job.

If you’re a product owner though, oh well, that’s par for course. Who else is going to send out that mail if it isn’t you? Of course you’re going to write the public docs, the other tech writers are busy, and you didn’t do a good enough job of explaining the product to them anyway. And we gave you Freshdesk access on Day 1 for a reason.

I wouldn’t say this is because the role is ill-defined, it isn’t. Simply put, you own the product (sigh) end-to-end. If there is a gap anywhere between inception and customer happiness, it is your job to not only fill it but also analyse the rest of the process looking for other gaps and therefore other additional responsibilities.

💡 Example Time. At Razorpay, we’ve recently added a small component called ‘Entrepreneurial Activities’ to the list of core competencies expected from product managers. If you ask for an explanation here, it’s simply a placeholder for all the things you may be required to do to make your product a success. We’re aware the other competencies might not cover everything, so this one is a catch-all and a reminder that if something isn’t anybody’s duty, it’s probably yours.

“Be ready to write.”

Let the product folks on Twitter wax poetic about how important it is to do customer conversations regularly, and what the correct frequency of redoing your quarter roadmap is, and how product managers are supposed to be ‘generalists’. None of this changes the fact that over 51% of your job is always going to be just writing stuff down.

A year ago, 2-drink-down Khilan Haria told me that he hoped I knew what I was getting into, and specifically gave me this warning:

Be ready to write a lot. Most of this job is writing docs, specs, one-pagers. You’re not an idea-factory, but you are responsible for writing other peoples’ ideas down. Not all of these docs will actually get used. In fact most of them might not be used. So be ready to write.

Another thing he didn’t mention then but I’m sure he’d be happy to add now is this: Be ready for no one to read. Your docs can serve the purpose of a concept note, i.e. a simple pitch statement for what you’re building and why. But they can also serve as comprehensive references and repositories of information (think long appendices), detailed explanations of the reasoning used to make big decisions, and the factors that were considered in making them. This means there’s a good chance that there’s no need for anybody in your team to bother reading the whole thing. Aside from you, in the future, probably more than once.

I’m not a fan of product-related epigrams myself (yes, I get it, we’re janitors, but would you shut up?), but I’m going to allow myself to use one here because I find it useful to think about. A large chunk of a PM’s responsibilities can be reduced to simply this: Understand things by interviewing one party, then explain things by teaching the other party. The latter can take on many forms, like writing explainer docs, delivering KT sessions, and quickly putting together tiny slide decks full of flowcharts because you need to present information to people, and you know they won’t have the time to go through your docs.

“Is there a workaround?”

In contrast to the other points, this one calls out a similarity to one’s average workday as a developer, which is that hacking is still very much a thing. The difference is that you aren’t hacking via code anymore, you’re hacking processes. And you’re begging developers to do the hacks for you.

Once any engineering team has had the chance to mature, hacks (rightfully) acquire a bad rap. Developers start to recognise that in a fast enough work environment, any “quick fix” has a significant chance of being a permanent fix, or at least permanent enough that it can come back to haunt the team later if it isn’t done in the best possible way. One starts to hear longer and longer timelines, and the term ‘hack’ tends to take on a different meaning, i.e. you’ll hear less of the awed “they’ve managed to hack it together” and more of the disparaging “this seems like a hack to me”.

Despite this, hacks are often the only thing that can save the day when a customer is being affected by a production issue. The people using your product need quick resolutions, and they couldn’t care less about these resolutions adding to your tech debts. For a product manager, their experience will start to take on a higher priority again, and hacks are therefore back on the table. So are “Folks, can I temporarily get access to do so and so?” and “Can someone write a script to do this quickly before we get escalations?”

💡 Example Time. At Razorpay, we maintain a separate running copy of most of our production systems that we call ‘Dark’ since they do not receive any live traffic. The purpose of this copy is to allow devs and testers to try out new changes on production before doing a full release, so access to deploy on Dark is freely granted. If you’ve been paying attention, you’ve also noticed that Dark is a product manager’s best friend, since it allows an individual developer to make temporary changes on a production app with no complicated approval process, since real customers can’t get affected. It is, therefore, a godsend during firefighting sessions where something needs to be changed on production as quickly as possible to avoid affecting customers.

I’ve used Dark (or, more precisely, asked others to use Dark) more times in the last 3 months than I did in my last year as a developer. I’ve also resorted to other, less flattering methods of getting the job done, which I’m not going to mention here because my manager is probably going to read this too. But I’m calling it out because it is in many ways one of my favourite things about being a product manager: the rules around process become a little more lax if it is once again your responsibility to think about nothing but serving the customer.

“Harman, this looks more like a tech spec than a product spec.”

I’m not kidding, this line is now a recurring theme in my nightmares. I’ve heard it so many times in the last year, and it is so utterly crushing, that my friends could reasonably start using it as a tactic during chess games if they wanted to unsettle me. Here’s why it’s a bad thing to hear.

There is no overstating the importance of dropping the baggage you carry as a developer who knows how your app works, and instead focusing on just designing the best experience for your customer.

I have seen this happen time and time again when in discussions with fellow product managers. My peers will come up with a simple insight that stems from their belief that everything needs to be built with the customer in mind first. It’s usually something I missed because I was bogged down by subconsciously taking into consideration what is feasible or unfeasible for our tech team to do. This is a terrible strategy for two reasons: Firstly, because there’s an entire team whose job it is to think about feasibility, so my considerations are redundant, and secondly because that team is much much better at these considerations than I am anyway. The first filter for feasibility cannot be someone who last wrote code 12 months ago.

The truth is that there is no way you’re going to build amazing, awe-inspiring products if you don’t give your engineering team the chance to flex their creativity. You need to step back, focus on the problem, draw up a wishlist, and have faith that your friends in engineering will find a way.

💡 Example Time. At a recent joint session between our product and sales teams, a few sales folks requested a way for our merchants to better handle late authorizations (a bad word in the Indian payment industry that refers to cases where a customer gets debited but the merchant doesn’t find out until later because of network issues during redirection). I made a fuss about clarifying whether they were asking for a way to control the merchant’s configured ‘auto-refund delay’ (how quickly Razorpay refunds the money to the customer) or the configured ‘timeout period’ (how long Razorpay waits for a bank response before calling a payment failed). The sales folks indulged me for a few minutes before my manager pulled me aside and reminded me that the problem was simply ‘handling’ late authorizations, and nobody in the room cared about the various flags and configurations Razorpay’s backend was using, or what they were called, as long as the end customer’s problem is solved. So stop dropping terminology, and just listen to the problem. It was a good point, and something I need to remind myself of constantly when speaking to end-users.

If you’re making the switch from tech to product, this is something you need to hear: Good developers don’t really need to have the solution explained to them in as much detail as you’d expect. The people implementing your stuff are very probably extremely capable individuals, so your spec really just needs to explain what the problem is, and why it’s important to solve. If you can explain it well enough, and if you involve them in the process of writing the spec, they’ll usually just end up proposing the perfect solution themselves, with minimal input from you. Your main contribution to this process is your ability to empathise with the customer and their problems. The rest engineering can handle.

Incidentally, this is also why in smaller companies, the greatest, most driven developers don’t need to have product managers around at all. They have empathy, along with the time to act on it. In larger settings, that becomes your job.

“Shit, it works.”

For me, this one was the most unexpected. If you’ve ever built anything in your life, you’ve experienced a moment where a long period of effort results in the first sign that things are coming together. It isn’t the final result, far from it. It’s just the very first indication that significant progress has been made, and things are on track.

For web developers, particularly backend developers, experiencing this moment involves a little reaching. You don’t get to touch your product, you can’t feel what its surface is like, so you look out for other signs. At Razorpay, while adding new bank integrations, this was usually the very first time a successful redirection took place. You’re watching the screen, you’ve hit the Pay button, and now the screen changes to exactly what you wanted it to. You know exactly how it happened, it isn’t magic, but it still feels great.

I expected to feel less of this. Truthfully, this was the one thing I thought I’d miss most once I switched roles. Product managers don’t really build anything. All we get to do is put it in the research, bring together a wishlist, and pitch it to the real builders. Then when they’re done, it’s our problem again to make sure people use it. We aren’t involved in the actual creation process, so we can’t experience the joy of something coming together, right?

Right?

Weirdly, the joy of seeing a project take shape somehow gets dialled up to 11. All that’s required is that you tap in on the build process once in a while, ask for a demo of what’s ready, and delay it as much as you can to optimise the dopamine rush. That redirection still happens, that first design draft still looks amazing, and the only difference is that you know less about what’s happening under the hood, and so, in a way, it’s a lot closer to straight magic. If anything, the detachment from the process of building has contributed to your sense of euphoria.

💡 Fun side-effect: I am abjectly useless at providing very quick design feedback because my first instinct is that everything is bae. You put these screens together to help fulfil that wishlist I had drawn up for a new merchant dashboard? It is literally the most beautiful thing I have seen in weeks.

“It’s the right thing to do though, isn’t it?”

This one is for idealists, so feel free to skip this point if you have a healthy detachment from the goals of the company that you work for.

It stems from a strange, inexplicable kinship you feel with your company and everything it stands for. Your friends or family ask you whether and why you like your work, and instead of thinking about the specifics of what you do in a single working day, your mind jumps to grander statements. You think of big picture stuff that, if said out loud, sounds suspiciously like the ‘mission statement’ copy that your company puts out in PR releases.

If any of this sounds familiar, you’ve probably already started to think about taking on a product owner role. It seems obvious somehow, even though nobody has ever explained the role to you in quite that way. But you already seem to know that being a product manager allows you to contribute in impactful ways that you might otherwise not have been able to.

If the first section in this article talks about how you don’t get credit for the things you do, this one is the corollary: you get to do a lot if you aren’t expecting credit. You get to ‘right the ship’ in keeping with your own beliefs about what is good for the team and the company. If someone asks you why you bother, you quote the company’s core values, because you know there’s shelter there. But really it comes to you naturally, and it did before the core values were defined.

💡 Quick digression: Every time a company attempts to draw up a list of core values, its goal is to provide a real definition for the kind of motivations that some or all team members already feel. This is why the process of defining core values almost always starts with focus groups. They’re aiming to figure out what your motivations are, and what drives you to do the good work you do. If your natural motivations are already in line with all the company’s values, your company probably needs you on the product team.

In a nutshell, nothing is really beyond your charter, which means everything is your problem. The ownership thing everybody keeps talking about is real, and you cannot get enough of it.