← All AI Engineer talks

AI Engineer World's Fair 2025

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

Read the talk

Choosing what to build when AI makes building cheaper

Government projects Consult, Minute, and Redbox show how early evaluations, broad feature experiments, and changing infrastructure reshape AI product decisions.

From a talk by James Lowe

From frontline services to the Prime Minister’s meetings

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 by 10 Downing Street to deliver public good through 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.

Andrew Ng post stating that software prototypes are becoming cheaper, demand will increase for people who decide what to build, and AI product management has a bright future.
Andrew Ng links cheaper software prototyping to demand for people who can decide what to build.
0:170:27
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

0:17 · section reference included

AI adds uncertainty to ordinary product decisions

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.

AreaProduct questionAdded AI concern
BusinessIs it viable?Tolerance for experimentation and failure
TechnologyIs it feasible?Evaluation and performance monitoring
UsersIs it desirable?Probabilistic outputs, guardrails, and human involvement

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.

2:152:25
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

2:15 · section reference included

Consult: validate the capability before building around it

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.

5:085:24
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

5:08 · section reference included

Minute: explore the interface, then remove what does not help

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.

Slide showing the Minute name beside a magenta notebook icon, with “Go wide with features” below.
Minute: “Go wide with features.”

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.

8:008:10
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

8:00 · section reference included

Justice Transcribe: a narrower audience needs fewer controls

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.

Exploratory Minute interfaceJustice Transcribe change
Multiple summary templatesRemove the picker for one user group
Optional agenda inputRemove an option these users did not need
Separate AI edit and AI chatRemove both while exploring a combined feature

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.

10:5511:09
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

10:55 · section reference included

Redbox: follow demand from paperwork to secure chat

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.

Slide titled “The evolution of Redbox” lists three incarnations: digitise the ministerial redbox; the easiest and cheapest way to securely chat to an LLM; client to access i.AI tools and data.
Redbox evolves from digitising the ministerial redbox to a client for i.AI tools and data.
12:2312:29
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

12:23 · section reference included

When the ecosystem changes, the interface strategy changes

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.

14:5315:11
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

14:53 · section reference included

Familiar product principles under different conditions

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.

16:2416:36
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

16:24 · section reference included

Resources

From the talk

Updates since the talk

Read the complete timestamped transcript
  1. 0:00

    [upbeat music] Hi, everyone.

  2. 0:17

    Thanks for that welcome. Uh, as you just heard, my name's James Lowe. I'm head of AI engineering at the Incubator for AI. We're a small team of experts, uh, in the UK government.

  3. 0:27

    We were created by [REDACTED:location_address] to deliver public good using AI, and we do that via experimentation and product building.

  4. 0:37

    The UK Government delivers, uh, for its citizens. It spends over a trillion pounds delivering for its over 70 million citizens. So there's a lot to play for. At the Incubator for AI,

  5. 0:50

    uh, we deliver products that, uh, uh... a wide range of products, all the way from frontline services, all the way up to the Prime Minister's meetings.

  6. 1:04

    This remit is very wide, uh, and so we've had to get quite good at deciding what we should build, and that is what I'm here to talk to you about today.

  7. 1:16

    I'm gonna start with a post from Andrew Ng.

  8. 1:19

    He says, "Writing software, especially prototypes, is becoming cheaper. This is not just because of AI coding agents and assistants, but also because AI features in products, uh, make the previously impossible possible."

  9. 1:35

    He says, "This will lead to increased demand for people who can decide what to build.

  10. 1:41

    AI product management has a bright future." In this talk, I'm gonna build on this post, and I'm gonna make the case for the AI product manager. I'm gonna argue that AI expertise is really important for this role.

  11. 1:55

    I'm gonna deliver three hard-won lessons from the Incubator for AI.

  12. 2:00

    So I hope that whether you're, uh, a product manager, whether you're an AI engineer, or whether you're a founder, uh, there's gonna be a lot for you to learn from these lessons and help you build great AI products.

  13. 2:15

    Before I talk about AI product management, I'm gonna quickly recap product management. This is an extremely rich field, so I'm only gonna skim the surface here.

  14. 2:25

    Product management can be thought of as the intercept between these three important areas. We have the business. Is your product viable? For example, is it going to be profitable?

  15. 2:36

    We have the technology. Is your product feasible? For example, do we have the right skills on the team? And we have users. Most importantly of all, is your product desirable?

  16. 2:47

    What problem are you solving for your users? A product manager sits at the intercept of these three areas and has to balance them all to find the right path forward for the product.

  17. 2:58

    Then AI comes along and makes the whole process a bit more complicated and a bit messier.

  18. 3:03

    It intersects with each of these areas in slightly different ways. For example, for the business, is your business happy with the fact that for AI products, a higher amount of experimentation, uh, is needed, and there's a higher chance of failure?

  19. 3:18

    For technology, how do you evaluate and monitor the performance of your AI?

  20. 3:23

    And for users, how should you handle the probabilistic nature of AI? In particular, will it work for your users? What guardrails do you need, and how do you build human-in-the-loop?

  21. 3:33

    And for AI products sitting right in the middle of all of this, we have a big question. Is what you're doing even possible?

  22. 3:40

    An AI product manager has to resolve all of these different areas to find the right path forward.

  23. 3:47

    A lot of the existing product manager skills- skillset is still very important, but now there is an increased importance in things like data and AI proficiency. AI product managers need to understand the importance of data, the necessity of evaluation, and how to deal with the probabilistic nature of AI.

  24. 4:08

    Whether you're, uh... What, what that essentially means for you is, uh, if you're a product person in this room, if you're a product manager, it's the importance of upskilling in AI.

  25. 4:17

    But what it also means is if you're, uh, an AI engineer or someone more technical, that actually that is a good background also to go into the product manager space as well.

  26. 4:27

    And just to be clear, when I talk about the product manager space, I actually think of this as more of a mindset than like a specific role you need on your team.

  27. 4:34

    What's really important is that you have someone on your team that is grappling with these four areas in order to find the path forward.

  28. 4:42

    As Brett Taylor said on a recent episode of the Latent Space Podcast, "There is a lot of power in combining product and engineering into as few people as possible.

  29. 4:51

    Few great things have been created by committee." And that's exactly the point that we're stressing here.

  30. 4:56

    So I hope you feel, uh, excited by the prospect of, of adopting that pr- AI product manager mindset, and the question now is what lessons can you learn from the Incubator for AI?

  31. 5:08

    The first lesson is gonna come from our project called Consult, and it's gonna be all about evaluating AI early. Every time the government wants to undertake a really big policy change, they need to and want to get input from the public, and in fact, they have a legal duty to do so.

  32. 5:24

    They do this via consultations, which are essentially large, uh, surveys with free text responses. They run hundreds of these a year, and some of these attract hundreds of thousands of responses.

  33. 5:38

    Analyzing these responses can take months and cost millions of pounds. This is a prototypical use case for AI. But when we started this project eighteen months ago, we weren't sure exactly what path to take.

  34. 5:51

    You see, there was already precedent for using natural language programming, uh, techniques such as BERT Topic to analyze consultations, and we were under a large amount of pressure to start delivering.

  35. 6:03

    So we made the mistake of going straight into product building mode.

  36. 6:07

    What we did is we built a product around those existing, uh, techniques. Uh, but what we found is once we started testing with real users, we found that the results were, uh, inaccurate, they were inconsistent, and they not only didn't meet user needs, but wouldn't have passed the very high legal threshold that we needed to pass.

  37. 6:27

    So we went back to the drawing board and instead prioritized the AI capability first.

  38. 6:32

    We got data from real users and generated synthetic data to create evals, which we optimized against, and then we started testing the outputs as well with real users. And we developed that into a package which we call Theme Finder, which has now been open sourced so other people can benefit from it.

  39. 6:50

    What we found was that the output of this package was not only comparable to what humans were doing, but it was a thousand times faster and four hundred times cheaper.

  40. 6:59

    Most importantly of all, by prioritizing the AI capability, what we found was the key points in the package, in the pipeline, where human input and human-in-the-loop was really valuable.

  41. 7:11

    That meant the product that, the product that we then went on to build was actually different from the one we originally envisioned. That shows that starting with the AI capability and getting that right not only means you don't waste time building something that's not possible, but also don't waste time building the wrong product.

  42. 7:29

    We've now taken this, and we've been evaluating it on live consultations. Uh, and, um,

  43. 7:37

    it leads us very nicely to our first lesson, which is resolve AI uncertainties early on with evaluations and tests with real users.

  44. 7:47

    With that, with those live consultations, we've been creating, uh, evaluations which we've actually published, and our first one of those even made its way onto the BBC front page.

  45. 8:00

    I'm gonna take us on to another product now for our second lesson. That product is our AI transcription tool called Minute. And, uh, the lesson's all about going wide with features.

  46. 8:10

    There are many use cases in the government where secure AI transcription and summarization could be transformational. There are many places where frontline staff, for example, are spending time away from the job that they want to do, to do, uh, administration and filling, filling in paperwork and forms, for example.

  47. 8:31

    There's also, uh, very good existing off-the-shelf solutions, such as the AWS and Azure transcription services. So for this product, the question was more about how do you create a, a streamlined, frictionless experience for users, uh, that gives them this capability?

  48. 8:55

    When we were exploring the possibility of this space, what we found was, um, we thought there was lots of ways that AI could help by developing AI features that could, um, help the user get access to this experience.

  49. 9:08

    But there was a lot of different ways you could do this, and there's a lot that was quite uncertain.

  50. 9:13

    We also knew that AI could help us build those features really quickly with AI coding assistants and tools. So what we ended up doing is going extremely wide and trying quite a lot of features with different groups of users and seeing what worked and what didn't.

  51. 9:27

    The important thing is, after that point, we then stripped back and focused on what actually worked. One of the benefits of using AI coding assistants to make those features as well is that you don't have the sentimental attachment to them, so it makes it much easier to strip them out again afterwards.

  52. 9:42

    I'm gonna is- illustrate that point, uh, by showing an example of what the tool looked like when it had lots of features and then when we stri- streamlined it down.

  53. 9:50

    Uh, so here the user's already recorded their meeting, uh, and they've been taken to this page to, uh, help them generate the summary of them. You see at the top, there's, like, the ability to choose lots of different templates because we had different users we were experimenting with.

  54. 10:03

    Some of our users seem, seem to want the, uh, the output to follow an agenda from the, from the meeting, so we gave them the option of inputting that agenda information.

  55. 10:13

    At the bottom, we had two different AI features. We had an AI edit button, so they could use free text to, uh, edit the output of the meeting, but we also had AI chat, so they could ask questions of the meeting.

  56. 10:25

    And this doesn't touch on some of the AI that's happening behind the scenes, such as automatically predicting who the speaker names are and also doing citations back to the original transcript.

  57. 10:35

    It's no surprise that when we were testing this with a lot of our users, they found it a little bit overwhelming and a little bit complicated, and in fact, many of them weren't even using these features.

  58. 10:47

    We also found, because we were testing with different groups, a specific group that there was quite a lot of value of pursuing with, which was the probation services use case.

  59. 10:55

    So what we did next is we focused in on that use case, and then we streamlined the app down. And what we ended up with is with this Justice Transcribe, and we built this in collaboration with Justice AI, who's an AI team in the Ministry of Justice.

  60. 11:09

    As you can see, it's a lot simpler. Because we're focusing on one set of users, we didn't need to have the template picking option. These users didn't need the agenda option, so we could strip it out entirely.

  61. 11:22

    What we found with the AI edit and the AI chat feature is an overwhelming amount of pressure to merge them into one feature. So we've taken them out, and we're experimenting heavily so that there's not that same confusion.

  62. 11:34

    We've been getting extremely positive feedback from users with this, and we're currently taking part in an evaluation where we're, we're being compared to other, uh, tools in this space to work out which ones are the most impactful.

  63. 11:47

    But I hope this illustrates the point and the lesson that we're making here, which is experiment hard and go wide with lots of features. Lean into that uncertainty of what is...

  64. 11:57

    what makes a good AI feature at the moment, but then cut back and s- and streamline the app down.

  65. 12:05

    I thought you might be interested in, in another use case that we were exploring, which was for prime ministerial meetings. Uh, this was actually from a recent meeting, which was the first ever prime minister meeting where AI was used to transcribe and summarize the meeting, and it was done using our tool.

  66. 12:23

    For the final lesson, I'm gonna tell you a little bit about Redbox, and the lesson is all about being ready to pivot.

  67. 12:29

    For those of you that don't know, all of our government ministers carry around a big red box which is full of paperwork, and submissions, and important decisions that they have to make.

  68. 12:40

    Their private offices do a lot of work to summarize, collate, and collect all that information to put it in the red box. Again, this is a prototypical use case of AI, so it was no surprise that the idea to digitize this red box was the winning idea at a hackathon run by one of our sister teams, Evidence

  69. 12:57

    House. This became the first incarnation of Redbox, to digitize the ministerial red box.

  70. 13:06

    We, we took this, uh, winning idea from the hackathon, built it into a full product.

  71. 13:11

    However, what we found when we actually tested it with real users is that the feature that they were most after, the one that they wanted above all else and that they didn't really care about anything else, was just the ability to securely chat with a large language model.

  72. 13:25

    You see, this was over a year ago when enterprise, uh, the ability for enterprises to chat with large language models, uh, was definitely a bit rarer, and particularly in the civil service.

  73. 13:35

    So people were familiar with the value they could get from things like ChatGPT, but they couldn't put their work information into it.

  74. 13:43

    This led to the second incarnation of Redbox, which was to be the easiest and cheapest way to securely chat to a large language model for civil servants. This also gave us an opportunity.

  75. 13:56

    A lot of our other tools, we were experimenting with ways of making government-specific data more accessible and easy to navigate. For example, we had a product called Parlex, which was all about making parliamentary and legi- legislative data, uh, more available.

  76. 14:10

    But we were developing these as independent products with their own user interfaces.

  77. 14:15

    The opportunity we saw is to use Redbox as that interface. Why not bring these tools and products into this, uh, kind of chat interface that we were already creating, and that lots of people already had access to?

  78. 14:27

    That's why our third incarnation was to be the client to access the Incubator for AI's tools and data.

  79. 14:34

    It's worth saying after the second one, uh, the reason that we validated that that was a useful use case, we launched it within the Cabinet Office, and within just a matter of weeks we had thousands of users.

  80. 14:43

    So that's why we knew it would be a useful front, front end for some of our other tools as well. The next thing that happened were two important things.

  81. 14:53

    The first is that, uh, the commercial landscape changed. Microsoft announced that Copilot Chat, their enterprise version of ChatGPT, was going to be free for enterprise Microsoft users, and a lot of the government is an enterprise Microsoft user.

  82. 15:11

    The second thing that happened is that Claude's Model Context Protocol exploded onto the scene, and provided a way of providing standardization for being able to bring tools and data to models.

  83. 15:24

    This meant we had to pivot again. It no longer made sense for us to bank on Redbox being the main way that civil servants would be accessing secure chat with large language models, and it no longer made sense for that to be the only way for people to access our tools and data.

  84. 15:38

    So instead, we've been investing hard in using the Model Context Protocol to bring our tools and data to any client, whether it's Redbox, whether it's, uh, Copilot Chat, whether it's enterprise versions of other tool, like Anthropic or ChatGPT.

  85. 15:55

    So it's worth stressing that throughout that time, Redbox has been valuable, uh, and is still valuable. It's still the main way that a lot of people in the Cabinet Office, uh, are able to access that secure chat with a large language model.

  86. 16:07

    But I hope this lesson shows that things are moving really quickly, and it's really important to evolve and change with it, otherwise you get stuck on the wrong path.

  87. 16:16

    That's why our third lesson is you'll have to pivot harder and faster than ever before.

  88. 16:24

    So let's recap the four lessons we've covered today, and yep, there were four. Lesson zero: The importance of AI product managers, and the fact this is a vital role which requires AI expertise.

  89. 16:36

    Lesson one: Evaluate AI early. Resolve AI uncertainties early on with evaluations and tests with users.

  90. 16:44

    Lesson two: Go wide with features. Experiment hard with new features on real users, then cut back.

  91. 16:51

    And lesson three: Be ready to pivot. You'll have to pivot harder and faster than ever before.

  92. 16:59

    Now, some of you are probably sat there thinking, "How much of this is really new?" And that's a fair question to ask. There's a lot of wisdom within existing product management that feels very familiar to the stuff we're covering here.

  93. 17:12

    For example, the principle of resolving your biggest uncertainties first, uh, has been around for a long time, as is putting your users first, listening to them, and testing features with them.

  94. 17:23

    However, I hope that what these lessons have emphasized is that AI really does make things different.

  95. 17:29

    AI really does, uh, resolving AI's uncertainties really is an important thing you have to do, and is something that is a bit more challenging with the extra need for experimentation and evaluation.

  96. 17:42

    Uh, for lesson two, which we had, which was, uh, going wide with features, AI really does change the landscape. Uh, it makes it easier to go faster with features and have less attachment to them, and therefore you should be doing that, and testing those features, and scaling back.

  97. 17:57

    As well as AI features being new and there being more uncertainty around exactly what makes a good AI feature.

  98. 18:04

    And finally, the AI landscape is changing extremely quickly, which is why pivoting is, is more necessary now than ever before.

  99. 18:14

    So I hope, uh, those lessons have been useful. I hope that you feel ready to step up into that AI product manag- manager mindset, uh, that your product needs.

  100. 18:25

    And thank you so much for listening, and please do check us out. Uh, we're currently hiring. Thank you. [upbeat music]