Uday Marepalli is Director of Product Management at Upwork, a $4B marketplace, where he leads client outcomes and retention. He has spent the past 10+ years across AI, marketplaces, consumer, and SaaS, beginning his career in technology venture capital. Uday later worked in the CEO’s Office at Blaize, an AI computing platform. Before joining Upwork in 2021, he led jobseeker personalization for 50M+ users at Glassdoor.
In our conversation, Uday shares his player-coach philosophy: how product leaders can stay close to customer problems while scaling their impact across teams. He discusses balancing hands-on leadership with autonomy, coaching PMs to develop judgment and taste in an era of AI, and maintaining strategic focus as product development accelerates.
The player-coach philosophy
What is your philosophy on a product leader’s role as player-coach?
I directly own a few things end to end and lead everything else through other people. A product leader’s job is to raise the ceiling on the team’s thinking, and you cannot do that entirely from a distance. I retain some direct ownership to stay calibrated. Product management depends heavily on judgment and taste; if you stop doing the work, your feedback becomes less valuable. People may still act on it because of positional authority, which can be dangerous.
I tend to step in directly when an important problem lacks a clear owner, such as an outdated experience, a gap between teams, or a zero-to-one problem that is not yet well enough shaped to hand off. I coach when the goal and ownership are clear, but the PM needs a thought partner, sharper judgment, or help removing obstacles.
A leader who only coaches eventually loses touch with the craft, while a leader who only plays is limited by their own capacity. Product leaders today need to deliberately balance both roles.
As a PM moves into leadership, how do you suggest they stay close to customer problems?
Product always starts with the customer. As you move into leadership, staying close to customers must become intentional, because it no longer happens automatically. Your calendar fills with internal alignment, reviews, planning, and recurring meetings. If you do not protect time for customers, you can go months without hearing from one directly.
Secondhand research is useful for identifying patterns, but it compresses the experience. You receive a conclusion, without experiencing the hesitation, frustration, or intensity behind the customer’s pain. A slide might say customers find something confusing, but hearing someone struggle with the experience for five minutes gives you a very different understanding of the problem. I maintain a regular cadence of customer conversations and talk to a customer every couple of weeks.
I use the product I build and stay up to date on the end-to-end flows, even when my teams do not own them. I do not need to join every interview, but talking to customers and using the product firsthand can help me calibrate the insights that reach me.
That proximity to customers also makes me a better coach. When I understand what customers need, I can help a PM distinguish between a feature request and the underlying problem. The goal is not to bypass the team’s research, but to maintain an independent view of the customer so my judgment stays grounded in reality.
Can you give an example of what the player-coach approach looks like in practice?
One example was the Early Access Customer Program we launched at Upwork earlier this year. Many teams were shipping new experiences, including a new design system and agentic products, to small audiences so they could gather customer feedback and iterate quickly.
Each team independently recruited customers from our broader user base. Every team was doing its job, but the system wasn’t working well. Recruitment was inefficient, customers had no clear way to understand or manage their participation in experimental products and features, and teams lacked a scalable pool of engaged testers. It was a cross-team problem that no single PM was positioned to own.
I stepped in to shape the solution. I wrote the initial requirements and worked with design, product marketing, launch, and product operations. Together, we created the centralized Early Access Program, with clear ways for customers to opt in to and out of early feature testing.
Just as important, I handed the program off after launch. Product operations took over, multiple launches have since used it, and it has become a repeatable launch model for the company.
That is the player-coach model: step in when a cross-team problem needs leadership, create momentum, and establish durable ownership.
Hands-on leadership without micromanaging
Where’s the line between being hands-on and micromanaging?
It is a fine line. For me, the distinction comes down to which aspects of the work you examine closely and why. I focus on the customer problem, the supporting evidence, and how the work connects to company goals. Leadership context and judgment can materially improve the product’s direction in these areas.
Once we align on those points, I give the PM room to shape the hypothesis, solution, and execution. Being hands-on means adding signal that improves the outcome. Micromanaging means leading with authority or personal preferences in ways that do not benefit the team.
For example, if I say, “Can we change this copy because I prefer another phrase?” or prescribe every step without evidence, I am probably not helping the team. But if I ask, “What problem are we trying to solve? Why now? How will we measure success?” I can help the team sharpen its goals and execute more effectively.
One practical habit is to state explicitly which mode I am in. Sometimes I say, “This is one person’s opinion. Feel free to discard it.” Other times, I say, “I have a strong recommendation.
Let’s debate it, and one of us should leave convinced.” Occasionally, I make a mandate involving strategy, risk, or a decision for which I am directly accountable. In those cases, I am clear that I am making the decision and will own the outcome if it does not work.
When a problem lacks clear ownership, a player-coach should step in, create a system, hand it over, and move on. You cannot become attached to something you created because you must preserve the capacity to address the next important problem.
How does staying close to product details make you a better coach to experienced PMs?
There is a common leadership phrase: “Hire great people and get out of their way.” I agree that hiring great people is critical, but the second half is often oversimplified.
Experienced PMs generally do not need someone to teach them the basics of building a product, but they value a credible thought partner. You cannot play that role if you are not close to the details, because your understanding of the product will be superficial.
Staying close to the details helps me ask sharper questions and offer more relevant context. If I notice something broken and raise it thoughtfully, it signals that I care about the work and understand the team’s constraints. That builds trust. Spotting an issue does not mean prescribing the answer.
I also create low-stakes spaces where PMs can riff on unfinished ideas without feeling evaluated. The goal is to help them sharpen their thinking and ultimately ship a stronger product for customers.
Coaching through judgment and AI
You mention judgment as a critical skill with AI. Are you finding you have to push back on PMs more now, as they rely heavily on AI to produce their output?
AI has made producing work much cheaper, which makes judgment more valuable. Writing a document, analyzing data, and building a prototype used to be significant bottlenecks; now they are much faster to produce. The scarcer skills are deciding what deserves to exist and whether the output is actually good.
That said, AI produces many poor first drafts. It can generate polished, confident work that is still wrong. As output has increased, my coaching has shifted toward verification and testing. If a PM says, “I created this analysis using AI,” that is great. People should use AI to work more efficiently. My coaching then turns to questions: How do we know this is true? What would disprove it? Is it merely well presented, or is it genuinely good? I act as an editor, helping people reach a polished artifact we trust.
This is where being hands-on helps. If you understand how users move through a flow, you can flag engagement data that does not make sense. If you know the customer pain points well, and the synthesis seems counterintuitive, you can review the source transcripts to understand what customers actually said.
How are you using AI to shorten the customer discovery loop without losing firsthand understanding that comes from talking to customers?
I use AI to accelerate the work around and after customer conversations, but I prefer to conduct the conversations myself. Before an interview, I use AI to review account details, draft a discussion guide, sharpen my hypothesis, generate counter-hypotheses, and stress-test my thinking.
As a human, I might be attached to an idea, but AI is not. I can use it to broaden the range of possibilities or ask plainly why my hypothesis might fail. Then I enter the customer call ready to probe the real problem instead of orienting myself or projecting my own assumptions.
AI also makes it faster to create something concrete, such as a prototype for customers to react to. We recently explored a marketplace buyer protection program, and I moved from an initial hypothesis to customer insights in under a week. A few years ago, that would have taken much longer.
After the interview, AI can help synthesize findings and identify patterns across conversations. I use it carefully because it can flatten the intensity of customer feedback. Before packaging or acting on recommendations, I review the original transcripts myself for a final check.
Scaling product leadership across teams
As your scope grows, how can you use your view across teams to identify and solve problems that individual PMs may not see?
The main advantage of broader scope is stronger pattern recognition. You see where customer journeys break across team boundaries and where sensible local decisions create a poor system-level outcome. Individual PMs are rightly focused on making their areas successful. Product leaders must connect those efforts into a coherent customer journey. The seams between teams often hold the largest opportunities.
I stay close by reading each team’s updates, reviewing metrics across the portfolio, and looking for recurring customer behaviors or tactics through firsthand product use and customer conversations. I currently lead our client-retention charter. Some teams help active customers do more, while another focuses on reactivating customers who have left the platform.
These teams target different customers, but their tactics, customer needs, and platform capabilities overlap. A cross-team view allows me to identify opportunities for them to partner.
My role is to connect those intersections, align teams around the shared problem, and establish clear ownership so each team has its own swimlane.
What mental model do you use to think about being a player-coach at a time when AI is increasing individual output?
Production has become much cheaper, making judgment and taste more valuable. Historically, the main objection to hands-on leadership was capacity: two days spent building something were two days not spent leading the broader organization. With AI, the same task may take an afternoon, so much of that trade-off disappears. I can analyze a funnel, build a prototype, or conduct a competitive teardown without taking ownership away from the team.
I can create a rough artifact and ask my team what is missing. That gives us a more productive starting point while preserving their ownership. It also makes the editor’s role more important: countering AI slop and coaching for verification and taste.
Building judgment and choosing the right problems
How are people coming up now as PMs who didn’t have experience working without the assistance of AI building taste and judgment?
This is where mentorship matters. I have found that the best PMs are always open to feedback.
Product management is largely an apprenticeship: you learn what good looks like through experience and from mentors you can emulate. Everyone has a different superpower, and you build your toolkit by learning from each person. A strong group of player-coaches raises the entire team’s game because people learn from one another.
As the product life cycle accelerates, how do you maintain focus on selecting the right customer problems to solve?
As building becomes cheaper, teams can fall into the trap of testing every idea or, worse, shipping it just to see what happens. Faster production does not eliminate the costs of distracting customers, fragmenting the product experience, or consuming organizational resources.
I use two mental models to counter that. First, separate the problem from the solution. Choosing which customer problem to solve should be evidence-based and relatively durable. The solution can be much more fluid; teams should test, learn, and pivot without abandoning the problem. Stress-testing the problem itself helps keep teams anchored.
Second, distinguish speed from velocity. Speed is how quickly you move; velocity is how quickly you move in a specific direction. A good product strategy establishes that direction. Strategy cycles are shortening as AI changes the market rapidly, but strategy itself is more important, not less.
AI should increase the number of solutions we explore, not the number of disconnected problems we pursue. Product leaders must maintain conviction about the destination while giving teams and tools the freedom to find a faster path.
What does LogRocket do?
LogRocket’s Galileo AI watches user sessions for you and surfaces the technical and usability issues holding back your web and mobile apps. Understand where your users are struggling by trying it for free at LogRocket.com.