Starting a new product role is exciting for the first week, and then reality hits you. I have done this multiple times in my career, from running a startup to working on multiple different products at Meta, ranging from Ads to Meta Avatars, then doing it over again at TikTok and Paypal.I’ve been through this ‘new role, new product, high expectations’ cycle multiple times.I have developed a process that has helped me succeed without losing my sleep. Every single time I started a new product role, I walked into a messy backlog, strong opinions in every direction, and a product that needed to move fast while still being safe, compliant, and reliable. I have been lucky to get the chance to do it again in the recent past, this time as a Lead Product Manager at PayPal, working on the payments product for platforms and marketplaces. In my first 90 days, the biggest exercise I did was reminding myself that the job early on wasn’t to prove myself. The job was to create clarity. Clarity for myself, my leadership and all my stakeholders. Clarity about what we prioritize and how we prioritize. That clarity comes when you have clarity about the customer problem, the constraints, the trade-offs, and what 'good' looks like. This helps the team execute without thrashing.
First 30 days
In the first 30 days, I focused on understanding the system and earning trust. Before I touched a roadmap, I mapped the ecosystem around the product: engineering and design, of course, but also analytics, risk, legal/compliance, partner teams,sales and not to forget the platform dependencies that quietly dictate what’s possible. I learned quickly that platforms and marketplaces are not 'just another merchant segment', their flows are more complex, their failure modes are more expensive, and they often come with multi-party requirements that show up in the edges. In parallel, I grounded myself in customer reality. I didn’t rely only on dashboards or AI created document summaries. I spent time with the sales team, shadowed my marketing, and design teams.
What worked in that first month was forcing a simple narrative and repeating it until it became a shared language. Platforms and marketplaces can pull you into endless nuance, so I kept coming back to a clear story: who the customer is, what job they’re trying to do, what fails today, and what changes if we solve it. I anchored that story to a primary outcome metric we could all rally around, total payments volume (TPV), and then paired it with the reality that TPV only matters if we protect the system with the right guardrails (reliability, risk signals, dispute/chargeback considerations, and operational burden). I also made sure I delivered one early win that reduced friction for the team. It wasn’t flashy, but it signaled that I wasn’t here to add process, I was here to make execution easier.
What didn’t work as well early on was trying to be too universally responsive. I said 'yes' too often in the name of being helpful, joining too many slack threads and entertaining too many 'quick calls’. That created context switching and slowed me significantly. The lesson I took from that was that responsiveness isn’t impact. Once I started using a clear filter, I simply asked this question: does this move our product ahead in this quarter? I saw that the noise dropped, prioritization got easier, and the team trusted the decisions more.
Days 30 to 60
Between days 30 and 60, I shifted from learning to alignment and decisions. This was the stage where I stopped collecting inputs and started translating them into a plan that the team could execute with confidence. I worked with data science and engineering to define success in a way that connected to TPV. I pushed for clarity on the levers that actually influence TPV in this new world, activation, time-to-value, reliability of critical features, and reducing friction that causes churn or stalled adoption. I also made trade-offs explicit instead of letting them stay implicit. Most roadmap debates in payments aren’t about ideas, they’re about constraints. So I brought real options to the table, clarified what we gained and what we risked with each path, and made sure decisions were visible and durable rather than re-litigated every two weeks.
What worked in days 30 to 60 was narrowing scope into tangible, shippable products that could be measured. Instead of treating the roadmap like a list of features, I treated it like a set of bets tied to TPV and the leading indicators that feed it. I looked for the smallest end-to-end experience we could deliver safely, something we could roll out progressively, monitor closely, and iterate on quickly. I also found that writing decisions down, briefly, clearly, and in plain language, created alignment faster. A simple decision log reduced confusion, reduced debates, and helped stakeholders get oriented in one single direction.
What didn’t work as well in this phase was assuming alignment meant everyone interpreted decisions the same way. I had a couple of moments where I walked out of a meeting thinking we were aligned, only to discover that different teams had different mental models of scope, ownership, or sequencing. The lesson I learned was to make alignment testable. I started closing key meetings by restating the decision, the owner, the next step, and what was explicitly out of scope. It felt repetitive, but it prevented expensive misunderstandings.
Day 60 to 90
From days 60 to 90, I’ll shift from alignment into execution and proof. This is where the narrative has to meet reality, and where I’ll try to operate more like an operator than a storyteller. I’ll make sure we launch with a plan that clearly defines what success looks like for TPV , what failure looks like through guardrails, and what we’ll do in either scenario. We’ll design the rollout to be controlled and measurable, with monitoring that’s easy to interpret and the ability to pause or roll back if guardrails trip.
What I expect will work in this phase is treating launch as a learning loop, not a finish line. I’ll push for a post-launch review quickly, while the details are still fresh, so we can compare expectations to reality, capture surprises, and decide what to change next. I’ll also start building out the next two quarters as clear bets with measurable outcomes, while keeping the longer horizon directional so we preserve flexibility without creating false certainty.
What I want to avoid repeating in this phase is 'shipping for shipping’s sake,' or letting urgency turn into scope creep. The lesson from the first 60 days is that focus is a discipline, not a personality trait in this new environment. I’ll keep practicing saying no sooner, especially when work doesn’t map cleanly to moving TPV, improving the platform/marketplace experience, or protecting the system with the right guardrails.
If you’re stepping into a new PM role on a complex product, my biggest takeaway is simple: your first 60 days are about creating clarity, and your next 30 are about proving you can turn that clarity into measurable outcomes. In my case, that means shipping in a way that earns the right to scale, and moving TPV the right way.
