Pratik Chawla is Head of Product at Tempo, an AI-driven fitness software that provides real-time feedback to correct form and track movements. He began his career as a software engineer at Accenture before moving to consulting at PwC. From there, Pratik joined Microsoft as a program manager working on Office 365. Before joining Tempo, he worked in product management at Apple and Meta, where he worked on Siri and AI features for smart glasses, respectively.
In our conversation, Pratik talks about the importance of prioritization when building zero-to-one products and the responsibility that comes with building products for millions of users. He discusses attributes that make a good product manager, including user-centricity, data-drivenness, and stakeholder alignment. Pratik also shares his experience launching products in new categories, such as Meta Smart Glasses.
Sure. I currently live in California and I’m a dad of two. I love music and hanging out with my family as much as my kids allow us to. I’m a bit of a tech geek by nature, so one of my favorite pastimes is watching consumer product tech reviews on YouTube.
Product management has been a fun journey for the last 10-ish years of my life. It’s still a relatively new profession though — it didn’t exist when I first started working. My career started in software engineering, and then after I got my master’s, I moved into consulting at PwC, which was very business-centric. I realized I was missing how we connect the dots to make whatever business plan I proposed really happen.
For me, product management was the bridge between those two professions. I could stay connected to the product and the technology, connect the dots and make a business plan a reality, and see the difference that I was going to make when I built something.
When I was at Microsoft, there was no such thing as a product manager. As a result, we were working as program managers. However, as a product manager, your job is to understand what the user needs are, make sure that engineering has the right priorities, and make things happen, and these were things that we were all doing or facilitating as program managers anyway.
What you aren’t able to do as a program manager is approach the product strategy from the bottom up, so I’m glad that the role of product manager exists now. Product managers are encouraged to think beyond what they’ve been told, create a product strategy, and then present it to leaders higher up. By moving ideas from the top down to bottom-up or hybrid, you’re still open to ideas and advice coming down from the top, you’re still the voice of the customer. That’s where product management differentiates itself from program management, and why it has a lot more value.
I’ve enjoyed the evolution of product management. I think it’s still evolving, especially with generative AI and all these new tools. In fact, roles in every project and every profession are evolving, but one thing that stays common and central to product management is that we’re still the voice of the customers. We want to bring what users want to use and why to the table, as well as the confidence we can project on those things. That’s where a product management role differentiates itself and adds a lot of value.
It’s fun to think about these new ideas and what people would want to use, but product managers have a huge responsibility when it comes to zero-to-one products, especially those that will be used by millions of people. You constantly wonder if you’re really focusing on the right things, know what users want, and are heading toward the right product vision.
Things get even more complex when hardware is involved because the lead times are super high. You wonder whether the product will still be relevant two years from now, how it’ll evolve, if the competition will build the same thing, and how you’ll remain differentiated. There’s a lot of ambiguity.
There’s also a lot less data than you’d want, so when you’re creating a product that’s categorically new, you often need to use the product intuition you’ve built in previous roles to start with a hypothesis. For example, when I was working on Meta Smart Glasses, the hypothesis was that people would want translations, so we used research to try to prove or disprove that. When you’re creating a category, not just a new product, you worry a ton about acquisition. We had to connect the dots between the two and think about finding a balance between the features and products people would pay for, want to keep, and love the product for. You need a good mix of these to make a product successful.
Also, it’s important to create a culture of experimentation where people are rewarded not just for their product shipments, but for all of their “failed” ideas as well. In the end, final products don’t ship anywhere close to how we envisioned them. This is why it’s important to invite people to create prototypes, whether they end up working out or not. When you put product success above personal success, you’re not worried about failing constantly anyway. As a product leader, creating this culture is a huge responsibility, but when you have a passionate team it’s the most fun way to work.
It’s extremely important for product managers to have a good sense of prioritization — to make sure that the people who are working to make the product a success are putting their time and effort into the right things. Again, this is especially true for zero-to-one products and products where hardware is involved because of the lead times required.
We usually start with product managers giving some sort of directive, such as to sell X amount of units or have a metric improve by X percentage points. Then, with that goal in mind, we think about the product’s basic principles. What does the product need to do? Where do we see it in, for example, two years? What about seven years? After that, it’s essential to make sure that everyone, including stakeholders and leadership, agrees on those product principles.
Next, I encourage product managers to use a comprehensive product prioritization framework. I know that frameworks such as RICE already exist, but I’m a data person at heart, so when I’m working in an environment where data doesn’t exist, I like to make sure that we’re thinking about all the other angles.
So in our prioritization framework, we list the things that we care about the most. For example, if delight, differentiation, or alignment to company strategies is important to us, then that’s what we list. After that, we assign scores to each list item.
Then, we reaffirm alignment. We ask everybody if the framework makes sense and if we’ve covered all of the angles that are important to us (without talking about features). Once we’ve agreed on the framework, prioritization is very easy. Now, we can comprehensively and objectively run people’s strong opinions about product features through the framework that we’ve all agreed on and show how they score against everybody else’s ideas.
Once we put things on paper and provide that perspective, it becomes a lot easier to have conversations about prioritization.
The key is drawing parallels between your product and a similar product. Once you’ve done that, try to validate the user segment. Find out what the segment size is, what their pain potential is, and what their opportunities for growth are, then use surveys, interviews, and other types of user research to talk to the users of that segment. Validate that their pain points are what you expected them to be. Finally, present them with a scenario in which your product would be used and ask them if they would use it, or its features.
It’s hard for people to envision something that doesn’t exist, so I still take every insight with a grain of salt, especially when it comes to novel technologies. Something that I find helps a lot is creating proof of experience using Figma or something else. For example, imagine when the iPad was launched — there was nothing like that before and it was a categorically new product. On my team with Meta Smart Glasses, the same thing applies. We gave people a pair of glasses with screens on them. Giving them that hands-on experience tells you whether it’s delightful for the user or not, and enables you to get feedback.
So first, try to find parallels with a similar product, then try to validate the user segment, and then try to validate your product’s features. This is critically important for zero-to-one products, and helps you to sustain and evolve the right customer data sets that you would otherwise chase down the line.
There are certainly times when people get emotionally attached to their ideas and wonder why we’re not going through with them. I believe that the best way to handle this is to build a transparent culture where people can talk about these concerns freely, and there are two ways to do this.
Firstly, establish the right forum. This is a place where people can talk about their concerns or insights that they’ve learned. It’s important to not have bloated meetings made up of 30 or 40 people — otherwise, people won’t talk. This especially applies to virtual environments. Instead, create smaller groups where people are able to talk more comfortably.
Secondly, create that culture of experimentation that I mentioned, where people are rewarded for experimentation rather than for playing it safe. Playing it safe is where you miss the moonshot. Create a culture where if something fails, you’ve at least learned something. Then, reward both learning and shipping equally. It’s a tough thing for product managers to navigate because they’re under pressure to move metrics for the company. The trick is to turn those learnings into metrics as well. For example, you could try to determine how much money was saved by avoiding a bad idea.
There are three attributes that I really value. One is being user-first. I know it sounds cliché and we all feel like we’re user-first, but it doesn’t always happen in reality. You have to constantly ask yourself, your team members, and everybody else if users really care about what’s being discussed. That question asked at the right time can make all the difference, and you’d be surprised how often we forget to ask that question at some of the world’s biggest companies.
Secondly, I strongly value data-informed products. Being data-informed at every step of the process is key to building any kind of product, particularly zero-to-one products where there isn’t enough data at first to be fully data-driven.
I also value stakeholder alignment. It’s essential to repeatedly make sure that absolutely everyone, including beta customers, understands the bigger vision. This means keeping them in the loop and giving them opportunities to provide feedback and voice their opinions.
What I’ve learned in my time in product management is that when you try to keep folks informed, even if you don’t have a solid strategy yet, information passed down is super helpful and makes people feel more connected with the product vision. As a result, they understand all of the hoops that you’ve gone through to come up with that product vision, and that helps them to subscribe to it.
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Want to get sent new PM Leadership Spotlights when they come out?
Role-definition frameworks like RACI, RAPID, and RASIC take a structured approach to assigning roles and clarifying accountability.
Jann Curtis talks about understanding your audience’s purpose and what they hope to get from the conversation.
Scaled agile is an approach that allows you to extend agile principles across multiple teams, projects, or business units.
“Disagree and commit” is a management principle that encourages team members to voice their opinions during the decision-making process.
Learn more →
