Designing for Uncertainty: Product in the AI Era

Four reflections from my first foray into building AI products

Like many of my Product colleagues, I’ve recently entered the world of building AI products. As expected, I’ve noticed a few distinct shifts in how we apply product thinking in this space. While our core principles (user-centricity, outcome focus, and fast feedback loops) haven’t changed, there are certainly new behaviours, considerations and frameworks to adopt. In this post, I’ll walk through some of my observations so far.

Feature ideation & design: from shipping features to shaping behaviour

In AI products, the old habit of ideating discrete features breaks down quickly. What matters more is the behaviour you’re trying to unlock and the outcome you want users to achieve, because the “feature” is often a fluid interaction between model, UI, and user intent. While being outcome-oriented has always been at the heart of product thinking, how users get to their desired outcome using AI products is less clearly defined. PMs and design teams have to shift from spec’ing static functionality to designing systems that guide, constrain, and learn from user behaviour over time. That means spending less time perfecting high-fidelity designs and flows up front and more time prototyping end-to-end experiences, testing how people actually prompt, correct, and rely on the system, and baking in guardrails where the model is likely to go off-script. Creating and applying solid experience guidelines here is crucial, ensuring safety, transparency and trust in our interactions.

Workflow mapping: from linear funnels to human–AI loops

As PMs, we’re generally used to clean funnels and deterministic flows: user does A, system does B, outcome C happens. However, in AI products, real workflows become loops, with humans prompting, the model responding, humans correcting or steering, and the system adapting. This becomes even more critical with agentic AI, where the system is no longer just responding but planning, taking actions, and chaining steps across tools and contexts. Now the “workflow” includes planning, tool use, intermediate decisions, and actions taken by the system on the user’s behalf, often across multiple steps and agents. The shift for PMs and dev teams is to move from mapping happy-path funnels to designing and stress-testing autonomy boundaries: what the agent is allowed to decide, where it should retrieve information from, when it should ask for confirmation, how it exposes its reasoning or plan, and how users can interrupt, correct, or roll back actions when things go wrong. For more on the topic of agentic AI workflow mapping, take a look at my colleague Sophie’s recent post.

Evals: from QA checklists to continuous measurement of usefulness

In classic software, QA and acceptance criteria are about whether the feature works as specified. In AI products, determining whether something “works” is less clear, and model behaviour drifts with data, prompts, and use cases. The shift here is from one-off validation to ongoing evaluation of usefulness, reliability, and failure modes in the real world. PMs need to think about evals as a product surface: what signals actually reflect user value, what bad outcomes matter most, and how quickly can the team detect and respond to regressions? This pushes teams to invest early in lightweight eval pipelines, user feedback loops, and qualitative review, rather than treating evaluation as a late-stage, purely technical concern. As above, workflow mapping is a great way to define where evaluations should be applied throughout the journey, to break them down into more discrete, testable chunks. My colleague Tim recently shared this great article on lean thinking for evals here.

Organisational readiness: from shipping teams to learning organisations

Finally, building AI products isn’t just a product or engineering shift; it’s an organisational one. The old model assumes stable requirements, predictable delivery, and clear ownership boundaries. AI work is messier: uncertainty is higher, iteration cycles are shorter, and the “right” answer evolves as models and user behaviour change. The shift PMs and leaders need to make is from optimising for execution to optimising for learning. That means creating space for experimentation, normalising that some bets won’t pan out, and aligning incentives around insight gained rather than features shipped. Teams that can learn fast, adapt their mental models, and collaborate across product, design, data, and policy will outpace teams that treat AI like just another tech stack upgrade.

My overarching reflection is that product thinking in this space is less about finding the perfect spec and more about designing for uncertainty: making intent explicit, constraining autonomy thoughtfully, instrumenting what “good” looks like, and building teams that can respond when reality doesn’t match the plan.