World model companies won't say what they're building. The question that asks a product manager to say it.
On September 20, 2026, TechCrunch published an account by a writer who had moderated a panel on world models at the All In conference that week. The piece named Yann LeCun's AMI Labs and Fei-Fei Li's World Labs as the big players in the space, and observed that both "rank pretty low on the trying-to-make-money scale". When the writer pressed Michael Rabbat, a co-founder of AMI Labs and its VP of World Models, on what the company was working on, the answer was, "We’ll talk about it when we’re ready to talk about it." Over email, Rabbat clarified: "We’re still in a research and building phase, so we’re not talking publicly about any product plans or timeline." TechCrunch was careful to be fair about this. AMI is "less than a year old", and the article argues the silence is rational: once a path to market becomes clear, well-funded rivals follow, so it is best to "delay it for as long as possible". The writer called it a "dark forest scenario".
The detail that lingers is a smaller one. On the sidelines of the same conference, TechCrunch spoke to Alex de Vigan, CEO of Physicl, a data supplier to these companies. He knows his data has been useful, the article reports, but not for what. "I wish they would tell us more. We could build more useful data if we knew what they were working on," he said. Nothing in the report describes what happens inside these labs, and secrecy toward competitors is a strategy, not a flaw. But de Vigan's sentence is a precise picture of what building costs when the builder does not know what the thing is for. The article also notes that AMI has "dipped its toe" in manufacturing, biomedicine, robotics and AI software for doctors, and adds, "Surely it won’t pursue all of those". Somebody has to choose among viable directions, and somebody has to make sure the people doing the work know what was chosen. That is a job description, and it is the one behind a question candidates tend to underestimate: "How would you define the role of a product manager?"
Why they ask it
It sounds like a warm-up. It is a calibration. No two companies draw the product manager's boundary in the same place, and the interviewer is listening for which version of the role the candidate has actually lived in. A product candidate reveals what they believe they are accountable for. An engineering manager asked the same question reveals where they think decisions sit, and how much of the product manager's work they quietly expect to do themselves or to resent.
The question is also a test of compression. A person who has done the job for years should be able to say what it is in a sentence, and then defend that sentence. Most cannot, because they have only ever described the job by listing what fills the week.
The trap
There are three common failures, and they share a cause.
The first is the slogan: the chief executive of the product, the voice of the customer, the intersection of business, technology and design. These are borrowed phrases, and an interviewer has heard each of them many times. They commit the speaker to nothing.
The second is the inventory. Writes requirements, runs discovery, maintains the roadmap, aligns stakeholders. This describes a calendar. It does not say what would go wrong if the person stopped turning up.
The third is the authority claim, in which the product manager decides and everyone else executes. It collapses on the first question about an engineer who disagreed.
A strong answer defines the role by the decision it owns and by the cost of its absence. De Vigan is what that absence looks like from the outside: capable, willing, told his work is useful, and unable to make it more useful because no one has said what it serves.
Applying STAR-T
The question is definitional, so the structure bends slightly. A strong answer opens with one sentence, then proves the sentence with a story. Something like: a product manager decides what the team is building and for whom, out of more viable options than it can pursue, and makes sure everyone building it knows the decision and the reason. Then the evidence.
Situation. Our platform team had a capable event pipeline and several groups asking for it: analytics, fraud, and a partner integration. Every request was reasonable. Engineers were building a slice for each, and none of the slices was finished.
Task. Choose one customer for the next release, and make the choice legible to the people doing the work, including the outside vendor supplying our labelled data.
Action. The candidate describes what they personally did. They interviewed each requesting group, found that only the fraud team had a hard deadline and a loss they could measure, and wrote a single page stating who the release was for, what was explicitly not being built, and when the decision would be revisited. They walked the engineers through it, then shared the relevant part with the vendor, who changed the format of what they delivered once they understood the use.
Result. The fraud release shipped first. The vendor's data arrived in a shape the team could use without cleaning, and the half-built slices stopped accumulating.
Trade-off. The analytics group waited a further quarter, and their lead was unhappy about it. A strong candidate says so plainly, and says what they did to keep that relationship: a date, kept.
The story does the defining. It shows a choice among good options, a reason, and the reason reaching the people who needed it.
The follow-up that breaks weak answers
It is usually some form of this: what did you decide not to build, and who did you tell?
A definition made of activities has no refusals in it, so the candidate who gave the inventory has nothing to offer here. The candidate who gave the authority claim has a refusal but no account of telling anyone. Only the candidate who defined the role as a decision, communicated, can answer both halves.
A second follow-up often arrives close behind: where was the engineering manager in all this? The good answer gives the engineering manager real ground, the how and the when and the health of the team, without handing back the question of what and for whom.
There is a useful distinction hiding in the TechCrunch piece. Keeping quiet toward rivals can be sound strategy, as the article argues. Keeping the builders in the dark is a different thing, and a product manager is the person expected to know which silence is which.
Score your answer against the director’s bar
Q: How would you define the role of a product manager?
Bank the story where a choice among good options was made and carried to the people building, then rehearse it aloud until the follow-up holds. Try it free →