AI can help product managers interpret customer evidence, investigate alternatives and prepare decisions. Its value grows when the team can return to the sources, understand why a choice was made and revise that choice as the product changes. A useful product workflow connects research to a commitment, then checks what happened after release.
That requires more than a well written feature brief. Support, sales, design and engineering encounter different parts of the same problem. Their observations arrive at different times, in different tools, with different levels of certainty. A product manager needs to establish what those observations mean together before deciding what deserves development time.
This guide follows that work through an illustrative example: a company that sells catalog software to retailers is considering a bulk editing feature. The aim is to show where AI can contribute, what evidence the team needs and which decisions people still own.
Start with the task customers cannot finish
The requests sound similar. A support ticket asks for bulk editing. A sales call mentions spreadsheet uploads. A store manager wants to reuse last season's product selection across several locations.
An AI summary could group all three under a proposed bulk editor. That would be a plausible description of the requests, but an incomplete account of the work. Uploading a supplier catalog, changing prices and applying a seasonal selection have different permissions, risks and measures of success.
The product manager asks for an evidence map before a recommendation. For each observation, it records who was trying to do what, the current workaround, the consequence of failure and a link to the source. Customer statements remain distinguishable from the team's interpretation.
Atlassian's account of product discovery places customer understanding and validation before a commitment to a solution. AI can help assemble the material for that work. A cluster of similar words is a starting point for investigation, not proof that a particular feature should exist.
In this example, the recurring task is preparing seasonal availability across stores. The team can now investigate that specific problem without committing to a general purpose editor.
Make the customer evidence comparable
Product evidence often contains duplication. A customer may describe the same issue in a ticket, a meeting and a message forwarded by an account manager. Counting each appearance as independent demand gives the most heavily documented account disproportionate influence.
Ask AI to group related observations by organization and underlying incident, while preserving the individual sources. Record unresolved identity matches for review. A company name in a transcript may be a prospect, a partner or an example someone mentioned.
Segmentation matters too. A regional administrator managing many locations may need a different workflow from an owner operating one store. Existing customers, lost prospects and internal employees provide useful evidence, but they answer different questions.
For the catalog team, the resulting record separates three needs:
| Customer task | Evidence to investigate | Important distinction |
|---|---|---|
| Repeat a seasonal selection across stores | An observed planning session and the current workaround | Some stores must retain local exceptions |
| Import a supplier's new catalog | Import errors and representative input files | This is an ingestion problem with separate validation needs |
| Change prices across a product group | Pricing roles and approval procedures | This would introduce a different action and permission boundary |
This table is a proposed research aid. It does not establish that any of these needs is widespread. The product manager uses it to choose follow up questions and identify gaps in the evidence.
Give AI a question that could change the proposal
Useful discovery questions have consequences for the design. Can a seasonal selection be reused without overwriting local exceptions? Who is allowed to approve the change? How does a store manager recognize that the proposed result is wrong?
AI can compare interview notes, retrieve earlier decisions and prepare a list of unresolved questions. Give each finding a source and a confidence status such as observed, reported or inferred. These labels describe the evidence, not a model's numerical confidence in its own answer.
Avoid asking the model to invent customer responses. A simulated conversation can help rehearse an interview, but it cannot establish what customers need. Where the evidence is absent, the output should identify what a researcher needs to observe or ask.
Productboard's guidance on discovery with AI describes useful assistance with gathering and synthesis while retaining human judgment over product direction. The catalog team applies that division by asking AI to prepare a research brief, then having a researcher validate the proposed workflow with actual users.
Our guide to AI for market research covers evidence gathering in more detail. Here, the next step is deciding which product response the evidence can support.
Compare approaches before writing the feature specification
Once a problem has a name, a preferred solution can become surprisingly difficult to challenge. A polished AI generated specification may make the idea feel further along than it is.
The catalog team keeps three approaches open: a general bulk editor, a saved seasonal selection and improvements to the existing import process. Each option must explain how it addresses the observed task, what remains unsolved and what new operational burden it introduces.
A saved selection might fit the seasonal workflow well while doing nothing for supplier imports. That is acceptable if the team makes the boundary explicit. A broad editor might serve more tasks but require substantial work on validation, permissions and recovery from mistakes.
Ask AI to critique the options against the same evidence. It should identify a conflicting interview, an unsupported assumption or an overlooked constraint with enough specificity that someone can investigate it. A generic list of advantages and disadvantages contributes little to the decision.
The product manager should also ask what would invalidate the leading option. If customers need to combine selections in ways the prototype cannot support, the team should know that before committing engineering capacity.
Write a brief the next team can act on
After research, the fictional team chooses to prototype a saved seasonal selection with a preview of the affected stores. This is a product decision for the example, not a claim that the design has been validated.
The brief states the intended outcome: a regional administrator can prepare availability for selected stores without repeating the same manual work or silently removing local exceptions.
It also specifies the limits. Prices are excluded. A store outside the administrator's access cannot be included. Changes with unresolved conflicts remain blocked. The preview must show which stores and products would change before the administrator confirms.
Keep the rejected alternatives and their reasoning beside the brief. The team may revisit spreadsheet import later; excluding it now should not erase the evidence behind that request.
AI can draft the document and check it for contradictions. Design owns the usability questions, engineering owns feasibility and technical risks, and the product manager owns the product commitment. If a dependency changes, the brief needs an explicit revision. A new AI summary should not silently replace an approved scope.
Keep decisions current while delivery proceeds
During implementation, an engineer discovers that a local exception can exist at both store and product level. The preview described in the brief is no longer sufficient.
An agent can assemble the affected design notes, acceptance criteria and customer evidence into a proposed change. The useful output is a clear question: should the first release support both exception types, restrict the eligible workflow or wait for a more complete design?
A person authorized to change scope makes that decision. Record the revision, its reason and which previous statement it replaces. Other agents and team members should be able to discover the current decision without reading an entire conversation.
This is where shared context becomes valuable. A design assistant, an engineering agent and a customer success colleague may contribute at different times. They need consistent access to the approved brief and its evidence, with customer information limited to the people and tools that need it.
Delivery dates, dependencies and progress reporting are covered in our article on AI for project management. Product management keeps responsibility for whether the proposed work still solves the intended problem.
Decide how the team will learn from release
Define the review before launch. For the saved selection, useful observations include whether eligible administrators complete the task, whether they correct unexpected changes in the preview and whether stores retain their intended exceptions.
An increase in feature use would not establish that the workflow became easier. People might repeat the action because the first attempt failed. A drop in support tickets could reflect seasonality or a change in customer mix. Pair usage signals with direct observation and clearly defined failure cases.
AI can prepare a comparison of the original assumptions and the available results. Keep denominators, time periods and eligibility rules explicit whenever numbers enter the discussion. Include unresolved cases and negative feedback, even when the overall result looks encouraging.
The output should support a decision: continue the rollout, adjust the design, investigate a failure or stop the feature. Closing that loop turns a feature brief into knowledge the company can use in its next product decision.
Use Swarm to retain the product reasoning
A Swarm Space can give the initiative a shared place for source material, discussion, agent work, outputs and human decisions. A connected agent can help investigate a question or update a brief while retaining a record other authorized participants can review.
For the catalog example, organize the Space around the seasonal availability problem. Keep the current brief easy to identify, connect important conclusions to their evidence and record scope changes as decisions. Give research, design and engineering contributions a clear responsibility so the next participant knows what remains open.
Bring source material through the authorized tools available to the team, and check what the Space makes visible before sharing customer records. Assign responsibility for maintaining the current product brief and reviewing proposed changes.
The result is a product decision that survives the meeting where it was made. People and agents can continue the work with its evidence, constraints and unresolved questions intact, then improve the decision when new information arrives.