How to scope your AI product

Step 1: Accept that it’s not an “AI product”

I have to confess something: I’ve been lying when I say I work on an AI product. I did it to sound cool. I did it to fit in. I did it because AI is trendy.

And ultimately, I did it because it’s easier to say than the truth, which is “I work on a product with features that are powered by AI technology.”

It sounds like a technicality, but lately the distinction seems more important than ever. More than a year into the Generative AI revolution, many of us have watched tech companies speedrun through the stages of AI maturity. From “let’s be cautious” to “let’s throw AI at the wall and see what sticks,” AI strategies have left critics feeling either like AI will change everything or AI will change nothing and rarely something in between. But for those of us working in otherwise-mature design organizations, we’re going about this all wrong. AI is taking up too much of the front half of our sentences.

Working in this space has kept me busy this year. The technology changes fast and new competitors pop up even faster. I’ve been working on this project for almost a year and we still keep pivoting strategies, adjusting our roadmaps, and support an ever-bloating list of feature requests. Understandably, many of us working in this space are learning new things as we go. But I keep forgetting about this one tool I’ve been carrying around in my design toolkit all along: the power of saying “No.”

Scope Creep

After many stagnant years of technology, I enjoy that there’s so much enthusiasm in the air. Everyone is excited to innovate. Everyone has ideas. And it’s setting us up to fall right into the trap of the Scope Creep.

If you think an AI uprising sounds scary, you’ve never stared the Scope Creep straight in the eyes. The Scope Creep preys on design organizations without a clear sense of direction, weighing down products with extra ideas that “might be cool” or that “the design team should look into.” Much like Bigfoot, we don’t really know what the Scope Creep looks like because it lurks in the shadows, avoiding detection until it’s too late. By the time the Scope Creep sneaks up on an unsuspecting project, it’s already doomed, pulled into the quicksand, destined not to get off the ground. The only antidote for the Scope Creep is to define an appropriate scope for your project ahead of time.

Scopes Appropes

Defining the right scope for a project begins with understanding what kind of product you’re working on, and that’s why I no longer say I work on an AI product. When I attended Reginé Gilbert’s talk at ConFig earlier this year, she asked how many of us in the room work on AI products; an overwhelming number of hands shot up, including my own. But let’s be realistic — how many of us work for OpenAI, or in the exclusive circle of companies licensing a proprietary AI model as their product? Sure, those people can say they work on an AI product. But the rest of us, for the sake of responsible design, need to remember that AI is not our product. AI is not our feature. AI is technology. Everyone wants to get in on the buzzword, but, respectfully, it doesn’t deserve this much attention.

If you’ve ever included user stories in your design process, you know that people don’t want to use your product. People have goals and challenges. If your product helps people achieve their goals or eases their challenges, then and only then will they use your product.

This is no different for products that use AI, but the shine of AI has distracted us from what we’re really trying to do: deliver value to our users. If you work in technology then you’re likely biased towards the technology surrounding you. But I assure you that the average person’s goal is not to use more AI. Their goal might be to write a more succinct email or to summarize a meeting they missed, and if an AI model can execute a feature that achieves that goal, then they might use more AI. But if you start your design process under the premise of “adding more AI features” then you’re doing a disservice to your users.

It’s all about value

My product is not an AI product. It’s a product with many features, and some of those features are powered by AI. Specifically, it’s a product that delivers value to users through features that perform better or faster because of an AI model’s strengths.

I’m not trying to redefine the words we use. I just think we need to shift AI to the end of the sentence so we can make more room for the value to come first. As I face a long list of feature requests that risk scope creep, the first step to saying no is to stress test whether the feature provides a desired value for the customer. I recently started to do this by using what I call Value Pyramids.

Product Value Pyramids

What kind of product do you work on, and what’s it really about anyway? If you’re like me and work in a large design organization on a large product that predates your tenure, this might not be a trivial question. As far as you’re concerned the product existed before you, it’ll continue to exist after you, and your job is simply to add, remove, update, and improve its features.

But before you can deliver valuable features, you need to understand why users value the product in the first place. The Product Value Pyramid (PVP) places the value at the base of the pyramid, supporting a customer-driven purpose which keeps the product afloat. You should be able to build a value statement in the format “We are a [BLANK] product that enables customers to [BLANK] so that the customer can [BLANK].” For example, a rideshare company might say “we are a transportation product that enables customers to hire a ride from their phone so that they can get from Point A to Point B on a moment’s notice.”

Don’t feel limited to only one of these statements either. In my own work, some customers see us as an analytics product and others see us as a tech support product. The important thing is that they probably don’t see us as an AI product even if AI-powered features help them analyze data or answer questions faster.

Feature Value Pyramids

Once you have established at least one value statement for the product you work on, you have a way to evaluate new features to ensure that they provide a value that aligns with the product values. The Feature Value Pyramid (FVP) is an inversion of the PVP — this time, the value is on top. Before you even define what any new feature is, you should have an idea of what customer value the feature will support, and then figure out what technology will get you there.

In this case, you’ll build the value statement in the format “The customer can [BLANK] because we enable [BLANK] by leveraging [BLANK].” This statement emphasizes that you need to understand why you’re adding a new feature before you define what the feature is or how you’ll achieve it.

If you start to write out all of the values your product provides, and then write out all of the values the product’s features — current and future — using the same framework, you should be able to stack your pyramids in such a way that the features support the product’s purpose(s).

When you place it all together, you’ll notice that the value of a feature ends where the value of the product begins. When you define your feature values in a way that supports the product values, you should see a close alignment across that middle section.

Meeting in the middle

When you place your value statements together and line them up in the middle, reading horizontally across that middle row should tell a consistent story. If you’re working on a product that already exists, it’s good to start by framing the current features in this format. Make sure that all of your stakeholders can agree on what the product is, what values it provides, and why the current features are there.

From there, you can then address your backlog of feature requests coming in. Before you accept them into your roadmap, make sure that you can write the user story in a way that maintains the consistency of these value statements. If you find yourself performing mental gymnastics to make it fit the narrative, that’s a good sign to dig in deeper and reframe what problem you’re attempting to solve. If you prioritize the features that fit best with your values, you can keep the Scope Creep at bay.

When I didn’t have a framework for evaluating new feature requests, I felt like we were conflating the technology (Generative AI) with the purpose (meeting actual customer needs). You may look at these PVPs and FVPs and see this as the reinvention of conventional stories, but my goal here was to detach the soul of the product as much as possible from the technology that was powering it — in this case by five degrees of separation. We haven’t yet seen the extent of GenAI technology or what it can do for us in the future, but we can’t build around a specific iteration of a tool. It’s a lot like building a car: we might use the best engine available for this year’s model, but that’s not why we’re building it. We’re building it to move people forward.

How to scope your AI product was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.