Skip to content

Shreyas Karanth: Moving from SW Engg to Product

Shreyas Karanth is a Product Manager at Soroco. Soroco is a Medium-sized Enterprise-focussed B2B Automation company. Before Product Management, Shreyas was the fastest growing engineer - going from a fresh grad to a Technical Lead within 3 years of graduation.

This is also when I worked with him, during his engineering days. Here, I asked a bunch of questions why he moved to Product Management, what excites him and what he considers as Product Management work at Soroco.

Background

Nirant: How many people work at Soroco now?

Shreyas: Actually, closer to 250 I think, with around 170+ people in engineering

Nirant: And how many people can you distribute work to?

Shreyas: PM work? No one. There are 7-8 engineers in my team though.

Nirant: What is PM work here?

Shreyas: Customer demos, sales collateral, market research, sprint planning, end user facing documentation.

Nirant: Demos and collaterals should be with the functional team, right? Also, what product do you PM - if I may ask?

Shreyas: What do you mean by the functional team here? And I was PMing an internal product, where we had built a single interface to monitor and control automation systems and their dependencies.

It was originally slated to be a companion to our automation systems, but we started selling it as a standalone product by itself, a few months ago.

Nirant: Functional team - e.g. sales collateral comes from Sales team, docs from tech, market research from sales/business development.

Shreyas: And before that, I worked for 3 months as a PM to build a demo version of one of our products. It was basically our enterprise offering with stripped down features, deployed as an Electron app, so that customers can download it on their machines and test out the tool quickly.

So, Sales doesn't make most of their own collateral. In Soroco, Marketing + Product makes it for them. Rather, we create a library of slides/one-pagers. It's up to Sales to choose the right ones from this library for each customer. And to request for more when it's needed -- because Marketing owns the customer-facing message.

Nirant: What are the advantages of this vs Sales owning it outright?

Shreyas: Tight control over messaging by centralizing it. Also, easier to maintain quality of collateral. Enterprise sales people don't really have the best aesthetic sense.

Nirant: Centralized to who? Marketing?

Shreyas: Yes.

What do you love the most?

Nirant: What have you loved the most, in transitioning from tech to product?

Shreyas:

  1. 90% of the articles I read when I was in tech, were "product" articles. What has been great is actually putting these things (that I'd read over the course of 2 years) into practice. Even small things, like coming up with a set of questions to ask customers, require me to go through articles and books that I'd bookmarked over the years, and then actually using those tips.

  2. Coming up with hypotheses around why certain features need to be built is also enjoyable to me. Putting together what I've learnt from the articles I've read, as well as what I have understood from sales pitches and customer interviews to come up with a view of what to do has been pretty fun.

  3. Here, PMs give a lot of customer demos, essentially doubling up as sales people on some calls. This is one thing, which I've unexpectedly come to enjoy (If you hadn't noticed already, I don't really talk much).

  4. Understanding all the other details that go into actually releasing a product in the market has been fun. Some of the things I've really enjoyed are: understanding how to price your product, figuring out whether you should go all-in on SaaS or keep an on-prem option, market research, competitor analysis and even fine-tuning sales pitches. Basically, I get to sample (almost) everything that goes into building a product.

What has been the hardest?

Shreyas:

  1. Preventing myself from getting into the technical details has been pretty hard. I've come to look at it this way: If things break, I'm not going to be the one who is going to dive in and fix it; that'll be the engineers. So, I should stop getting too involved here. (credit to @Pentropy for this advice)

  2. Writing in a way that non-technical folks can understand you has been challenging. (However, I think you will have no problem here, based on what I've seen of your writing from when you were in Soroco)

  3. The amount of organizational skills required to be a PM is pretty crazy. I thought of myself as a fairly organized person, but I've found myself coming up short after I became a PM. You need to deal with engineering, sales, marketing and also leadership. And you have only so many hours in the day.

  4. An addendum to the above point is that you will have to inevitably deprioritize some things owing to lack of bandwidth. Some people are bound to be unhappy with the priorities that you've chosen and you have to handle that well, since you may be asking them to prioritize something you need the very next week.

  5. Accountability for things that you can't directly control. You become the scapegoat, in some way, for problems that are hard for you to control. If the tech team runs into an unexpected issue and that delays a release, that's your problem. If the sales team hasn't gotten a good enough response from customers for your product, that's your problem. If the marketing team has been too busy with other things to prepare collateral for you, that's still your problem.

  6. Your responsibilities are very fluid. As a tech guy, on every project/product I worked on, I knew my main set of responsibilities very clearly. I used to help out other people with their responsibilities, but I would make sure that I fulfilled my own first. As a PM, when there's something that needs to be done, and you can't clearly call it the engineering, marketing or sales team's responsibility, it just becomes your responsibility. Sometimes, even when it is another team's responsibility, but they are busy and you need to get it done, you need to just suck it up and do it (like creating marketing collateral).

  7. (Bonus) Oh, I forgot #7 for what's been harder - the feedback loop on my work has become much longer. Code gave me instant gratification, but I am not used to deriving satisfaction from making a market research deck or a specs doc yet. Also, I am not sure whether a lot of the decisions that I have taken were the right ones.

What does your typical day look like?

Shreyas:

  1. Standup in the morning

  2. Calls with engineering to clarify features that I've written specs for

  3. Calls with design to brainstorm UI/UX design for features

  4. Some ad-hoc work for client engagement, which includes, but is not limited to

    • Help with proposals

    • Input and slides for client demos

    • Understanding and prioritizing high priority bugs in the product

    • Calls to understand asks from customers

  5. Prep for client demos (if any)

  6. Prep for customer feedback sessions (if any)

  7. Write down specs and hypotheses for features in the next sprint

  8. Work on fine-tuning:

    • Customer-facing roadmap

    • Slides for sales pitches

  9. Read about competitors

  10. Read about the market, in general

  11. Client demos and customer feedback sessions (if any)

All of the above won't happen in one day. But you can consider this as a sum of what might happen over the course of a typical week.

I may have missed out on a few things here, but I think I got the gist right. Discussions around pricing, product vision etc. happen much more rarely, so I can't really consider that as part of a typical week.

Nirant: Aaah. That is a lot of variety. Thanks a ton! This is next-level detail. And thank you for taking the time to type it out! I'll be able to revisit this because of that!

If you loved this writing, tweet to @shreyas94