One idea from Zero Click SF has stayed with me more than the larger predictions about where search is going.
In the Figma session, Reema Batta distinguished between the needs of a Product Designer and a Creative Director. I attended the event on April 8 and included the example in my recap the next day.
What interested me was the practical consequence for the work: a broad question about a product category can hide the distinctions that make a recommendation useful.
One product, several questions
Take a hypothetical software evaluation. The person using a product every day may want to understand how a task works. The person responsible for a department may want to know how the team will adopt it. Someone reviewing the purchase may need evidence about cost, access, or implementation.
A single product page can contain information for all of them. But a generic explanation can leave each person searching for the part that matters to their decision.
That's the connection I make to AI-search research. If our prompt set only asks for the best products in a category, we're examining a small part of the decision. We may be missing the questions where the product is a particularly good fit, or where the explanation is weakest.
I'd try two briefs
Before commissioning a large content program, I'd choose two real roles involved in the buying process. For each, I'd write a short brief: what are they trying to accomplish, what do they need to know, and what evidence would help?
For an illustrative rollout, one brief might ask how an individual completes a task in the product; the other might ask how a team reviews and approves that work. The first could need a walkthrough. The second could need an explanation of roles, permissions, and handoffs. Those are different pieces of evidence, even when they concern the same feature.
I'd use recent customer or prospect conversations to ground the actual briefs. A job title alone is too thin. Two people with the same title can have very different requirements.
Then I'd inspect the AI answers and the pages already available for each situation. Where is the description accurate? Where does it skip a requirement? Which claims are supported by useful examples? Where does a buyer have to infer how the product would work for them?
The result might call for a new page. It might also reveal that an existing page needs a clearer example, a relevant customer story, or a better route to implementation details. More pages aren't automatically the answer.
Keep the research honest
It's easy to produce a very detailed set of synthetic buyer questions and mistake that detail for knowledge of the market. I would use those questions to organize an investigation, then check them against what people actually ask.
If the distinction between two roles doesn't change the information they need, I wouldn't split the content merely to fill a persona grid. If the distinction changes the proof they need to feel comfortable with the purchase, it deserves a place in the brief.
That's the small, useful exercise I'd bring back from the event: take a page you're about to write and ask which person's question it answers. Then look for the evidence that this is really their question.