I have been thinking about where AI adds most value in the product development process, where it is useful and where it makes things harder. Also considering the use cases where you ‘build for AI’ or ’embed AI’ in products and services. How is this changing the way we think about the product org, how we build product teams and how we deliver value?

There is no doubt that this technology now has a profound impact on the entire product development lifecycle, on resourcing and culture.

I have recently spoken to a few product managers in the market, exploring the role of ‘Discovery’ in product. The consensus was that discovery and synthesis are difficult to do well, and AI does not make it easier. If product managers want to do it properly, they often feel like the only person in the company making the case for a solid discovery process, working to get the choices right while everyone else wants to get on with building or selling. The sales organisation wants to know the margin before a single customer need has been discussed. The engineer wants a POC in production as soon as possible. Many people ask why you ‘can’t just automate it and get AI to write requirements’.

If you are a product manager, your job is to make sure the customer (not the technology) has the clearest voice in the room. That can slow the process down in the short term, but it is what protects the commercial return over the life of the product.

Here are my thoughts on the topic.

The best teams care about outcomes more than titles

If we go back to basics (before we start on tooling), I think it’s worth reflecting on how to best structure product teams and orgs in the age of AI. The teams I have seen do product well, the ones that successfully take services and products to market in the current environment, are those where titles matter less than the outcomes the team delivers.

Sit with this one. Imagine a team where the GM of product sits in customer interviews and picks up enough code to help prototype, then plays it back to customers to validate the thinking. Where the Head of Engineering gets into the ethics and data privacy work, so that what they design is compliant and does no harm to the stakeholders involved. Where engineers learn human centred design, so they understand how their technology choices land with different types of users, and how to work within the constraints of human cognition and individual need.

That diversity and crossover of skills is where the magic happens, and where great products and services emerge. This is especially true if you are designing anything with an AI component.

A good discovery process covers five things

Inline with the theme of ‘revisiting the foundations’, I’d also point out what makes a good discovery process, to help us decide what to build and how to go about it.

Many successful product organisations have built teams to assess all following domains: desirability, viability, feasibility, usability, and ethics*.

No single person in a product team is accountable for all five. All five need addressing for a product to actually turn into billed revenue. This leaves us with an important task: to build a product team diverse enough, and capable of collaboration, to cover all of these domains.

Here is an example. Take a new online banking feature that tags your expenses automatically and returns a monthly summary with budget recommendations.

Desirability. Do customers want this? Which ones do, and which ones actively do not?

Viability. Should we build it, given the business we are? What does it do to cost to serve and margin? Can the sales team sell it?

Feasibility. Do we have the technology, skills, data, and architecture to build it?

Usability. Can a customer understand why a transaction was tagged the way it was, and act on the recommendation without help?

Ethics. What happens when we send budget advice to someone already in financial difficulty, and what have we told them about how their transaction data is used?

That is a lot of work to do before you build anything. So where does AI most help on this journey? And how do we go about introducing it?

Synthesis is expensive. Start there.

When assessing desirability of a service or a product, most customer-centric organisations would place high value on customer insights, interview data and behaviour. Many organisations have processes to gather this data, often across multiple streams, from different parts of the business. To synthesise this data successfully, reading across thirty customer conversations, holding the patterns in your head, separating what people said from what they meant, and arriving at an opportunity worth pursuing takes real cognitive effort.

It is expensive work. It is also a real taught skill and a process. Many organisations never give their people the capacity to do it properly. The interviews get done and the notes get filed, and the insight never reaches engineering with enough clarity to set a direction. So, engineering builds it their own way, without the insight, based on what they judge to be best practice.

That is the gap AI has the potential to partially close. Teresa Torres, who wrote Continuous Discovery Habits (great book by the way!!), describes teaching Claude to do customer interview synthesis and finding it learned faster than the humans she had trained over years. The research she points to suggests AI raises the floor for novices and the ceiling for experts. In other words, your least experienced product person gets to a workable standard sooner. Your most experienced one gets more range and can make a massive impact.

Don’t let AI take over your customer relationship

The aspiration for most businesses building stuff if to build ‘loveable services and products’. By that I mean products designed so closely around the needs of the people using them that they feel effortless, addressing the need at hand without adding cognitive load. Loveable products create real, enduring, sustainable demand which is a pre-requisite to revenue and margin growth. There is no shortcut to this.

AI can synthesise the conversation with customers like we explored above. It cannot have the conversation on your behalf. If you were thinking about outsourcing customer interviews, sales or support function to AI, don’t. You might get less bias, but you lose is the relationship, and the unprompted aside at minute forty that turns out to be the whole insight you build your service on.

That proximity to customers is what good product teams need to be designed for. Practically, that means customer interviews happening frequently (or having great feedback loops across the business), recorded, and made available for analysis, with the privacy rules and policies in place to make that fully transparent, consented, safe and lawful. Connecting that interview corpus to an MCP service for synthesis turns a filing cabinet into a living source of insight for product development. This is where a well architected AI solution can be a huge asset.

Someone still has to make the choice

As AI accelerates development and production, the decision about what to build becomes the point of differentiation between teams. Faster delivery, using modern technology and AI, raises the cost of choosing the wrong thing. So you better make sure you choose right…and choose your product leaders wisely.

The temptation is to skip the thinking, stand up a POC, and ship it straight into production. That is exactly when the thinking matters most, because you can now be wrong at far greater velocity and end up with a lot of wrong things to support which is expensive. The pattern shows up most often in siloed organisations where IT or engineering is left to set the product direction on its own. It all comes back to culture…

So keep talking to customers and build an inclusive, diverse culture where cross-functional teams thrive and you will build amazing, lovable products. That is still the part no tool or AI will do for you.

References:

• (*) The first three come from IDEO U. Usability joins them in Marty Cagan’s four product risks, set out in Inspired. Ethics is an addition for the age of AI, and I would argue it is no longer optional.