Skip to content

2020

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

Standing Out at Work

In my short career, I've seen some amazing young people stand out at work.

Here is what they did, organized by 5 themes:

  1. Unlock Knowledge

  2. Automate Boring Stuff

  3. Write Widely

  4. Solve Open Problems

  5. Outside-Visible Work

Unlock Knowledge

Expertise and know-how stay trapped in emails, docs and codebases. Unlock this for everyone else.

Get your Star Salesman on an internal podcast to spill their secrets. Do email interviews with your tech leaders and PMs. Publish as internal docs on best practices of your teammates.

Build a repo of this over the years.

Automating Boring Stuff

You can get noticed quickly by writing Excel macros for the analysis your boss does manually every week.

Or improve build-deploy speeds for devs. In design, make a theme for Sales Decks and Internal meetings. PMs can templatize repeated docs that they write, like updates or shipped emails.

Write Widely

Write team/company-wide docs. E.g. Setting up your machine, in-jokes, internal dictionaries etc. Make the codebase navigable by adding docs and README.

Take notes in a meeting. Email them to everyone later. It helped Chris get into Google and become a VC.

Outside-Visible work

In some teams, the culture will prevent you from taking initiative.

In those cases, get visible outside your company first. Participate in hackathons, meetups and do open source work, or write blogs.

This is what I've used the most and perfected to an art form. I got more projects for my Deep Learning skills at my work once Hindi2vec and Awesome-NLP went viral. My skills had not changed at all.

Solve Open Problems

Most teams have 1 or 2 important problems which are parked for later.

Research them

You can do primary user interviews, Twitter polls and Google Form surveys on WhatsApp. Get macro-estimates from Google Searches. Compile into a crisp video/written report. Share widely. Add recommendations by asking experts.

To re-iterate, all of this builds on the most fundamental principle: Doing your job well.

When you promise something, get it done. Nothing stands out more than initiative and accountability.

What have you seen amazing people around you do that you’d want others to do as well? Do reply and share your experiences.

That is all for tonight!

Natkhat, Nirant

Fail Resume

A fail resume is, as its name suggests, a list of rejections and setbacks.

This concept originated in academia, but can be applied to improve one’s career, resilience, and approach to challenges in any walk of life.

I’ve organized my setbacks by year (starting with 2016), and what constitutes a “failure” (or fail) here is based solely on my own judgement. It’s important to not only list the failures, but also learn from them, so I will add reflections to some of them (in progress).

2021

  • Never heard back from Forethought.ai, Coinbase. Had applied via the cold form on their websites.
  • Rejected by Flowrite because they could not afford me
  • Ghosted by XFlowPay in mid-August
  • Ghosted by Google Recruiter in July

2020

  • Rejected by UMass, UW, CMU Language Technolog, UCB MIMS, and bunch of other Grad school programs because of a bad recco
  • Lesson Learnt: Never trust an American
  • Sahil, the Product Manager and Verloop and Piyush, the CTO at Verloop quit -- atleast in part because I think I overwhelmed them
  • Got cold-rejected by someone I thought it'd work out with romantically

2019

  • Spent 6 weeks prototyping a solution at Verloop.io which doesn't break even on cost
  • Lesson Learnt: In Enterprise SaaS, never write any code before someone tells you what they are willing to pay for that
  • Tried to get better at DevOps, but ultimately could not because of lack of discipline

2018

  • Did not even get interview callbacks from my favourite NLP Company at the time: Rasa
  • Had to quit Soroco because of lack of opportunities to grow internally. Really loved the crew, which was smart but not agile or humble
  • Did not even apply to GoJek, Linkedin and Swiggy's kickass Data Science teams
  • Lesson learnt: Be proactive. Take moonshots. Setting an upper-cap on your ambitions is kinda stupid

2017

  • Samsung: Filed for two patents -- which despite being selected, eventually never materialised

2016

  • Did not even clear Amazon's first programming round on campus

Inspired from Katherine Huang's Fail Resume