Why Does AI Need Product Management, Not Just Project Management?

AI implementations often begin before users fully understand what the technology makes possible. Managing AI as a product creates a process for learning what users actually need, rather than simply delivering against requirements defined at the beginning of a project.

More than 40 years ago, one of my professors at Wharton, David Ness, taught me something about building technology that has stayed with me throughout my career:

You can build exactly what a user specifies and still build a system they find worthless.

The problem isn't necessarily poor requirements gathering. Often, users simply can't tell you exactly what they need until they can see it, use it, and react to it.

Ness called his approach Middle Out Design.

The idea feels particularly relevant today as organizations begin building AI into their businesses.

The Limits of Requirements

Traditional systems development puts considerable emphasis on requirements.

Ask users what they need. Document the requirements. Design the system. Build it. Test it. Deploy it.

There is nothing inherently wrong with that process. The problem is the assumption underneath it: that users can adequately specify what they need before they experience the system.

Sometimes they can.

Often they can't.

A user may be perfectly capable of describing the problem they are trying to solve while being much less capable of specifying the best solution.

That distinction becomes particularly important when the underlying technology introduces capabilities the user has never experienced before.

Middle Out Design

Middle Out starts from a different premise.

Understand the problem you're trying to solve and enough of the larger direction to begin building. Then build enough of the solution to make it tangible.

Put it in users' hands.

See how they actually use it.

Learn what works, what doesn't, and what they now realize they need.

Then build the next iteration.

Short iterations are generally better because they shorten the distance between assumption and learning.

This isn't development without direction. And it isn't an argument against requirements.

It's recognition that some requirements can only be discovered through use.

The act of building the system generates information necessary to design the system.

AI Makes the Specification Problem Harder

I've been thinking about Middle Out a lot as companies begin implementing AI.

AI makes the requirements problem even harder.

We're asking people to define workflows around capabilities many of them have never experienced.

Imagine asking someone to specify exactly how they would use generative AI before they had ever interacted with it. They could describe their existing workflow and the problems with it. But how could they fully specify a new workflow built around capabilities they didn't yet understand?

This is one reason AI experimentation is so important.

The purpose of an early AI implementation isn't simply to prove that the technology works. It is also to learn what the organization should build around it.

Users see possibilities they couldn't previously articulate. They discover things they thought would matter that don't. New requirements emerge. Workflows change. Occasionally, the original problem itself gets reframed.

That learning isn't evidence that the initial project failed.

The learning is part of the implementation.

Project Management and Product Management Solve Different Problems

AI implementations still need good project management.

They need budgets, milestones, integration plans, security reviews, accountability, and disciplined execution.

But project management and product management optimize for different things.

A project asks:

Are we delivering what we agreed to deliver?

A product asks:

Are we solving the right problem, what are users actually experiencing, what are we learning, and what should we build next?

Or, put more simply:

A project is optimized to deliver what you specified.

A product is optimized to learn what you should build.

AI needs both.

But when an organization treats an AI implementation exclusively as a project, it creates a risk: the team can efficiently deliver exactly what was requested without discovering whether something different would create substantially more value.

Learning Is Part of the Implementation

The rapid evolution of AI makes this way of thinking even more important.

The first version doesn't have to answer every question. In many cases, it can't.

It needs to be good enough to generate the next set of questions.

Build. Use. Learn. Refine.

That was the logic behind Middle Out Design when David Ness taught it to me more than four decades ago. I think it is even more relevant when building AI systems today.

With AI, learning isn't something that happens after implementation. Learning is part of the implementation.

We used this exact approach to build our custom AI product photography system. Some of the most important capabilities in the system today weren't in our original requirements because we couldn't have known we needed them until people started using it.

That's the example I'll explore next.