Features

What features the solution should have, and what's absolutely most important

Features describe what the solution can do, and knowing which one matters most is the only way to avoid building a full product when a single function is enough to start.

Every solution grows features the longer you think about it. That growth is natural, but for a first AI-assisted solution it is also the main risk. The goal of this card is to get to a list of features and then ruthlessly identify the one that does the most important work. Everything else is a candidate for later.

Features for AI solutions often include both what the AI does and what the surrounding system needs: the interface a user sees, the integration that delivers inputs, the review step that a human takes. All of those are features. Some matter for the first version and some do not.

A useful test: which feature, if it worked well, would make someone want to use the solution again? That is your core feature. Start there, build only that, and decide what to add based on real use, not anticipated needs.

Make it visibleWrite a list of every feature the solution might have. Then put an asterisk next to the single feature that delivers the most value to the user with the least effort to build. Build only that feature first, and write the others on a separate list to revisit after the first version runs.

Why AI needs this

Each part of your work matters to AI in a specific way. Some of it is context a tool needs before it can help, some of it is work a tool can take on, and some of it is judgment that should stay with you.

Priority focus for AI

Prompting AI to build or generate across ten features at once produces something broad and shallow. Pointing it at one core feature produces something you can actually evaluate and use.

Scope protection

A ranked feature list makes it easy to say no to additions during a first build. Without it, every good idea that comes up in a conversation tends to become a requirement.

Signal for iteration

When you ship one core feature first, real use tells you which features to add next. That signal is far more reliable than speculation before anything has run.

Questions to explore

Use these on your own or in a group. There are no right answers, only better conversations.

If the solution could only do one thing, which one would make it worth using?
Which features are actually required for the solution to function, and which are nice to have for version two?
Are any of the features on the list solving a problem you have not yet confirmed is real?
Which feature is the riskiest to build: technically, operationally, or in terms of user trust?
If you could ship something in a week, which features would be in and which would be out?

Readiness traps

Feature lists written without asking users always over-represent the builder's interests and under-represent the user's needs: validate before you lock the list.
Treating all features as equal priority is the same as having no priority: rank them, even roughly, before you start building.
A solution that does many things tolerably is almost always less useful than one that does one thing well: resist the pressure to add scope before the core feature is working.