EuPMA - European Product Management Association
EuPMA is part of Open Innovation s.a.s.
For information or contacts: info@eupma.eu
European
Product
Management
Association
Product Management Action Card
Define Initial Requirements
We drive the future of Product Management in Europe
WHY
A product cannot enter development with only customer needs, Jobs-to-be-Done and Product Capabilities.
At some point, the team needs to translate this knowledge into Product Requirements: clear statements describing what the product must deliver, respect or achieve.
However, trying to define all requirements before development starts is usually a mistake.
Some requirements are fundamental from the beginning because they determine the value proposition, product boundaries, architecture, economics, safety or feasibility.
Others can be defined progressively as the product evolves.
And many detailed requirements—especially those describing exactly how the product should behave and work—are better discovered and refined together with design, engineering, prototyping and testing.
The objective is therefore not to create a complete specification before development.
It is to define the right requirements at the right time.
This provides enough direction to start development while preserving the ability to learn, iterate and improve.
WHAT
Initial Product Requirements are the requirements that need to be sufficiently clear before major product development decisions are made.
They translate customer needs, desired User Experience and Product Capabilities into a first structured definition of the product.
A useful distinction can be made between three levels of requirements.
1. Value Requirements — Define Early
These describe the results the product must deliver for customers, users and the business.
They may concern:
- customer value
- essential JTBD
- performance perceived by the user
- desired User Experience
- differentiation
- safety
- sustainability
- target cost or price
- regulatory constraints
- critical business objectives
They answer questions such as:
What value must the product deliver?
What must be true for the product to succeed?
These requirements should normally be understood before development begins, because they provide direction for all subsequent decisions.
2. Architecture Requirements — Define Early Enough
These requirements influence the fundamental structure of the product and decisions that may become expensive or difficult to change later.
They may include:
- main Product Capabilities
- physical or digital boundaries
- key interfaces
- platform and modularity constraints
- major technologies
- interoperability
- critical dimensions
- energy sources
- cybersecurity or safety architecture
- regulatory constraints
- manufacturing or supply-chain constraints
They answer:
What fundamental characteristics must the product have so that a viable architecture can be created?
Architecture requirements do not necessarily need to be completely detailed at the start, but the most consequential ones should be identified before irreversible design decisions are made.
3. Functioning Requirements — Define Progressively
These describe in greater detail how the product behaves and operates.
Examples include:
- detailed interactions
- control logic
- operating sequences
- interface behaviour
- error handling
- software rules
- detailed parameters
- secondary performance characteristics
- exceptional conditions
Many of these requirements do not need to be frozen before development starts.
They can be progressively defined and refined through:
design → prototype → test → feedback → learning → next release
This is particularly important in agile or iterative development, where understanding of the best solution increases during development itself.
HOW
- Start from Product Capabilities
Review the Product Capabilities and the customer knowledge from which they originate: Need → JTBD → User Activity → Desired User Experience → Product Capability. Use this traceability to understand why each requirement is needed. - Identify the requirements that define customer value
Ask: “What must the product achieve for the customer and user?”. Define the most important outcomes, constraints and performance expectations without unnecessarily prescribing the solution. - Identify requirements that constrain the architecture
Ask: “Which decisions would be difficult or expensive to change later?”. Capture the requirements that must influence product architecture from the beginning. - Do not specify detailed functioning prematurely
Avoid defining detailed behaviours simply because they can be imagined today. When a requirement can be safely discovered during development, leave room for learning. - Define measurable targets where they are already meaningful
Whenever possible, express requirements using measurable criteria. For example: The complete product shall weigh less than 12 kg. But avoid artificial precision when the necessary knowledge does not yet exist. - Define how requirements will be verified
For important requirements, clarify how compliance can eventually be demonstrated through testing, inspection, analysis, simulation or user validation. - Distinguish requirements by timing
For each requirement, specify when it needs to become stable. - A practical classification is:
- Required before development
- Required before the relevant architecture decision
- Required for a specific release
- To be defined during development
- Define release-specific requirements progressively
Not every Product Capability needs to reach its final level in the first release.
- Maintain traceability
Whenever possible, connect each requirement to the Product Capability, User Experience or JTBD that generated it. This makes it easier to challenge unnecessary requirements and understand the consequences of changing them. - Keep requirements alive
Product Requirements should evolve as new evidence emerges. - Development, prototypes, tests and customer feedback are not only activities for verifying requirements—they are also important ways of discovering and improving them.
The Principle
The objective is not:
Define everything → Develop → Verify
but rather:
Define what must be known → Develop → Learn → Refine → Release → Learn again
Some requirements must be defined early because they protect value and architectural coherence.
Other requirements should deliberately remain open until the team has enough knowledge to make a better decision.
The result is a Product Requirement set that provides direction without unnecessary rigidity.
Need support applying this Action Card?
Talk to EuPMA.
Read the quick guide.
Download the: “Identify the Product Capabilities" Action Card.