Back

Office Hours: I'm Product Lead at Superhuman and previously built products at Box and GustoFeatured

Hi everyone! I'm Ketki Duvvuru, Product Lead at Superhuman. I've spent the last 9 years building products at Box, Slyce.io, Gusto and now, Superhuman. I've served enterprise customers, small businesses and consumers, and worked at companies as small as 8 people up to 1,600+. I began my career as an engineer after graduating with a dual Bachelor’s degree in Computer Science and in South Asian Studies at UC Berkeley, where I also later earned my MBA.Ask me anything about product management, user experience research, partnering with engineering and design, leadership, or anything else that's on your mind!
Thanks so much for joining us @ketkiduvvuru!Elphas – please ask @ketkiduvvuru your questions before Friday, January 22nd. @ketkiduvvuru may not have time to answer every questions, so emoji upvote your favorites 🔥👍🏾➕
That was fun - thank you so much for having me! I really appreciated all of the thoughtful questions from my fellow Elphas. Hope my thoughts were useful - cheers!
Hi! Big fan of Superhuman -- so great work! We raised a seed round this past October, and our product team is made up of: backend engineer, frontend engineer, and a designer. We absolutely could improve our process of development and we're thinking we need a product manager. Do you think we're too early? If not, should I maybe start part time and move into full time? What qualities do I absolutely need in an early-stage hire like this for PM? Thank you!!!
Hi Jordan! Congratulations on raising your seed round - that's huge! You're asking a really good question here - I do think there is such thing as a company that's too young to have a PM (speaking from experience, unfortunately!). Take a look at this blog post by Nikhyl Singal; I've personally found it super helpful in the past: https://nikhyl.medium.com/choosing-your-next-company-9e72c953c609Singhal, who's the former CPO at CreditKarma, outlines 4 stages of companies, and what it might be like to be a PM at each. You can read the article and consider what stage your company is at to help you decide whether to find your first PM now or to wait. Good luck!
Hello! Thanks for sharing your insights. What are the sources of data/input that you use to make strategic decisions about where to lead the product? Which do you consider the most important? Visioning and being futuristic doesn't feel like a strong point for me right now, so I'm curious to hear about the elements that you take into consideration when defining product strategy.
Hi Laura, great question! A great starting point in my opinion would be to master what strategy is, before focusing on what your product strategy should be. I recommend you read “Good Strategy, Bad Strategy” by Ricard Rumelt. It’s a book that I personally really enjoyed. Rumelt defines the “kernel” of strategy as containing 3 key elements:1. A diagnosis of the current situation of the world (as relevant to the space your product plays in)2. A guiding policy or plan of how your team has specifically chosen to address the situation defined in the diagnosis3. A set of coherent actions that form the tactics of how you plan to carry out your guiding policy. These are coordinated and self-reinforcing.When it comes to product strategy, there’s a wide array of factors to study and analyze before deciding which to weight most heavily for your particular situation. These can include industry trends, customer preferences, competitive landscape, macroeconomic environment and technological constraints/opportunities. I hope that helps as an initial place to start! Cheers!
I just wanna say I love Superhuman so much. Your onboarding flows are 👌🏼
Thank you so much for offering to share your time and wisdom! Wondering if you have any tips for pivoting into Product Management from a non-technical background (I've been in Management Consulting for 11 years now)? Do I have a shot? How would you recommend I go about it?
Me too!
Me three!
Divna - thanks for asking! While many, especially larger, companies do require a technical background in order to be considered for their PM roles, not all do! A product manager works at the intersection of 3 major functional areas: 1. technology - how the product works2. business - how the company works, and3. design - how humans workProduct managers typically start off excelling in one area and focus on strengthening the other two areas. While PMs with a technical background may be at ease with the technology from the get-go, PMs coming from other backgrounds may have stronger intuition in one of the other two areas! For example, as a management consultant, you may have a strong sense of business — that is, how the company makes money, how it can save on costs and how it can compete against other players in the market. Another example is a customer support person: she may have a strong sense of design or customer behavior — through her current role, she might come to deeply know what customers typically don’t understand or complain about related to a product, and that's also a valuable perspective to have going into a PM role.So, a great place to start in my opinion would be to figure out which of the three is your superpower and how you can hone that even further! It’s often easier and higher leverage to make a strength even stronger than to try to turn a weakness into a slightly less weakness. Secondarily after getting better at the area you naturally excel in, you can work on updating your skills in the areas that you’re less familiar with. When it comes to actually making the transition into Product Management, I’ve personally found that it’s easier to make that move within the same company than it is to both switch companies and roles simultaneously. I joined Box and worked as a QA engineer for 1.5 years before transitioning into Product. It wasn’t quick, but it was enough time for the company’s leaders to learn about me - that I was a solid employee who was able to deliver on her responsibilities and be a team player - and for me to learn about the company and product - who the target customer was, how we made money, what opportunities we had to expand and improve. My time at the company even before becoming a PM enabled me to deeply understand our customer: her goals, her needs, her values, her fears. PMs represent the voice of the customer, and that voice is something you can internalize and develop an intuition about from almost any role in the company.All that being said, I couldn’t have successfully moved into Product without amazing coaches, mentors, and - most importantly - sponsors to help me along the way. My sponsors were the ones in the room when critical decisions were being made (like “Will Ketki be successful as a PM at this company?”). So, as you look for teams and organizations to join where you might one day serve as a PM, also be on the lookout for potential leaders who will be willing to support and encourage your goals.Best of luck!
Hi there @ketkiduvvuru - thank you for taking the time! I was wondering to what extent you apply your computer science knowledge / engineering background to your day to day as product lead. Could you provide a % breakdown of your typical workday? (e.g., 10% HR, 20% coding, 30% planning & PMO tasks etc.). In that same vein, what coding & computer science skills / languages do you think are most important for individuals looking to seek out Product roles?Thanks again!TB
Hi Tamara, thank you for asking! I’ll tackle the two parts of your first question separately: 1) how much do I apply my computer science knowledge on a daily basis? and 2) how do I spend my time in general?In my experience, product roadmaps involve a combination of features that are user experience/domain-specific and those that are more technical architecture-focused. Technical knowledge can definitely be helpful for both, but tends to be more critical for the latter. The relative proportion of each is dependent on the product itself and the primary value it provides to its customers. For example, in my earliest role at Box and my current role at Superhuman, we worked on a relatively larger percentage of technical challenges, because the products: cloud file sync and share and email, respectively, are inherently complex from a technology purpose (eg: handling large files, reliably sending messages). On the other hand, in my role at Gusto, a software payroll and benefits provider for small businesses, a greater fraction of my time was invested in understanding the complexity of payroll and US taxes in the offline world than the engineering details of how to translate that to software. In any case, my computer science knowledge comes most in handy when I’m partnering with the engineering team as they implement a feature or project. It helps me intuit approximate level of effort for various potential solutions, and it helps me discuss how things might work or what options we have to build what we’ve imagined. Engineers are the experts in topics like architecture, performance, technologies, languages; PMs typically don’t spend time coding, so the main benefit is collaborating together efficiently. In my opinion, non-technical PMs can also do this well by being curious and asking lots of questions and engineers can support them with a willingness to educate and support.Regarding how I spend my time in general: it goes without saying that every PM spends their time differently, not only based on the size and stage of their product and the organization but also based on the product strategy at a given point of time and even the part of the product lifecycle a given project is currently in. For example, at larger organizations, cross-functional collaboration and customer change management usually require higher investment by PMs, where as at smaller organizations, the focus is much more on rapid prototyping and hypothesis validation. At Superhuman today, I spend around 40% of my time on product thinking (synthesizing customer feedback, creating product requirements and wireframes), 20% on recruiting (we’re hiring PMs and engineers!), 20% on cross-functional collaboration (1:1s and team meetings, planning and prioritization) and about 20% on marketing and launching features (product announcements, internal training and release planning). This breakdown changes regularly as the needs of the business evolve.To your final question, I think developing an understanding of key computer science and technology concepts is more valuable than any specific language. For example: how web applications work, how APIs work, how data flows through a system, how databases work, what are bugs, edge cases, types of quality assurance testing. Picking up a simple scripting language like Python might be helpful, and learning SQL is definitely valuable to any PM to help analyze customer behavior in their product.Hope that helps!
Hi there! Thank you so much for taking the time and for providing such an insightful perspective.I will definitely take these lessons into my future roles as I expand my involvement in tech.Keep doing amazingly and paving the way for us,TB
Hi Ketki!Glad to have you on here! 😃 I’m curious what advice you have about version control when it comes to handing off mock-ups to a developer? We are constantly iterating on designs, features change, or there are new additions or bugs to consider so the design sometimes changes. But we are also trying to show the progression of our designs. Are there any tools, programs, advice your have on showing and sharing different versions of a design and notifying the developer of that update?
Hi Sammy - great question, thank you! At Superhuman, we've had a lot of success using Figma. It's a solid tool for design collaboration and discussion with its annotation/commenting features. Three effective practices that my design partner (and Elpha community lead!) Teresa Man and I have implemented below:1. Maintain a "drafts" file and a "final" design file for each project. That way, all old explorations are stored in an archive rather than deleted, but the latest and greatest versions are clearly marked as well.2. Use a sign-off mechanism for asynchronous review and feedback. When Teresa requests async feedback from key team members, she asks each person to move their picture from a "to review" to a "review complete" space to indicate that they've taken a look at the designs and submitted all feedback3. Conduct a live "hand-off" with the Eng team before development begins. Teresa and I meet with the engineers who will be implementing a given feature for a live voice-over of the spec and designs, in addition to asking them to review both ahead of time, in order to minimize the gap between intention and interpretation.Hope that helps!
Hi Ketki,Thanks for offering your expertise and knowledge! I'd love to learn from your perspective as a senior PM, what were the things you would tell yourself that would help you go from an OK product manager to one that is truly contributing and getting things done to push the product forward.I am transitioning into PM from Customer Success right now and I am having such a challenge with executing as a PM. My background comes from speaking with customers and trying to communicate that with engineers, but I struggle with making the full leap into becoming a strong product manager. Thank you so much for your time!
Hi Adriene — thank you for asking such a great question! 3 broad areas come to mind as I think about the skills any great PM has: customer insight, a great handle on data and strong relationships with other teams.1. Customer insight: This is likely an area of strength for you already since you’re coming from a Customer Success background! PMs are positioned to spend much more time directly with customers than engineers are. Therefore, strive to be the voice of the customer in each conversation. This means developing a stockpile of data, both qualitative (like customer interviews and user research) and quantitative (like usage information and product behavior), and confidently sharing what your customers’ goals, values, fears, and needs are. This is a critically important source of input to the product roadmap!2. Data: Ultimately, the role of any function in a company is to help drive the business forward. PMs are uniquely positioned to do so directly through the projects the p prioritize and execute in partnership with engineering. A deep understanding of how to measure and communicate key metrics and demonstrate the impact of the work you’re doing is a huge asset. Training yourself in basic SQL (lots of free online resources out there!) and understanding how your product tracks usage data can help you be self-sufficient in this area.3. Strong relationships: PMs are often the glue between different departments. Investing in relationships, approaching other teams with empathy, and creating trust proactively will go a long way in building the support you’ll need to execute on large problems. Product management is the epitome of influence without authority: in order to be successful, you need to inspire and motivate others to get things done, and getting to know them on a human level helps with that.Above all, keep learning! About your customers, about the market and industry and about the technology trends that may impact your product. Hope that helps and best of luck!
Thank you so much! I appreciate the time you took to write this response and will start by furthering my learning.
Hi @ketkiduvvuru! I'm really inspired by your career journey from engineering to Product Lead. I'm an engineer that's happiest when I'm building beautiful & useful digital experiences that drive my product forward. It's my dream one day to follow a similar path to yours. When did you decide to go into product management, and what are some steps you recommend taking as an engineer that's looking to eventually transition into product management?Thank you so much, any advice would be appreciated!
Hi Lauren! I appreciate you asking, and I’m happy to share a bit more about my own journey… I discovered product management only after I joined my first company post-college! Early on during my first job as a quality assurance engineer at Box, I realized that I was interested not only in the technology and engineering challenges that the team was solving but also in the business aspects as well: I wondered -- what are the characteristics of a good prospective customer? What elements of our product are so valuable that a prospect becomes a paying customer? Who are our competitors and how do we differentiate from them? How can we raise awareness among potential customers who don't even know about Box? It was based on this curiosity of how technology and business pursuits come together that I realized product management might be an ideal role for me. PMs sit at the crossroads of what we can build and what our customers want or need, and it was this broader view of engineering and marketing and sales and customer success that intrigued me.
As I mentioned in another response, a product manager works at the intersection of 3 major functional areas: 1. technology - how the product works2. business - how the company works, and3. design - how humans workSince you’re an engineer now, you’ve got a solid foundation of the technology part already. Therefore, I’d recommend that you focus on building your knowledge in business and in design. Much of a PM’s job is collecting data about what’s possible (technology), what’s profitable (business) and what your customers prefer (design) and making the appropriate trade offs and prioritization decisions that ultimately benefit your customer and your company. You can do this by seeking out mentors in other departments (for the business part: marketing and sales, and for the design part: design and product) and observing their decision making process. If you have capacity beyond excelling in your current role, you can take this one step further and volunteer to help them with projects and tasks in order to learn by doing and receive feedback on your work. In addition to supplementing your skillset as proposed above, I’ll offer a few concrete and tactical ideas: move into product at your current company, find a sponsor on the product team, and communicate your interest in the transition. When it comes to actually making the transition into Product Management, I’ve personally found that it’s easier to make that move within the same company than it is to both switch companies and roles simultaneously. Additionally, try to find a mentor on the product team (who can eventually be a sponsor too!) whom you can shadow, learn from and even help with small tasks and projects to learn and demonstrate your potential. That person will ideally advocate for you in the future if and when an opportunity opens up. Finally, communicate your interest in a role on the product team and investigate whether such an opportunity exists or might become available in the future. You can start these conversations with your manager, who is hopefully invested in your long-term success and career development, and then also introduce yourself to a decision-maker on the product team. Transitions like these can take some time - I was a QA engineer for 1.5 years before becoming an Associate PM - but if you’re confident that it’s something you want to do, then be patient, keep learning and persevere. Best of luck on the journey - it’s an exciting one!
Thank you so much @ketkiduvvuru for your incredibly thoughtful response. Such a great idea to get mentors in those different areas, I'll definitely be seeking some out! It's also a good reminder that ultimately, I'm in charge of my career direction and I need to vocalise my goals. It reminds me of one piece of awesome career advice that I received: "You are the CEO of your own career." I'll definitely need to communicate my career goals and look for support in the transition.Thank you again for the helpful and specific advice, I really appreciate you taking the time to share!
Hi Ketki! Wondering if you have any tips about how to conduct an efficient scrum meeting. What are some of your favorite product management tools?
Hi Kerrie! Thanks for asking! Running an effective meeting requires preparation. As the meeting host, you can share an agenda ahead of time, and start the meeting by reiterating the goals of getting together and outline the role of each individual present. If you're not the host, you can always request these details be shared ahead of time to ensure the right people have the right context for a successful conversation. I've found that good meeting hygiene and a well-understand process are more important than any particular tool. In smaller teams, like Superhuman currently, I use a combination of Trello and Github for issue management. At larger companies, like Box and Gusto, Jira was the norm. Hope that helps!
Hi Ketki, thanks so much for sharing your time and thoughts with us. I'd love to know how as a product leader, you think about strategy and anticipate or make bets on things that you think will happen in the future.
Cynthia, thank you for asking about this topic! I’m sharing my response to a similar question:I recommend you read “Good Strategy, Bad Strategy” by Ricard Rumelt. It’s a book that I personally really enjoyed. Rumelt defines the “kernel” of strategy as containing 3 key elements:1. A diagnosis of the current situation of the world (as relevant to the space your product plays in)2. A guiding policy or plan of how your team has specifically chosen to address the situation defined in the diagnosis3. A set of coherent actions that form the tactics of how you plan to carry out your guiding policy. These are coordinated and self-reinforcing.When it comes to product strategy, there’s a wide array of factors to study and analyze before deciding which to weight most heavily for your particular situation. These can include industry trends, customer preferences, competitive landscape, macroeconomic environment and technological constraints or opportunities. Hope that sheds some light on my perspective!
Thanks for sharing this Ketki. I'm curious more about making bets for things in the medium to long term future. While #1 is helpful for a strategy today, how do we, as product leaders, anticipate/guess/imagine the future state of the world and how we need to adapt our product to that future state?