Overview
This prompt guides startups in prioritizing essential features for their MVP, ensuring a focused product launch. Founders and product teams will benefit by avoiding feature creep and maximizing value.
Prompt Overview
Purpose: This feature audit aims to streamline the MVP by identifying essential functionalities for launch.
Audience: The primary audience includes startup founders and product teams focused on delivering value quickly.
Distinctive Feature: Utilizing the MoSCoW method ensures clarity in prioritizing features, preventing unnecessary complexity.
Outcome: The result will be a focused MVP that effectively addresses user needs while minimizing distractions.
Quick Specs
- Media: Text
- Use case: Feature audit for MVP
- Techniques: MoSCoW method, Scope Shedding
- Models: Agile, MVP
- Estimated time: 1-2 hours
- Skill level: Intermediate
Variables to Fill
- [INPUT: Startup Idea] – Input: Startup Idea
- [Action A] – Action A
- [Action B] – Action B
Example Variables Block
- [Action A]: Enroll in courses
- [Action B]: Access course materials
The Prompt
Act as a ruthless Agile Product Owner. You specialize in “Scope Shedding”?the art of cutting 80% of features to focus on the 20% that deliver value. You use the MoSCoW method (Must have, Should have, Could have, Won’t have) to prevent “Feature Creep.”
TaskConduct a feature audit for my MVP (Minimum Viable Product). You must categorize every feature I want to build to determine what is truly essential for launch day versus what is just “nice to have.”
ContextStartup Idea: [INPUT: Startup Idea]
The “One Thing”: [INPUT: The single most important action a user must complete]
Feature Wishlist: [INPUT: Comma-separated list of all features you want to build]
Sort the features into these 4 buckets. Be strict?if a feature isn’t 100% critical for the “One Thing,” it cannot be a “Must Have.”
- MUST Have (Non-Negotiable): Without this, the product simply does not solve the core problem. It’s illegal or useless without these. (Max 3 features).
- SHOULD Have (Important): Painful to leave out, but the product works without them. (e.g., “Password reset” can be manual at first).
- COULD Have (Nice to Have): desirable features that are not necessary for the core value. Save these for v2.0. (e.g., “Dark Mode,” “Social Login”).
- WON’T Have (Out of Scope): Features that are distractions right now.
Summarize the “v1.0” product in one sentence: “The MVP will ONLY allow users to [Action A] and [Action B], ignoring everything else.”
FormattingUse a bulleted list for the buckets.
Add a short “Cut Reason” next to items moved to “Could Have” or “Won’t Have” (e.g., “Dark Mode: Purely aesthetic, zero functional value for launch”).
Screenshot Examples
[Insert relevant screenshots after testing]
How to Use This Prompt
- [MUST Have]: Essential features for core functionality.
- [SHOULD Have]: Important but not critical features.
- [COULD Have]: Desirable features for future versions.
- [WON’T Have]: Distractions not needed at launch.
- [One Thing]: Key action users must complete.
- [Feature Wishlist]: List of desired product features.
- [MVP Definition]: Summary of the minimum viable product.
- [Cut Reason]: Justification for feature prioritization.
Tips for Best Results
- MUST Have: User authentication – Essential for secure access to the product.
- MUST Have: Core functionality to complete the “One Thing” – Critical for solving the main problem.
- MUST Have: Basic user interface – Necessary for users to interact with the product effectively.
- SHOULD Have: User profile management – Important for personalization but can be added later.
- COULD Have: Social sharing options – Nice to have for user engagement, but not essential for launch. Cut Reason: Adds complexity without immediate value.
- COULD Have: Analytics dashboard – Useful for tracking user behavior, but can be implemented post-launch. Cut Reason: Non-essential for core functionality.
- WON’T Have: Advanced search filters – Distracting feature that complicates the MVP. Cut Reason: Not critical for initial user experience.
- WON’T Have: Custom themes – Aesthetic choice that does not impact functionality. Cut Reason: Purely cosmetic, zero functional value for launch.
FAQ
- What is the purpose of the MUST Have features?
MUST Have features are essential for solving the core problem and ensuring product functionality. - How do SHOULD Have features differ from MUST Have?
SHOULD Have features are important but not critical; the product can function without them. - What defines COULD Have features?
COULD Have features are nice to have but do not impact the core value of the product. - Why are WON'T Have features excluded?
WON'T Have features are distractions that do not contribute to the MVP's immediate goals.
Compliance and Best Practices
- Best Practice: Review AI output for accuracy and relevance before use.
- Privacy: Avoid sharing personal, financial, or confidential data in prompts.
- Platform Policy: Your use of AI tools must comply with their terms and your local laws.
Revision History
- Version 1.0 (December 2025): Initial release.