Why your product needs an AI product manager, and why it should be you

How does a small AI team choose what to build when its remit stretches across government? James Lowe introduces the Incubator for AI as a team created to deliver public good through AI experimentation and product building. He frames the opportunity as a government spending over £1 trillion to serve over 70 million citizens. The team’s products range from frontline services to the Prime Minister’s meetings; choosing where to invest is an essential part of the work.

Cheaper software makes that choice more consequential. Lowe opens with an argument from Andrew Ng: coding assistants reduce the cost of prototypes, while AI capabilities make previously impossible products possible. Together, these changes increase demand for people who can decide what to build. As implementation becomes cheaper, product judgment becomes more valuable. AI expertise belongs in that judgment, whether the person exercising it is a product manager, an engineer, or a founder.

Conventional product management balances three questions: is the product viable for the organization, feasible with the available technology and skills, and desirable to users? The user question is fundamental: what problem does the product solve? A product manager must find a path that satisfies all three, rather than optimizing one in isolation.

AI complicates each part of that balance.

These concerns meet in a more basic question: is the proposed AI capability possible at all? Data proficiency, evaluation, and an understanding of probabilistic behavior therefore become part of product decision-making, alongside the existing product skill set.

There are two routes into this responsibility. Product managers can deepen their AI knowledge; AI engineers can bring their technical understanding into product decisions. Neither route requires creating a separate job title. What matters is that someone on the team actively reconciles business needs, technology, users, and AI uncertainty. Lowe connects this to Bret Taylor’s discussion on Latent Space about the power of combining product and engineering in fewer people. The AI product manager is a mindset the team needs, not necessarily another person in the approval chain.

Consult began with an apparently natural AI application: analyzing public consultation responses. Government consultations gather input on policy changes, often through free-text surveys; legal duties to consult apply in specified circumstances. Lowe describes hundreds of consultations a year, some attracting hundreds of thousands of responses. Analyzing them can take months and cost millions of pounds.

There was already precedent for using NLP techniques such as BERTopic for consultation analysis. With pressure to deliver, the team went straight into building a product around those techniques. Real-user testing then exposed inaccurate and inconsistent results. The implementation did not meet user needs and, in Lowe’s assessment, would not have met the required legal threshold. Existing precedent had not established that this particular capability was good enough for this particular task.

The team reset the work around the AI capability:

1. Obtain data from real users and generate synthetic data for evaluations.
2. Optimize the capability against those evaluations.
3. Test the resulting outputs with real users.
4. Package the capability as Theme Finder, which the team subsequently open-sourced.

Lowe reports output comparable to human work, produced 1,000 times faster and 400 times cheaper. Those are his reported results, not a general performance guarantee: the talk does not specify the benchmark conditions, and the published Consult evaluation does not establish the same speed multiplier.

The more consequential discovery concerned the workflow. Evaluating the pipeline exposed the points where human input added value. That changed the product the team subsequently built: the right interface depended on knowing where people needed to intervene. Capability evaluation determines both whether a product can work and what product should exist.

The team then moved into evaluations on live consultations and published results. Lowe says one of those evaluations reached the BBC front page. The lesson is to resolve AI uncertainty early through evaluations and tests with real users, before an unproven capability becomes the foundation of a finished interface.

Minute, the team’s transcription and summarization tool, started with a different uncertainty. Frontline staff were spending time on paperwork instead of the work they wanted to do, and secure transcription could help. Useful transcription services already existed through AWS and Azure. The central question was how to turn that capability into a streamlined, frictionless experience.

There were many plausible AI features and little certainty about which would help. Coding assistants made it practical to build broadly, try features with different user groups, and observe the results. The second half of that process mattered just as much: strip back to what worked. Lowe also found that using coding assistants reduced sentimental attachment to implementations, making them easier to delete.

The demonstrated exploratory interface begins after a user has recorded a meeting and is ready to generate a summary. It exposes several different ways to shape or use the output:

• Summary templates: multiple formats to support experiments with different groups.
• Agenda input: optional meeting information for users who wanted the summary to follow an agenda.
• AI edit: free-text instructions for changing the meeting output.
• AI chat: a separate way to ask questions about the meeting.

Behind the interface, AI also predicted speaker names and produced citations back to the original transcript. There was substantial functionality, but much of it did not translate into value for users.

Testing revealed that many users found the interface overwhelming or complicated, and were not using its features. Testing across groups also revealed a promising audience: probation services. That discovery gave the team a concrete basis for narrowing the product.

The team focused on probation users and worked with Justice AI, the Ministry of Justice’s AI team, to create Justice Transcribe. That focus made several interface decisions straightforward.

The last change was still an experiment. Users strongly wanted edit and chat brought together, but the demonstration did not show a completed replacement. The team had removed the confusing distinction while investigating how to combine the functions.

Lowe reports very positive feedback, with Justice Transcribe participating in an ongoing comparison against other tools to determine their impact. That is evidence of a promising direction, not a completed finding of superiority. The broader method is to experiment widely with real users, then use what those experiments reveal to simplify the application.

The transcription work also extended to another setting in the team’s remit: prime ministerial meetings. Lowe describes a recent meeting as the first Prime Minister’s meeting to be transcribed and summarized using AI, with the team’s tool providing that capability. The probation focus was therefore one valuable application of the underlying work, rather than its only possible use.

Redbox began with the physical red boxes used by government ministers. Private offices collect, collate, and summarize paperwork, submissions, and decisions for those boxes. Digitizing that workflow looked like a natural AI application, and the idea won a hackathon run by Evidence House, a sister team. The Incubator for AI turned it into a full product.

Real users wanted something simpler above everything else: secure chat with a large language model. In the period Lowe describes, enterprise access to such tools was less common, especially in the civil service. People knew what ChatGPT could do, but could not put their work information into it. Redbox’s second incarnation therefore aimed to provide the easiest and cheapest way for civil servants to chat securely with an LLM.

That direction opened another opportunity. Other Incubator for AI products made government-specific data easier to access. Parlex, for example, focused on parliamentary and legislative data, but these products had their own interfaces. Redbox could provide a common chat interface for tools that otherwise required separate destinations. Its third incarnation became a client for the team’s tools and data.

Lowe reports that Redbox attracted thousands of Cabinet Office users within weeks of launching secure chat. That adoption supported the shared-client decision: the team had an interface people already used, through which it could make additional capabilities available.

Two external developments changed the calculation again. First, Microsoft’s Copilot Chat announcement put free enterprise chat into the competitive picture for a government with substantial Microsoft enterprise usage. The relevant offering was free commercial chat with enterprise data protection, distinct from paid Microsoft 365 Copilot; the announcement also added metered agents. Second, Anthropic’s Model Context Protocol provided a standard for connecting AI applications to tools and data.

Together, those changes weakened the case for treating Redbox as either the main route to secure LLM chat or the exclusive interface to the team’s tools. The team shifted investment toward MCP so those tools and data could be accessed through multiple clients. Lowe names Redbox, Copilot Chat, and enterprise offerings from Anthropic and OpenAI as intended access routes. This was an investment direction, not a claim that every named integration was already deployed.

Redbox remained valuable. At the time of the talk, Lowe described it as a main route to secure LLM chat for many people in the Cabinet Office. The pivot changed its strategic role without making its existing utility disappear. A product can still serve users while changes in the market and technical standards require the team to rethink where it should invest next.

The three case studies rest on a prior requirement: someone must exercise product judgment with enough AI expertise to understand the uncertainties. Consult puts capability evaluation first; Minute explores features and then cuts back; Redbox changes direction as demand and infrastructure evolve. These are connected responsibilities, rather than independent recipes.

Resolving the biggest uncertainty first, listening to users, and testing features are longstanding product practices. What changes with AI is the environment in which they operate. Establishing whether a capability works requires additional experimentation and evaluation. Cheaper implementation makes it practical to explore more features and easier to discard them, while uncertainty about what makes an AI feature useful remains high. Rapid ecosystem changes can then alter the value of an entire product direction.

Adopting the AI product manager mindset means taking responsibility for those decisions alongside the implementation: deciding what evidence is needed, what users actually benefit from, and when the product’s direction needs to change. That responsibility is available to the engineer as well as the product manager.