Down with the Requirements
Requirements are often arbitrary constraints imposed on a solution that has yet to take shape. They restrict the team’s ability to make optimal decisions when addressing real technical and design constraints. To avoid this, I prioritise high-level scope and hard constraints, such as budget, time, or laws of physics, over detailed requirements.
While requirements and mockups are often considered standard deliverables for Product Managers, they frequently represent arbitrary decisions that fail to reflect the complex, evolving nature of the product and its ecosystem. These guesses can inadvertently constrain the product’s potential over time—not due to the problem’s inherent nature but because they were prematurely defined. Creating overly detailed requirements and mockups can encourage a ‘just doing my job’ attitude, detracting from the focus on the product as a whole.
Describing the initial idea in words, the core feeling and problem the team is trying to solve is enough and preferable. The whole team should be inside the same story, around a shared narrative. If the team is aware of the principles behind the idea and understands the grounding centre where everything else should revolve around, they will be able to make all the lower-level decisions necessary to make great products.
Down with the requirements.