Alright! Continuing with our series of blogs where we cover the AMAs we hold over on our Slack channel. In case you missed it we regularly host Product Managers and talk about everything #product.

Are you a Developer or someone from tech background looking for moving to Product? This AMA is gonna be pure GOLD for you!!!

We were joined by Harman Singh, Senior Product Manager, Fyle on a really interesting topic "Moving from Tech to Product without being hated by either Tech or Product".

Here are some key takeaways:

What should be the minimum requirement of Tech understanding in general for Non-Tech/Business folks moving into Product roles according to you?

The “minimum requirement” is a pretty variable definition, depending on what your product is and who your users are.

• If your product is an ecommerce platform and users are shoppers, you can maybe get by with a minimal understanding of what’s happening under the hood, and focus only on empathizing with your users. It might even act as an advantage at times, since in this kind of setup, you might be in the only person in your team who CAN empathize with the users. Over time you’ll develop an idea of what’s technically feasible and what isn’t, and that’s really all you need.
• If your product is a set of APIs, you’ll naturally be expected to be much more well-versed with basic web technologies and what your dev-users mean when they say they want a “clean API”.
• If you’re coming from a non-tech background, I have no choice but to regurgitate the same advice everyone else gives you: forget about tech vs non-tech, focus on the user. Understand their pain points, their motivations. If they care about APIs, learn about them. If they care about finance, learn about that.

Do we need to unlearn Tech before moving to Product so we develop Business oriented solutions and not Tech oriented?

In a way, yes.

When you first move out of Tech and into a PM role, it’s natural to apply what you think you know and answer questions about technical feasibility yourself without getting help from the tech team. It takes time (and some mistakes) to realize that your fading understanding of tech shiz is essentially throttling your team’s productivity and, perhaps far more importantly, their creativity. You’re basically a has-been, so you should NOT be taking any important tech calls.

The separation of roles and responsibilities exists for a reason. You’d do well by your team to focus only on the why and what (i.e. business) and less on the how (i.e. tech).

How to disagree with Tech when you know they are wrong?

Sigh. Smells like a question about timelines, so I will answer it as such. They probably aren’t.

A big part of working together long-term is learning how members of your team function in different situations. Some engineers do propose higher estimates than strictly necessary. That’s fine, and in fact even accounted for in traditional agile planning, where you can and should account for relative speeds of different engineers. In the long run, for most things you want to ship, it’s more important to be predictable than to be fast.

TLDR: If you think it should be 45 minutes and they’re saying 2 weeks, stfu and accept it. Track your team’s velocity diligently and maybe make a case for hiring more folks later.

How to communicate Tech challenges to Product teams?

By dumbing them down and talking in terms that your user (and your product team) understands. Tech challenges are never just “we have to do this cos we have to do this”. There’s a reason the framework needs to be updated, a reason the database needs cleaning. There is always a reason why, and you can and should ask your tech team to provide it. Be convinced about it yourself, and only then try to sell it to others.

I cannot stress this enough, but dumbing stuff down is a huge part of our job. The act of learning and teaching, absorbing and spewing, is basically what we do for a living. We ought to get pretty good at it.

What are the things you've learned in your PM journey that you wish you knew when you started?

Tried writing some of these here: https://medium.com/razorpay-unfiltered/a-year-without-deploying-code-af8cbe7f9d33

TLDR:

1) Trust your tech team to do their job well, work only to enable them.

2) If you’re putting in the research work, trust yourself and your instincts. As long as they’re based on your research, they are valuable to the team.

From a generalist background to specific ones, what are your opinions on Growth vs Product as career. How these roles evolve as career trajectories & some pros/cons?

IMO labels like these tend to ignore the fact that the variance of responsibilities across organizations is so huge that any generalizations tend to fail.

If you’re a ‘growth hacker’, you might simply be a marketer. But if you’re a very involved growth hacker, you might be involved beyond in the customer journey beyond acquisition (this usually means referrals).

Truth is, irrespective of their title, most product ICs will get involved to whatever extent they think is necessary for the success of their product.

TLDR: I consider both career tracks largely interchangeable. It would be difficult to be great at one without developing the skills you need to be great at the other.

(please take this advice with a pinch of salt, my own experience is fairly limited, all viewpoints can change with time and learning)

How did you manage to not being hate by the Engineering team?

Arre I wanted a nice name for the AMA, I have no idea how they really feel about me :)

Serious note: If you’re moving from tech to engineering and having a hard time dropping a tech mindset, usually the engg. team isn’t the one you have to worry about. We had the occasional tussle about timelines, but that’s it

Is there a specific aspect of a Tech mindset you had difficulty abandoning while you moved to a Product role?

I started off pretty bad at writing genuinely useful specs (or concept notes or PRDs or whatever your org calls them), because I kept thinking about solutioning, and forgetting that that’s not what my team needs most. “Harman this looks more like a tech spec than a product spec” was a recurring theme.

Till my last day in my previous org (where APIs were a big part of our product), I was still sometimes making this mistake and diving into solutioning.

What are some of the books/podcasts/blogs (online resources) you would recommend, ones that really helped you understand the product role better?

As you can imagine, I tend to get this question a lot, from people who are looking to make the switch themselves. I often just point to https://www.learnpmwith.me/ for being a great meta-resource.

For me personally, I went about reading a lot. There is a ton of literature out there around the product management discipline, and while a lot of it is overwhelming, it’s important to realize that you can benefit from just diving in and getting used to the language and motivations. For example, I was recommended a ton of books (https://www.goodreads.com/review/list/29255395-harman-singh?ref=nav_mybooks&shelf=product) to read to prep for interviews, and I did read some (Design of Everyday Things is absolutely life-changing), but I found the articles and videos linked above to be a little more helpful, and a better use of my time.

Blinkist is also a useful tool for this, as long as you’re well aware that it’s probably nowhere close to the real thing. In a world where you’ve got 20 books all teaching you the same thing, it helps to read 1 book and 19 summaries.

What are the pointers that a recruiter looks on the CV of a candidate who is coming from a Tech background? What are some ways the aspirant can fill these gaps?

If you’re coming from a Tech background and applying for a PM role, your tech CV likely won’t help the recruiter at all. Put it away, and write another, albeit shorter CV that showcases times when you took ownership of a lagging project, went beyond your role and did things that nobody else was available to do. It sounds trite, but that’s honestly more useful to me than the list of projects you worked on as a developer.

Your objective is to show-case product thinking. If your CV doesn’t have this, you’ll likely need to focus on showing it in other ways. Pick a product you like and review it. Participate in one of TPF’s teardowns, showcase that. Get creative about how to get past the resume stage and jump into one of the more effective evaluation rounds.

How one needs to translate their engineering experience into Product, considering someone has spent longer time in Tech than product?

Not sure if I understood this question. Assuming you’re asking how to translate technical jargon for use in product discussions, if you’re very used to the former.

Translating is the job. If you’re considering a switch to product, you are likely already extremely good at communication. If you aren’t, please reconsider the switch, or work on your communication. It will probably be one of the most important tools of your arsenal.

---

Alternately, if you question meant how to translate your position in an engineering track to an equivalent position in a PM track, this may not happen. Making the switch early on is probably the most effective way if you want to save on time. Or else simply accept that you’ll spend a little longer coming up to speed with your peers.

What made you decide to switch to Fyle especially when Razorpay hitting Unicorn Status?

Oof, slightly personal question. Will try anyway.

I simply thought it made sense for me. The team I spoke to at Fyle seemed great, and what they were looking for in their first PM aligned with what I wanted to do with my career. Got lucky that way.

If you’d had the good fortune of working at Razorpay for the time period that I did, you’d know that hitting Unicorn Status was pretty much inevitable for us, so that can’t be a factor. It’s an amazing organization, it’s got nowhere to go but up, and I’m ridiculously proud of the work I did there. Still, I had more to learn, and other places to learn it, so I moved on.

What are your views on believing in Numbers vs believing in Intuition approach while decision making?

Numbers when they’re available, Intuition when they’re not.

So many of the questions I need answered belong in the latter space (Who here has all the events and instrumentation that they want? Who?) that it becomes a given that you’re going to have to go on instincts at some point. Remember that what you’re calling instinct is also born out of some qualitative research. So if you’re putting in the work and having regular conversations with users, your ‘instinct’ is worth a lot.

What advice do you have for someone new to Product Management like Associate PMs?

Congratulations, welcome to the club. You’ve entered a great space, and there’s a helpful community. Remember that like every other field in the world, there is plenty of lame work that you need to do, and lots of habits and discipline you need to inculcate, in order to actually start enjoying the big wins. It’s an ongoing process, but hey at least you have company.

How do u see the role of PMs evolving in the future? Do u see any new skills that will emerge or become obsolete?

Wow, that’s a great question, and honestly not something I’ve had a chance to think very deeply about.

One trend I do expect to see that PMs, being domain-heavy roles already, will become more and more specialized for specific industries. This is already happening when folks look for other opportunities within the same rough vertical (FinTech PMs tend to stick to FinTech, B2B PMs tend to stick to B2B), expectedly so since they’re worked to develop domain-based skills over a long time and want to make the best use of them.

We still think of and explain away PM roles as a proxy for “biz-aware tech”. I expect that in a world of specialist PMs, they’d be closer to “tech-aware biz”.

I am a Final year Engineering student. So in my past 4 years I did Internships around Development, Product Management and Growth. I read you blog and resonates at the point that like me you also hold interest in both Dev and Product Management. In the past few months, I have given few interviews for Dev roles and APM roles, I was able to crack both roles at companies I admire. But not sure if it would be better to start my full time journey as a Developer (as I believe there are thing that I can pick from life as a developer that will help me in Product) and then pivot to product or start straight with Product?

If you know you’re aiming for a PM career eventually, I’d recommend going for it now. A tech background helps a bit, but the time you gain in the product space will more than make up for it.

“Switching” into PM is a common route because the role isn’t commonly understood by college folks who’re still figuring out what they want to do, and realize later that there are other options. If you’re better off because you know what you want, you should definitely use that knowledge.

Basically keep your end goal in mind. Don’t get into tech thinking it’s a safe springboard into product. It isn’t, and even if it was you don’t need it.

Follow up question - If I choose PMing, in your opinion are Early stage startups good place to begin with or a startup like Razorpay etc. which have more defined roles than startups?

Well it can’t be too early stage, cos then they won’t need PMs at all, or at least won’t call them that.

If you can afford to take the obvious risk, there’s nothing like PMing at a small startup. You’ll learn rapidly, and the experience will be invaluable for future prospects too.

As a recently graduated engineer, working in consulting and looking to break into product management, considering "learning" as the primary criteria for joining a new company, what factors should primarily be taken into account while selecting which companies to apply for. Please clarify for seed stage startup vs a series C/D one?

I’m not sure how qualified I am to answer this, I can only share what I’ve looked for in new companies. I know I function well in spaces where the company professes to care about culture, since it means they’re open to potentially awkward conversations. I like small setups where a higher personal impact is possible, meaning I’d be ‘broadening the T’ instead of deepening it. And I’m a sucker for founder whom I can debate with.

Your mileage may vary greatly, so I’ll defer this to The Man:

https://twitter.com/shreyas/status/1306640960282001408

The biggest problem I faced while trying to move into Product from Tech is, there is already an established perspective that people from Tech do no have Business perspective. The problem now becomes to deal with perspective and not the interview. What are your thoughts on it? By the way did I mention I am still unsuccessful?

Oof. Are you sure you want to work at a place where they’d rather make a decision about your business aptitude based on your background than on actual conversations? Sounds shady AF.

If you’re getting to hear the same feedback from multiple places, then you need to consider the possibility that you’re maybe not presenting your side of the argument well enough. Business perspective takes time to get used to, and any techie-turned-PM who claims to have ‘learnt’ it in less than 3 years is probably lying. Your contention needs to be that you’re capable, and that you’d learn on the job. That’s what entry level roles are for.

TLDR: Keep at it, and try different ways of presenting your case. This is a great community to start, make the most of it. If you’re regularly taking part in Teardowns for example, you’re already showing way more initiative than most of the candidates I’ve interviewed. You’ll get through.
‍

Want to join the next conversation? We’ll be having another Product Chat soon,  get your invite to our Slack community to get all the details. See you inside.

‍