Product scope defines the boundaries of what you're creating. Whether launching something entirely new or adding features to existing software, teams rely on shared vocabulary to describe their work. Terms like minimum viable product, product requirements document, and user stories create a common language that keeps everyone aligned on what success looks like. Understanding these terms helps you participate in planning conversations, write clearer documentation, and avoid the trap of building too much too soon. Scope creep happens when requirements expand without proper checks, turning focused products into bloated systems that miss deadlines and confuse users.
The terms in this lesson give you the tools to describe products clearly, document requirements properly, and recognize when scope boundaries need defending.
Minimum viable product (MVP)
A minimum viable product contains just enough features to satisfy early adopters and validate your product idea. The goal is to collect maximum validated learning about customers with minimal effort. MVPs reduce risk by testing assumptions in real market conditions before investing heavily in full development. This approach lets teams launch quickly, gather feedback, and refine based on actual user behavior rather than assumptions. An MVP must be viable, meaning it provides a complete solution to a specific problem and delivers a high-quality user experience. It's not a prototype or a collection of half-built features. Users should be able to complete entire tasks with the product, even if it lacks advanced functionality. The "minimum" refers to feature count, not quality or completeness. Amazon started as an MVP, selling only books from a garage before expanding to other products. Airbnb's founders tested their idea by renting out their own apartment through a basic website. These examples show how MVPs validate market demand before significant investment.[1]
Pro Tip! MVPs must deliver real value to early users. If users can't complete actual tasks or rely on it for real needs, it's still a prototype.
Greenfield project
A greenfield project starts from scratch with no existing code, systems, or infrastructure to consider. The term comes from construction, where developers build on undeveloped green land. In software, it means creating something entirely new without constraints from legacy systems or prior decisions. This freedom lets teams choose modern technologies, design optimal architecture, and build exactly what's needed for current requirements. Greenfield projects offer flexibility but carry a higher risk. Without existing systems to reference, teams must define everything from the beginning. This takes more time and requires careful planning to ensure the solution meets actual needs. However, the absence of legacy constraints means teams can innovate freely and avoid technical debt that accumulates in older systems. True greenfield projects are relatively rare. Most software development involves some interaction with existing systems or code. The term is most commonly used when the majority of work is new, even if minimal integration with other systems is required.[2]
Product brief
A product brief is a concise document that outlines the problem to solve, goals, target audience, and high-level approach for a new product or feature. Often called a "one-pager," it focuses on the strategic "what" and "why" rather than technical "how." Product briefs typically include:
- The product vision
- Target users
- Key objectives
- Success metrics
- Scope boundaries
The document aligns teams around a shared understanding before detailed planning begins. Product briefs differ from product requirements documents. While PRDs dive into technical specifications and implementation details, briefs stay high-level and problem-focused. This lightweight approach supports agile development by defining the problem clearly while leaving room for teams to explore solutions collaboratively. Briefs serve as communication tools between product managers, developers, designers, and stakeholders. The product brief acts as a starting point for design and development teams to begin thinking about solutions. It prevents misunderstandings by establishing clear strategic guidelines early. Teams can reference the brief throughout development to ensure work stays aligned with the original vision and objectives.[3]
Pro Tip! Keep product briefs to one page when possible. They should clearly define the problem without prescribing the solution.
Product requirements document (PRD)
A product requirements document defines what a product should do and how. It outlines the product's purpose, key features, functionality, behavior, and constraints. PRDs align teams by ensuring product managers, engineers, designers, and stakeholders share a clear understanding of what needs to be built and why. This document guides development and serves as the single source of truth for product details. Modern PRDs are leaner than traditional specifications. Agile teams focus on shared understanding rather than comprehensive documentation. Effective PRDs include:
- Product goals
- User stories
- Design considerations
- Success metrics
- Explicit out-of-scope items
This clarity prevents misunderstandings and helps teams make informed decisions throughout development. PRDs are living documents that evolve as teams learn more during development. While the core vision remains stable, specific requirements may change based on feedback, technical discoveries, or shifting priorities. Regular updates ensure the PRD stays relevant and useful throughout the product lifecycle.[4]
Pro Tip! PRDs should evolve as you learn. Update them regularly instead of treating them as fixed contracts written once and never changed.
Product specs
Product specifications outline the detailed technical requirements, features, and standards for building a product or feature. They serve as a blueprint that guides development teams by describing how the product should be designed and built. Specs include technical details like architecture, performance criteria, design elements, materials or technologies used, and functional specifications. Unlike high-level requirements, specs answer the "how" question with concrete implementation details. Product specs align cross-functional teams by providing a single source of truth for what needs to be built. They typically cover:
- Product functionality
- Technical constraints
- User interface details
- Acceptance criteria
- Quality standards
The level of detail depends on project complexity, but effective specs balance thoroughness with brevity, avoiding micromanagement while providing essential context. Specs differ from requirements documents in their focus. Requirements describe what the product should achieve from a user or business perspective. Specifications detail how those requirements will be technically implemented. Together, they form complementary documents that guide product development from concept through execution.[5]
User story
A user story is a brief description of a feature from users' perspective. It follows the format: "As a [user type], I want to [action], so that [benefit]." This structure keeps focus on who needs the feature, what they want to accomplish, and why it matters to them. User stories emphasize customer value over technical implementation. User stories form the building blocks of agile development. They're intentionally concise to encourage conversation between team members. The written story is just the starting point for discussions about requirements, design, and implementation. Teams add details through acceptance criteria, which define specific conditions the feature must meet to be considered complete.[6] Effective user stories are independent, negotiable, valuable, estimable, small, and testable. They should be small enough to complete within a sprint but large enough to deliver meaningful value. Stories help teams stay focused on user needs throughout development and make it easier to prioritize work based on customer impact.
Pro Tip! User stories are conversation starters, not complete specifications. Use them to spark discussions about what users need and how to deliver it.
Acceptance criteria
Acceptance criteria define the conditions a feature must meet to be considered complete. They establish clear, testable boundaries for what "done" means. Criteria help developers understand requirements, testers verify correct implementation, and product owners confirm features meet expectations. Without acceptance criteria, teams lack objective measures of completion. Most teams use one of two formats: checklists or Given/When/Then scenarios.
Checklists are simple pass/fail statements like "User can export data as CSV." Given/When/Then format describes scenarios: "Given I'm logged in, when I click export, then I receive a CSV file." Both formats work, but the key is making the criteria specific, measurable, and testable. Acceptance criteria should be defined before development begins, often during backlog grooming or sprint planning. The entire team collaborates on creating criteria to ensure shared understanding. This collaboration surfaces missing requirements, dependencies, and potential issues early when they're easiest to address.[7]
Feature creep
Feature creep is the gradual, uncontrolled expansion of a product's scope as new features are continuously added beyond the original plan. Often starting with "just one more small feature," it leads to delayed timelines, blown budgets, and bloated products that lose focus. Feature creep happens when teams lack clear priorities or can't resist adding functionality without evaluating strategic trade-offs. Common causes include:
- Vague product roadmaps
- Pressure from sales teams promising features to close deals
- Poor stakeholder management
- Teams adding "cool" enhancements not tied to core requirements
Feature creep is particularly dangerous because it accumulates slowly. Each individual addition seems reasonable, but collectively they derail projects and create complex products that confuse users. Preventing feature creep requires discipline. Teams need clear product vision, rigorous prioritization frameworks like MoSCoW (Must have, Should have, Could have, Won't have), and the courage to say ‘no’ to requests that don't align with strategic goals. Change control processes help evaluate whether new features truly warrant expanding the scope versus being deferred to future releases.[8]
