Before you cut a feature from an AI MVP, name the need it protects
Before you cut a feature from an AI MVP, name the need it protects
Before you cut a feature from an AI MVP, name the need it protects
The short answer
Don't cut AI MVP scope by counting features. For every optional capability, especially an extra input mode, name the distinct user need it serves and the testing and support it adds. Defer it only if that need is still met, accessibly, by what remains. Then record what you protected, what is still unknown, and what evidence would reopen the decision.
Don't cut AI MVP scope by counting features. For every optional capability, especially an extra input mode, name the distinct user need it serves and the testing and support it adds. Defer it only if that need is still met, accessibly, by what remains. Then record what you protected, what is still unknown, and what evidence would reopen the decision.
“Cut what doesn’t matter” supplies no decision rule. The leadership task is to distinguish a redundant capability from an unmet need.
Where this comes from
At Virtualitics, I led design of a chat-native concept for the platform. It was a clickable Figma prototype, not code. It explored three ways in: voice, typed chat, and a natural-language field that filled in and formatted variables.
We defined the analyst workflows with analysts, not for them. Seven volunteer subject-matter experts, recruited through a research survey and familiar with similar software, then reviewed the prototype. Their feedback pushed the MVP toward simplicity, with the intention of layering complexity in later. I left in September 2024, right as the MVP was being built, and helped define the next steps.
That experience informs the scoping approach below; it does not establish a product outcome.
Every input mode is a promise
Voice, typed chat, and a smart field are different interaction options, not evidence of three distinct user needs. Before retaining all three, establish which needs overlap and which require a separate path. Each option also brings its own work: failure cases, onboarding, testing, support, and accessibility.
So the leadership question is not "how many modes can we afford?" It is this:
Which distinct user need does this mode serve? If you can't name one that the others don't already cover, it is a candidate to defer.
What does it add in testing and support obligations? Count the work it brings, not just the build.
If we defer it, is that need still met, accessibly, within scope? If not, it isn't optional. Find a cheaper way to meet the need, or keep the mode.
The third question does the real work. Deferring a mode is fine. Deferring the need it serves is how MVPs quietly drop the people who most needed the product to work.
“Cut what doesn’t matter” supplies no decision rule. The leadership task is to distinguish a redundant capability from an unmet need.
Where this comes from
At Virtualitics, I led design of a chat-native concept for the platform. It was a clickable Figma prototype, not code. It explored three ways in: voice, typed chat, and a natural-language field that filled in and formatted variables.
We defined the analyst workflows with analysts, not for them. Seven volunteer subject-matter experts, recruited through a research survey and familiar with similar software, then reviewed the prototype. Their feedback pushed the MVP toward simplicity, with the intention of layering complexity in later. I left in September 2024, right as the MVP was being built, and helped define the next steps.
That experience informs the scoping approach below; it does not establish a product outcome.
Every input mode is a promise
Voice, typed chat, and a smart field are different interaction options, not evidence of three distinct user needs. Before retaining all three, establish which needs overlap and which require a separate path. Each option also brings its own work: failure cases, onboarding, testing, support, and accessibility.
So the leadership question is not "how many modes can we afford?" It is this:
Which distinct user need does this mode serve? If you can't name one that the others don't already cover, it is a candidate to defer.
What does it add in testing and support obligations? Count the work it brings, not just the build.
If we defer it, is that need still met, accessibly, within scope? If not, it isn't optional. Find a cheaper way to meet the need, or keep the mode.
The third question does the real work. Deferring a mode is fine. Deferring the need it serves is how MVPs quietly drop the people who most needed the product to work.
Know what your prototype can actually prove
A prototype answers some questions and is silent on others. Scope decisions go wrong when those get mixed up.
GOV.UK's guidance on the alpha phase frames early prototyping as testing your riskiest assumptions with only as much complexity as that needs. It also notes that the riskiest assumption is sometimes technical rather than about the interface. A clickable concept can show how people understand a proposed workflow and where they expect to check or correct a result.
It cannot show how a model performs. NIST's AI RMF Playbook treats that as separate work: evaluation in conditions similar to deployment, documented test sets and limits, comparison with simpler baselines, and then monitoring actual production behavior. Adoption and lasting value need evidence from real use.
In our case, the volunteers' feedback informed a scope decision. It did not, and could not, establish model reliability, recovery success, or adoption.
Know what your prototype can actually prove
A prototype answers some questions and is silent on others. Scope decisions go wrong when those get mixed up.
GOV.UK's guidance on the alpha phase frames early prototyping as testing your riskiest assumptions with only as much complexity as that needs. It also notes that the riskiest assumption is sometimes technical rather than about the interface. A clickable concept can show how people understand a proposed workflow and where they expect to check or correct a result.
It cannot show how a model performs. NIST's AI RMF Playbook treats that as separate work: evaluation in conditions similar to deployment, documented test sets and limits, comparison with simpler baselines, and then monitoring actual production behavior. Adoption and lasting value need evidence from real use.
In our case, the volunteers' feedback informed a scope decision. It did not, and could not, establish model reliability, recovery success, or adoption.
Make "accessible" a requirement, not an adjective
"Keep accessibility" turns into a slogan unless it names behavior. For a web implementation, WCAG 2.2 gives testable criteria that bear directly on AI workflows:
Controls work from a keyboard.
Controls expose their name, role, and state to assistive technology.
Status messages, such as "generating" or "done," can be announced without moving focus.
Detected input errors are identified in text, with correction suggestions where they're known and safe.
Two clarifications keep this honest. A wrong AI answer is not a WCAG "input error," so recovery from bad output is a separate design obligation. The linked WCAG edition is dated 12 December 2024. I use its criteria here as implementation guidance, not as a record of what our team checked.
This is also where the input-mode question bites. If voice is cut, the typed path must be fully operable. If the smart field is cut, filling variables by hand can't become a trap.
Make "accessible" a requirement, not an adjective
"Keep accessibility" turns into a slogan unless it names behavior. For a web implementation, WCAG 2.2 gives testable criteria that bear directly on AI workflows:
Controls work from a keyboard.
Controls expose their name, role, and state to assistive technology.
Status messages, such as "generating" or "done," can be announced without moving focus.
Detected input errors are identified in text, with correction suggestions where they're known and safe.
Two clarifications keep this honest. A wrong AI answer is not a WCAG "input error," so recovery from bad output is a separate design obligation. The linked WCAG edition is dated 12 December 2024. I use its criteria here as implementation guidance, not as a record of what our team checked.
This is also where the input-mode question bites. If voice is cut, the typed path must be fully operable. If the smart field is cut, filling variables by hand can't become a trap.
An explanation is not a safety net
The comforting assumption is that if the AI explains itself, people will catch its mistakes. The evidence is less kind.
In Bansal and colleagues' CHI 2021 experiments, which used study examples selected so AI and human accuracy were comparable, explanations did not significantly improve human-AI team accuracy over showing a recommendation with its confidence. They also made people more likely to accept recommendations, including wrong ones. The tasks were narrow, the participants were mostly non-experts, and the explanation formats were limited, so this doesn't show that explanations are useless. It does show that they can persuade rather than protect.
For an implemented workflow, my proposed test is direct: can intended users recognize a bad suggestion and complete a correction in a realistic task? That belongs in the MVP. A more elaborate explanation layer may not.
An explanation is not a safety net
The comforting assumption is that if the AI explains itself, people will catch its mistakes. The evidence is less kind.
In Bansal and colleagues' CHI 2021 experiments, which used study examples selected so AI and human accuracy were comparable, explanations did not significantly improve human-AI team accuracy over showing a recommendation with its confidence. They also made people more likely to accept recommendations, including wrong ones. The tasks were narrow, the participants were mostly non-experts, and the explanation formats were limited, so this doesn't show that explanations are useless. It does show that they can persuade rather than protect.
For an implemented workflow, my proposed test is direct: can intended users recognize a bad suggestion and complete a correction in a realistic task? That belongs in the MVP. A more elaborate explanation layer may not.
Use the guidelines to find gaps, not to pad scope
Two older references still earn their place. Google PAIR's Mental Models chapter argues for stating a system's capabilities and limits, letting people experiment reversibly, and offering a non-AI path when the AI fails. Microsoft Research's Guidelines for Human-AI Interaction, published in 2019, is useful here as a proposed coverage check.
I'd use both to ask "what evidence are we missing?" rather than "what else should we build?"
The decision record
Scoping by need only works if the reasoning survives the meeting. For each deferred item, write three lines:
Protected need: the user need that remains met, and how, including the accessible path.
Unresolved uncertainty: what we don't yet know, and at which evidence level (prototype, implemented system, or real use).
Revisit condition: the evidence or signal that would bring the item back.
Use the guidelines to find gaps, not to pad scope
Two older references still earn their place. Google PAIR's Mental Models chapter argues for stating a system's capabilities and limits, letting people experiment reversibly, and offering a non-AI path when the AI fails. Microsoft Research's Guidelines for Human-AI Interaction, published in 2019, is useful here as a proposed coverage check.
I'd use both to ask "what evidence are we missing?" rather than "what else should we build?"
The decision record
Scoping by need only works if the reasoning survives the meeting. For each deferred item, write three lines:
Protected need: the user need that remains met, and how, including the accessible path.
Unresolved uncertainty: what we don't yet know, and at which evidence level (prototype, implemented system, or real use).
Revisit condition: the evidence or signal that would bring the item back.
Hypothetical example, not the Virtualitics decision: “Defer an in-product voice mode only after testing that the remaining path meets the identified need accessibly. Reopen the decision if research reveals an unmet need.” The decision record should distinguish tested coverage from assumed coverage.
The takeaway
Cut optional scope around a named need and a named uncertainty, never around a feature count. Use prototype feedback to decide what to test next, not to claim that an AI workflow works. And write the decision down, so that each deferred item comes back only if its revisit condition is met.
Hypothetical example, not the Virtualitics decision: “Defer an in-product voice mode only after testing that the remaining path meets the identified need accessibly. Reopen the decision if research reveals an unmet need.” The decision record should distinguish tested coverage from assumed coverage.
The takeaway
Cut optional scope around a named need and a named uncertainty, never around a feature count. Use prototype feedback to decide what to test next, not to claim that an AI workflow works. And write the decision down, so that each deferred item comes back only if its revisit condition is met.
References
GOV.UK Service Manual, How the alpha phase works. Published 4 Aug 2016, updated 8 May 2019. Prototypes test the riskiest assumptions with minimal complexity, and have limits.
NIST, AI RMF Playbook: Measure. Undated page; AI RMF 1.0 released 26 Jan 2023. Separates deployment-like evaluation and production monitoring from interface feedback.
W3C, Web Content Accessibility Guidelines (WCAG) 2.2, edition dated 12 Dec 2024; originally a W3C Recommendation 5 Oct 2023. Testable criteria for keyboard use, names and roles, status messages and input errors.
Bansal, G. et al., Does the Whole Exceed its Parts? The Effect of AI Explanations on Complementary Team Performance, CHI 2021, May 2021 (author manuscript). Explanations increased acceptance of wrong AI suggestions without significantly improving team accuracy.
Google PAIR, People + AI Guidebook: Mental Models. Undated. Communicating limits, reversible experimentation, non-AI fallbacks.
Amershi, S. et al., Guidelines for Human-AI Interaction, CHI 2019, May 2019. A proposed, practitioner-evaluated coverage check for human-AI design.
References
GOV.UK Service Manual, How the alpha phase works. Published 4 Aug 2016, updated 8 May 2019. Prototypes test the riskiest assumptions with minimal complexity, and have limits.
NIST, AI RMF Playbook: Measure. Undated page; AI RMF 1.0 released 26 Jan 2023. Separates deployment-like evaluation and production monitoring from interface feedback.
W3C, Web Content Accessibility Guidelines (WCAG) 2.2, edition dated 12 Dec 2024; originally a W3C Recommendation 5 Oct 2023. Testable criteria for keyboard use, names and roles, status messages and input errors.
Bansal, G. et al., Does the Whole Exceed its Parts? The Effect of AI Explanations on Complementary Team Performance, CHI 2021, May 2021 (author manuscript). Explanations increased acceptance of wrong AI suggestions without significantly improving team accuracy.
Google PAIR, People + AI Guidebook: Mental Models. Undated. Communicating limits, reversible experimentation, non-AI fallbacks.
Amershi, S. et al., Guidelines for Human-AI Interaction, CHI 2019, May 2019. A proposed, practitioner-evaluated coverage check for human-AI design.