# Career moves in product, from your next role to your own company — Full Chat Transcript The Product Careers work group answers product career questions in group chats. The advice covers choosing a next role, reviews and promotion, and moving into product or out of it to found a company. Updated: 2026-10-13 HTML page: [Career moves in product, from your next role to your own company]() Summary: [Summary]() Work group: [Product Careers]() ## Participants - [Nikhyl Singhal]() — Founder of Skip. Former VP of Product at Meta and Chief Product Officer at Credit Karma - [Sachin Rekhi]() — Founder and CEO of Notejoy. Former Head of Product for Sales Solutions at LinkedIn - [Ravi Mehta]() — Product advisor. Former Chief Product Officer at Tinder and VP Consumer Product at TripAdvisor - [Yue Zhao]() — Founder and coach at The Uncommon Executive. Former Chief Product and Technology Officer at Fuzzy and PM manager at Meta - [Jiaona Zhang (jz)]() — Chief Product Officer at Laurel. Former SVP of Product at Webflow and CPO at Linktree - [Ben Erez]() — Co-founder of Insider Loops. Former PM at Facebook and Lead PM at Attentive - [Hadar Dor]() — Founding Product Lead for AI Shopping at Instagram. Former founding Product Lead for Ads at Shopify ## Full Chat Transcript #### [What to check before you accept your next role]() **Question:** How do you decide what kind of role to take next? ##### [Yue Zhao]() After the startup where I was Chief Product and Technology Officer shut down in 2023, I talked with companies about VP Product and CPO roles. The offers were strong, but I had already reached the product leadership goal I had spent years pursuing. I had to decide what I wanted the next role to do for my life. [Citation: https://news.theuncommonexecutive.com/p/how-the-uncommon-executive-was-born] My filter became three questions: Will I enjoy the day-to-day work? Will it let me have a meaningful impact on people? Can it cover my share of my family's finances? Coaching met the first two because I had already done it on nights and weekends since 2016. I expanded the practice and committed full-time once it reached my financial number in June 2024. [Citation: https://news.theuncommonexecutive.com/p/how-the-uncommon-executive-was-born] The filter can change with your stage of career. Earlier, I chose roles for title, pay, brand, and team size. By 2023, those were less useful measures for the decision in front of me. I would name the outcomes you need from your next role, then look for evidence in work you have actually tried before you accept an offer. ##### [Nikhyl Singhal]() I start with the kind of work I can do exceptionally well in the first six months. A bigger title can be a poor trade if I spend the first year struggling to get traction. A role where I can deliver, earn trust, and then take on more scope often creates the stronger next move. [Citation: https://theskip.substack.com/p/crafting-a-career-framework-with-c6c] Then I narrow the search by company stage. Before product fit, the work calls for fast experiments and comfort with uncertainty. After product fit, the company needs people who can add structure without slowing it down. Growth calls for resilience as teams and products expand; scale offers experienced managers and larger systems, with slower decisions. I usually find that only one or two stages fit what someone wants to do each day. [Citation: https://theskip.substack.com/p/stage-of-company-not-name-of-company] Finally, I ask whether the company is growing, how quickly I can find my footing, what story the role gives me for the next transition, what new skills it adds, and whether the pace fits my life right now. Those answers make the trade-offs between two offers much clearer. [Citation: https://theskip.substack.com/p/crafting-a-career-framework-with-c6c] ##### [Jiaona Zhang (jz)]() My first decision is which kind of work I want to get better at: building product myself, managing PMs, or leading the product function. Those are different jobs, even when the titles look similar across companies. [Citation: https://review.firstround.com/podcast/from-pm-to-vp-of-product-jiaona-zhangs-career-advice-from-webflow-airbnb-dropbox/#content] Early on, I chose roles that stretched a strength I already had. At Dropbox, I built on my ability to execute by taking on complex launches with lean teams. At Airbnb, I grew into building teams and thinking across platforms. At WeWork, I took on infrastructure because I wanted to understand both the underlying systems and the product work they support. Each move gave me a specific new skill to develop. [Citation: https://review.firstround.com/podcast/from-pm-to-vp-of-product-jiaona-zhangs-career-advice-from-webflow-airbnb-dropbox/#content] In interviews, I ask the future manager how they will define success in six months and a year, which skills I can build, and what challenges I will actually be able to influence. Their answers tell me more about the role than its title does. [Citation: https://review.firstround.com/podcast/from-pm-to-vp-of-product-jiaona-zhangs-career-advice-from-webflow-airbnb-dropbox/#content] ##### [Yue Zhao]() Nikhyl's company-stage test connects to one more question I would ask if the next role is a step into management: Is there an actual business need for that scope? At Instagram, I was exceeding expectations and leading the work of two PMs, yet the PM teams stayed lean and senior. There was no opening for the management progression I wanted. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7394745624056889344/] Before accepting a role with a promised path to leadership, I would ask whether the skip-level's team and budget are growing, whether a role at the target level is likely within six months, and whether that company usually promotes its own people into senior roles. A hiring manager's support matters; the staffing plan determines whether there is a role to move into. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7394745624056889344/] ##### Question > Nikhyl, Yue tested coaching alongside her job and went full-time when it could cover her share of family finances. How would you weigh that evidence against the growth offered by a strong CPO role? Please ground your answer in a public example and cite it. ##### [Nikhyl Singhal]() Yue's years of coaching alongside her job and a clear financial threshold are strong evidence. I would give that real weight against a CPO offer, especially if she has already learned what that leadership job asks of her. The remaining question is which path offers the growth she wants now: a CPO role could deepen her experience leading product, while coaching lets her build a different kind of work she has already tested. I have long coached product leaders while holding operating roles. In my conversation with Lenny, I described starting a small group of product leaders, watching its members find value in helping one another, and being careful about scaling it because trust mattered to the work. That was a way to learn what the work required through practice, rather than assuming a bigger audience would make it better. [Citation: https://open.spotify.com/episode/4sTtoDcy2QFK49QRGW8cgY] For Yue, I would compare the specific learning and day-to-day work of the best CPO offer with what her coaching practice had already shown her. Once the practice covered her financial need, the CPO title alone would give me little reason to override that evidence. ##### Question > Ravi, Nikhyl would prioritize a role where he can gain traction in six months, while jz looks for a specific skill to build. If one offer gives you quick wins and another gives you a bigger learning curve, how would you choose? Please use a public example and cite it. ##### [Ravi Mehta]() I would choose the bigger learning curve if I could name both the skill I want to build and a credible first win. If the company needs me to learn an unfamiliar domain, I would ask what I can improve in the first 90 days while I learn it. My product competency guide breaks the craft into 12 skills so you can identify a specific strength and gap, then make a development plan. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7018275366993616898/] An early win can be small and still matter. In my public framework with Jori Bell for a new product leader's first 90 days, examples include fixing a recurring support issue, running an A/B test on a high-traffic page, or retiring a feature that consumes resources. Those moves build trust while you learn the people, business, and processes. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7316155441758015489/] So I would ask each hiring manager two things: Which skill will this role force me to practice repeatedly, and what useful result can I deliver in the first quarter? A stretch role with a credible answer to both would beat an easy-win role for me. If the stretch role offers no path to an early result, I would take the quicker traction seriously. ##### [Sachin Rekhi]() The PM title can hide four very different jobs. Builders own the roadmap and user experience; tuners run tests to move a metric; innovators search for product-market fit; enablers build tools and services for other teams. I would ask what the role actually requires each week and compare that work with the skills I want to develop and the work I enjoy. The same company can offer several of these roles, while a small startup may need one PM to do parts of each. [Citation: https://www.sachinrekhi.com/p/3-types-of-product-managers-builders-tuners-innovators] Early in your career, trying several types helps you find your fit. I do recommend building strong core PM skills as a builder before taking an innovator role. Searching for product-market fit already involves a lot of uncertainty; learning the basics of managing a product at the same time makes it harder to succeed. [Citation: https://www.sachinrekhi.com/p/3-types-of-product-managers-builders-tuners-innovators] ##### [Yue Zhao]() There is a useful third option between waiting for a promotion and taking an external offer. After a year at Instagram, I wanted to manage again. I was leading work across two PM roles and exceeding expectations, yet the team kept PM groups lean and made few internal promotions. Moving to another part of Meta with larger teams gave me a more credible path back into management. [Citation: https://news.theuncommonexecutive.com/p/why-being-wickedly-smart-and-capable] If a current role still has work you value, look at adjacent teams before leaving the company. Ask where investment and team size are growing, then check whether leaders there have recently promoted people into the level you want. Those facts say more about your likely next step than a promise to revisit your title later. [Citation: https://news.theuncommonexecutive.com/p/why-being-wickedly-smart-and-capable] ##### [Jiaona Zhang (jz)]() Yue's point about a real opening matters especially for a head-of-product role. I would also ask the CEO what decisions they expect me to make and where they want us to work together. At Webflow, Vlad was deeply product-minded, so part of my job was helping us step back from a proposed solution, agree on the problem, and turn the company's vision into a strategy teams could execute. That is a specific working relationship; the same title under another CEO could mean a very different job. [Citation: https://review.firstround.com/podcast/from-pm-to-vp-of-product-jiaona-zhangs-career-advice-from-webflow-airbnb-dropbox/#content] ##### [Nikhyl Singhal]() One risk in that trade-off is treating a company's past growth as a promise of your own growth. In my work on ex-hypergrowth companies, I have urged people to check whether the business is still expanding and creating new work, since a company can retain its reputation after its growth slows. [Citation: https://theskip.substack.com/p/should-i-join-or-leave-an-ex-hypergrowth-b00] For either offer, I would ask what new customer demand is creating the role, which product decisions the person will own, and what would have to happen for the role to expand. A steep learning curve is worth taking when there is room to apply what you learn; quick wins matter more when they earn you the trust to take on that room. ##### [Sachin Rekhi]() For two roles with similar day-to-day work, I use passion, skill, and opportunity as separate tests. Passion includes both the mission and the tasks filling my calendar. Skill means a credible path to becoming excellent at the work, including the time needed to learn it. Opportunity means enough demand for the work to support the life I need. The weights vary by personal circumstances, but an offer that fails one test deserves a closer look even if its title is strong. [Citation: https://www.sachinrekhi.com/p/optimize-your-career-for-passion-skill-opportunity-fit] I would ask people doing the role to walk me through a recent week. That conversation can reveal whether a mission I care about comes with work I would actually enjoy practicing for years. ##### [Ravi Mehta]() Sachin's four types are useful, and I would go one level deeper in the interview: ask how much time the job actually calls for in innovation, management, and production. My IMP exercise has leaders estimate the share they need in each area, then compare it with how people spend their time today. That gap can explain why a role advertised as strategy ends up being mostly execution, or why a team needs a manager more than another idea generator. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7009204927373692928/] I would ask the hiring manager to do that estimate for the first six months. It gives me a concrete way to check whether the learning curve I am choosing is the one I will actually encounter. ##### [Nikhyl Singhal]() Yue's internal move is a useful reminder that a transition can happen inside the same company. In my career FAQ, I call out the "double jump": someone joins for one job and moves into another as a growing company develops a new need. That possibility is worth investigating before accepting a bigger outside title. [Citation: https://theskip.substack.com/p/career-faq-with-nikhyl-singhal-e56] I would ask the prospective manager which teams have gained scope in the past year and where people who succeeded in this role went next. If they can point to actual moves, the initial role may be a better entry point than its title suggests. If every example depends on a future reorganization, I would judge the job on its current scope. ##### [Yue Zhao]() jz's question about the CEO's working style also tells me to compare answers across the hiring panel. In senior leadership searches, I've seen executives begin interviews with different ideas of what the new leader should do; sometimes they settle on the criteria only during the search. [Citation: https://news.theuncommonexecutive.com/p/how-to-communicate-what-really-matters] If the CEO expects a product strategy partner and the CTO expects someone to run delivery, I would ask them to agree on the first six months of decisions, priorities, and authority before accepting. That conversation tests whether the role I am choosing is the role the company intends to hire for. ##### [Jiaona Zhang (jz)]() The company should need the version of you that wants to show up each day. When founders hire a first product leader, I advise hiring for the scale the company expects to reach in roughly two years. Someone whose experience is far ahead of the company's needs can end up with too little meaningful work; someone with too little experience can struggle to lead its next stage. I would apply that same check as a candidate: ask what the team and product will need from me now, and what will change as the company grows. [Citation: https://review.firstround.com/podcast/from-pm-to-vp-of-product-jiaona-zhangs-career-advice-from-webflow-airbnb-dropbox/#content] ##### [Ravi Mehta]() One final check I would use is how the company makes trade-offs under pressure. I have suggested asking, "All things being equal, what isn't?" The answer tells you which priority wins when two good options compete. Ask the hiring manager for a recent decision where the team chose between shipping sooner, improving quality, and learning from customers. The example gives you more to judge than a statement of company values, especially if you are choosing a role where you expect to make those calls yourself. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7311085449643442176/] #### [Title or company: how to compare the two offers]() **Question:** Should you take a bigger title at a smaller company or a smaller role at a stronger one? ##### [Nikhyl Singhal]() I’d compare the two jobs by the story each lets you tell after two years: what you built, how your scope grew, and whether you learned to handle a harder class of problems. A smaller role where you can establish yourself quickly can lead to greater scope; a bigger title with weak company growth may leave little room to deliver. In my career framework, I also weigh company growth rate, the skills the role adds, and the pace of work I can sustain. [Citation: https://theskip.substack.com/p/crafting-a-career-framework-with-c6c] I saw the stage mismatch at Credit Karma. As we entered hypergrowth, roughly two-thirds of the PM team left over 18 months. Many took senior roles at earlier-stage companies where their experience finding product fit and managing early scale was useful. Others stayed and grew with Credit Karma. Both paths made sense for different people. [Citation: https://theskip.substack.com/p/when-do-you-know-its-time-to-leave] Ask each hiring manager what you would own in year one, how the business is growing, and what someone who excels in the role would own in year two. Those answers tell you more about what good looks like than the title. ##### [Yue Zhao]() I took a smaller IC role at Instagram/Meta after growing into Head of Product for Pro at Thumbtack. I wanted an official level and a different kind of experience. Later I left Meta for a CPO role at Fuzzy because the path through a large company no longer fit the work I wanted to do. Those moves made sense at different points in my career. [Citation: https://news.theuncommonexecutive.com/p/whats-the-best-or-fastest-path-to] I would compare the offers on three concrete questions: ✅ What decisions will you actually own, and what team and budget can you direct? Ask for examples of decisions the last person in the role made. ✅ Is the company growing enough to create the next level of responsibility? Thumbtack grew rapidly after Sequoia's investment, which gave me room to grow from first PM to Head of Product for Pro. A startup title offers less growth if the business stalls. [Citation: https://news.theuncommonexecutive.com/p/whats-the-best-or-fastest-path-to] ✅ Who will sponsor your growth, and what will you learn from them? At Meta, sponsorship and mentorship mattered to my path. [Citation: https://news.theuncommonexecutive.com/p/whats-the-best-or-fastest-path-to] I would take the bigger title when the authority, business growth, and support are real. I would take the smaller role when it gives me stronger coaching and a clearer route to meaningful scope. ##### [Sachin Rekhi]() The title is a poor proxy for the level at which you’ll practice product management. In my career-ladders analysis, PM advancement has three dimensions: independence, product scope, and leadership. Probe for the decisions you can make independently, the complexity of the product you own, and whether you will lead beyond your immediate team. A smaller company can give you the full product lifecycle quickly; a larger company can offer strong coaching and rotations across products. [Citation: https://www.sachinrekhi.com/product-management-career-ladders-at-8-top-technology-firms] My experience leading Sales Navigator at LinkedIn made the scope question concrete. I owned the business results and reviewed weekly bookings with the CEO and CFO. That exposure forced me to get much better at reading product and business metrics. [Citation: https://www.youtube.com/watch?v=tiCEnVs--dk] I’d choose the bigger title when it comes with comparable ownership, a team that can execute, and room to learn. If the stronger company gives you more demanding work and better coaching, take the smaller role. ##### [Nikhyl Singhal]() One trap in the "stronger company" choice is treating its past growth as its current growth. I’ve warned about ex-hypergrowth companies where a lower valuation, tighter budgets, and a shift toward sustaining the business change the jobs available to PMs. The name on your résumé stays strong while the scope you were promised may shrink. [Citation: https://theskip.substack.com/p/should-i-join-or-leave-an-ex-hypergrowth-b00] I would ask what happened to customer growth, new product investment, and the PM org over the last four quarters. Then ask which team owns the next growth bet. If the smaller role puts you on that team with a clear path to own more, I’d give it serious weight. If the smaller company has a real product customers want and gives you authority to build the team, the larger title can be the better transition. ##### [Ravi Mehta]() I would separate your own skill growth from the company's ability to reward it. My Reverse 9-Box asks you to assess both; a strong performer can still stall in an environment with little potential. My Career Escalator looks for evidence in a thriving business, promotions, recognition, and how well you work with the manager. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7150555643089707008/] Ask each company to walk you through the last two people who grew into more scope: what did they deliver, how long did it take, and what new responsibility opened up? Then identify the skill you most need to build in your next role. If the smaller title gives you practice in that skill and the company has a record of rewarding it, I would take it seriously over a bigger title with no credible next step. ##### [Jiaona Zhang (jz)]() A bigger title may move you into a different job entirely. I think about a product career in three phases: doing the product work yourself, getting results through a team, and leading the whole function. Ask which phase each offer puts you in and whether you actually want to do that work. [Citation: https://review.firstround.com/podcast/from-pm-to-vp-of-product-jiaona-zhangs-career-advice-from-webflow-airbnb-dropbox/#content] Ask the hiring manager to name a hard problem you will face and how they would help you learn through it. A company-wide obstacle you cannot influence will teach you less than a hard product problem you can work through. At Dropbox I became known for getting complex launches over the finish line with lean teams; at Airbnb I developed a different skill in building teams. Those experiences gave me specific ways to grow, regardless of what the title said. [Citation: https://review.firstround.com/podcast/from-pm-to-vp-of-product-jiaona-zhangs-career-advice-from-webflow-airbnb-dropbox/#content] ##### Question > Yue, jz says the bigger title may mean leading a function instead of doing product work. When you moved from leading Pro product at Thumbtack to an IC role at Meta, how did you judge whether the smaller role would build skills you could use later? Please use public sources only. ##### [Yue Zhao]() I judged the Meta IC move by what I could learn and the level I could establish there. At Thumbtack, I had grown from first PM to Head of Product for Pro and reached a ceiling. Meta gave me a recognized level and a chance to work with people operating at a very different scale. That was useful even though the title looked smaller. [Citation: https://news.theuncommonexecutive.com/p/whats-the-best-or-fastest-path-to] I would check two things before making that trade. First, will the IC role give you enough product scope to perform at the level you want to reach? Second, is there a manager who can teach you and sponsor the next move when a management seat opens? When I later sought to move into management at Meta, I passed on teams where the manager was new or the culture felt wrong. I chose a new initiative with good scope and a senior leader I wanted to learn from. [Citation: https://news.theuncommonexecutive.com/p/how-i-went-transitioned-from-ic-to] ##### Question > Sachin, Yue chose an IC role at Meta for its level, scope, and manager, while you assess independence, product scope, and leadership. If both offers meet those tests, how would you decide between them before accepting either one? Please use public sources only. ##### [Sachin Rekhi]() The product stage changes the job more than the company name suggests. I distinguish builders, who improve an existing product; tuners, who optimize growth or monetization; and innovators, who search for product-market fit. An innovator role can exist inside a large company, while a small company with an established product may need a tuner. [Citation: https://www.sachinrekhi.com/p/podcast-3-types-of-product-managers] Ask each hiring manager to name the product problem you would spend most of your week solving, then compare that work with the skills you want to build. If you want to learn product discovery, a senior title attached to optimizing an existing funnel will give you fewer chances to practice it than a smaller role launching a new product. #### [Switching career tracks or going deeper: run a trial first]() **Question:** When is it worth switching career tracks instead of going deeper in your current one? ##### [Nikhyl Singhal]() I’d compare the growth rate of your skills with the growth rate of the opportunities available to you. First, define what good looks like in your current track: larger problems, less guidance, and work you can point to. Then ask whether your current company can give you those problems. A slow quarter alone is weak evidence; a sustained lack of scope is stronger. [Citation: https://theskip.substack.com/p/when-do-you-know-its-time-to-leave] A track switch is worth serious consideration when the adjacent track gives you a better path to grow and you can see how you’ll succeed there. In my career framework, I ask what story a role creates for the next opportunity, how quickly you can find your footing, what new experience it adds, and whether its pace fits your life. A smaller role where you do excellent work in six months can be a better first transition than a big title where you struggle to get traction. [Citation: https://theskip.substack.com/p/crafting-a-career-framework-with-c6c] At Credit Karma, roughly two-thirds of the dozen PMs I inherited left within 18 months of hypergrowth; many joined earlier-stage companies at senior levels, using the skills they had built in that phase. Their experience suggests a useful test: identify the problems you already solve well, then find a track and company phase where those skills give you a credible start. [Citation: https://theskip.substack.com/p/when-do-you-know-its-time-to-leave] ##### [Sachin Rekhi]() I would switch tracks when a small, real trial shows a better fit between the work I enjoy, the skills I can build, and an actual opportunity. Until then, I would keep building depth while testing the alternative. I learned this through two short experiments. A three-month Goldman Sachs internship showed me that building software for bankers left me unfulfilled. A Microsoft program management internship showed me that shaping software around users was work I wanted to keep doing. Later, I tried product marketing for six months because I wanted broader scope and more customer contact. I missed having a direct hand in the product, so I returned to product management. Each trial gave me evidence before I made a larger commitment. [Citation: https://www.sachinrekhi.com/p/how-i-leveraged-an-explore-exploit-algorithm-to-find-my-dream-job] For someone weighing a switch, I would ask: Which tasks give you energy after the novelty fades? Can you get strong at them with sustained practice? Is there a role where those skills matter? Then design a bounded trial, such as a project with the adjacent team, and judge the day-to-day work. At mid-career, time for building mastery is limited, so a switch should earn its place against the depth you could build where you are. [Citation: https://www.sachinrekhi.com/p/midlife-career-exploration] ##### [Yue Zhao]() I would separate a stalled role from a career-track change. At Thumbtack, I hit a ceiling after five years and moved to Meta; I stayed in product because I still wanted to grow as a product leader. A delayed promotion with no clear path, or a lack of support from sponsors, can be a reason to change companies without abandoning the craft. [Citation: https://news.theuncommonexecutive.com/p/whats-the-best-or-fastest-path-to] My move into coaching had a different test. After Fuzzy shut down, I had opportunities to pursue another VP Product or CPO role, but the goals I was optimizing for had changed: impact on people, joy in the day-to-day work, and enough income to cover my share of family finances. I had coached on nights and weekends since 2016, expanded from a few dozen clients to hundreds, and reached my financial number before committing full-time in June 2024. [Citation: https://news.theuncommonexecutive.com/p/how-the-uncommon-executive-was-born] So I’d ask: Is the current ceiling about your company, or about the work itself? Have you tried the new work enough to know you want its ordinary Tuesdays? And what concrete income or runway threshold would make the switch sustainable? If the answer points to the company, seek a role with better scope and sponsorship. If it points to the work, run a small trial and set a financial threshold before switching tracks. ##### [Nikhyl Singhal]() Sachin’s trial is a good way to test the new work. I’d run a second test in parallel: ask for a harder problem in your current track, with clear ownership and a date to review the result. If that work restores your growth, the constraint may have been your role or company phase rather than your track. I saw how much phase can matter at Credit Karma. Some PMs who left during hypergrowth took senior jobs at earlier-stage companies, where their experience with the earlier phase was immediately useful. Before retraining for a different career, check whether another team or company phase would let you use what you already do well on bigger problems. [Citation: https://theskip.substack.com/p/when-do-you-know-its-time-to-leave] ##### Question > Ravi, Nikhyl suggests testing harder work in the current track while Sachin tests the adjacent one. If both trials go well, how would you decide whether switching tracks is worth the lost depth? Please use a public example and cite it. ##### [Ravi Mehta]() If both trials go well, I’d choose the path where the next two years of work build the stronger edge. Score each trial on three things: the results you produced, the work you want to repeat every week, and the scope someone will actually give you next. A successful trial alone says you *can* do the work; it doesn’t tell you which path will build more on your strengths. My public example is the way I’ve advised PMs responding to AI. A PM can now prototype across design and engineering boundaries, but that wider reach does not automatically justify changing specialties. I’ve argued for getting better at the hardest parts of your own job, using AI to extend your particular strengths, and learning enough about other competencies to judge the output and bring in a person with stronger judgment when needed. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7508260081600454656/] If an adjacent-track trial gives you repeated evidence of a stronger edge *and* a real role with more ownership, the switch has earned its cost. If both trials are equally promising, I’d keep the depth already built and expand the work around it. ##### Question > Hadar, Ravi would switch when a trial repeatedly uses your strengths and opens more room to grow. Across your moves at Postmates, Lyft, Shopify, and Instagram, how did you decide to change product areas while staying in PM, and what would have justified leaving PM entirely? Please cite public sources. ##### [Hadar Dor]() Across those moves, the product area changed while the work I wanted to do kept building on itself: understand a user problem, make decisions with a team, and ship. At Postmates I worked on courier signup and retention; at Lyft I worked on driver onboarding, new ridesharing modes, and regulatory compliance. Those were different problems where my marketplace and growth experience still helped me contribute. [Citation: https://www.hadardor.com/background] Shopify gave me a new mission, room to build its Growth practice, and the chance to work again with Archie Abrams, a manager I trusted. [Citation: https://hadardor.substack.com/p/joining-shopify] When I later joined Instagram Business, I chose another product-building problem: consumer subscriptions. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7171642029817425921/] I haven’t made a permanent move out of PM, so the threshold is a judgment call. During my four-month career hiatus, I wrote, advised founders, and coached 40 aspiring or junior PMs. I learned that close collaboration was where I learned best, and I returned to a product role. [Citation: https://hadardor.substack.com/p/hadars-newsletter-3-ending-my-hiatus] I’d leave PM if sustained work in another craft made me want its ordinary working days more than the best available product role, gave me people to learn with, and offered a viable way to contribute. A new product area was enough when I could get that through PM. #### [Stay and fix the job, or leave: make one clear ask first]() **Question:** How do you decide whether to stay and fix a job or leave it? ##### [Yue Zhao]() At Thumbtack, I nearly quit after three years. My scope had grown, I was mentoring new director-level hires, and my manager praised my work. I had never clearly asked for the title or compensation I wanted. By the time I raised it, the conversation was heated and tearful because months of resentment had built up. [Citation: https://news.theuncommonexecutive.com/p/how-to-advocate-for-your-needs-at] I would make one specific attempt to change the job before deciding. Tell your manager what needs to change, whether that is scope, support, pay, or a path to promotion. Ask for a concrete commitment and a date to revisit it. If they can make changes and follow through, staying gives you useful information and room to grow. If they cannot offer a credible path, you have your answer sooner, while you still have the energy to look elsewhere. Speaking up does not guarantee a fix, but silence makes it much harder to tell what is possible. ##### [Nikhyl Singhal]() I look at two growth rates: mine and the company's. If I'm ready for bigger problems and the company has no new customers, products, or teams that would create that scope, a job change may be the right move. But first I'd ask my manager what good looks like for the next role and whether the constraint is company opportunity or a skill I still need to build. A difference of opinion about my readiness is something to work on, not a reason to leave immediately. [Citation: https://theskip.substack.com/p/when-do-you-know-its-time-to-leave] The reverse can happen too. When I joined Credit Karma, the company was growing faster than some of the PMs could grow into the roles it needed. About two-thirds of the dozen PMs I inherited left over the next 18 months, many for senior jobs at earlier-stage companies where their experience fit. That was a sensible transition for them. I would give a difficult stretch time to teach me something, then leave if the mismatch persists and I can name a role where my skills and the company's needs fit better. [Citation: https://theskip.substack.com/p/when-do-you-know-its-time-to-leave] ##### [Sachin Rekhi]() I’d start by looking at the work you actually do each week. Which parts give you energy, and which parts drain it? Then ask whether you can change that mix in your current job: a different scope, a senior individual-contributor role, or more time working directly with customers and the product. I faced this at LinkedIn. Sales Navigator grew into a $200 million business, and I had a path toward VP. Yet leading a large team meant I spent less time talking to customers and building products, the work I loved. Continuing up that path would have taken me further away from it. I chose to pursue a different path because I expected to regret never trying, and I believed I could return to a leadership track if the move failed. [Citation: https://podcasts.apple.com/hr/podcast/this-will-make-you-rethink-your-product-and-career-in/id1736359687?i=1000681301768] If a concrete change in your current role gets you closer to the work you want, give it a chance. If the job’s path keeps pulling you away, compare the risk of leaving with the regret of staying. ##### [Jiaona Zhang (jz)]() I ask two questions: Am I still learning through the hard parts, and do I have a credible path to make the work better? Feeling frustrated can mean you are at the point where you are growing most. Feeling too comfortable is a reason to check whether you are still learning. If the current role has a real block, I would look for a specific new opportunity I am excited to build toward, rather than make the decision in the heat of that frustration. [Citation: https://review.firstround.com/podcast/from-pm-to-vp-of-product-jiaona-zhangs-career-advice-from-webflow-airbnb-dropbox/#content] The people affected matter too. At WeWork, during a period of major change, I was offered a role on another team. I had hired people who faced tighter constraints, including someone on a visa, so I chose to give the role to someone else and find my next job. I joined Webflow while pregnant. That choice was specific to my circumstances and the commitments I felt I had made to my team. [Citation: https://podcasts.apple.com/us/podcast/building-minimum-lovable-products-stories-from-wework/id1627920305?i=1000619030079] ##### Question > Ravi, Nikhyl would test whether the company can offer bigger problems, while Sachin left a VP path because the daily work pulled him away from building. How would you decide when the company offers growth but the work itself drains you? ##### [Ravi Mehta]() If the company is growing but the work drains you, inspect the job you'd actually have after the next promotion. More scope can mean more of the same work. If the part you enjoy is building with a small team and the promotion means spending most of your time managing a larger one, company growth alone won't solve the mismatch. I'd ask to change the mix of work first: take ownership of a product problem, spend more time with customers, or move into a role that fits the work you want to do each week. Then judge the proposed role by its calendar and responsibilities, rather than its title. I think recognition and a sense of flow are signals that your environment supports growth. If the company can offer a different mix, staying may work; if its available paths keep taking you away from the work you want, I'd pursue another role. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7324833016369885185/] #### [Before you quit to start a company: what to test while employed]() **Question:** How do you prepare to leave an operating job and start a company? ##### [Sachin Rekhi]() I left LinkedIn while Sales Navigator was growing and I had a clear path to more senior roles. The decision started with the work itself: I wanted to talk to customers and build product again, while my job had become mostly managing people and reviewing their work. Ada and I chose to start Notejoy together and keep the team to the two of us. We also talked through the downside. I felt I could return to an operating role if the company failed. [Citation: https://podcasts.apple.com/hr/podcast/this-will-make-you-rethink-your-product-and-career-in/id1736359687?i=1000681301768] For the idea, write down your assumptions before you write code: the specific customer, their problem, and the value you expect to deliver. With Notejoy, we spoke to both likely users and senior leaders who might sponsor the tool. We did interviews in waves of five, revised our mockups or product, and repeated until the conversations stopped revealing new problems. That gives you a practical preparation task while you're still employed: find people outside your own team who have the problem and listen for evidence that your first assumptions need to change. [Citation: https://www.sachinrekhi.com/podcast-the-notejoy-journey] ##### [Hadar Dor]() I’d use the months before leaving to test what kind of work you want to do when no one has assigned you a roadmap. Set aside regular time to speak with potential customers, write down the problem they face, and try to solve one small part of it. Check your employment agreement and keep company data and resources out of that work. When I left Lyft, I set specific goals for a career hiatus and spent part of it advising founders at five startups. I also coached 40 aspiring or junior PMs. That time taught me about the work and habits I wanted to carry into my next role, even though I ultimately joined Facebook rather than founding a company. [Citation: https://hadardor.substack.com/p/hadars-newsletter-3-ending-my-hiatus] I’d make the decision to resign after you’ve heard a recurring customer problem firsthand and know what you want to test full time. ##### [Ravi Mehta]() Before leaving, test whether you can deliver the outcome by hand. When we started Scale Higher with Victoria Young, we offered 1:1 mentoring to students trying to break into tech, with sessions for the first 40 applicants. That gave us a specific group of people and a real service to learn from. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:6990757852021764097/] I would use that kind of small test to decide what to build and whether to leave: recruit people with the problem, deliver the service, and ask what they would use again or pay for. We later described Outpace as 1:1 guided sprints combining learning, practice, and feedback in a four-week plan. The practical prep is to define a narrow customer and run a repeatable trial with them before committing to a full company. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:6993279684654358528/] ##### [Ben Erez]() I quit a job paying over $100K to start my first company. I thought I had enough savings, then ran out of money around the one-year mark and had to ask for help. So I’d calculate personal monthly spending, pick a date when the cash runs out, and make sure the plan still works if revenue or funding takes longer than expected. [Citation: https://medium.com/p/1e04b7a5d57] Sachin’s interview loop is a good start. I’d add one harder test before resigning: ask prospects to change a real workflow. With my first startup, stores said they would pay us, but the meaningful signal was whether they would integrate their mobile presence, inventory, and customer processes into our software. If you’re a nontechnical founder building software, get specific about who will build it with you. I never found a true technical cofounder, and I consider that my biggest mistake. [Citation: https://medium.com/p/1e04b7a5d57] [Citation: https://medium.com/p/3519b7eae83c] ##### [Sachin Rekhi]() One way to make those pre-resignation customer interviews useful: ask each person to name their five biggest work problems before you mention your idea. Then add your proposed problem to the list and ask them to rank all six. If yours consistently lands near the bottom, you have a weak reason to ask someone to switch tools, even if they politely say they would use yours. I use that sequence to reduce the confirmation bias that comes with pitching an idea first. [Citation: https://podcasts.apple.com/hr/podcast/this-will-make-you-rethink-your-product-and-career-in/id1736359687?i=1000681301768] ##### [Hadar Dor]() Before choosing a cofounder, work together on a small project with real deadlines. Pay attention to how you make a hard decision, give each other feedback, and handle a week when the plan stops working. I’ve found that working closely with someone I trust, who trusts me back, has a huge effect on my career choices. Working with Archie Abrams again was a major reason I joined Shopify. [Citation: https://hadardor.substack.com/p/joining-shopify] I’d want that working relationship tested before tying a new company to it. ##### [Nikhyl Singhal]() The readiness test I would add is whether you can create momentum without your employer's distribution, engineers, and existing customers. In my conversation with Shreyas Doshi, I pointed out that starting a new product inside a large company can feel like founding while drawing on a great deal of support. Look back for a time when you identified a problem, chose a direction, and got people moving before anyone gave you a plan. If you cannot find one, create that experience on a small scale before you resign. [Citation: https://www.youtube.com/watch?v=xjGy2Mt4atU] I would ask why I want to do this now, and whether I want to spend years working on the problem. Shreyas urged founders in that same conversation to plan psychologically for a ten-year journey. That changes the discussion with family and prospective cofounders: everyone should understand the time commitment alongside the cash risk Ben described. [Citation: https://www.youtube.com/watch?v=xjGy2Mt4atU] ##### [Ben Erez]() I’d keep fundraising conversations out of the runway calculation until there’s a signed term sheet. With my first startup, we raised an initial friends-and-family round quickly and assumed a second $250K round would follow once we had a prototype. We overestimated how easy that would be. Investor dinners felt promising too, but I learned that serious interest takes a concrete commitment. Put a separate date on your calendar for when you will cut spending, seek income, or stop if that second check never arrives. [Citation: https://medium.com/p/1e04b7a5d57] ##### [Ravi Mehta]() One correction to my earlier example: free mentoring can test whether you can deliver value, but it cannot tell you whether people will pay. At Scale Higher, we learned that willingness to pay depends on how people experience the offer, so you have to charge to get a clear signal for a paid product. We also tried to shorten the time between each hypothesis and what we learned from customers. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:6889261981283569664/] Before resigning, I would run a paid version of the smallest useful offer and record three things for each customer: what they paid, whether they completed it, and what they sought next. Those observations give you a stronger decision than a list of people who say they like the idea. ##### [Ben Erez]() Hadar’s small project test would have saved me some pain. I started my first company with friends, then found that slow progress made hard personnel decisions emotionally difficult. Later I moved to Gainesville to recruit developers while my cofounders stayed in South Florida; the distance made it harder for them to stay involved in daily product decisions, and the team shrank. [Citation: https://medium.com/p/1e04b7a5d57] I’d use that trial project to agree on who makes product and hiring calls, how often you work together, and what happens if one person needs to step away. Then see how those agreements hold up during a missed deadline. ##### [Sachin Rekhi]() Ben's point about who builds the product is worth making explicit before you resign. I kept my development skills current with a small side project even while working in product and, later, a GM-like role at LinkedIn. When we started Notejoy, I spent time getting back into the technology stack and built the web, desktop, and iOS apps myself. If your plan assumes a tiny team, list the actual work needed for the first product and identify who can do each part before you commit to that plan. [Citation: https://www.sachinrekhi.com/podcast-the-notejoy-journey] ##### [Hadar Dor]() I’d do some market homework alongside the customer interviews. Make a list of the companies already serving the same customer, ask how customers solve the problem today, and write down why your approach might earn a place in their workflow. When I began angel investing, researching companies and their markets and speaking with founders taught me a lot about the kinds of businesses people were actually building. [Citation: https://hadardor.substack.com/p/joining-shopify] That exercise is useful before quitting too, because a promising customer conversation still leaves open how you’ll reach enough similar customers. ##### [Nikhyl Singhal]() Sachin's ranking exercise and Ravi's small trial should lead to one more question: do the same customers want the same product? At Cast Iron, we had paying customers and thought we had found product-market fit. By the tenth customer, the engineers were handling different feature requests because the first customer's problem differed from the second's. I would track the request and the work needed to serve each prospect, then look for a repeatable sale before hiring around the early wins. [Citation: https://review.firstround.com/how-to-craft-your-product-team-at-every-stage-from-pre-product-market-fit-to-hypergrowth/] ##### [Ben Erez]() If the first product needs an engineer you have yet to recruit, make the work concrete before you ask someone to join. I taught myself to create clickable mockups for my first startup, and within weeks two developers were working with me on a prototype. I also took a basic iOS class so I could discuss specs with them more clearly. That preparation gave prospective collaborators an actual product flow to react to, even though I could not build the software myself. [Citation: https://medium.com/p/3519b7eae83c] ##### Question > Ravi, Nikhyl asks whether a founder can create momentum without an employer’s customers or engineers. For your first 40 mentoring applicants, what would you have checked before resigning to know the service could keep attracting customers on its own? Please cite your public account. ##### [Ravi Mehta]() For those first 40 mentoring applicants, I would have recorded where each person heard about us and whether they applied because of a channel we could use again. Then I would have offered the smallest paid version and tracked how many applicants paid and completed it. We offered those first sessions free, so applications alone could not answer the willingness-to-pay question. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:6990757852021764097/] I learned at Scale Higher that you have to charge for a paid product to get a useful signal, and shorten the time from a hypothesis to what customers actually do. Before resigning, I would have repeated the recruitment and paid offer with a second group through the same channel. That would tell me more about independent customer acquisition than a single burst of interest. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:6889261981283569664/] #### [PM, designer and product engineer: who owns which decision now]() **Question:** How do PM, product designer and product engineer roles differ, and where are they blurring? ##### [Ravi Mehta]() I’d distinguish the roles by the decisions each person is expected to own. The PM connects customer needs, strategy, and business outcomes to a choice about what deserves to ship. The designer owns how people understand and use the experience. The product engineer owns how the experience works in software and whether it can hold up in production. Those are useful centers of responsibility, even when one person contributes across all three. The blur is clearest in prototyping. The old handoff was PM specs, designer mocks, engineer build. Now all three can bring a working prototype to a discussion. I’ve argued that prototypes should help teams explore ideas, test feasibility, and validate with users before anyone treats the code as a production commitment. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7448430077089890304/] That changes the PM’s job in a practical way. If the team has three prototypes, the PM needs to help separate deliberate product choices from defaults the tool made, then connect the next experiment to an outcome. An AI feature can gain usage while losing money on each model call. The designer and engineer should be in that decision early because interaction choices and technical costs shape the same outcome. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7505268105149829121/] ##### [Yue Zhao]() On an Instagram Feed project, my tech lead, EM and staff engineers joined user interviews while designers updated prototypes every 2 to 3 days. I kept a loose requirements doc with our goals, constraints, hypotheses and what we were learning. That is where the roles blurred in practice: engineers helped choose which customer problems and solutions to pursue before anyone had a final design. [Citation: https://substack.com/home/post/p-160394845?utm_campaign=post&utm_medium=web] Ravi’s decision ownership is useful. I would start the blur earlier than prototyping, in discovery. The engineer who hears users describe the problem can propose an approach the designer and PM would miss at the UX level. During the build, that shared context helps the team revisit a design when constraints surface, rather than treating the spec as a contract. At Instagram, we debriefed after interviews to compare observations and decide which hypotheses to test next. [Citation: https://substack.com/home/post/p-160394845?utm_campaign=post&utm_medium=web] ##### [Ravi Mehta]() Yue’s example moves the boundary to the right place: engineers who hear users firsthand can shape the problem and the solution before a spec exists. That also means a team can distribute product management work across PMs, designers, engineers, and founders. The job still includes understanding customers, setting strategy, connecting features to outcomes, and deciding what ships. I’ve seen the distinction matter when teams cut PM roles: someone must still make those decisions and make the trade-offs visible. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7511432879525015554/] For a small team, I’d make one shared discovery habit explicit: after each user interview, have the PM, designer, and engineer write down what changed about the problem, the experience, and the implementation. Then name who will make the next call and what evidence would change it. ##### [Sachin Rekhi]() Yue's example makes the discovery step concrete. I'd move the roadmap decision until after the team has tested possible solutions. I used to start with the customer problem, put it on the roadmap, and explore solutions afterward. My case for product shaping is to prototype several problem-solution pairs first, then prioritize the pair with the strongest evidence that the solution resonates. AI makes that exploration cheap enough for many teams to do. [Citation: https://www.sachinrekhi.com/p/the-complete-guide-to-ai-prototyping] The PM still owns the choice of problem and the strategy behind it. Bring the designer and product engineer into interviews before building the prototypes, so their observations shape which problem-solution pairs get explored. Then let the designer challenge the interaction and the engineer challenge feasibility while the PM tests whether the customer problem is worth solving. The team can prioritize after learning from all three. ##### [Yue Zhao]() At Fuzzy, I wanted engineering to start projects with PM and design before specs were locked. Our VP of Engineering preferred final specs and designs before the build. That disagreement affected how quickly we could learn while the company had nine months to turn profitable. The board and CEO eventually combined the CPO and CTO roles to speed decisions and give the teams one product-development approach. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7267641129884336132/] Role blur at the IC level needs an executive counterpart: product and engineering leaders must agree on when engineers enter discovery and how teams change direction during the build. Otherwise a team can do Ravi’s interview debrief perfectly and still wait for permission to act on what it learned. ##### [Sachin Rekhi]() Yue's leadership example points to a practical distinction: faster prototypes only speed learning if the team can change its plan after seeing them. In my work, AI has helped me build interactive vision walkthroughs without waiting for dedicated design time, while I still spend human judgment on prioritizing the roadmap. A generated requirements doc tends to cover generic needs and miss the specific choices that differentiate a product. [Citation: https://www.sachinrekhi.com/p/how-i-use-ai-as-a-product-manager] For a PM, designer, and product engineer working together, I would set a short decision review after each prototype test: what did customers actually do, what changed in the experience, what technical constraint emerged, and which roadmap choice changes as a result? Leaders need to let the team act on that review. Otherwise the prototype becomes another artifact waiting for approval. ##### [Nikhyl Singhal]() The amount of role overlap should change with the company's stage. In my First Round piece, I described bringing a PM into my startups too early, while the founder was still finding product-market fit. The PM had little room to set a direction. Waiting too long creates a different failure: once several engineers and a designer join, people lose the reasons behind a feature and engineering can build something that misses the mark. [Citation: https://review.firstround.com/how-to-craft-your-product-team-at-every-stage-from-pre-product-market-fit-to-hypergrowth/] Yue’s point about when engineers enter discovery matters here. In a small team, I’d have the founder, designer, and engineers share customer context directly and ask which decision actually needs a PM owner. As the company grows, the PM’s work shifts toward making releases predictable, then choosing among opportunities across products. At Credit Karma’s growth stage, we had to expand beyond free credit scores while scaling the existing product, which demanded both shared discovery and clear decisions about where to invest. [Citation: https://review.firstround.com/how-to-craft-your-product-team-at-every-stage-from-pre-product-market-fit-to-hypergrowth/] ##### [Jiaona Zhang (jz)]() Sachin’s point about testing a solution before committing to it matters even more when a prototype makes a feature look easy to ship. At Webflow, we had invested in memberships and logic and reached a hard question: we could make the features viable, but could we get them to the quality users wanted? We considered whether to keep investing internally or let the ecosystem build some of that experience. The decision required the PM, designer and engineer to look together at user expectations, the quality of the workflow and the cost of building more. [Citation: https://podcasts.apple.com/us/podcast/building-minimum-lovable-products-stories-from-wework/id1627920305?i=1000619030079] That is where I see a useful difference in emphasis. A designer can name what makes the workflow feel complete to its users. An engineer can judge which pieces the product or ecosystem can reliably deliver. The PM has to make the investment choice and explain what success would look like. All three need enough customer and business context to challenge the choice before the team commits more time. [Citation: https://podcasts.apple.com/au/podcast/how-linktree-is-powering-50m-next-gen-creators-with/id1801935822?i=1000702039992] ##### [Nikhyl Singhal]() Jz’s Webflow example is a good test of what good looks like after roles blur: someone still has to decide whether to keep investing, while design and engineering make the quality and delivery tradeoffs visible. For a PM choosing a career direction, I’d look at which part of that work gives you energy. In my PM career framework, I distinguish builders who stay close to product details from managers who get satisfaction from scaling the team and its delivery. Both can contribute; a PM who enjoys neither will have a harder time as AI reduces the amount of routine coordination needed. [Citation: https://www.youtube.com/watch?v=Eu10wQt9uJs] A practical test is to build a small prototype around a customer problem, show it to a designer and an engineer, and ask what each would change before users see it. The PM learns whether they enjoy making choices in the product itself, and the team gets a clearer view of where specialist judgment is needed. ##### [Ravi Mehta]() Jz’s Webflow example points to a useful hiring test. Once a candidate can make a prototype, I’d assess the judgment they bring to the investment decision around it. Ask a PM why this problem deserves investment, a designer how the interaction will make sense to users, and an engineer what the prototype leaves unresolved for production. Then ask each what evidence would make them stop investing in the feature. I’ve argued that people should deepen their strongest product competency while learning enough of the others to give AI useful instructions and spot weak decisions. The goal is to know when a teammate has better judgment than the tool or than you do. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7508260081600454656/] ##### Question > Jiaona, in your Webflow memberships and logic example, how did the team decide whether the quality gap called for more internal work or an ecosystem solution? Which judgment belonged to the designer, engineer, and PM? Please cite the public account. ##### [Jiaona Zhang (jz)]() In the public Webflow account, I described the choice we faced with memberships and logic: we could reach a viable version, but we were unsure we could reach the experience users wanted by continuing to build internally. We considered releasing what we had and asking the ecosystem to contribute to the fuller experience. I did not describe a final team decision or a formal division of decision rights in that account. [Citation: https://podcasts.apple.com/us/podcast/building-minimum-lovable-products-stories-from-wework/id1627920305?i=1000619030079] The judgment I would want from the designer is which parts of the workflow need polish for users to trust and enjoy it. The engineer should estimate what we can build well ourselves and what the ecosystem could support reliably. The PM should weigh those findings against user need, time and investment, then make the choice clear to the team. In that conversation, I argued for doing fewer things well instead of spreading the team across too many partly finished features. [Citation: https://podcasts.apple.com/us/podcast/building-minimum-lovable-products-stories-from-wework/id1627920305?i=1000619030079] ##### Question > Sachin, you said the PM owns the choice of customer problem. Nikhyl says founders may lead that choice before product-market fit, even with a designer and engineers on the team. How would you assign that decision at each stage, and when would you add a PM owner? Please cite public work. ##### [Sachin Rekhi]() I would assign the customer-problem decision to whoever is accountable for the product strategy at that stage. Before product-market fit, that may be the founder. The designer and engineers should still join discovery and test possible solutions, while the founder makes the final investment call. My definition of PM work covers vision, strategy, design, and execution, but it does not require every team to have a PM title for those decisions to happen. [Citation: https://www.sachinrekhi.com/p/video-the-role-of-the-product-manager] I would add a PM owner when the founder can give them a real area of product direction to own: a customer segment and problem, a goal, and room to choose among competing problem-solution pairs. At that point, I would specify the needed kind of PM work. I've distinguished innovators finding new opportunities, builders bringing products to life, tuners improving existing products, and enablers supporting other product teams. Hiring against that work is more useful than adding a PM to coordinate handoffs. [Citation: https://www.sachinrekhi.com/p/video-types-of-product-managers] The handoff should be explicit: name who makes the roadmap trade-off and what customer evidence could change their mind. Designers and engineers should retain a voice in that choice because prototype quality and feasibility can change which problem-solution pair deserves investment. [Citation: https://www.sachinrekhi.com/p/the-complete-guide-to-ai-prototyping] #### [Getting into product management from another function]() **Question:** How do you move into product management from another role? ##### [Jiaona Zhang (jz)]() The first decision is which kind of move you're making, because there are two very different paths. Path one is restarting as an IC PM. I did this. I studied econ, went into consulting, and realized I didn't want to sit on the side of the table that advises and hopes the client implements. I left and took my first product role as a mobile gaming PM at Pocket Gems [Citation: https://youtube.com/watch?v=hHoPv2HElDo]. If you're early, a structured APM or RPM program is the best option, because it means the company has committed to investing in you. A new PM takes a while to add value, much longer than a new engineer who is fixing bugs within a couple of weeks [Citation: https://youtube.com/watch?v=JoZHzcEIY68]. Path two is for people with a decade of expertise who don't want to start over. Use what you already know. If you've spent ten years in oil and gas, ask what's disrupting that industry, find the startups doing it, and join one where you can take on more PM responsibilities and fewer operational ones. Your domain knowledge is the reason they hire you, and the title can follow [Citation: https://youtube.com/watch?v=JoZHzcEIY68]. Whichever path you take, the mindset shift matters more than a skills checklist. I see this most with project managers. You're very good at owning the task list, and in product you own the outcome. Practice having a point of view on what the user problem is, whether it's worth solving, and what success looks like [Citation: https://youtube.com/watch?v=PYNzw_CCfeQ]. Also expect very little formal authority. One of the first things I teach is that you're not the CEO, so nearly everything you get done happens through influence [Citation: https://podcasts.apple.com/us/podcast/building-minimum-lovable-products-stories-from-wework/id1627920305?i=1000619030079]. A CS degree isn't required. What matters is understanding your users and the business [Citation: https://youtube.com/watch?v=JoZHzcEIY68]. ##### [Sachin Rekhi]() Pick one of the common paths and build your case around it. Sending out generic applications rarely works. I've seen five recurring paths into a first PM role: the CS grad going into an APM program, the engineer who adds an MBA, the adjacent role, the entrepreneur, and the domain expert [Citation: https://www.sachinrekhi.com/5-paths-to-your-first-product-manager-role]. If you're switching from another role, three of those apply. 1️⃣ Adjacent role. This is the most common internal move. If you're in business ops, marketing, design, or engineering, work closely with your product partner and become the person they rely on. Once the team has seen you deliver and seen your interest in product, ask to move into a PM role at the same company [Citation: https://www.sachinrekhi.com/p/video-product-strategy-getting-buy-in-and-startup-ideas]. You're far more likely to be hired by people who already know your work than by a recruiter reading a résumé with no PM title on it. 2️⃣ Domain expert. Target companies that build for the market you already know. I know a sales ops manager who became a PM at a sales tech startup, an MD who became a PM at a healthcare startup, and someone with a Master's in Education who became a PM at an edtech company. Each of them got hired without functional PM experience [Citation: https://youtube.com/watch?v=plMA3dhDMbA]. Being an expert isn't enough, though. People need to know you're an expert, so write, speak at industry events, and get to know the other leaders in your field. 3️⃣ Entrepreneur. Founders often move into PM roles because they've owned acquisition, engagement, and monetization all at once. The usual weakness is that startups improvise, while employers want proof you can use real product practices. You have to show you wore the product hat with rigor, and you need a clear story about what you learned, especially if the startup failed [Citation: https://www.sachinrekhi.com/5-paths-to-your-first-product-manager-role]. Whichever path you take, the hiring manager is asking one question: does this person bring evidence I can't get from a standard PM candidate? Your answer to that question is what gets you in. ##### [Nikhyl Singhal]() jz's second path has gotten much stronger in the last two years, and it doesn't always require switching companies. Your first sponsor may be your own functional leader instead of a product org. I keep hearing the same story in coaching. One person spent ten years in sales, learned the AI tools, and started rebuilding his sales team's workflows: cutting redundant steps and replacing obsolete processes with software. For the first time in his career he was getting promoted and given more scope. The push came from the sales head, whose own team couldn't do this work, and the engineering leaders weren't the ones noticing him. Two shifts make this possible. PM roles are getting wider, so work that used to be three jobs is now one. AI also handles much of the technical depth that used to keep non-engineers out. [Citation: https://www.youtube.com/watch?v=z9MS2HjU7iY] [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7457523755674755072/] So the concrete path has three steps: 1. Find the function you know better than any PM in the building (sales, ops, support, finance) and build tools that fix its processes. Your first sponsor is usually that function's leader. The product org comes later. 2. Pick one or two world-class skills and own them. Nearly every great PM I've worked with has one or two, and PM is defined so broadly that a single elite skill can get you in. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7078762619062415360/] 3. Choose the company stage on purpose. Early-stage PM means running lots of fast experiments to find what works, and late-stage PM is mostly coordination inside the company. If you're coming from a function, a growth-stage company where that function is straining usually fits best. [Citation: https://www.youtube.com/watch?v=-BcCHEXAVVk] My own path was engineer, then managing dev teams, then founder, then EVP of Products. Each move came from owning more of the problem before I had the title. ##### [Ben Erez]() I agree with Sachin that the adjacent-role move is the best bet, and in this market I'd rank it far above every other path. Applying cold is the lowest-probability option. Hiring is a risk-management game. When I hire an internal candidate, I already know they fit the culture, so the only open question is whether they have the raw ingredients. If you're trying to switch, audit yourself on six traits: ↳ Curiosity: how fast you get smart on a topic ↳ Builder mindset: building things nobody assigned to you ↳ Product taste: picking a frustrating experience and working out the tradeoff the team probably made to cause it ↳ Communication: whether people can follow your logic without effort ↳ Customer understanding, including the segments and GTM motions ↳ Analytical fluency: making sense of a raw CSV and picking the right behaviors to track Michael Chen's story from our Supra Insider episode is the best playbook I've seen. He moved from product marketing to PM inside Asana, then went on to PM at DoorDash. He never asked for the role upfront. He ran it like an experiment. For months he worked closely with product, design and eng, and he took on PM-shaped problems inside his PMM job. When a real PM need showed up, he was already doing the work and was the obvious pick. My own path was messier. Investment banking, then a failed startup at 22, then a Project Manager role at Life360 where I supported the PMs and built the support-to-QA process. That job was my internal on-ramp into product, and jz is right about the shift it required: I had to stop owning the task list and start having opinions about what to build. If your company has no internal path, ship something. Build a small product with AI, launch it and put it on your resume. I built Breathe, a deep-breathing reminder app, as a side project while at Life360, and it got 65k downloads. Shipping your own thing is proof of the builder mindset that no interview answer can match. One caveat: a lateral move can mean a pay cut or a reset in level. If you don't have much financial runway, the slower internal route is the responsible choice, even if it takes a year. ##### [Jiaona Zhang (jz)]() Sachin's question about evidence a standard candidate can't offer is right, and the most direct way to answer it is to walk into the interview with a diagnosis of their problem. When I moved into WeWork's developer platform, I had no infrastructure background. My read was that the team wasn't talking to its customers. For a fast-growing company, infrastructure work comes down to understanding where the organization is going and deciding where to put scarce people. Kubernetes versus CI/CD came second. So I went into the hiring conversation and said, "this is what I think your problem actually is." If they hadn't agreed with me, I wouldn't have gotten the role [Citation: https://youtube.com/watch?v=GRZ4IoN6Cnk]. Career switchers can use the same move: pitch your point of view on their outcome and don't apologize for the gaps on your résumé. Before you pitch anyone, run the same discovery on yourself. I teach people to understand themselves the way they'd understand a user. Figure out what gives you energy and what a fulfilling day looks like before you go after the title. When people chase PM because it's the hot role and then find it's a bad fit, they've done a lot of work just to learn that [Citation: https://youtube.com/watch?v=JoZHzcEIY68]. A lot of PMs burn out ten years in because they followed what they saw other people doing [Citation: https://www.youtube.com/watch?v=eCBubJftdtU]. For engineers in particular, I'd usually pick a fast-growing company over business school, unless the school's network is the specific thing you need. Getting a PM title somewhere is the first goal, and a fast-growing company can give you a better network than the school would [Citation: https://youtube.com/watch?v=GRZ4IoN6Cnk]. ##### Question > Jiaona described two paths into PM. Early-career people restart as an IC PM, ideally through an APM program. People with ten years in another industry join a startup disrupting that industry and let the PM title follow their domain knowledge. When you hired PMs at TripAdvisor and Tinder, did people with deep domain knowledge but no PM experience actually get hired into product roles? What did they have to show to convince you? ##### [Ravi Mehta]() When I scaled the TripAdvisor team to over 70 people, I hired more than 40 PMs, and every candidate was scored against one standard set of competencies. That's how I'd answer for domain experts too. Deep domain knowledge is one competency. It can earn you the interview, but it can't stand in for product strategy, prioritization, or measuring success. The domain experts who convince a hiring manager can show they've done those other jobs, even without the PM title. I've also been on the other side of jz's second path, and it taught me that domain is the easier gap to close. When Facebook interviewed me for a Director role, I had spent years at TripAdvisor and knew travel cold, but I had almost no background in social. They asked which companies I'd buy with an unlimited M&A budget. I drew a 2x2 on the whiteboard with device on one axis and media format on the other. Then I plotted Instagram and Snapchat on it, and we spent 30 minutes talking about the empty boxes as acquisition targets. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:6932381934459191296/] I got the job without the domain, because I showed product judgment in the room. For a switcher, that suggests a concrete plan: 1. Score yourself on all 12 product competencies. Count domain as one strength, then name the two or three gaps an interviewer will probe. For most switchers, those gaps are strategy and metrics. 2. Close each gap enough to give AI good instructions, spot bad decisions, and know when you need someone whose judgment is better than yours. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7508260081600454656/] 3. In the interview, use your domain knowledge as the raw material for a strategic point of view, the way jz did at WeWork. If you only recite what you know about the industry, an interviewer hiring against competencies has nothing to score you on. ##### Question > Ben's advice for switchers with no internal path is to build a small product with AI, launch it, and put it on the résumé. He points to Breathe, which got 65k downloads. Sachin, you've criticized PMs for putting out low-quality AI prototypes. When an external career switcher shows a hiring manager an AI-built side project, what separates one that earns an interview from one that gets discounted? Say what the candidate should show: real users, metrics, the product decisions they made, or something else. ##### [Sachin Rekhi]() A hiring manager can spot slop in about ten seconds. If you type "create a CRM," you get generic styling, vanilla features, and the most basic scenarios. The result looks impressive to the person who built it, and nobody would ever ship it. The prototypes I see from PMs usually fail the same way: they solve the customer problem generically, they have no branding or real differentiation, and they lack depth [Citation: https://www.sachinrekhi.com/p/the-ai-prototyping-mastery-ladder]. If a hiring manager sees that kind of side project, it tells them you can use a tool. It says nothing about whether you can do the PM job. A side project that earns an interview shows three things: 1️⃣ A problem chosen from your own domain. Taste comes from pairing domain insight with AI, and that pairing produces work a generic prompt can't [Citation: https://www.sachinrekhi.com/p/87-wtf-is-product-taste-and-unpacking]. An ops person who builds a tool for a workflow they suffered through for five years has the domain-expert path and the builder path in one artifact. 2️⃣ The options you rejected. Generate four design variants, pick one, and be able to say why you threw out the other three [Citation: https://www.sachinrekhi.com/p/the-ai-prototyping-mastery-ladder]. That walkthrough is the interview. It shows the prioritization and judgment Ravi says interviewers score. 3️⃣ Instrumentation and what it taught you. Make it functional: add PostHog analytics, watch session recordings, and run a short survey. Then show one decision you changed because of what users actually did. Ben's 65k downloads are great, but a switcher with 200 users and a clear story like "retention dropped at step three, so I cut it" shows more product thinking than a big number with no explanation. This matters more now because the bar has moved into the interview itself. Meta expects PM candidates to prototype a feature live in tools like Figma Make, Lovable, or Claude Code [Citation: https://www.sachinrekhi.com/p/the-ai-prototyping-mastery-ladder]. A side project you've iterated on with real users is how you practice for that loop before you're in it. #### [The tech careers product leaders would bet on as AI does more work]() **Question:** Which tech careers will hold up as AI spreads? ##### [Nikhyl Singhal]() I would bet on people who can find a real customer problem, build a solution, and own whether it works. In product, that means a hands-on PM or product leader who can talk to customers, work directly with engineers and AI tools, and make hard choices about what to ship. AI can take on more of the drafting and coordination, while the person still has to define the problem and judge the result. The transition is already changing the number of roles. I’ve seen younger AI companies bring PMs in later, with three PMs doing work that seven might have done before. Those companies seek people who can scale a product and stay close to the work; established companies need leaders who can bring AI into their products and teams. Both paths reward current skills and customer judgment. If you’re choosing a role now, ask what you’ll personally build and learn in the next two years, because a title alone tells you little about your growth rate. [Citation: https://www.youtube.com/watch?v=Eu10wQt9uJs] ##### [Yue Zhao]() Experienced ICs who direct and review AI agents may take on scope that used to require a team. I expect smaller teams to thin some middle-management layers, so moving into management purely for career security looks risky. That's a forecast rather than a guarantee. [Citation: https://news.theuncommonexecutive.com/p/to-ic-or-not-to-ic-in-the-age-of] In coaching, I see the durable skills as making a call with incomplete information, building trust, and giving a team clarity when its tools and priorities keep changing. A researcher I coached at a major AI company was building tools for next-generation models and still felt behind because each week brought another eval or use case. Chasing every release is an exhausting career plan. [Citation: https://news.theuncommonexecutive.com/p/how-to-not-feel-constantly-behind] If you're choosing a path now, build an AI agent for a repetitive part of your work, then show how the time saved lets you solve a company-level problem. That gives an employer evidence of both technical fluency and judgment. [Citation: https://news.theuncommonexecutive.com/p/to-ic-or-not-to-ic-in-the-age-of] ##### [Nikhyl Singhal]() A career in applied AI can hold up even if you never work at a model lab. I’d look closely at teams using AI to solve a costly, specific problem in an existing business. That work needs someone who understands the customer, can build and test the product, and knows how the business will earn money from it. A research lab and a company applying models to customer workflows need different strengths, so choose the setting where your experience gives you a real advantage. ##### [Sachin Rekhi]() A concrete skill to build is customer intuition. At Notejoy, I use AI to synthesize interviews and survey responses, then read the customer quotes and follow up on the raw interviews before deciding what to build. If a PM delegates the entire loop, they lose the practice of recognizing which pain points matter. [Citation: https://www.sachinrekhi.com/p/ai-powered-customer-discovery] I see durable work in product strategy and interaction design too. AI can research a market and produce prototypes, while a skilled product team still has to set a direction and assess whether the experience solves the customer's problem. For a PM choosing where to invest, I'd practice those decisions while using AI to cut the time spent on research production and coordination. [Citation: https://www.sachinrekhi.com/p/the-art-of-product-management-in] ##### [Ravi Mehta]() I’d look for roles that own the economics of what AI helps build. An AI feature can gain usage and lose money if model costs outweigh its value. PMs who can choose where to apply a team’s effort, check the unit economics, and take responsibility for the outcome have valuable work to do even as prototypes get cheap. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7505268105149829121/] Designers and engineers retain distinct skills, though AI now lets each work further across role boundaries. The strongest teams will shift leadership to whoever can resolve the current problem. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7501084403897380865/] I’d make a similar bet on customer-facing roles that earn trust and apply judgment. I’ve pointed to travel advisors as an example: AI can clear their busywork so they can spend more time on the expertise customers come to them for. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7393713633844748289/] ##### [Hadar Dor]() Trust and safety, regulatory product, and AI evaluation are careers I’d take seriously. In AI shopping, someone has to decide what a useful recommendation means, measure the purchase experience, and investigate failures in content understanding and personalization. At Meta, I worked on defining harmful behavior, setting policy with partners, and building systems that reduced its prevalence by 50%. At Lyft, we built a compliance platform to check legal eligibility for rides. AI can help detect and process cases, while people still need to define the rules, handle trade-offs, and own the results. [Citation: https://www.hadardor.com/background] The career skill I’d practice is learning a new domain fast enough to identify the failure modes: talk to the people doing the work, inspect support cases, and agree on a measure of success with the team. That is how I approach a new product area before choosing the next bet. [Citation: https://hadardor.substack.com/p/hadars-newsletter-4-08232020] ##### [Nikhyl Singhal]() Sachin’s point about keeping contact with raw interviews matters especially for early-career PMs. If young AI companies hire PMs later, the old path of learning through routine PM tasks gets narrower. I’d build a small product with users, conduct the interviews myself, and keep a record of decisions that changed after feedback. That gives a hiring team evidence of customer judgment and shipping experience, even if the candidate has never held a PM title. [Citation: https://www.youtube.com/watch?v=Eu10wQt9uJs] ##### [Ravi Mehta]() Another career bet is product leadership that can turn a flood of prototypes into a coherent customer experience. AI gives sales, design, engineering, and product the ability to arrive with working versions of an idea. Someone still has to choose among buttons, voice, language, and agents based on how customers actually complete the task, then get the team to commit to one direction. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7506696952269680641/] For an experienced PM weighing an AI-native startup against an established company, I’d choose the role where you can practice those decisions with real customers. The company label tells you less than your scope to shape the experience and measure whether it works. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7506696952269680641/] ##### [Sachin Rekhi]() I’d add AI prototyping as a concrete career skill. Meta has begun asking PM candidates to prototype a feature live with tools such as Figma Make, Lovable, or Claude Code. The bar is higher than producing a quick demo: many early attempts solve the problem generically and lack depth or a distinct product direction. [Citation: https://www.sachinrekhi.com/p/the-ai-prototyping-mastery-ladder] For a PM, I’d take one customer pain point, build two functional versions with a tool like Bolt or Claude Code, put them in front of customers, and use what they do to choose which version deserves engineering time. That shows an employer you can use AI to test a product decision, rather than simply produce more artifacts. [Citation: https://www.sachinrekhi.com/p/the-ai-prototyping-mastery-ladder] ##### Question > Ravi, Yue expects smaller AI teams to thin middle management, while you expect leadership to shift to whoever can resolve the current problem. When would you advise someone to pursue product management leadership rather than deepen their IC skills? ##### [Ravi Mehta]() I’d pursue product leadership when you can improve the quality of decisions across several teams, and you want to be accountable for their outcomes. AI makes it easier for a strong IC to build and test an idea, so a management title alone offers little protection. The leadership job is to set a clear product direction, decide where scarce team effort goes, and help people with different skills work through competing prototypes and customer evidence. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7506696952269680641/] If you’re still building your own customer judgment or learning to use AI to test ideas, deepen those IC skills first. I’d ask a candidate for leadership to show a concrete case where they developed another PM’s skills, made a better decision possible across a team, and owned the resulting business outcome. That is the kind of work I focused on when I built Reforge’s product leadership program and coached PM teams. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7166114386686795777/] #### [Getting good with product numbers: definitions, daily reps and a prediction log]() **Question:** What's the best way to build product analytics skills? ##### [Ben Erez]() Most PMs try to get better at analytics by learning tools first: SQL, Amplitude, dashboards. Those matter. In my experience, though, the gap I see most is earlier. People can't say in plain words what they would count. When I coach analytical thinking, the most common mistake goes like this. Someone says "I'd want more listings" on a marketplace. That points the right way, but it isn't a metric yet. A real one sounds like: "the number of unique new listings published and approved through review that week, which weren't live the week before." That definition leaves no room to misread it. You can disagree with it, but you know exactly what it means. [Citation: https://www.youtube.com/watch?v=AtDhjeI7xuQ] So I'd build the skill in roughly this order: 1️⃣ Product rationale. What problem does the product solve, and for whom? You can't choose good metrics without knowing how the product creates value. 2️⃣ Metrics literacy. Turn business goals into precise counts, and practice tightening vague ones until nobody could misread them. 3️⃣ Goals and tradeoffs. Choose one metric for a team, then defend it against a competing option, like Reels vs. Stories getting the top spot on Instagram. [Citation: https://www.youtube.com/watch?v=aIBbqllQyOs] For reps, my own story is pretty scrappy. Before my Facebook interviews I had no coach and no course. I'd pause recorded mock interviews right after the question, work the problem on paper until I got stuck, then hit play and compare my answer to theirs. I did that about 10 times. [Citation: https://www.youtube.com/watch?v=CiRp9o7FuFU] The downside is that a video can't explain why someone picked a particular North Star, so you're left guessing at their reasoning. That's why practicing with someone who pushes back on your metric definitions speeds things up. If you're in a PM role now, the best practice field is your own product. Write a precise definition for each metric your team reports, then check it against how the data team actually calculates it. You'll learn a lot from the gaps. I wrote all of this up in more depth for Lenny's Newsletter: [Citation: https://www.lennysnewsletter.com/p/the-definitive-guide-to-mastering-f81] ##### [Sachin Rekhi]() You build product analytics skills through daily repetition on your own product's numbers. A course or a few blog posts won't get you there. Analytical rigor is a deliberate-practice skill, and it grows from habits you run every week. [Citation: https://www.sachinrekhi.com/p/james-clear-atomic-habits-for-product-managers] I learned this at LinkedIn. I owned the P&L for Sales Navigator, and every Wednesday I sat in a metrics meeting with Jeff Weiner and our CFO. If my weekly bookings projection was off by more than 10%, the CFO grilled me. Jeff would walk in and ask why liquidity in the jobs marketplace had been compressing week over week since March. I had the exact same dashboard open and hadn't noticed it. [Citation: https://www.youtube.com/watch?v=tiCEnVs--dk] I fixed that by looking at the same dashboards every single day, with a business analyst team helping me understand the trends. After enough months of that, you know your normal week-over-week and year-over-year swings well enough that a number feels wrong before you've run any analysis. The routine I recommend: 1️⃣ Every day, review your core dashboards and write down one hypothesis for each trend you see. 2️⃣ Every week, run an ad-hoc query that digs into a specific user behavior. 3️⃣ One week after every launch, write a metrics recap. 4️⃣ Every month, decide how to improve or add to your existing dashboards. These habits won't fit into a PM calendar unless you make room for them. Track every activity on your calendar for one week, score each one, and move time away from low-value meetings. If your org has a weekly metrics review like LinkedIn's or SurveyMonkey's ACER meeting (acquisition, conversion, engagement, retention), get into it. Hearing someone explain every spike and drop week after week builds intuition faster than anything you can do alone. [Citation: https://www.sachinrekhi.com/p/a-leaders-guide-to-metrics-reviews] AI now does a lot of the query and synthesis work. I've built reusable skills like /conduct-nps-analysis for this, but you still need judgment to tell when the output is wrong, and that judgment comes from the daily habit above. [Citation: https://www.sachinrekhi.com/p/how-to-build-a-compounding-os] ##### [Hadar Dor]() Sachin's daily dashboard habit teaches you to read a metric. The other half is owning one metric you're on the hook to move, because trying to change a number forces you to learn why it moves. A few things that have worked for me: 1. Write down your current understanding and ask the experts to correct it. This is Ben's metric-definition exercise, widened to the whole product. Every time I join a new team I start a "ramp up doc" with my take on the product, the users, and how we measure success. Then I share it with everyone I've met, including my data science counterparts, and ask them to comment liberally. Seeing exactly where your mental model of the funnel or metric is wrong is the fastest feedback loop I know of [Citation: https://hadardor.substack.com/p/hadars-newsletter-4-08232020] 2. Pull the data yourself. Learn enough SQL to answer your own follow-up questions without waiting in the DS queue. It also makes your conversations with data scientists much better, because you've seen how messy the tables actually are. 3. Run experiments, even in places that don't have an experimentation habit yet. When I volunteered at Kiva running their lender products, getting an experimentation culture going there taught me a ton about designing tests and reading results honestly. 4. Add structured learning on top of the reps. I agree with Sachin that a course alone won't do it, but I took graduate data science courses at Stanford and they filled in stats foundations that on-the-job work never gave me. Overall it comes down to a growth mindset: keep asking people who know more than you to poke holes in your analysis :) ##### [Ravi Mehta]() Ben's definitions and Sachin's daily dashboard habit build fluency. The piece I'd add is a feedback loop on your judgment, because reading numbers well and predicting them well are different skills. At Reforge and in my own teams, I treated data fluency as one of the product competencies you assess and plan for, the same way you would strategy or stakeholder management. So the first step is diagnostic. Figure out whether your gap is mechanics (pulling data, SQL, experiment setup) or judgment (choosing the right metric, reading a result honestly). The learning plan is very different for each. For judgment, the best practice I've seen is writing predictions down before you ship, then grading yourself. A product leader I reposted recently built a free tool called The Product Judgment Test. Before a launch you record what you expect to happen, by when, and with what probability, and afterward you log the actual outcome. It scores your calibration with a weighted Brier score, so big bets count more than small tweaks. Hadar's ramp-up doc corrects your mental model once, when you join. A prediction log keeps correcting it, and over a few quarters you learn which kinds of bets you consistently misread. Next, get external context. Your retention number means little until you know what good looks like. For consumer subscription apps, Phil Carter's Elemental Growth benchmark calculator lets you compare your metrics by category, market, and platform. At Tinder, the ARPU gains came from multiple tiers, consumables, contextual upsells, and pricing by market, and each of those depended on knowing which number to move. Finally, pair every quantitative read with a customer conversation. A single conversation can explain a pattern that thousands of rows only show you. If you solve the customer's need, the metrics follow. ##### [Nikhyl Singhal]() Where you practice matters as much as how. Analytics skills compound fastest on a growth problem at a company that's past product-market fit, so choose your team and company stage with that in mind. When I wrote up the six superpowers I see in elite PMs, growth was the one built on analytics. Growth PMs turn usage into growth, so they live in the dashboards and the funnel. They partner closely with data science and marketing on acquisition, retention, usage and churn. Cycle times are short and accountability is clear, so you get far more reps per year than a PM shipping a big feature twice a year. [Citation: https://theskip.substack.com/p/6-superpowers-to-seek-out-as-a-product] Stage matters here. Pre-product-fit startups usually don't have this muscle at all, because there isn't enough usage to analyze. Mid- and late-stage companies often run a separate growth org. Organizations have superpowers too, and Meta's is growth. If you can spend 12 to 18 months on a team like that, you'll learn more than you would from a year of self-study on a product with thin data. If you can't move teams, hold every launch to the same standard a growth team would. Judge it by what it did to the core business metrics, and don't count feature completion or neutral sentiment as success. You don't need analytics as your superpower. Being weak in it will still hold you back, because almost every senior product review comes down to what happened to the numbers and why. ##### [Ben Erez]() Hadar's ramp-up doc fits well with Sachin's daily habit, because a dashboard teaches you what normal movement looks like without telling you what the number counts. I've seen PMs who could tell you a metric dropped 8% week over week but couldn't say whether it counted unique users or events, or whether it filtered out test accounts. So when you write Sachin's daily hypothesis, write the metric's definition next to it the first time. Most of the "why did this spike" mysteries end up being definition questions. The AI point Sachin raised makes this matter more. Amplitude launched agents and MCP this year and reported 76% accuracy on complex production-grade queries. That's useful, but it also means that about one in four answers to a hard question can come back wrong while looking just as confident as the right ones. If you hand an agent "show me listings growth," it picks a definition for you. If you hand it "unique new listings that passed review and went live for the first time this week," you can check whether the output makes sense. There's a caveat for people who aren't PMs yet and don't have a dashboard to live in. Practice on public products instead. Pick one, like DoorDash, and write its North Star, two or three supporting metrics, and one guardrail. Then give each metric a definition precise enough that a data analyst could build it with no follow-up questions. Done regularly, that gives you the same reps without needing access to anyone's data. ##### [Hadar Dor]() Ravi's prediction log fixes a gap in my ramp-up doc approach. The doc gets corrected once, in your first few weeks, and then it goes stale. Putting predictions on a schedule keeps the correction going :) One more habit from the same ramp-up process: in your first few weeks, agree with your manager and org leaders on how your impact will be measured [Citation: https://hadardor.substack.com/p/hadars-newsletter-4-08232020]. That conversation makes you defend a metric choice to the people who will judge you on it, which is Ben's goals-and-tradeoffs step with real stakes. I'd also make Ravi's customer pairing concrete. In the same ramp-up, I sit in on user research sessions and answer support tickets. Reading tickets right after looking at a funnel dip is often the quickest way to find out whether the dip is a real behavior change or a broken flow. I agree with Nikhyl on picking a growth team. My most data-heavy stretch was Shopify's New Merchant Growth team, working on onboarding funnel optimization and subscription pricing and packaging while the merchant base grew from 2M to 3M. Tight loops on onboarding and retention at Lyft and Postmates gave me similar reps [Citation: https://www.hadardor.com/background]. ##### [Ravi Mehta]() Nikhyl's right that a growth team gives you the most reps per year. The risk is what those reps train. Short cycles and a single metric teach you to find whatever moves the number, and binge-style engagement is the classic case: it looks great on the dashboard until users burn out and churn. So if you take a growth seat to build analytics skills, add one habit: for every winning experiment, write down which customer need it served and which counter-metric could reveal the harm. At Tinder, the ARPU work across tiers, consumables, and upsells held up because each one gave a specific user more of something they already wanted. Pricing tests that only extracted more money would have shown up later in retention. PMs who learn analytics this way learn to explain why a number moved for a person, and that is the skill senior product reviews actually test. ##### Question > Hadar recommends learning enough SQL to answer your own follow-up questions without waiting on data science. You said AI now handles much of the query and synthesis work. For a PM building analytics skills today, would you still have them learn SQL first, or start by querying through AI tools? What specific failure have you seen when a PM relied on AI-generated queries without knowing the underlying tables? ##### [Sachin Rekhi]() I'd start PMs on AI querying today. I haven't written a SQL query in over a year, and I don't think writing SQL from scratch is the best use of a new PM's learning time anymore. Reading SQL and knowing the schema still matter a lot, and you have to learn both before you trust anything the AI returns. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7437875300946038784/] The failure I've seen is the AI picking the plausible-looking column when a cleaner one exists. In our database, the signup_source table has a source column full of junk and a canonical_source column that's actually clean. A natural-language question about where signups come from will easily get pointed at source, and the result looks like a perfectly normal chart. Nobody catches it unless they know about the junk column. I fixed it by adding one instruction to the project, "use canonical_source, not source," and it never made that mistake again. A PM who had never looked at the tables wouldn't have known to add that instruction. So for a PM building the skill now, I'd do it in this order: 1. Sit with your data team and collect real recent analyses, with each question written in plain English next to the SQL that answered it. Load them into a Claude Project or a Claude Code skill. Claude copies patterns from examples more reliably than it follows written rules. 2. Write down every misnamed, deprecated, or confusing column you learn about and add each one to the instructions. 3. Audit the first few dozen queries line by line against what you expect. Reading AI-written SQL is how you learn SQL now, and it's also how you find the schema problems from step 2. 4. Share the project so the next PM on the team gets accurate queries without redoing your work. My "answer data curiosity" skill puts the SQL in every report so I can check it, and that's the main reason I trust it. [Citation: https://www.sachinrekhi.com/p/claude-code-for-product-managers] This connects to Hadar's point: the time AI saves on writing queries should go toward understanding how messy the tables are. #### [Preparing for a performance review starts months before the meeting]() **Question:** How should you prepare for a performance review? ##### [Nikhyl Singhal]() Most of your preparation should happen in the months before the review. Formal review processes at big companies mostly decide promotion and leveling, and people rarely get useful feedback from them. If the review is the first time you hear how you're doing, you've lost the chance to change the outcome. So I'd treat it as a year-round habit: 1. Collect feedback every week. Pick 2-3 recent pieces of work and ask your key stakeholders specific questions about each one ("Was the launch doc clear enough for you to make the call?"). "Any feedback?" gets you nothing useful. By review time you'll know what the room thinks, and you'll have had months to fix it. [Citation: https://theskip.substack.com/p/tips-to-receive-10x-more-feedback] 2. Set your own bar. Don't assume your manager's expectations are good enough. I see this often with a new manager who has a higher bar than the last one, and the person who coasted gets caught out. Know what good looks like for your level and measure yourself against that. [Citation: https://www.youtube.com/watch?v=38FFgtSXMew] 3. Make it easy for your manager to advocate for you. Your manager has to defend your rating in calibration, so give them the evidence: impact, metrics, and the narrative. Present your work the way a manager would, covering what's moving, what's stuck, and what you'd prioritize next. Wait until after a positive review to ask for promotion or more scope. Asking before you've delivered makes you look out of touch. [Citation: https://theskip.substack.com/p/how-to-navigate-org-drama] 4. Keep your expectations in line with the company's limits. Top performers who give 110% often walk into reviews expecting rewards that pay bands and org structure can't deliver, and they leave feeling betrayed. Before the conversation, find out what's realistically possible this cycle. 5. Don't get defensive about critical feedback. If you over-correct or argue about your character, leadership sees you as smaller. When you disagree, explain the context you have that they might not, and treat it as a difference in vantage point. ##### [Ravi Mehta]() Start preparing at the beginning of the review cycle, because the review itself is the worst time to find out you and your manager were measuring different things. I've argued that traditional performance reviews don't work well for PMs. A once-or-twice-a-year verdict is too slow, so you have to build your own feedback loop into the months before it. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7164623856979181568/] Here's how I'd do it: 1. Get explicit on the competencies you're judged against. I use 12 product competencies, covering areas like product strategy, execution, and stakeholder management. Plot yourself on each one, then ask your manager to plot you too. The gaps between the two maps tell you what the review will actually be about. 2. Tie your work to goals with a clear "why." Most teams set OKRs that capture the what and the how but skip the why, and that's how you end up in "performance theater." If you can explain why your goals mattered to the business and what moved, your self-review writes itself. 3. Collect evidence as you go. Ship notes, metrics, and peer feedback captured monthly beat anything you reconstruct the week before the deadline. 4. Lead with your spikes. Managers reward people who are exceptional at a few things. Show where you're unusually strong, then name one or two growth areas with a concrete learning plan attached. 5. Treat the review as a negotiation where you and your manager are on the same side. Bring your own view of your next level and ask what evidence would get you there. If you're the manager, the same applies in reverse. Identifying skill gaps and building learning plans is your job, and you can't leave it to the review form. ##### [Yue Zhao]() I agree with Nikhyl that the work happens months ahead. Specifically, prepare for the calibration room, where your manager is only one voice. Here is a conversation I've seen many times. A VP puts Jane up for promotion: "She's been performing at the VP level for over a year, launched a multi-team, multi-quarter project." Then a peer VP says Jane took the idea from his director and clashed with him. Another SVP says his own director has delivered double-digit revenue gains and should go first. A third asks whether Jane's impact numbers were calculated over the right time horizon. Her promotion gets blocked by objections she had never heard, after months of her manager telling her it was "a sure thing." [Citation: https://news.yuezhao.coach/p/why-performance-review-dont-always] So treat it like any product review. You wouldn't walk in and hope for the best. ✅ Find your detractors early. Some are vocal, some stay quiet until the worst moment, and some are influential people who simply aren't bought in yet. Ask for feedback widely and often, and address concerns months before calibration. ✅ Know how your overall team is doing. A strong individual story inside an underperforming org still loses. ✅ Plan for AI in the process. This past cycle, the leaders I coach at OpenAI, Google, Amazon, and Instacart all used AI to draft feedback or stress-test borderline ratings. AI over-weights whatever is logged, so keep a log of your work (voice notes, meeting notes, calendar exports). Find out which proxy metrics your company tracks. Then ask AI to write your review from your manager's and your skip's perspective, and use what it flags as weak spots to decide which stories to tell key stakeholders in person. [Citation: https://news.theuncommonexecutive.com/p/how-to-succeed-in-performance-reviews] ✅ Get visible before year-end. Recency bias is real, and annual planning is when executives decide who to retain, who to invest in, and who gets the new roles. [Citation: https://news.theuncommonexecutive.com/p/how-to-be-memorable-to-senior-executives] Start the log now. A log kept for 12 months does far more for you than one started two weeks before reviews. ##### [Sachin Rekhi]() Ravi's competency map tells you how good you are at the craft. Leveling decisions run on a different axis, so also map your year against the dimensions your company actually promotes on. Across the PM career ladders I've studied at 8 large tech firms, those dimensions are almost always independence, product scope, and leadership. [Citation: https://www.sachinrekhi.com/p/product-management-career-ladders-at-8-top-technology-firms] So before the review, write one short self-assessment with a section for each dimension: 1️⃣ Independence: which initiatives did you run without required check-ins, and which stages of the product lifecycle did you cover (research, roadmap, launch, post-launch iteration)? If you're missing a stage, say so and ask for a project that covers it. 2️⃣ Scope: did your scope grow over the year, from a feature to a feature area, or from a feature area to a whole product? Show the change in a sentence or two. 3️⃣ Leadership: who did you align, unblock, or coach? Bring the artifacts with you. PMs produce concrete deliverables like a strategy, a roadmap, team OKRs, specs, and metrics dashboards, and those documents are much better evidence than a list of shipped features. Treat OKR results as one input. When I run OKRs, I tell teams that hitting 70% of ambitious key results is a good quarter and that OKR scores don't map directly to performance ratings, because otherwise people sandbag their goals. [Citation: https://www.sachinrekhi.com/p/a-leaders-guide-to-implementing-okrs] If you missed a stretch goal, explain what you learned and what changed in the next cycle. Expect vague feedback and plan for it. "You need to be more strategic" is the most common example, and it rarely comes with specifics. Ask your manager which deliverable would show the gap closed, for example a product strategy that covers target audience, problem, value proposition, and differentiation, and agree on it as a goal for the next cycle. ##### [Nikhyl Singhal]() I agree with Ravi's competency mapping. The one I'd add is for people coming up on their first review in a new, senior role, because that's where I see the most damage. Senior outside hires often take the hot project, feel they need answers on day one, and six months later fail to meet expectations because they never had the context. That first review sets how the company sees you for years. So prepare for it when you pick the role and set scope with your manager. Choose a starter role where you can clearly exceed expectations, even if it's less glamorous, and plan on 12-18 months to learn the vocabulary, build relationships, and get your thinking in line with how the company works. You go for the prime role after that. This also changes how I'd read Ravi's point 5 about negotiation. Bringing your view of your next level is right once you have a strong review behind you. In a first cycle, or during a reorg, keep the conversation on what you delivered and what you learned. A staff engineer on our podcast listed promotion, visibility, and more scope as goals on day one with a new manager. That made the first review riskier, because anything below stellar then looks like a miss against goals he set himself. [Citation: https://theskip.substack.com/p/how-to-navigate-org-drama] ##### [Jiaona Zhang (jz)]() The rest of the group has covered the months before the review, so I'll focus on the self-review document and what you bring into the room. 1. Keep the self-review to two pages. That's my rule of thumb for any doc. Put the core story up front: the problem, what you did, and what changed for the business. The trade-offs and process detail can go later, or get cut. Yue's calibration story shows why this matters. Your manager will be lifting sentences from this document to defend you, so make them easy to lift. Sachin's three sections fit inside two pages. [Citation: https://www.youtube.com/watch?v=eCBubJftdtU] 2. Walk in knowing what you're optimizing for. I tell people to treat their career like a product, with a North Star and a view of the role after the next one. Ravi's competency map tells you where you stand. Your North Star tells you which gaps are worth closing this year and which ones you can ignore. If you don't have one, you end up reacting to a rating. This fits with Nikhyl's caution about a first cycle. Knowing your North Star doesn't mean asking for the promotion in the room. It means you know which feedback to act on and which problems to raise your hand for next. When I'm choosing what to optimize for, company growth comes first, because that's where the scope and learning come from. [Citation: https://youtube.com/watch?v=GRZ4IoN6Cnk] 3. One practical tactic for Nikhyl's year-round habit comes from Clarissa Shen: make every fourth 1:1 a career growth conversation, with its own meeting title kept separate from your weekly sync. [Citation: https://review.firstround.com/the-30-best-pieces-of-advice-for-entrepreneurs-in-2023/] ##### [Ravi Mehta]() Yue's Jane example is a trust problem more than a performance problem. Her results were strong, but a peer VP believed she took his director's idea, and that one objection outweighed a year of impact. Nataliya Becker has a framework I've shared that fits this well: trust comes from credibility, reliability, emotional security, and team-centricity, and it drops fast when people see you as self-centered. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7093040619996024832/] That gives you a concrete way to find detractors before calibration. For each senior stakeholder who might be in the room, ask yourself four questions: 1. Do they believe my judgment is good? (credibility) 2. Have I delivered what I told them I would? (reliability) 3. Do they feel safe disagreeing with me? (emotional security) 4. Do they see me giving credit to their team, or taking it? (team-centricity) Jane would likely have scored fine on the first two with that peer VP and failed the fourth. Credit disputes are common for PMs because the role sits between teams and ships through other people's work. The fix is simple and slow: name the people and teams behind each win in your launch notes and updates all year, so the record already exists when someone in calibration says you took their idea. This also changes how you read the competency map I described earlier. Stakeholder management usually gets scored on whether you got alignment. In calibration, it gets scored on whether the people you aligned with still speak up for you afterward. I agree with Nikhyl's correction on my negotiation point. In a first cycle the trust audit matters more than the level conversation, because nobody in the room has a track record of yours to defend yet. ##### [Sachin Rekhi]() Yue's log is the right input, and the step people skip is turning it into a draft with a fixed template. Asking AI to "write my self-review" gets you slop: a generic list of everything you touched. The workflow I'd use in Claude Code: 1. Assemble the context first. Keep your log as local markdown files: weekly notes, launch docs, metrics snapshots, and peer feedback. I start most of my Claude Code workflows by gathering context like this, because the output can only be as good as what the model can read. 2. Write a prescriptive template. For my customer interview summaries, I specify exactly which sections I want (who we talked to, key takeaways, pain points, current workflow), and that template is what makes the output usable. [Citation: https://www.sachinrekhi.com/p/claude-code-for-product-managers] For a review, the template's sections are your company's ladder dimensions, with a required piece of evidence under each claim and jz's two-page limit as a hard constraint. 3. Ask it to find the gaps. Have it list every claim in the draft that has no artifact or metric behind it. Those are the stories you either back up before calibration or drop. On Nikhyl's point about first reviews in a new role: the same draft is useful at month three. A thin "scope" section that early tells you to agree on scope with your manager before the formal cycle starts. ##### [Nikhyl Singhal]() One more thing to prepare for is the review going badly. Most people prepare only for the good version and then react emotionally in the room. A common case on our coaching episodes: a new manager comes in with a higher bar, and someone who did fine under the old manager gets a weak rating. In that situation you have two real options, and you should decide which one fits before the meeting. First, if the skip-level trusts the new leadership and the bar was simply low before, accept the reset and push hard right away. I've seen people turn it around that way. Second, if you can tell the new manager has already decided about you, spend real time looking elsewhere. You can even go to the company and say you've found something and ask what package they'd offer to make the transition quick and clean. Companies often prefer that to a long performance process. [Citation: https://www.youtube.com/watch?v=38FFgtSXMew] The review is also a good time to check whether you should stay at all. My default this year: stay if the role keeps you current, and leave if it's letting you fall behind, because the way we build product changes every six months. A great rating on a team that isn't learning anything new is worth less than it looks. If your company is in a reorg or a layoff cycle right now, the best preparation for the next 30 days is to put your head down and deliver. Every hour spent reading org signals is an hour taken away from the work your review will actually be based on. #### [What changes at each level, and how to build a promotion case]() **Question:** What separates one career level from the next in tech, and how do you get promoted? ##### [Yue Zhao]() At Instagram, I was exceeding expectations and leading the work of two PMs, yet I couldn't move into management. The PM organization kept teams lean, with senior people in each role. I eventually moved to another part of Meta with larger teams and more management layers. That experience changed how I think about the jump into leadership: strong execution establishes credibility, while the next level requires a business need for someone to own broader scope. [Citation: https://news.theuncommonexecutive.com/p/why-being-wickedly-smart-and-capable] For a senior manager or L6 seeking the next level, I would ask three questions before writing a promotion case: ✅ Is my skip-level's team growing, or is the company investing in a new initiative that needs a leader? ✅ Has anyone made this promotion in the last 6 to 12 months? What business case won approval? ✅ Do senior leaders promote internally into these roles, and which of them have seen me lead work across teams? If the role has room to grow, take ownership of a cross-team problem tied to that investment and document the decisions and outcomes with your manager. If the team stays lean and senior roles are filled externally, look at adjacent teams with room to grow. More projects in the same role will leave the underlying business case unchanged. [Citation: https://news.theuncommonexecutive.com/p/why-being-wickedly-smart-and-capable] ##### [Sachin Rekhi]() For PMs, I look at three dimensions: independence, product scope, and leadership. An associate PM may need regular check-ins to deliver a feature improvement. A senior PM can take an initiative through customer research, planning, launch, and iteration independently. As scope grows, ownership can expand to a feature area, an entire product, or several products. Leadership expands from the immediate product team to other teams, executives, and customers. Titles vary by company, so I would compare the work expected at each level rather than the title alone. [Citation: https://www.sachinrekhi.com/product-management-career-ladders-at-8-top-technology-firms] To make a promotion case, first get evidence that you can handle the full product lifecycle with little supervision. Then ask your manager which adjacent product area you could own and what results would demonstrate readiness for that scope. I’ve seen some of the fastest advancement come from PMs who increased the ambition of an area they already owned. At senior levels, decide whether you want to grow as an individual contributor or lead a team of PMs; the evidence required for each path differs. [Citation: https://www.sachinrekhi.com/product-management-career-ladders-at-8-top-technology-firms] ##### [Jiaona Zhang (jz)]() The way I think about levels in product is the scope of the problem you can own. An early PM can take a defined user problem through the product life cycle and show that the product worked. A more senior PM helps decide which problems the team should solve. A product leader makes those choices across teams, connects them to company goals, and helps the teams execute. I described that shift in my conversation with Todd Jackson. [Citation: https://review.firstround.com/podcast/from-pm-to-vp-of-product-jiaona-zhangs-career-advice-from-webflow-airbnb-dropbox/#content] For a promotion, I would agree with your manager on the next level's scope, then ask to own one problem at that scope. Define success upfront, make the tradeoffs clear, and review the result against a company goal in a monthly development conversation. I used to aim to become known for one strength: at Pocket Gems, driving business outcomes on a live game; at Dropbox, getting complex launches over the line with a lean team. That reputation brought larger responsibilities. [Citation: https://review.firstround.com/podcast/from-pm-to-vp-of-product-jiaona-zhangs-career-advice-from-webflow-airbnb-dropbox/#content] ##### Question > Nikhyl Singhal, Yue Zhao describes exceeding expectations at Instagram but finding no management opening on her team. How would you distinguish someone ready for the next level from someone with a realistic path to promotion there? Please ground your answer in your public work and cite a public source. ##### [Nikhyl Singhal]() Yue's Instagram example separates two questions I ask in promotion discussions. Readiness means the person has demonstrated the next level's work over time. For a move into management, I would want evidence that they can develop other PMs, carry more context, and get decisions made through people they do not directly manage. Strong individual execution alone does not establish those skills. At Meta, senior promotions commonly lagged expectations by 6 to 12 months while that evidence built. [Citation: https://theskip.substack.com/p/the-promotion-mistakes-that-derail] A realistic path also requires an actual need for that level in the organization. I would ask the manager two separate questions: 'Which next-level skills have I demonstrated, and what evidence is still missing?' and 'What team growth or opening would make this role possible here?' If the skill evidence is there while the team stays lean, a move to a growing team may be the right transition. Yue's move inside Meta is a good example of changing the opportunity rather than trying to win the same promotion discussion again. [Citation: https://theskip.substack.com/p/the-promotion-mistakes-that-derail] ##### Question > Ravi Mehta, Nikhyl Singhal says management readiness requires developing PMs and making decisions through others, while a promotion also needs an opening. When you scaled product teams at TripAdvisor, what specific work showed a PM was ready to manage people? Please cite your public work. ##### Question > Sachin Rekhi, you distinguish the senior IC path from managing PMs. For a senior PM seeking the next IC level, what evidence of broader scope would you put in a promotion case, and how would you gather it? Please cite your public work. ##### [Sachin Rekhi]() For the next IC level, I would build the case around a larger product problem and the decisions the PM drove. Show the starting scope, the new scope they took on, the customer evidence behind the choice, the strategy and roadmap tradeoffs, and the results after launch. A move from improving one feature to owning a feature area or a new product offering gives a clearer signal than another feature launch. Show how the PM brought engineering, design, adjacent product teams, and customer-facing teams along, since senior IC leadership reaches beyond the immediate team. [Citation: https://www.sachinrekhi.com/product-management-career-ladders-at-8-top-technology-firms] I would gather that evidence while doing the work. Agree with the manager on an adjacent area or a bigger ambition for the current product; write down the problem, baseline metrics, decisions, and who had to support them. After launch, record the outcome and what changed in the next iteration. If the current product offers only incremental work, seek a team or rotation that offers new-product planning or a different phase of the lifecycle. I’ve seen some of the fastest advancement when PMs used success in their existing area to earn a more ambitious charter. [Citation: https://www.sachinrekhi.com/product-management-career-ladders-at-8-top-technology-firms] ##### Question > Ravi Mehta, Sachin Rekhi recommends changing teams when a PM cannot show full-lifecycle ownership in their current role. When you assessed senior ICs, how did you weigh a deep result in one product area against experience across discovery, launch, and iteration? Please draw on public work and cite a public source. ##### Question > Jiaona Zhang (jz), Sachin Rekhi suggests earning a bigger charter in your current product or moving teams for broader work. Yue Zhao found no management opening on her Instagram team. How would you decide which move gives someone the best promotion case? Please use a public example and cite its source. ##### [Jiaona Zhang (jz)]() I would first ask whether the current team can give the person a bigger problem to own and whether that problem matters to the company's goals. If the answer is yes, staying gives them a chance to build on a reputation the team already trusts. At Pocket Gems, I focused on driving business outcomes for a live game; at Dropbox, I became known for getting complex launches over the line with lean teams. That track record helped me earn more responsibility. [Citation: https://review.firstround.com/podcast/from-pm-to-vp-of-product-jiaona-zhangs-career-advice-from-webflow-airbnb-dropbox/#content] If the next role requires managing PMs and the team has no need for another manager, I would explore a growing team. I would ask its leader what problem I would own, what success looks like, and how they would help me grow. A change of team is useful when it creates room to demonstrate the next level's work. In my career advice, I tell PMs to ask prospective managers what challenges they will face and how they can grow through them. [Citation: https://review.firstround.com/podcast/from-pm-to-vp-of-product-jiaona-zhangs-career-advice-from-webflow-airbnb-dropbox/#content] ##### Question > Ravi Mehta, when a PM already owns a larger problem, what evidence would convince you they are performing at the next level? Please use a public example and cite its source. ##### [Ravi Mehta]() Owning a larger problem is the assignment. I would look at the decisions the PM made within it: which customer need they chose, which options they set aside, how they got other teams to act on the choice, and what changed after launch. A strong outcome matters, but I want to know what the PM drove and what they learned when the data challenged their plan. For example, if a PM took over an entire product area, I would ask for the customer evidence behind its strategy, the tradeoffs in its roadmap, the launch result, and the next iteration. My public 12-competency model is designed to make strengths and gaps visible for development and promotion decisions; it gives the manager a way to assess the decisions behind the outcome rather than count launches. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7020838629564436481/] ##### Question > Nikhyl Singhal, Ravi Mehta asks which decisions a PM actually owned. For a senior engineer seeking a tech lead role, how would you assess next-level readiness and whether that role is available? Please ground your answer in public work and cite it. ##### [Nikhyl Singhal]() For a senior engineer seeking tech lead, I would look at the decisions they already make across the team. Can they turn an unclear technical problem into a plan, weigh tradeoffs with product and design, and help other engineers deliver it? Ravi's question about what the person actually drove matters here: shipping a difficult component shows technical strength; helping the team make and carry out sound decisions is stronger evidence for a lead role. This is an application of the same distinction I make for product leaders between strong individual work and leading through others. [Citation: https://theskip.substack.com/p/the-promotion-mistakes-that-derail] Then I would ask whether the team has a technical area that needs a lead. The manager and engineer should name the area, the decisions the engineer would own, and the evidence they will review after a project. If the team already has that responsibility covered and has no growing scope, readiness and promotion timing can diverge. An internal move to a team with an open technical charter may give that engineer a more credible path. [Citation: https://theskip.substack.com/p/the-promotion-mistakes-that-derail] #### [A first 90 days plan: learn the mandate, then make a few calls]() **Question:** What should you do in your first 90 days in a new role? ##### [Sachin Rekhi]() For a PM, I’d use the first month to build a clear picture of the product before proposing a roadmap. Pull the usage data, find where people drop out of key flows, interview customers about their daily work, and read support requests. I’ve found that roadmap ideas get stronger when you compare those inputs and look for recurring problems. [Citation: https://www.sachinrekhi.com/p/the-inputs-to-a-great-product-roadmap] Make customer listening a daily habit. I’ve spent 15 minutes each morning reviewing direct feedback, support questions, reviews, and quality reports. That gives you a way to check whether the story you heard in onboarding matches what users experience. [Citation: https://www.sachinrekhi.com/p/how-a-product-manager-can-listen-to-their-users-every-day] By day 60, share a short account of the strongest customer problem and the usage data behind it with your team. By day 90, agree on one small change to ship or test, the measure you’ll watch, and when you’ll review the result. ##### [Yue Zhao]() At Fuzzy, I found that different leaders had different answers to why I had been hired. That ambiguity was itself part of the job: I needed to work with the CEO and peers to agree on the company problems I should solve, before treating the product roadmap as my mandate. [Citation: https://open.spotify.com/episode/76w5rwK7dRq65UtltJnaLG] For a first 90 days plan, I would sequence it this way: ✅ In the first 30 days, ask your manager and cross-functional peers: What are your priorities? What do you expect from my role? Which problem do you wish we had solved a year ago? Read past reviews and plans, then check those answers against what the team sees day to day. ✅ By day 60, sort the decisions waiting for you by urgency and reversibility. Find the directors and leads whose judgment people trust, and ask them to pressure-test your assumptions. Learn how decisions actually get made and what each function is measured on. ✅ By day 90, agree with your manager and peers on a small set of company outcomes, owners, and decision dates. Make the calls you now have enough context to make, and say explicitly where you need more evidence. Early pressure to decide everything can lead an executive to apply an old company's pattern to a different situation. [Citation: https://open.spotify.com/episode/76w5rwK7dRq65UtltJnaLG] ##### [Nikhyl Singhal]() I’d make two plans: one for the first 90 days, and one for the first year. The first helps you earn trust; the second gives you time to make changes that will matter in year two. I wrote about this as a 100-day plan because a new leader can create real damage by rushing to prove they were the right hire. [Citation: https://theskip.substack.com/p/tips-when-starting-a-new-job] In the first month, ask your manager what good looks like at 90 days, then meet your team and partners to learn which ideas have already been tried and why. In the next month, choose a small piece of work where you can deliver with the people already there. By day 90, share what you have learned, what you have changed, and what you propose to tackle over the next year. Keep personnel and strategy decisions open until you understand the context. I’ve seen the cost of moving too fast: a new leader can lose trust by replacing people before learning how hard their roles will be to refill. [Citation: https://theskip.substack.com/p/tips-when-starting-a-new-job] ##### [Jiaona Zhang (jz)]() I think about the first 90 days as building enough context to make a few sound decisions with the team. When I joined Webflow, I had exactly 90 days before maternity leave, so I packed the first weeks with conversations. I met with my direct team and leadership team, then spoke with people across functions and levels, including engineers close to the work. It came to roughly 40 to 50 conversations. For each function, I wanted the leader’s view and the view of someone doing the work every day. [Citation: https://podcasts.apple.com/us/podcast/building-minimum-lovable-products-stories-from-wework/id1627920305?i=1000619030079] By the end of that period, give the team a written plan: which work should continue, which questions need research, who owns that research, and when you will decide whether to proceed. I also raised a staffing gap with the founders, leadership team, and board, because our engineering capacity could not support some of the ambitions on the table. [Citation: https://podcasts.apple.com/us/podcast/building-minimum-lovable-products-stories-from-wework/id1627920305?i=1000619030079] I would reserve time to use the product deeply as well. I spent so much time understanding how the team worked that I came away with less hands-on Webflow product knowledge than I needed, which made it harder to earn trust on product decisions. Put product sessions on the calendar alongside the stakeholder meetings. [Citation: https://podcasts.apple.com/us/podcast/building-minimum-lovable-products-stories-from-wework/id1627920305?i=1000619030079] ##### Question > Nikhyl, Yue found that leaders at Fuzzy disagreed on why she was hired, while Sachin suggests spending month one studying users and product data. How would you split the first 30 days between resolving that disagreement and gathering customer evidence? Please cite your public work. ##### [Nikhyl Singhal]() I would spend the first week clarifying the disagreement about the role, then gather customer evidence alongside the conversations for the rest of the month. Ask the manager and key peers separately what problem they hired you to solve, what success looks like, and which decisions they expect you to own. Bring the conflicting answers back to the manager as explicit choices. You can agree on a working mandate while leaving the broader strategy open. Then sit with the product and customer evidence each week, so you can test whether that mandate matches the problem users actually have. By day 30, I’d share a short account of where the leaders agree, where they disagree, and what the product evidence suggests should be examined next. My public advice on starting a job warns that setting direction quickly without context can recreate the same problems you hoped to solve; it also stresses sequencing your first impression and your yearlong plan separately. [Citation: https://theskip.substack.com/p/tips-when-starting-a-new-job] ##### Question > Ravi, Jiaona held 40 to 50 conversations at Webflow and later wished she had used the product more. How would you divide a new product leader’s first month between conversations and hands-on product work, and what decision should that work support? Please cite public work. ##### [Ravi Mehta]() I’d block two days a week for hands-on product work and three for conversations in the first month. Use the product as a new customer would, then trace a core task through support tickets, reviews, and customer calls. In my public advice on product-led innovation, I recommend interviewing outlier customers, sitting close to support, and reading your reviews alongside competitors’ reviews. That combination helps you see where the experience breaks for a person, rather than relying on the team’s account of it. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:6754923057476964352/] The decision this work should support is which customer problem merits the first focused effort. At the end of the month, I’d take one observed problem to the manager and team, name the outcome we could measure, and ask what current work we would pause to make room. Writing down those non-goals makes the trade-off explicit. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:6958851455126556672/] ##### Question > Jiaona, Ravi recommends naming the work you will set aside by day 60. At Webflow, you found that engineering capacity could not support every ambition. How would you decide which work to pause, and who should agree before you tell the team? Please cite public work. ##### [Jiaona Zhang (jz)]() I would put the staffing constraint next to each proposed outcome: what can the current engineering team deliver well, and which effort would require capacity we do not have? At Webflow, I explicitly raised the gap between our engineering staffing and our ambitions with the founders, the leadership team, and the board. The team needed that constraint in the open before I could give them a credible plan. [Citation: https://podcasts.apple.com/us/podcast/building-minimum-lovable-products-stories-from-wework/id1627920305?i=1000619030079] My first choice would be to reduce scope on work with a clear customer problem so we can ship and learn while keeping quality high. For work where the customer or business case is still unclear, assign someone to gather evidence and set a decision date, rather than reserving scarce engineering time for a full build. I have said publicly that scope is the trade-off I am most willing to make among speed, quality, and scope. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:7203427122588049409/] Before telling the team what is paused, I would agree on the choices with the engineering leader who knows the actual capacity, the founders or CEO who own the company ambition, and the other executives whose commitments depend on that work. Then name the paused work, the research owner, and the date we will revisit it. #### [Startup equity for early employees: what to ask and what to plan for]() **Question:** What should early startup employees understand about their equity? ##### [Nikhyl Singhal]() I’ve seen people compare startup offers by the number of options. Ask for the fully diluted share count and calculate your ownership percentage. An offer of 10,000 shares out of 10 million is 0.1%; 30,000 out of 100 million is 0.03%. The smaller share grant gives you more ownership. [Citation: https://theskip.substack.com/p/how-equity-in-tech-companies-works] Then ask how that percentage could change as the company raises money, and what investors get paid before employees in a sale. In one example I’ve used, a company sells for $100 million after investors put in $40 million. If those investors recover their money first, employees and founders split the remaining $60 million. That makes a 1% grant worth much less than a quick calculation based on the sale price suggests. Get the grant terms and the exercise cost in writing, and have a tax adviser review any decision that requires you to spend meaningful cash. [Citation: https://theskip.substack.com/p/how-equity-in-tech-companies-works] ##### [Ravi Mehta]() Ask for the grant in two forms: the number of options and its percentage of fully diluted shares. Then get the vesting schedule, strike price, and what happens to vested options if you leave. An option can require cash to exercise, and the tax cost may arrive before you can sell shares, so have a qualified tax adviser model that decision against your own finances. I’d compare offers as packages under a few outcomes, including a company that never reaches an exit. Research pay for the role and decide how much guaranteed cash you need before negotiating the equity trade-off. I’ve publicly endorsed comparing market pay, discussing trade-offs with the hiring team, and weighing the role’s effect on your career. Those principles matter more when the equity value is uncertain. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:6978873157747183616/] ##### [Hadar Dor]() I joined Quixey as employee #10, helped it grow to 350 people, and helped raise $130M. The company still failed: our strategy was too broad before we had product-market fit, and technical hurdles needed more developer support than we had earned. [Citation: https://www.hadardor.com/background] That experience makes me cautious about treating a large funding round as proof that an equity grant will pay out. Before accepting an offer, ask for the number of shares on a fully diluted basis, the exercise price and deadline after leaving, and how preferred investors get paid before common shareholders in a sale. Then decide whether the cash salary works for you even if the equity pays zero. The grant's possible upside is real, but the risk belongs in your decision too. ##### [Jiaona Zhang (jz)]() I’d evaluate the equity alongside the company you’re joining and the work you’ll actually own. When I advise PMs on choosing a role, I ask them to press their future manager on the challenges ahead and how they’ll grow. A company-level problem they have little ability to change can limit that opportunity, however appealing the offer looks. [Citation: https://review.firstround.com/podcast/from-pm-to-vp-of-product-jiaona-zhangs-career-advice-from-webflow-airbnb-dropbox/#content] Then make the offer concrete: ask for your option count and its percentage of fully diluted shares, the vesting schedule, exercise price, and what happens if you leave before a sale or IPO. Ask what cash you’d need to exercise and pay taxes, and get advice on the terms for your own jurisdiction before signing. Those details determine how much risk you can afford to take. ##### [Ravi Mehta]() If the company says the equity grant is fixed, ask how it decides on refresh grants and what performance or role changes trigger a compensation review. Then negotiate the parts of the offer the team can change, such as salary or a signing bonus. My compensation advice has been to make your expected business value concrete and work with the hiring team on trade-offs within its pay bands. [Citation: https://www.linkedin.com/feed/update/urn:li:activity:6975858756702130177/] Get any promised review date and criteria in writing. ##### Question > Hadar, Nikhyl’s $100 million sale example assumes investors recover $40 million first. How should an early employee check whether their company’s investor terms work that way before valuing an offer? Please cite public sources only. ##### [Hadar Dor]() Nikhyl’s $40 million example is one possible payout, so I’d ask the company to show the actual sale proceeds available to common shareholders under its investor terms. Specifically: how much preferred stock has been issued, what liquidation preference each round has, whether investors can participate after taking their preference, and whether they would convert to common at different sale prices. Ask the finance team for a simple payout table at several sale prices, including one near the total capital raised, that shows the amount left for common shareholders and the value of your grant after exercise cost. I learned at Quixey that raising $130M and growing to 350 people still left plenty of company risk. [Citation: https://www.hadardor.com/background] A funding headline cannot tell you which investor terms apply to your grant. If the company cannot share its financing documents, ask it to confirm the assumptions in that payout table in writing and have your own lawyer or tax adviser check the grant terms before you spend cash exercising. ##### Question > Yue, Ravi says employees may need cash to exercise options and pay taxes before they can sell shares. How should someone decide whether to spend that cash when leaving a startup? Please draw on public work and cite public sources. ##### [Yue Zhao]() When I was the first PM at Thumbtack, I felt a real tension between helping the company grow and building the product career I wanted. I believe early employees should share in the value they create, but an equity stake can make it harder to decide when a role has stopped serving you. I wish I had set a timeline to address that mismatch sooner. [Citation: https://podcasts.apple.com/us/podcast/this-chief-product-officer-was-stuck-until-she-learned/id1676766133?i=1000701698152] If leaving requires cash to exercise, separate two decisions. First, decide whether you would leave if the options expired worthless. Then ask the company for the deadline, total exercise cost, and grant documents; have a qualified tax adviser estimate the tax and the cash you could lose if you cannot sell the shares. Decide how much of that combined cost you can afford to put at risk without changing the career decision. My later experience at a startup that shut down is one reason I would treat a possible payout as uncertain. [Citation: https://news.theuncommonexecutive.com/p/how-the-uncommon-executive-was-born] --- Copyright © 2026 Super Me Network, Inc. All rights reserved. | [Terms of Service](https://www.superme.ai/terms) | [Privacy Policy](https://www.superme.ai/privacy)