Building AI Products as Systems of Trust: Alexis Zheng at Mind the Product Chicago
Mind the Product Chicago

Building AI Products as Systems of Trust: Alexis Zheng at Mind the Product Chicago

November 9, 2026/12 min read

The central claim of Alexis Zheng's talk at MTP Chicago 2026 is that data, compute, and ever-better models are no longer what’s holding back AI; trust is. Alexis draws on her experience as the CPTO of G2, a Chicago-based company operating the world’s largest data source for B2B software, and more broadly on her career, which she describes as “building the trust layer of software”.

She starts her talk by asking the audience, "what is a product manager?", before playfully adding, “hold that thought.” Her hope is that, by the end of this journey, they’ve changed their view of the craft. After all, as products and AI evolve together, a PM's job evolves too—now it’s about designing systems that users can trust, she says.

From big data to big compute to trust

Zheng argues that AI is not a disruption at one moment in time, but the culmination of decades of innovation coming together. If the 2010s were the age of big data, then the 2020s are the age of big compute and the direction of her own career reflects this.

In the 2010s, Alexis worked on a generation of AI products where the focus was collecting massive amounts of data and building more powerful neural networks. At the time, data was the constraint, and compute was an afterthought. The guiding belief was the more data, the more powerful the model, and the better it generalises beyond observed patterns to predict the world.

As the 2020s rolled around, Alexis moved on to working on self-driving cars, another form of tech that required extensive data collection. But when ChatGPT arrived, things got flipped upside down. Suddenly, endless amounts of data were readily available, meaning compute was the new bottleneck.

Her next mission was to help companies adopt AI by building compute systems tailored to suit their needs. But she soon found that some of her customers had no good use case to support AI adoption. That was, in her view, an existential moment: data and compute had not really crossed the chasm. There was one last mile, and that was trust. That was the missing part.

In the token economy, value is represented by outputs you trust

If the last generation of the digital economy was attention-based, where views were the commodity and ads were the currency, what we have now is intelligence as the commodity, tokens as the currency, and trust as the true value differentiator.

Alexis explains that the token, symbolising compute, is the unit economics at the centre of a multi-hundred-billion-dollar industry. She mentions Nvidia buying Hugging Face and SpaceX acquiring a coding assistant as examples of token flow. If tokens are a river, these companies just found a way to put cargo ships on it.

But what is trust in this context and does it only apply to human users? Alexis believes that agents, too, need trust signals, which is why a trust layer is emerging everywhere in AI.

“Trust is not about blind faith. It’s really about clear boundaries, it’s knowing when a system works and when humans still have to step in.”

Take the following two stories.

When automobiles first appeared, people actually put horses in front of their cars as backup for when the cars inevitably still backfired, got stuck, or were driven into ditches. A modern-day analogy comes from a warehouse company Alexis once consulted for. It had just put together a fleet of robots and very quickly found it also had to hire a team of humans whose job was, as she puts it, to push the robots along when they got stuck.

In her present role at G2, the company's buyer surveys show the same gap between use and trust:

  • About 60% of buyers already use AI in some shape or form in their purchase journey, but
  • Only 9% say they actually trust the results of AI recommendations.
  • Meanwhile, for 55% of those who’ve bought agents, the expected productivity gain is offset by having to supervise them and redo their work.

What’s missing here, Alexis explains, is the trust layer: a user's ability to trust the models. Without it, the models may keep getting better, but the adoption curve will stay the same. There is a growing gap between frontier capabilities and where enterprise adoption stands, and that gap is costing enterprises billions of dollars. That, she says, is the economic value of trust.

These are her five lessons for building it.

Lesson 1: Think in systems, not screens

Alexis argues that AI products are like an iceberg and the user experience is only the tip. Nevertheless, it’s one of the first places trust is built.

Users no longer need to click through every screen of a mobile app; they can just ask for something in natural language, and agents will use the software on their behalf. As a result, while every application has AI at its centre, the model isn’t the product. The product is what you build around that, and the new product craft is systems thinking.

An example from Uber

Many years ago, Alexis worked at Uber, which she calls "an example of an intelligent system, about a decade before agents existed". When you’re a PM in such a complex system, she says, you can’t design directly for the outcome; you can only design the ecosystem to incentivise the behaviours you want.

That used to be challenging, she admits, because every change you made rippled through the marketplace and could accidentally alter fundamental constraints, creating winners and losers down the line. You might struggle to find enough converting customers, because making a match costs too much time, cost and effort. Or, even if you could, you might struggle to create enough value from those customers because of low repeat rates, high acquisition costs or, as a result, low margins.

But over the years, AI improved this. Uber began using it to detect real-time supply and demand, and to learn a user’s preferences, so they could better predict when the user will convert, at which price point, and on which product.

Every time a new supply unit came online they could reroute the entire system and tweak buyer and rider incentives in real time to create more incremental trips. In her view, the most successful product managers over those years were the ones who leveraged AI and systems thinking to make the unit economics work better.

Lesson 2: Design the harness

What do you do to build trust around failure? Because you cannot fix a probabilistic system such as AI one failure at a time, Alexis believes PMs must also know how to design the harness—whether literal or agentic. The way she learnt that was by working on self-driving cars, which she sees as the physical-world counterparts of agentic AI.

Over the last decade, she watched copilot and autopilot software evolve into almost fully autonomous systems. In 2010, the PM's job in the industry was diagnosis: collect all the failure modes of the car on the road, troubleshoot them, attribute each to the offending stack, and assign it to the right engineering team. Alexis herself once had to manually prioritise a list of hundreds of failure modes for an organisation of AI and AV engineers. Identifying and troubleshooting every single one would take too long, so she could only pick three.

As the car got smarter, failure modes evolved too, becoming harder to identify, troubleshoot, and recover from. The solution was designing for fault tolerance at scale, which in today's language means designing the harness.

These are Alexis' top lessons for that:

  • Perception. No matter how many sensors you have or how good your sensor fusion is, perception will never be perfect. You do not need to identify every single object; the most important thing is to know which objects are vulnerable, so you can exercise caution around them.
  • Prediction. You will never have a crystal ball; if you did, she jokes, you should trade the stock market. Instead you model the entire distribution of likely movements of the agents around you, as well as their reactions to your every move.
  • Epistemic uncertainty. The model knows when it is uncertain. When it goes out of distribution, it degrades its performance gracefully: it slows down, exercises caution, pulls over or, if needed, calls a human for assistance.
  • Latency. Reaction time is critical for everyone involved. After all, she says, a human standing in front of an approaching car is only safe if they or the car can react fast enough. That means the system should be designed for end-to-end latency. Agents are no different: depending on the use case, you have different latency requirements.

Over the years, Alexis believes that agents can take control of more and more of the system, pushing the PM to design at a much higher level of abstraction. Trust is essential, though.

Lesson 3: Design the learning loop

The next thing that builds trust is the learning loop. Humans make mistakes and learn from them, so what if your machine could do exactly the same?

While working with self-driving cars, Alexis’ teams designed what she calls a continuous learning loop:

  1. Miners—for mining data—are embedded on the car, and as the car is deployed they score its every move.
  2. As the car collects more samples, this triggers a complete retrain of the model, with no humans in the loop.
  3. A new version of the software is deployed that is much better and much safer.

That, more or less, is the thinking behind today's loop engineering. An agent starts out with your organisation and makes mistakes at the beginning, like an intern. It collects its own mistakes and turns them into new requirements. With those requirements it designs test suites, so it knows a mistake has been corrected, and then it deploys a new version of the software. As it collects more data, it keeps getting smarter, so each iteration is better and faster than the previous one.

Alexis believes this changes product requirements entirely. A while back, they used to be the bane of a PM’s existence, but today you can design software that writes its own requirements and you just oversee the learning loop. As you accumulate learnings from each real-world encounter and then embed them in the right operational flows, the system can continue improving on its own.

Lesson 4: Build verification that earns trust

“Your loop is only as good as the verifiers that you write at every stage.”

Of course, a solid verification system is crucial to trust. After all, Alexis says, today's bottleneck is not model architecture but experience and evaluation at scale.

In the self-driving industry, her teams built simulators. With one click you could generate infinite scenarios of complex road conditions, so the car could be evaluated and trained in them and, before it ever hit the road, it already had a large body of knowledge.

But what about software buyers? Why should they trust a company to automate their workflow? Alexis maintains that, since AI is a black box, the PM's role is to design systems that earn trust. That’s the thinking behind what her current company, G2, is building next.

How G2 is applying these lessons

For over a decade, G2 built the software trust layer with verified buyer reviews based on real usage, real workflows, and real outcomes. But all that has changed.

Before, buyers extensively researched the software they were interested in, sometimes for months. But now, they use agents to make recommendations or even to decide directly in the workflow.

This hasn’t made buying any easier, though. Buyers are bombarded by identical-looking demos that all seem to have come straight out of Claude as sellers grapple with pressure to offer a better agentic experience than Claude of OpenAI.

The solution for G2, Alexis says, was to introduce agent evals—agents evaluating agents. This uses agentic AI to show buyers how an agent actually behaves: whether it follows policy, whether it really completed the task, and what failure modes to look out for. How they did it:

  • G2 built simulated companies with support, sales, legal, and finance departments, each with their own data, policies and tools.
  • The agents, however, get real tasks, based on real enterprise operations data.
  • The agent runs through the work, every interaction is captured as a trace, and the trace is graded against a set of predefined rubrics.

If buyers are losing trust in the software purchasing process, this is one way to repair that rupture.

Lesson 5: Build at the frontier

Finally, Alexis’ fifth lesson for PMs is becoming competent in building at the frontier. G2, for example, found a new class of agents emerging that is completely headless and built for the agentic age. Their breakthrough idea, she explains, is to stop having humans use software at all and let agents do the work for them. Incumbents are innovating too: Salesforce, for example, recently unveiled a headless experience of its own.

Alexis paraphrases Andrej Karpathy by adding that, with all the capabilities coming onto the market, a lot of software will probably eventually get rewritten. Though it’s difficult, she says the prize is that every time you ship a product that would not otherwise have existed and that fundamentally changes the world, you will look back to find that you also shipped a better version of yourself.

A word on PM-market fit

Alexis closes out her talk by returning to her earlier question, “what is a product manager?”. She concludes the concept of product-market fit can be extrapolated to a PM–market fit.

Rather than defining the what and then figuring out the how as they go along, PMs can now use agents for much of that while they themselves design systems, harnesses, and learning loops. However, without trust, adoption will stay flat no matter how much models improve.

Zheng's message to PMs is to move up a level of abstraction: stop defining every feature and instead design the systems that let agents act reliably and learn from mistakes, then prove that they can be trusted.