When the military engages in battle, it operates in a fluid environment; all of its best-laid plans can change at a moment's notice. Only after the first point of contact with their opponent will they start to discover the true nature of their counterpart's strategy. 

General Patton, and military leaders like him, realized that instead of trying to plan and tightly control the outcome, a much better strategy was to set the minds of his commanders in the field to work instead. If he gave them an objective, then those on the ground were much better placed to determine how to reach its outcome as the battle evolved around them. If things took a turn for the worse while trying to reach that objective, the local commander had ownership of the strategy and was able to adjust it for the better, instead of just following orders blindly.

Our work may seem far from a battlefield, and hopefully, it is. In the same way, however, the nature of the problems we solve are complex and often unfold as we begin to work on them. Often, solutions given upfront will only take us part of the way. If our Development Team has ownership of the solution, as we uncover new information we can evolve our strategy to better fulfill the outcome we've been asked to achieve. Adaptive strategies will often reduce the time taken to reach the outcome our Product Owner desires.

How does this work in practice? Through close collaboration between the Product Owner and the Development Team, we should be able to respond to any challenge we're set. We've deliberately hired a cross-functional team so that they have all the skills necessary to do the job we're asking them to do. Depending on the problem you're trying to solve, this will usually include UX and graphic design, software design, development and testing, and so on.

A common trap that we can fall into as Product Owners is to write User Stories in a way that prescribes how to build something. For example, acceptance criteria such as "Place the checkout button below the form; if the form isn't filled out correctly when the user presses the button, display errors related to the incorrect data."

The preceding example is bad for a couple of reasons:

• Firstly, the user experience of placing the button below the form has been prescribed. But what if placing the button below the form means that the button is at the bottom of the page and out of view for 80% of our customers?
• Secondly, why wait until the button is pressed to prompt our customer to fill in certain fields, or tell them that the information they've entered is incorrect? We could give the customer some indication that certain fields are mandatory on the form instead. We could also give them immediate feedback on incorrectly-formatted information, for example, if they type an invalid email address into the email address field, or type an alpha character into a field expecting a number, such as a telephone number.

By prescribing these simple requirements, we've constrained our team to produce an inferior user experience. Instead, a better way to write the acceptance criteria would have been "The customer can easily complete the checkout form with the required information." This is far less prescriptive and gives the team the ability to decide the best possible approach to achieve the outcome our Product Owner would like.