It’s the first day on a new team as a product owner. You sit down with the tech lead to get a lay of the land: What are our products? Who are our customers? What does our backlog look like? The tech lead waves you off and says, “You are here to help us build things people want. It’s your job to figure those things out, we don’t know.”

Building things people want is the job of the entire team in partnership with the users. Software exists to solve user’s problems. Software exists to solve user’s problems. We fail at software development when we fall into the gap between software requirements and real world user experience. The business wants products that sell or make processes more efficient. The thing that most undermines a good development team is when they build something that never gets sold, used, or heard about. All too often, organizations don’t know how to do that.
During this session we will learn why we listen to users, how to listen to users, and who should be involved in those discussions. We will use that customer feedback to create feedback loops which iteratively solve customer problems. Using advisory groups, feature toggles, and iterative release strategies we can test hypotheses, see user adoption and hurdles, and build the right thing. We will also touch on how DDD practices like ubiquitous language and domain mapping and help both the development team, and the customers, speak the same language and collaborate towards functional software.