{"id":4213,"date":"2020-07-16T09:48:24","date_gmt":"2020-07-16T04:18:24","guid":{"rendered":"https:\/\/razorpay.com\/blog\/?p=4213"},"modified":"2022-10-08T16:18:29","modified_gmt":"2022-10-08T10:48:29","slug":"a-year-without-deploying-code","status":"publish","type":"post","link":"https:\/\/razorpay.com\/blog\/a-year-without-deploying-code\/","title":{"rendered":"A Year without Deploying Code"},"content":{"rendered":"

Last month I completed 4 years at<\/span> Razorpay<\/span>. For 3 of those years, I was part of Razorpay\u2019s incredible engineering team. We built cool stuff, hacked cooler stuff, etc, etc. It was great.<\/span><\/p>\n

Then last year, I acted on a hunch and switched over to a product management role (and Razorpay let me). It\u2019s been\u2026interesting. This article does not aim to cover the pros and cons of making such a move. But if you\u2019re considering it for yourself, here are some observations about what life is like for a techie-turned-PM.<\/span><\/p>\n

\u201c<\/b>What credit?<\/b>\u201d<\/b><\/h2>\n

\"\"<\/p>\n

This is the simplest difference, and the one I usually bring up when asked over drinks how things are different now that I\u2019m not in engineering.<\/span><\/p>\n

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

If you had the good fortune of joining a company relatively early (I was employee #49 @ Razorpay), then you\u2019ll likely have an excellent understanding of how the company functions, specifically what the different teams do. In that kind of setting, <\/span>it\u2019s easy to step up and do more than what is strictly expected of you<\/b>. <\/span><\/p>\n

Once you\u2019ve 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.<\/span><\/p>\n

If you\u2019re a product owner though, oh well, that\u2019s par for course. Who else is going to send out that mail if it isn\u2019t you? Of course you\u2019re going to write the public docs, the other tech writers are busy, and you didn\u2019t do a good enough job of explaining the product to them anyway. And we gave you Freshdesk access on Day 1 for a reason.<\/span><\/p>\n

I wouldn\u2019t say this is because the role is ill-defined, it isn\u2019t. 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 <\/span>other<\/span><\/i> gaps and therefore other additional responsibilities.<\/span><\/p>\n

\ud83d\udca1 Example Time.<\/b> At Razorpay, we\u2019ve recently added a small component called \u2018Entrepreneurial Activities\u2019 to the list of core competencies expected from product managers. If you ask for an explanation here, it\u2019s simply a placeholder for all the things you may be required to do to make your product a success. We\u2019re aware the other competencies might not cover everything, so this one is a catch-all and a reminder that if something isn\u2019t anybody\u2019s duty, it\u2019s probably yours.<\/span><\/p>\n

\u201cBe ready to write.\u201d<\/b><\/h2>\n

\"\"<\/p>\n

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 \u2018generalists\u2019. None of this changes the fact that over 51% of your job is <\/span>always<\/span><\/i> going to be just <\/span>writing stuff down<\/b>.<\/span><\/p>\n

A year ago, 2-drink-down<\/span> Khilan Haria<\/span><\/a> told me that he hoped I knew what I was getting into, and specifically gave me this warning:<\/span><\/p>\n

Be ready to write a lot. Most of this job is writing docs, specs, one-pagers. You\u2019re not an idea-factory, but you are responsible for writing other peoples\u2019 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.<\/span><\/i><\/p><\/blockquote>\n

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

I\u2019m not a fan of product-related epigrams myself (yes, I get it, we\u2019re janitors, but would you shut up?), but I\u2019m going to allow myself to use one here because I find it useful to think about. A large chunk of a PM\u2019s responsibilities can be reduced to simply this: <\/span>Understand things by interviewing one party, then explain things by teaching the other party<\/b>. 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\u2019t have the time to go through your docs.<\/span><\/p>\n

\u201cIs there a workaround?\u201d<\/b><\/h2>\n

\"\"<\/p>\n

In contrast to the other points, this one calls out a similarity to one\u2019s average workday as a developer, which is that hacking is still very much a thing. The difference is that <\/span>you aren\u2019t hacking via code anymore, you\u2019re hacking processes<\/b>. And you\u2019re begging developers to do the hacks for you.<\/span><\/p>\n

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 \u201cquick fix\u201d has a significant chance of being a <\/span>permanent<\/span><\/i> fix, or at least permanent enough that it can come back to haunt the team later if it isn\u2019t done in the best possible way. One starts to hear longer and longer timelines, and the term \u2018hack\u2019 tends to take on a different meaning, i.e. you\u2019ll hear less of the awed \u201cthey\u2019ve managed to hack it together\u201d and more of the disparaging \u201cthis seems like a hack to me\u201d.<\/span><\/p>\n

Despite this, <\/span>hacks are often the only thing that can save the day when a customer is being affected by a production issue.<\/b> The people using your product need quick resolutions, and they couldn\u2019t 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 \u201cFolks, can I temporarily get access to do so and so?\u201d and \u201cCan someone write a script to do this quickly before we get escalations?\u201d<\/span><\/p>\n

\ud83d\udca1 <\/span>Example Time.<\/b> At Razorpay, we maintain a separate running copy of most of our production systems that we call \u2018Dark\u2019 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\u2019ve been paying attention, you\u2019ve also noticed that Dark is a product manager\u2019s 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\u2019t 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.<\/span><\/p>\n

I\u2019ve 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\u2019ve also resorted to other, less flattering methods of getting the job done, which I\u2019m not going to mention here because my manager is probably going to read this too. But I\u2019m calling it out because it is in many ways one of my favourite things about being a product manager: <\/span>the rules around process become a little more lax if it is once again your responsibility to think about nothing but serving the customer.<\/b><\/p>\n

\u201cHarman, this looks more like a tech spec than a product spec.\u201d<\/b><\/h2>\n

\"\"<\/p>\n

I\u2019m not kidding, this line is now a recurring theme in my nightmares. I\u2019ve 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\u2019s why it\u2019s a bad thing to hear.<\/span><\/p>\n

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.<\/span><\/p><\/blockquote>\n

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\u2019s 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\u2019s an entire team whose job it is to think about feasibility, so my considerations are redundant, and secondly because that team is much <\/span>much<\/i><\/b> better at these considerations than I am anyway. The first filter for feasibility <\/span>cannot<\/b> be someone who last wrote code 12 months ago.<\/span><\/p>\n

The truth is that <\/span>there is no way you\u2019re going to build amazing, awe-inspiring products if you don\u2019t give your engineering team the chance to flex their creativity.<\/b> 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.<\/span><\/p>\n

\ud83d\udca1 Example Time.<\/b> 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\u2019t 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\u2019s configured \u2018auto-refund delay\u2019 (how quickly Razorpay refunds the money to the customer) or the configured \u2018timeout period\u2019 (how long Razorpay waits for a bank response before calling a payment failed<\/a>). The sales folks indulged me for a few minutes before my manager pulled me aside and reminded me that the problem was simply \u2018handling\u2019 late authorizations, and nobody in the room cared about the various flags and configurations Razorpay\u2019s backend was using, or what they were called, as long as the end customer\u2019s problem is solved. <\/span>So<\/b> stop dropping terminology, and just listen to the problem<\/b>. It was a good point, and something I need to remind myself of constantly when speaking to end-users.<\/span><\/p>\n

If you\u2019re making the switch from tech to product, this is something you need to hear: Good developers don\u2019t really need to have the solution explained to them in as much detail as you\u2019d expect. The people implementing your stuff are very probably extremely capable individuals, so <\/span>your spec really just needs to explain what the problem is, and why it\u2019s important to solve.<\/b> If you can explain it well enough, and if you involve them in the process of writing the spec, they\u2019ll 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.<\/span><\/p>\n

Incidentally, this is also why in smaller companies, the greatest, most driven developers don\u2019t 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.<\/span><\/p>\n

\u201cShit, it works.\u201d<\/b><\/h2>\n

\"\"<\/p>\n

For me, this one was the most unexpected. If you\u2019ve ever built anything in your life, you\u2019ve experienced a moment where a long period of effort results in the first sign that things are coming together. It isn\u2019t the final result, far from it. It\u2019s just the very first indication that significant progress has been made, and things are on track.<\/span><\/p>\n

For web developers, particularly backend developers, experiencing this moment involves a little reaching. You don\u2019t get to touch your product, you can\u2019t 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\u2019re watching the screen, you\u2019ve hit the Pay button, and now the screen changes to exactly what you wanted it to. You know exactly how it happened, it isn\u2019t magic, but it still feels great.<\/span><\/p>\n

I expected to feel less of this. Truthfully, this was the one thing I thought I\u2019d miss most once I switched roles. Product managers don\u2019t really <\/span>build<\/span><\/i> 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\u2019re done, it\u2019s our problem again to make sure people use it. We aren\u2019t involved in the actual <\/span>creation<\/b> process, so we can\u2019t experience the joy of something coming together, right?<\/span><\/p>\n

Right?<\/span><\/p>\n

Weirdly, <\/span>the joy of seeing a project take shape somehow gets dialled up to 11<\/b>. All that\u2019s required is that you tap in on the build process once in a while, ask for a demo of what\u2019s 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\u2019s happening under the hood, and so, in a way, it\u2019s a lot closer to straight magic. If anything, the detachment from the process of building has contributed to your sense of euphoria.<\/span><\/p>\n

\ud83d\udca1 <\/span>Fun side-effect:<\/b> 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.<\/span><\/p>\n

\u201cIt\u2019s the right thing to do though, isn\u2019t it?\u201d<\/b><\/h2>\n

\"\"<\/p>\n

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.<\/span><\/p>\n

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 \u2018mission statement\u2019 copy that your company puts out in PR releases.<\/span><\/p>\n

If any of this sounds familiar, you\u2019ve 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.<\/span><\/p>\n

If the first section in this article talks about how you don\u2019t get credit for the things you do, this one is the corollary: you get to do <\/span>a lot<\/span><\/i> if you aren\u2019t expecting credit. <\/span>You get to \u2018right the ship\u2019 in keeping with your own beliefs about what is good for the team and the company.<\/b> If someone asks you why you bother, you quote the company\u2019s core values, because you know there\u2019s shelter there. But really it comes to you naturally, and it did before the core values were defined.<\/span><\/p>\n

\ud83d\udca1 <\/span>Quick digression:<\/b> 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\u2019re 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 <\/span>all<\/span><\/i> the company\u2019s values, your company probably needs you on the product team.<\/span><\/p>\n

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.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

If you\u2019re making the switch from tech to product, you need to know that good developers don\u2019t really need to have the solution explained to them in as much detail as you\u2019d expect.<\/p>\n","protected":false},"author":51,"featured_media":4226,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[69],"tags":[80,82,81,72],"class_list":{"0":"post-4213","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-razorpay-stories","8":"tag-coding","9":"tag-engineering","10":"tag-product-management","11":"tag-tech"},"_links":{"self":[{"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/posts\/4213","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/users\/51"}],"replies":[{"embeddable":true,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/comments?post=4213"}],"version-history":[{"count":0,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/posts\/4213\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/media\/4226"}],"wp:attachment":[{"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/media?parent=4213"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/categories?post=4213"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/razorpay.com\/blog\/wp-json\/wp\/v2\/tags?post=4213"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}