Leader Spotlight: Leveraging the best of product and engineering, with Vamsee Chamakura

---

Vamsee Chamakura is VP of Product, Web at Speechify, a text-to-speech product working to ensure that reading is never a barrier to learning. He began his career in software engineering and built the knack for product. He was one of the co-founders of DocTalk, a conversational AI platform for healthcare providers. Vamsee later joined Speechify as a product manager before working his way up to VP of Product, where he leads the product’s web experience.

In our conversation, Vamsee talks about how his engineering background helps him act as a bridge between different groups in the organization while not losing fine details. He shares the importance of early communication with all stakeholders, as well as Speechify’s core value of “leading with love.”

---

Bridging product with engineering

You started your career in engineering before moving into product. How does that influence how you think about product, your leadership, and how you handle collaboration between the two functions?

The biggest perk of having an engineering background is being able to speak different languages. When you’re talking to engineering teams, you’re able to get into the weeds and talk about the finer details, whereas when you’re talking to customers or other stakeholders, like the design team, you’re able to put user needs and customer requirements forward. This is a very unique skill because often, a lot of the finer details can get lost in translation if you don’t understand them well. In my role, it feels like I’m creating a bridge between different verticals within the company.

Working in product management, I feel that the biggest impact that someone like me can have is cross-communicating across teams. And when you can speak engineering, the engineers respect you and are willing to collaborate a lot more. The entire company is working toward a few definite goals, as well as their internal team objectives. Further, when you work in product, you’re trying to manage expectations and ensure that you’re prioritizing properly. You have a big picture of where everything stands and that’s useful for effective decision making.

Can you share an example of a time when your engineering background was instrumental in the ideation phase?

Yes. It’s very important to ask questions about why specific experiences are built in a certain way. For example, Speechify’s web application lets users upload documents that they want to listen to. This is especially useful for students because they have a lot of assigned readings. PDFs are one of the most common file formats that users upload and, as you can imagine, they can vary from one page to hundreds of pages.

Previously, users would upload a file and Speechify did all the processing in the background. There was a significant delay between submitting the file and being able to listen to it, and that time would increase significantly depending on how large the file was.

This product change was a huge undertaking because it was a core component of our entire experience. But now, if you upload a document on Speechify, it’s instantaneous — you’ll be able to start listening within a second while the upload happens in the background. We cut down our time-to-listen metric to less than one second compared to the previous 5–10.

The importance of early communication

You mentioned engineering often being very nuanced and hard to understand for those who don’t have a technical background. Are there certain strategies that you use for that communication?

Communication is a huge component of success. Often, a lot of work happens in isolation. However, whenever you’re kicking off a project, it’s important to get all of these different divisions into a meeting early to talk through which problems you’re trying to solve and the metrics that you’re going after. You need to get everyone on the same page so that there’s no miscommunication on what the team is trying to accomplish here. Early collaboration has been very helpful in my career.

Second, it’s crucial to change direction based on inputs from different people. Let’s say you’re building out a feature that the design team came up with. When you take this to engineering, you might realize that certain aspects of that are too large of a lift. Being able to have those conversations at a deep level helps everyone push back and set expectations realistically. The idea is to be able to get into the weeds, understand the requirements, and if necessary de-scope or change paths to be more effective in reaching the goal.

Do you have an example that illustrates how following that process had a measurable impact on an iteration or a new product?

Sure. Speechify has a Chrome extension that lets you listen to any article on your browser simply by pressing a button. We found that many of our users only skim through news websites and articles — they’re not reading the entire thing, but just trying to get a gist of it. But, the extension didn’t have a way for users to do that because it read the entire article out loud. Our idea was to implement a feature that could summarize the key points of the article at the top of the page and also give users the option of playing the entire reading.

If we didn’t include the engineering team early on in this process, we wouldn’t have realized a few problems with this approach. One was the fact that the summary had to be instantaneous, but that caused a lot of complexities. It was going to increase our costs extensively because of the high number of requests users would be sending to the backend. Also, loading instantly means the summarization or extraction of the key points has to be available within a few seconds. With that amount of latency, we’d be depending on the user’s internet connection, which is something we didn’t consider either.

Since we involved engineering early, we were able to realize that to build this with low cost and low latency, we’d need to figure out how to build it on a device without an internet connection. Early collaboration was helpful here because it provided the design team with extra information about loading time, which impacted their designs. With a lot of iteration, we ended up building it and it’s currently doing well in production to a small group of users. We’ve gotten some good initial feedback.

Balancing workloads and tech debt

As you think about utilizing new technologies, what’s your approach for assessing their fit for your product’s needs versus the potential disruption they might cause in the engineering workflow?

With any new technology, whether it’s AI or dev tools, the most important thing is to evaluate if you have relevant expertise within the team to support this new technology. In most cases, one or two people are trying to pioneer a technology to bring to the organization, but the problem with this is that it creates a single point of failure. If that person were to leave tomorrow, no one else would be able to immediately support the technology, and that could cause a huge delay in operations. That’s why it’s important to always consider if multiple people within the team can support the technology.

Second, can you clearly state the problems that we’re trying to solve and the goals that we’re trying to accomplish with these new technologies? Each one will be different, so stating the goal is very important. You also have to make sure to analyze the pros and cons of getting something new into the product. It might seem like a small decision at that time, but you have to ensure that you choose the right option in the long run.

Lastly, it’s important to consider if this new tech fits into business fundamentals. Does it increase cost? What are the goals? What are you trying to accomplish with this? Is the extra effort of bringing it on worth the potential gains?

How do you balance the need for rapid product innovation, such as when you’re trying to iterate quickly and get a new feature out, with technical debt?

It’s a trade-off that you have to live with. I think it’s important for people to be very hands-on deck and keep a finger on the pulse because whenever tech debt grows out of hand, you’re probably going to lose a few months of output from the engineering team to clear it up. The question is, would you rather spend that time distributed across multiple weeks and months, or would you be OK with taking a two-month break from shipping something new? In my experience, the right answer is always the first one — you should be good at distributing it.

Improving the time-to-listen for document uploads on the Speechify app was a pretty significant project — it took multiple months. It was a significant refactor, not from a standpoint of tech debt, but in terms of how the product itself works. When you get opportunities like that, you should try to use them to eliminate some tech debt at the same time. It’s a two-birds-one-stone situation.

I also feel that sometimes, engineers are so stressed with meeting deadlines that code quality can become secondary. That’s why within my team, I’ve tried to establish a culture of customer obsession. That implies different things for each group, but for engineering, it means writing good code, making sure you have unit tests and are testing your code before it goes into production, and making sure your code is scalable.

Overall, we encourage people to have conversations about tech debt so it doesn’t become an elephant in the room. Everyone knows it exists, but no one wants to talk about it. The problem with tech debt is that a lot of people struggle to attribute solving tech debt to a measurable metric. That’s why we want to make sure that it’s measurable and conveyable to stakeholders so we can justify why we’re spending time on it.

‘Leading with love’

You talked about being customer-obsessed and getting the team customer-obsessed, but how would you describe your own leadership style?

My role as a product person is to ensure that everyone around me is succeeding in whatever way possible. I’m more of a facilitator or an accelerant. I want to make sure that everything I do is increasing the output or pace at which metrics are moving. I try to do that primarily through collaboration. I truly believe having good and early collaboration solves a lot of issues. I also find that people with agency and ownership are hard to come by. When you do find someone who portrays those values, you need to encourage them and make sure they’re being rewarded.

I’ve found that the key differentiator between ICs is whether they can own things themselves, see things end to end, and find high-impact opportunities. Especially in startups where everything is fast-paced, these are qualities that truly stand out. It’s very important to recognize that and also try to show others on the team why this is so important.

Further, one of Speechify’s core values is leading with love. I think this is crucial — you always need to assume that, especially with people on your team, you are one unit. You all have the same good intentions. So when we’re saying, “Leading with love,” we’re saying that we assume the best from people. That’s very important because we need to be supportive of each other. There will always be situations where we get into conversations that are not totally agreeable. And if we don’t come in from that team framework, those conversations can become unproductive.

When you’re interviewing for your team, how do you identify people who have agency and ownership?

It varies in different roles. When interviewing for PMs or product people, we usually have synchronous case studies to see what direction the candidate chooses to go in given a specific scenario. The idea is to see how well they work with ambiguity. When you’re put in this place where you can take it in any direction you please, the thought process and framework of how you get there is really important.

That also gives us, as a hiring team, a sense of whether they can ask the right questions. Can they have conversations with the right stakeholders? Our interview panel plays the role of these stakeholders, which makes the scenario more realistic.

On the other hand, when hiring engineers, we rely on anecdotal references that they give us during the interview process. We ask them to talk about things that have excited or challenged them in the past, for example. Was it something that they were passionate about and drove through within the organization? Or was it just something that they worked on because it was assigned to them?

Lastly, how do you coach PMs who are less technical and help them get more comfortable with the nuances of working closely with engineering?

First, I think that this is a skill that PMs need to build over time. Like any other muscle, you need to train it enough to be good at it, even if you don’t have a technical background. It’s not like you’re going to start writing code, so just being able to have those conversations with engineers is a good enough start. Doing it enough times will help you get better at it.

I like to ask people to find a partner within their engineering team. They could be a tech lead, an engineering manager, or just someone they have a good rapport with. The idea is for them to have conversations about different things over time, like architecture, why they chose one approach over another, etc.

Lastly, don’t be afraid to ask questions. Even if it sounds “dumb” at the moment, you will learn a lot. Be sure to ask from a point of curiosity, and I’m more than sure that engineers will be happy to explain. Asking the right questions to the right people will go a long way, and once you start building that muscle, you’ll improve even more over time.