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:
The “minimum requirement” is a pretty variable definition, depending on what your product is and who your users are.
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).
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.
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.
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.
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)
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
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.
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.
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.
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.
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.
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.
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.
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”.
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.
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.
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
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.