AI Is Splitting Product Management Into Builders and Information Movers

Mike Abbott framed product management as a function whose shape has changed repeatedly with the way software is built. Twenty years ago, he said, the default enterprise model was a project manager writing a structured Product Requirements Document and handing it to engineers. That was the “classic playbook” of companies such as IBM and Microsoft. Consumer software developed differently: at companies such as Twitter, in Abbott’s telling, product managers existed but were often not decisive because the founder remained the product decision-maker. Apple, he said, has no product managers in the conventional sense, with products built through the interaction of design and engineering.

The shift Abbott wanted to isolate is that AI is now blurring even those remaining boundaries. Designers can “vibe code”; engineers can prototype interfaces; product people can build. The old distinctions among design, engineering, and product are becoming less stable.

Nikhyl Singhal sharpened that point by separating “product management” as a title from the work that companies still need done. AI, in his account, is not killing product work; it is separating builders with judgment from managers who mostly move information.

Product managers, in Singhal’s simplest definition, sit between the people who build and the people who sell, “gluing” what the company is trying to build to how it should be built. But that glue work has often degenerated into moving information around an organization for someone else to decide. That version of the role, he said, is vulnerable. It is not that companies no longer need product judgment; it is that AI can increasingly perform the coordination, synthesis, and reporting work that many product managers were hired to do during the last expansion cycle.

Singhal described the pre-AI product job, especially in larger organizations, as “responsibility without authority.” Builders entered product because they liked making things, then found themselves organizing others, writing status reports, packaging information, sitting in back-to-back meetings, and preparing materials for executives. In his view, that is why so many product people were unhappy even during the zero-interest-rate hiring boom: the job had become bureaucratic rather than creative.

AI changes the work for people who want to build. Singhal said leaders and product people now experience “more joy” because they can act directly: use Claude Code, prototype an idea, automate a status report, or remove some other rote informational obligation from their workflow. The parts of the job that remain valuable are the ones he listed as judgment, decision-making, courage, testing in the wild, customer conversations, hard technical collaboration, and partnership work.

The labor market, in Singhal’s account from the senior product leaders he works with, looks contradictory only if product management is treated as one uniform function. He said the executives he talks to are anxious, that if someone is in Big Tech they are looking at “somewhere between 30 and 70% layoffs this calendar year,” and that layoffs are severe. In the same answer, he said he is seeing more open product management roles than ever, salaries for the top 1% of product people more than doubling in 18 months, and four product-leadership contracts he helped negotiate crossing eight figures in annual compensation.

His point was that the market is differentiating between two kinds of people. Companies no longer want the PM who manages information flow. They still want, and may pay heavily for, product builders with judgment.

Singhal’s account of product management began with a company lifecycle. The same title can mean different work depending on whether the company is searching, stabilizing, scaling, or reinventing.

At the beginning, there is no meaningful product-management function in the conventional sense. A founder’s job is to find product-market fit by rapid experimentation. Singhal compared it to rubbing two sticks together, hoping to get smoke. The organization is taking as many shots on goal as possible and throwing things away when they do not work. In that phase, he said, people who want to “help build out” an early-stage company should recognize that product management may not be the right framing: “you need to found.” The work is not to manage a product machine; it is to discover whether there is any machine to build.

Once product-market fit appears, the needed skill changes. Singhal called product-market fit a “sucking sound”: the product begins to pull customers in. The irony, he said, is that the behavior that produced the fit — fast experimentation and willingness to discard — now becomes dangerous if it continues unchecked. The company has to stop giving every customer a different product. It has to build resilience and consistency. The founder is pulled toward fundraising, go-to-market, and the business side. Product management enters as a quieter, more process-oriented function: creating predictability, coordinating multiple teams, and ensuring customer needs connect to what the organization can repeatedly deliver.

A smaller subset of companies then enters hypergrowth. Singhal used older and newer internet companies as an illustrative contrast: when he was in school, he said, growth to massive user scale took far longer; later, distribution through the App Store, Facebook ads, and the internet allowed companies to grow much faster. In hypergrowth, the company’s problem is no longer merely to scale the hit product. It must also expand into adjacent product lines. This, he said, is where large product teams and the chief product officer became especially important over the past decade: managing the scale of the organization while pursuing expansion.

He placed his own operating roles in this phase. At Google, the company’s Search and Ads businesses created room to try new products. At Facebook, he worked on scaling Feed and expanding into products such as short-form video, where Reels came from. At Credit Karma, he said, the company wanted to move beyond credit scores and become “the money button on the phone.”

The final phase is late-stage technology incumbency. At that point, the company has so much success that product leadership becomes a fight against the innovator’s dilemma. The task is to create something new inside an organization that has many reasons not to. A small new business looks insignificant beside the existing one. In Singhal’s framing, product work at this stage is a return to zero-to-one creation, but under the weight of a large company’s scale, politics, and opportunity cost.

That stage-based model matters because it explains why generic arguments about PMs being “dead” miss the target. The function Singhal described as least defensible is not product judgment itself, but a particular managerial layer that grew up around coordination, reporting, and organizational scale.

Asked about Google Hangouts, Singhal treated it as a lesson in the gap between an internal product rationale and an external customer problem. Hangouts, as he described it, was a major Google effort to combine communications products across Gmail, Android, and other surfaces into one app for text, voice, and video on a new stack. Internally, the case was legible: Google had multiple codebases, products, registrations, and identity systems. Consolidation made sense from inside the building.

Users, he said, did not have that problem.

The product assumed people wanted one universal communications app across business, individual, voice, text, video, and group use cases. Singhal argued that this was not how people actually behaved. They were, and are, comfortable using Zoom for one kind of communication, iMessage or WhatsApp for another, FaceTime for another, and the phone for calls. Fragmentation was not necessarily painful enough to demand one unified app.

WhatsApp, in his telling, succeeded by doing the opposite. It focused on an extraordinarily well-executed text-only product, making it work reliably in India and rural regions and becoming “the most reliable text message product in the world.” Once the network existed, voice and video could be layered on. The core lesson was that WhatsApp solved an actual customer problem, while Hangouts addressed a Google architecture and organizational problem.

Singhal took three lessons from the experience. First, “inside the building drama and trauma” does not automatically translate into user need. Second, large companies have trouble sticking with products that do not look successful immediately. Third, product quality is less about the first version and more about the rate of improvement.

He connected that third lesson to other Google products. The early Android phone, he said, looked like a “doorstop” and was “freaking horrible.” But Android improved quickly. Chrome’s key organizational innovation, in his telling, was shipping every six weeks while Firefox shipped every quarter and Internet Explorer shipped every year. Android shipped every quarter while iOS shipped yearly. The decisive capability was not initial polish; it was iteration speed.

That point connects directly to product work with AI tools. If AI lets teams build and test faster, then the most important product skill is not producing a perfect document or first draft. It is knowing what problem is real, validating quickly, and improving faster than competitors or incumbents can.

A question about forward deployed engineers opened a specific comparison. Singhal defined a forward deployed engineer as a technical person who goes into a customer environment, solves an actual customer problem with the product, and brings expertise, standards, and lessons back into the core product. He acknowledged that this can sound a lot like product management: understand a customer use case, then generalize it into something many customers can use.

Mike Abbott added that, “back in the day,” this was often called professional services. Palantir, he said, had done a “brilliant job” rebranding the role. In early companies, Abbott said, people close to customers often effectively served as product management.

Singhal did not argue that forward deployment is useless. For complex enterprise products with deep customer environments, he said, it remains valuable. But he argued that AI increases the volume and usability of customer signal in a way that changes the bottleneck.

A product person can now wake up to an agent-generated summary of every customer use case that appeared in support chats. They can see summaries of every sales call from the past week. They can synthesize survey responses, complaints, revenue implications, implementation complexity, and fit with the product’s system or brand. A year earlier, Singhal said, that would have sounded like science fiction.

The new constraint is not getting enough information from the field. It is deciding what the information means. AI can collect, summarize, prioritize, and present. The product builder still has to judge whether a request is worth building, whether it coheres with the product’s architecture, and whether the company is being pulled by a real market signal or distracted by noise.

That distinction helps explain his repeated attack on “information movers.” If a role exists mainly to gather and repackage customer data for a decision-maker, agents can erode it. If a person can make the decision — grounded in customer reality, technical constraints, business impact, and product taste — their value rises.

Singhal asked the Stanford room two questions: how many were anxious about getting a job after college, and how many were having fun building things with AI. In his account, essentially the same group raised hands for both. He said he sees the same pattern among executives he works with: high anxiety and high excitement at the same time.

The anxiety, he said, contrasts sharply with the period before mass layoffs, when interest rates were near zero and even average candidates could have many offers. But the older period was not necessarily healthier. People were less anxious, yet many disliked their jobs because they were not building.

The more exposed group, in Singhal’s view, is not the current student who starts their career inside AI tools. It is the mid-career manager, perhaps eight to 15 years into a career, who was “an okay builder” but got promoted during the zero-interest-rate era because they could talk and manage people. These managers may have families, children, aging parents, and little time or appetite to reinvent themselves. If their main expertise is moving information and managing meetings, Singhal expects them to have difficulty.

Abbott agreed and turned it into a broader career principle: staying curious keeps people modern. Those who do not stay curious, he said, “will go” and may not find another job.

Singhal’s advice to students was to translate curiosity into hands-on grit. Being current is not just following the latest tools. It means using them, forming opinions about what should be built, validating those opinions quickly, and developing a founder-like ability to move from idea to test.

He also said that, in what he is seeing from high-quality employers, brand names matter less than they used to. Companies such as Anthropic and OpenAI, in his telling, can tell when someone is learning AI tools just in time for an interview. They can also tell when someone mainly wants to manage. In the environment he described, “there’s no more management” in the old sense; it is “all about building” and being hands-on.

The implication is not that hierarchy disappears completely. It is that management begins with direct contribution. Singhal said experienced people may join high-quality AI companies in seemingly generic individual-contributor roles because they are joining the rocket ship. The conventional advice still applies: if you see the rocket ship, find a seat. Growth creates opportunity, and being inside the fastest-growing, most current environment can matter more than preserving a nominal seniority level.

Nikhyl Singhal expects organizations to become flatter, but not smaller in every respect. He described a “mix shift”: companies remove layers of people who move information while hiring more broadly for people who build, decide, and operate close to the work.

The mechanism is partly technological. Leaders can put agents into meetings, collect summaries, and weigh in without relying on a chain of managers to transmit information upward. AI can surface ground truth better than a slide-deck bureaucracy. That reduces the need for hierarchy whose primary function is packaging.

His critique of modern product process was blunt. When asked what part of modern product management is “bullshit,” he gave two answers. The first was the movement and packaging of information, which he estimated occupies a large share of many PMs’ time. The second was organizational theatrics: large formal meetings, dog-and-pony slide decks, layers of VPs and directors refining materials that originate from an experiment run by a junior employee who may not even be in the room.

Singhal argued that this is how much software has been built in large organizations: not by direct engagement with the core facts, but by ceremonial amplification of them. AI threatens that ceremony because it can gather, summarize, and present what is happening without requiring so many meetings or status rituals. He pointed to a growing trend toward drastically fewer meetings, even gathering only half a day a week, because AI can explain work and expose ground truth more effectively.

The result, if it works, is a more attractive role for people who want to build. Less meeting theater; more direct product judgment. But it is also a more demanding role. Singhal said the leaders in his group are working twice as hard as before, even while having more fun.

A question about Meta’s metaverse investments brought out a more nuanced tension: large companies may need founder-led conviction to build the next platform, but that conviction can also keep capital flowing into efforts that are not working.

Nikhyl Singhal said he admired Mark Zuckerberg’s willingness to drive belief through Meta’s balance sheet, while acknowledging that Zuckerberg does not always get it right and likely would not claim otherwise. His interpretation was that Zuckerberg wanted Meta to become the innovator of the next computing platform. Meta had leveraged mobile and the web, but did not create those platforms. It also was not the innovator of the cloud. The metaverse represented an attempt to own or define the next platform rather than depend on others.

That kind of bet, Singhal argued, cannot be made by consensus. Meta, like Apple in some respects, is more founder-led. Google, in his description, is more reactive and more internally consensus-driven: first solve the inside-the-building alignment problem, then get things out. There is no single right model, he said, but “big unobvious innovation” requires someone to commit capital before the evidence is obvious.

Abbott added the counterpoint: sunk cost fallacy. Large companies, and startups too, can continue because they have already invested years and billions, even when killing the project would be better. He cited Apple’s car project from his time at Apple, saying it was obvious to people outside the group that the project would not happen, yet the company continued spending heavily and hiring heavily for too long.

Singhal then explained why large-company decisions can look irrational from the outside. At the scale of Meta, a billion-dollar business may barely matter. For an individual founder, creating a billion-dollar business would be career-defining. At a giant platform company, Singhal said, an extra billion dollars could look like a “four line change into a ranking algorithm.” To grow 20%, 30%, or 40% from an already enormous base, a company may need to attempt something as large as a car, a new computing platform, or autonomous driving.

That scale problem also explains why startups retain an opening. They can pursue markets that look too small for incumbents until those markets become large. Scale gives big companies resources, but it also makes many promising opportunities appear immaterial.

Singhal described his current work at The Skip as a response to a career problem: technology careers are long, but individual jobs are short. He expects many people now entering the industry to work for 40 to 50 years, possibly longer, because their work is not physically destructive in the way some forms of labor are. At the same time, he said the average tenure at a tech company tends to be two to three years. That implies 15 to 18 jobs over a career.

His conclusion is that a career is not like periods in a hockey game; it is like chapters in a book. The important question is not only whether the next job is good, but whether it sets up the chapter after it. He named The Skip for that idea: the best career advice is to think one move beyond the move currently in front of you.

The same logic shaped his advice to students who want technology jobs. Singhal separated the practical question from the broader purpose of university. Stanford, he said, is not a trade school, and computer science theory matters even when it is not directly used in daily industry work. But for job preparation specifically, he named three priorities.

The first is being modern. Students can differentiate themselves from people in their first decade of work by being current with AI tools and building practices. Brand, he said, is at an “all-time low” as a signal. Someone who has spent six years at Google may be less relevant than a student who is deeply hands-on with current AI tools, because the Google employee may have spent years in meetings and on one internal stack. Employers want people who can use the new tools fluently, push them hard, and form opinions from direct use.

The second is relationships. Singhal said he was not especially social as an undergraduate and later realized how valuable Stanford relationships became. He still stays in touch with about 25 undergraduate classmates, and those relationships brought luck and opportunity in both directions: helping one another, working together, advising, and recovering from setbacks.

The third is a systems programming mindset. Singhal studied systems as a master’s student and described the progression of platforms from assembly language to compiled languages, scripting languages, and now prompted languages. Stacks keep becoming smarter. As construction becomes easier to express through AI tools, the harder question becomes whether something should be built, how it fits, and how to know whether it works.

That is an engineering abstraction skill more than a narrow computer science requirement. In a world where “knowledge is a service” and many things can be built by expression, the key is understanding the system: the company, the product, the brand, the stack, and the consequences of adding something new.

Near the end, Singhal reduced career timing to one principle: the company and environment around you should be growing slightly faster than you are. If the environment is bigger than the person, it pulls them forward. That is part of why people choose demanding institutions and fast-growing companies.

The warning sign is comfort. If someone is the smartest person in the room, pushing everyone else along, their learning may be constrained by the environment. They may still be competent, even dominant, but the setting is no longer accelerating them. Mike Abbott put the same idea more sharply: when a job becomes comfortable, “that’s when you gotta go,” because it means learning has stopped.

Singhal said people should evaluate whether the company, project, or team is moving them forward. If not, they should diagnose whether they are being held back by skill, perception, or lack of courage. The answer determines whether to improve, reposition, or leave.

That advice ties back to his “chapter after the next” career model. The best job is not merely the most prestigious or senior role available now. It is the one that places a person in a growing environment, forces them to become modern, surrounds them with strong peers, and sets up the next chapter. In the AI environment Singhal described, that favors people willing to build directly, operate without much hierarchy, and keep learning faster than their title changes.