# Career moves in product, from your next role to your own company — Summary 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]() Transcript: [Full Chat Transcript]() Work group: [Product Careers]() ## Questions ### [What to check before you accept your next role]() Decide what the next role has to do for you, then check the offer against evidence: the actual weekly work, the company's growth and a real opening at the level you want. - **Name the outcomes first.** Yue Zhao weighed her options with three questions: would she enjoy the daily work, would it have a meaningful impact on people, and could it cover her share of the family finances. Coaching met the first two, and she went full-time once it reached her financial number. - **Look past the title.** Sachin Rekhi notes that the PM title covers builders, tuners, innovators and enablers, and suggests asking people in the role to walk you through a recent week. Jiaona Zhang first decides whether she wants to build product, manage PMs or lead the function. - **Check that the company can grow you.** Nikhyl Singhal weighs company stage, growth and how quickly he can find his footing. Before trusting a promised path into management, Yue would ask whether the skip-level's team and budget are growing. - **Take the stretch if it has an early win.** Ravi Mehta would choose the bigger learning curve when he can name the skill it builds and a useful result for the first quarter. He would also ask the hiring manager how the first six months split across innovation, management and production. ### [Title or company: how to compare the two offers]() Compare what you would own in year one, whether the company is growing enough to create more scope, and who will teach and sponsor you. - **Ask what you would own.** Yue Zhao suggests asking for examples of decisions the last person in the role made, and what team and budget you would direct. Sachin Rekhi suggests probing independence, product scope and leadership, the three dimensions of his career-ladders analysis. - **Check how fast the company is growing now.** Nikhyl Singhal warns that a former hypergrowth company keeps its name while the scope it promised can shrink. He would ask about customer growth, new product investment and the PM org over the last four quarters. - **Find out who grew there.** Ravi Mehta would ask each company about the last two people who grew into more scope: what they delivered, how long it took and what opened up next. - **A bigger title can be a different job.** Jiaona Zhang points out that a bigger title can move you from doing product work to leading a team or the function. Yue left her role as Head of Product for Pro at Thumbtack for an IC role at Meta, for an official level and the chance to work with people operating at a very different scale. ### [Switching career tracks or going deeper: run a trial first]() First work out whether the problem is your company or the work itself. If it is the work, test the new track on a small scale before you give up the depth you have. - **Separate a stalled role from the wrong track.** Yue Zhao left Thumbtack for Meta after hitting a ceiling, and stayed in product. Her later move into coaching passed a different test: impact on people, enjoying the daily work and an income threshold she reached before going full-time. - **Run a bounded trial.** Sachin Rekhi tested tracks in short stints, including six months in product marketing before he went back to product management. He suggests a project with the adjacent team, judged on the daily work once the novelty fades. - **Test your current track as well.** Nikhyl Singhal would ask for a harder problem with clear ownership in your current track at the same time. If that restores your growth, the constraint may have been the role or the company's phase. - **If both trials go equally well, keep the depth.** Ravi Mehta would score each trial on results, the work you want to repeat and the scope you would get next, and keep the depth when both look equally promising. Hadar Dor changed product areas several times without leaving PM. ### [Stay and fix the job, or leave: make one clear ask first]() Make one specific request to change the job, with a date to revisit it. Leave if the company has no credible path to the work you want. - **Ask before resentment builds.** Yue Zhao nearly quit Thumbtack after three years without ever clearly asking for the title or pay she wanted. She suggests naming the change you need and asking for a commitment and a date to revisit it. - **Compare two growth rates.** Nikhyl Singhal checks whether the company has new customers, products or teams that would create bigger problems for him. He would treat a disagreement about his readiness as something to work on, not a reason to leave immediately. - **Judge the daily work.** Sachin Rekhi left a path toward VP at LinkedIn because leading a large team kept him from customers and building. Ravi Mehta suggests judging a proposed role by its calendar and responsibilities. - **Don't decide in the heat of frustration.** Jiaona Zhang asks whether she is still learning through the hard parts, and would look for a specific opportunity she is excited about before leaving. ### [Before you quit to start a company: what to test while employed]() Use the months before you resign to gather evidence: a customer problem heard firsthand, someone paying for the smallest useful offer, a runway date and a cofounder relationship that has survived a missed deadline. - **Listen before you pitch.** Sachin Rekhi asks prospects to name their five biggest work problems before he mentions his idea, then to rank his alongside them. For Notejoy, he and his cofounder interviewed in waves of five until the conversations stopped turning up new problems. - **Charge for the trial.** Ravi Mehta corrected his own example: free mentoring at Scale Higher showed the team could deliver value, not that people would pay. He would run a paid version of the smallest offer and record what each customer paid, whether they finished and what they wanted next. - **Set a runway date that ignores unsigned money.** Ben Erez ran out of money about a year after leaving a job that paid over $100K. He suggests working out monthly spending, picking the date the cash runs out and leaving fundraising out of it until a term sheet is signed. - **Test the cofounder and your own momentum.** Hadar Dor suggests a small project with real deadlines before you choose a cofounder. Nikhyl Singhal would look for a time you moved a problem forward without an employer's distribution, engineers and customers. ### [PM, designer and product engineer: who owns which decision now]() Tell the roles apart by the decisions each one owns. The overlap starts in discovery and prototyping, and someone still has to make the investment call. - **Split the roles by decision.** In Ravi Mehta's framing, the PM connects customer needs and business outcomes to what ships, the designer owns how people understand and use the experience, and the engineer owns how it works in production. Jiaona Zhang would split a Webflow decision the same way: the designer judges what needs polish, the engineer what the team can build well, and the PM makes the investment choice. - **The blur starts in discovery.** On an Instagram Feed project, Yue Zhao's engineers joined user interviews while designers updated prototypes every two to three days. Sachin Rekhi would prototype several problem-solution pairs before anything goes on the roadmap. - **Leaders have to let teams act.** Yue describes a disagreement at Fuzzy over when engineering should join a project, which ended with the CPO and CTO roles combined. Sachin suggests a short decision review after each prototype test, with leaders letting the team act on it. - **Company stage changes the overlap.** Nikhyl Singhal brought PMs into his startups too early, while the founder was still finding product-market fit. Sachin would add a PM once the founder can hand over a real area of product direction. ### [Getting into product management from another function]() The most reliable route is internal: do PM-shaped work alongside a product team until you are the obvious pick. Without that path, bring evidence a standard candidate can't. - **Start next to the product team.** Sachin Rekhi calls the move from an adjacent role the most common internal path, and Ben Erez ranks it above every other. Ben points to a product marketer who became a PM at Asana by taking on PM-shaped problems for months, without asking for the role up front. - **Use the domain you know.** Jiaona Zhang suggests that people with a decade in one industry join a startup disrupting it. Nikhyl Singhal suggests building tools that fix your own function's processes, with that function's leader as your first sponsor. - **Domain knowledge is one competency of many.** Ravi Mehta, who hired more than 40 PMs at TripAdvisor, scored every candidate on the same competencies. He suggests switchers name the two or three gaps an interviewer will probe, usually strategy and metrics, and close them. - **Make a side project show judgment.** Sachin says a generic AI prototype only shows you can use a tool. He suggests a side project that shows a problem from your own domain, the design options you rejected and one decision you changed after watching real users. ### [The tech careers product leaders would bet on as AI does more work]() These product leaders would bet on roles that own an outcome: the economics of an AI feature, the rules and evaluation behind it, or the choice among competing prototypes. - **Own the outcome.** Ravi Mehta would look for roles that own the economics of what AI helps build, since a feature can gain usage and still lose money on model costs. Nikhyl Singhal has seen younger AI companies bring in PMs later, with three doing work that seven might have done before, and says they seek people who can scale a product and stay close to the work. - **Keep the judgment calls.** Sachin Rekhi uses AI to synthesize interviews at Notejoy, then reads the customer quotes himself before deciding what to build. Hadar Dor would take trust and safety, regulatory product and AI evaluation seriously, because people still define the rules and own the results. In her coaching, Yue Zhao sees making a call with incomplete information as a durable skill. - **Bring evidence an employer can check.** Sachin suggests building two working versions of a fix for one pain point, putting both in front of customers and letting what they do pick one. Nikhyl suggests early-career PMs build a small product with users, run the interviews themselves and record the decisions feedback changed. Yue suggests building an AI agent for a repetitive part of your work and showing what problem the saved time let you solve. - **Lead because you want the accountability.** Yue expects smaller teams to thin some middle-management layers, so moving into management purely for career security looks risky to her. She calls that a forecast. Ravi would pursue product leadership when you can improve decisions across several teams and want to answer for their outcomes. If you are still building customer judgment, he suggests deepening IC skills first. ### [Getting good with product numbers: definitions, daily reps and a prediction log]() Start by saying exactly what a metric counts, then get daily repetition on your own product's numbers and a way to check your predictions against what happened. - **Define the metric before you learn the tool.** Ben Erez finds the most common gap comes before SQL and dashboards, when people can't say in plain words what they would count. He suggests writing a precise definition for each metric your team reports and checking it against how the data team calculates it. Without a dashboard of your own, he suggests practicing on a public product such as DoorDash. - **Read the same numbers every day.** Sachin Rekhi owned the Sales Navigator P&L at LinkedIn and once missed a trend Jeff Weiner spotted on the dashboard Sachin had open. His fix was to read the same dashboards every day. He recommends a daily hypothesis for each trend, a weekly ad-hoc query, a recap one week after each launch and a monthly dashboard review. - **Grade your own predictions.** Ravi Mehta suggests writing down what you expect before a launch and scoring yourself afterward, and points to a free tool, The Product Judgment Test. Hadar Dor starts a ramp-up doc on each new team and asks the people she meets, data scientists included, to correct it. She also suggests owning one metric you have to move, because trying to change a number teaches you why it moves. - **Practice where the reps are.** Nikhyl Singhal says analytics skills compound fastest on a growth problem at a company past product-market fit. Ravi warns that growth reps can teach you to move a number at the user's expense, and suggests noting the customer need and a counter-metric for every winning experiment. - **Learn SQL by checking what AI writes.** Sachin would start new PMs on AI querying, while insisting they learn to read SQL and know the schema. He has seen AI pick a junk source column over a clean canonical\_source one and return a normal-looking chart. Ben adds that a vague request lets an AI agent choose the definition for you. ### [Preparing for a performance review starts months before the meeting]() Most of the work happens in the months before: ask for specific feedback, keep a log of your work and learn who might object before your manager has to defend you. - **Know where you stand before the meeting.** Nikhyl Singhal suggests picking two or three recent pieces of work and asking stakeholders a specific question about each, so the review brings no surprises. Ravi Mehta suggests plotting yourself on the competencies you are judged against and asking your manager to plot you too. The gaps show what the review will be about. - **Find your detractors before calibration.** Yue Zhao describes a promotion blocked in calibration by objections the candidate had never heard, after months of her manager calling it a sure thing. She suggests keeping a log of your work all year. Ravi reads the case as a trust problem and suggests naming the people and teams behind each win in your updates. - **Write a self-review your manager can quote.** Jiaona Zhang suggests two pages, with the problem, what you did and what changed for the business up front. Sachin Rekhi suggests a section each for independence, product scope and leadership, backed by artifacts such as strategies and specs. He would draft it in Claude Code from your log, with a fixed template. - **Plan for a first review, or a bad one.** Nikhyl suggests senior outside hires pick a starter role where they can clearly exceed expectations, and keep a first review on what they delivered. If a new manager with a higher bar gives you a weak rating, he suggests deciding before the meeting which option fits: accept the reset if the skip-level trusts the new leadership, or look elsewhere if the manager has already decided about you. ### [What changes at each level, and how to build a promotion case]() Each level means owning a bigger problem with less supervision and more influence across teams. A promotion also needs the organization to have a role at that level. - **Levels track independence, scope and leadership.** Sachin Rekhi compares PM levels on those three dimensions and suggests comparing the expected work, since titles vary by company. Jiaona Zhang frames levels by the problem you can own: an early PM takes a defined problem through launch, a senior PM helps choose the problems, and a product leader makes those choices across teams. - **Readiness and an opening are separate questions.** Yue Zhao was exceeding expectations and leading two PMs' work at Instagram, but the lean organization had no management role for her, so she moved to a part of Meta with larger teams. Nikhyl Singhal suggests asking your manager which next-level skills you have shown, and separately what team growth would make the role possible. - **Build the case on decisions you drove.** Ravi Mehta treats a larger problem as the assignment and would look at the decisions inside it: the need chosen, the options set aside, how other teams were brought along and what changed after launch. Sachin suggests recording the problem, baseline metrics, decisions and supporters while you do the work. - **Stay to grow scope, or move to find it.** Jiaona would first ask whether the current team can give you a bigger problem tied to company goals. If the next role means managing PMs and the team needs no other manager, she would explore a growing team. Nikhyl would ask the same of an engineer seeking a tech lead role: whether the team has a technical area that needs a lead. ### [A first 90 days plan: learn the mandate, then make a few calls]() Use the first month to learn why you were hired and what customers experience, then by day 90 make the few decisions you have enough context for. - **Settle why you were hired.** At Fuzzy, Yue Zhao found that different leaders had different answers to why she had been hired, and needed to agree with the CEO and peers on the company problems to solve. Nikhyl Singhal suggests spending the first week asking the manager and key peers separately, then bringing the conflicting answers back to the manager as explicit choices. - **Study the product and its customers.** Sachin Rekhi suggests pulling usage data, interviewing customers and reading support requests in month one. Ravi Mehta would block two days a week for hands-on product work. Jiaona Zhang held roughly 40 to 50 conversations when she joined Webflow and came away with less hands-on product knowledge than she needed. - **Hold the big calls.** Nikhyl warns that a new leader can do real damage by rushing to prove they were the right hire, and suggests keeping personnel and strategy decisions open until you understand the context. Yue warns that early pressure to decide everything can lead an executive to apply an old company's pattern to a different situation. - **End with a written plan.** Jiaona suggests telling the team which work continues, which questions need research, who owns that research and when you will decide. Before announcing paused work, she would agree on it with the engineering leader, the founders or CEO and the executives who depend on it. Sachin suggests agreeing on one small change to ship or test by day 90. ### [Startup equity for early employees: what to ask and what to plan for]() Work out what percentage you own and what you would receive after investors are paid, then make sure the offer still works for you if the equity pays nothing. - **Turn the option count into a percentage.** Nikhyl Singhal suggests asking for the fully diluted share count: 10,000 shares out of 10 million is 0.1%, more than 30,000 out of 100 million. Ravi Mehta and Jiaona Zhang would also ask for the vesting schedule, the strike price and what happens to your options if you leave. - **Check who gets paid first.** In Nikhyl's example, a company sells for $100 million after investors put in $40 million. If they recover their money first, employees and founders split the remaining $60 million. Hadar Dor suggests asking the finance team for a payout table at several sale prices that shows what is left for common shareholders. - **Plan as if the equity pays zero.** Hadar joined Quixey as employee \#10. It grew to 350 people and raised $130M, and still failed. She suggests deciding whether the cash salary works for you even if the equity pays nothing. Ravi would compare offers under a few outcomes, including a company that never reaches an exit. - **Price the cost of exercising.** Ravi notes that exercising options can take cash, and the tax bill can arrive before you can sell. When leaving means paying to exercise, Yue Zhao suggests first deciding whether you would leave if the options expired worthless, then having a tax adviser estimate the cost. ## 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 --- Copyright © 2026 Super Me Network, Inc. All rights reserved. | [Terms of Service](https://www.superme.ai/terms) | [Privacy Policy](https://www.superme.ai/privacy)