Arjun Lalwani

The through-line

Arjun Lalwani's account of product management keeps returning to one idea: the job is defined by outcomes, not by a job description, and everything else is a skill you go and acquire because the team in front of you needs it. He came to product after pushing back on a PRD as a software engineering intern at Microsoft and discovering the PM had reasons he hadn't considered, thinking "five years out" while he "was just thinking like two months out" [1]. From there the pattern repeats at every stage: identify the gap, whether it is design literacy, business analysis, interviewing technique or credibility on a new team, and close it deliberately. The second, quieter through-line is humility about how much of the field is luck and timing, and how little of it is settled: "product management as a field is constantly evolving there's like what is expected for PM constantly keeps changing" [1].

On what makes product management a different kind of puzzle

What drew him away from engineering was the breadth of the problem rather than its depth. He compares the satisfaction of cracking code to the PM equivalent, except that in product "you don't exactly know what your customers want but you have a hypothesis of what your customers want and you work with so many different stakeholders to put together that holistic product that would be a great MVP or could be great enough like product that a customer would choose to use you and give you five star reviews" [1]. The ingredients he lists are human psychology, market dynamics, competitors and the underlying technology, and it is holding all of them at once that he finds more interesting than the engineering version of the problem [1].

Underneath the changing expectations, he holds the core steady. A PM is "responsible to making sure you're Building Products that customers love" and that the work is "generating like revenue for the business", and if you do those two things, the precise shape of your role from quarter to quarter matters less [1].

On technical fluency for people without a technical background

His answer to the most common question he gets is the restaurant manager analogy: you can run a restaurant without being able to cook, but you need to know what the chefs are doing and whether the food is good, "you need some level of like ability to know if this is overburned or under burned" [1]. Translated to product, engineering is the critical piece and "you don't need to be a master at it but you do need to understand the fundamentals" [1]. His prescription is concrete and modest: take a coding class for fun, spend six or eight months building an app or a website for your friends, and develop an intuitive sense of how things get made so you can follow what engineers are saying [1].

He gives two second-order reasons this matters. It helps when hiring, because you can judge an engineering manager's quality from how they communicate and which technologies they keep up with [1]. And it inoculates you against panic when the industry shifts. He is candid that even with a technical background he finds the current AI boom hard: "I've spent a lot of hours trying to understand the space and I am Technical and I still don't understand a lot of it right I maybe get like five percent of what's being taught in a lecture" [1]. The danger is not ignorance but paralysis, and assuming the engineers have it figured out while you can't cross the gap leaves you "always be at a disadvantage in this industry" [1].

On spiky skills and closing your own gaps

He frames every background as producing a skill profile with spikes and holes rather than a deficit. Coming from computer science, working with engineers and brainstorming fast ways to build something "came very easily to me because I just did that in college for four years", while design was a blank: when designers asked his opinion he thought "I don't know like I have not studied design why are you asking me for my opinion" [1]. His response was to take design courses in order to "speak the design language" and give tangible, concrete feedback, and he did the same for data science and for business skills he describes bluntly as horrible, including how to analyse a market and understand competitors, strategies and moats [1]. The general rule he draws is that the gaps are relative to the team: "depending on the strengths and weaknesses of the team you will have to learn some skill or the other so you can be more competent while working with stakeholders" [1].

On learning product by starting something

His standard advice to anyone trying to build the skill set is to start something, for students and for people pivoting mid-career alike. Build a product your friends will actually use, find a pain point, and if the pain point is trivial, so be it: "it could be something as simple as I don't like the t-shirts people are wearing so I'm going to start a t-shirt company" [1]. The teaching happens because the problems arrive unbidden. You discover you cannot do it alone and have to build a team, you run into pricing, you confront why people aren't buying, and you end up finding your own route to product market fit [1]. He is clear this teaches more than any classroom and that it is really founder training that overlaps with product: "I would argue you're learning more of the founder skill set as well along with product management", and the same problems recur at larger scale inside big companies [1].

On breaking in, referrals and interview preparation

He is direct that his own path involved failure first. He applied for a Google internship two years before joining the APM program, went on site and did not get an offer because his interviewing skills were weak and he lacked experience [1]. He then engineered the fix: two product internships the following year, one focused on metrics and the analytical part of the user funnel, the other on user experience and shipping end to end [1]. On interviewing itself he treated it as a trainable skill, preparing from late June through to November with near-daily mock interviews, roughly 120 by the time of his on-site, until basic product questions were routine and only the harder ones tripped him up [1]. He pairs that with a warning about performance decay under pressure: "it's very rare that you are actually at Peak Performance on interviewing day you're probably like 30 40 worse than what your Peak Performance was", so prepare with that discount priced in [1].

On getting seen at all, he favours combining a referral with direct contact: get the referral, then ping the recruiter yourself to ask for an interview, or ask your contact inside the company to ask the recruiter to prioritise your application [1]. He does not oversell it, noting that thousands apply and only so many can be interviewed, so "a lot of it is luck" and "a good word goes a long way" [1]. For resources he points to Lenny's newsletter, which he reads religiously, and Lenny's course that runs in the fall and is announced on Twitter, Shreyas's course, and for interview preparation specifically Exponent and Stellar Peers, along with his own Medium article "navigating APM interviews" listing what he used [1]. He distinguishes between them: some of that material is more useful once you are already a PM, while the interview prep sites are for getting in [1].

On earning credibility as a junior PM

The most counterintuitive advice he passes on came from a senior PM early in his time on Google hotels. He had spent two months reading about the travel industry and its competitors because he thought that was what a PM does, and was told to stop: "don't waste your time doing all this like it does not matter like you will never be able to change major strategy because you don't have credibility on this team yet" [1]. The instruction was simply to execute, and crush whatever project he was given [1]. He took it, and describes delivering faster, with fewer resources, or by changing the approach when the original one wasn't working [1]. The result was a reputation that engineers and designers wanted to work with him because he shipped, which then earned him a project to lead end to end and with it the room to do actual strategy work [1]. He adds the caveat that this depends on the manager and the company, so the pattern is not universal [1].

On reading the team and the leadership you have

He resists applying industry-wide trends about what PMs should do to every situation, arguing it is highly team dependent [1]. The method he recommends is diagnostic: assess the team's strengths and weaknesses, find the part that is underperforming, and step in, add resources or otherwise accelerate it [1]. Leadership quality is the sharpest variable. Where you disagree with the strategy, the job becomes evidence gathering, running quick prototypes and tests to validate or disprove leadership's hypothesis with customer data [1]. Where leadership is strong and the strategy is clear, "it's all just execution and you just have to like make sure how can we hit this as quickly as possible", which he calls a very different ballgame [1]. His conclusion is that working across different companies, teams and stages of the product lifecycle is what gives you the nuance to tell which situation you are in [1].

On what he looks for when interviewing PMs

Having run dozens of interviews, his headline complaint about PM candidates is a lack of clarity of thought and a failure to sit with the clarification questions [1]. He says the first five to ten minutes tell him most of what he needs to know about preparation and structure. The signal he wants is a candidate who breaks the question down, parses every word of it, establishes the bounds and constraints, and then lays out a road map for how they will answer, which tells him "this person knows what they're doing and has a very structured way of thinking about things" [1]. A little randomness is tolerable; jumping straight into an answer is not [1].

Takeaways

• The core of the PM job survives every change in the role's definition: build products customers love and generate revenue for the business [1].
• Non-technical PMs should aim for intuition, not mastery, by taking a coding class and spending six to eight months building something real for friends, enough to judge whether the work is good the way a restaurant manager judges the kitchen [1].
• Treat your own skill profile as spiky and fix the holes deliberately, taking design courses to speak the design language, and building data science and market analysis skills so you can give concrete feedback to each stakeholder [1].
• The fastest way to learn product is to start something small with real users, because pricing, team building and product market fit force themselves on you in a way no classroom replicates [1].
• Interviewing is a trainable skill, and he prepared with near-daily mocks over four to five months, roughly 120 in total, while assuming he would perform 30 to 40 percent below his peak on the day [1].
• Combine a referral with a direct message to the recruiter, and accept that at application volumes this large, a good word matters but luck still dominates [1].
• As a junior PM, skip the industry deep dives and simply execute what you are given, because credibility on the team is what buys you the right to influence strategy later [1].
• When evaluating PM candidates, judge the first five to ten minutes: whether they parse the question's constraints and set out a structured road map before answering [1].
• Fear of new technology waves is the real career risk, not ignorance, since even technical people grasp only a fraction of what is happening in AI [1].