4. Validate with your target audience
Determine the real user of your product early in the process and work to identify their needs. You might do quality assurance by getting a random person to test your site, but their opinion about whether the site is usable or useful only matters if they are in your target audience. For example, if you’re building an app for veterans, it doesn’t matter that your brother thinks all the acronyms are hard to understand, if those are terms everyone learns in bootcamp.
Software that is built on requirements provided by the bureaucrat, executive, or official (when they are not users) will often fail to achieve the goals of its users, and ultimately the business goals as well.
Never stop learning
Constantly validate what you build with a representative sample of users and continue to keep identifying their needs. Course correct as you learn new information about the needs of the user.
Working product to working product
Agile teams work in sprints. The output of a sprint should always be a working, deployable product that solves a user need. Your goal is to test as early and as often as possible with users, so always having a working product means that you can do this continuously.
This principle ensures that you break down a problem into smaller, manageable pieces and work on those pieces one at a time. This also helps keep stakeholders happy. They always have something useful and can help validate that it does in fact, solve a user need.
Remember that eight incomplete features are less useful than two usable ones.