Item 1: Assume people have no idea what they want

This is pretty much always the case. When I started out in Software, I was used to building things according to a well-defined specification. This is what I did when I was programming open-source software for myself. It's also what I did in all my computer science classes. It's also how every single coding architecture book presented problems: you're given something wholly concrete, and then asked to implement it.

The most frustrating meetings I've experienced are ones where either myself or someone else who's a software engineer is trying to get this information from somebody else: I can't speak for others, but reflecting back on my own experience, I realized that was I was expecting was for someone to hand me a fully-formed, unambiguous product spec, and then leave it up to me how to decide how to implement the software for that spec.

In reality, they had a vague, abstract idea of what they wanted, but were not trained (and could not possibly be trained) to get it to the level of detail in order to build it into software. Once I realized this, I shifted my perspective from trying to get them to tell me exactly what they wanted, to helping them figure out what they want.

When talking to stakeholders and customers, view your job as helping them figure out what they want, vs. assuming they know what they want and extracting the requirements out of them.

Many of the items in this chapter will cover in detail strategies and tactics for going about doing this. The point of this item is to shift your mental model of a customer / stakeholder from someone who knows exactly what they want to someone who only has a very vague notion of what they want.

The science behind this is Khaneman and Tversky, behavioral economics. Basically: we're not as smart as we think (BIBLIO: THINKING FAST AND SLOW)

Assuming ignorance is paramount to taking full advantage of the rest of the advice in this part.