The team’s collective understanding will naturally increase over the duration of the project. Towards the end of the project, a good team will have built up a deep, intimate knowledge of the user needs, and be able to proactively propose features and implementations that will be better suited to their particular user base. But this learning path is neither linear nor predictable. It is hard to know what we don’t know, so it is hard to predict what we will learn as the project progresses.
While reading it, I was in agreement right up to the last sentence. Don't get me wrong, I agree with it too; the problem is that since we don't know what we don't know, how can we tell when we've actually built up enough knowledge of the user's needs that the features and implementations we propose will actually be valuable? Unless the target audience is developers, and we're building the tools we're using, I think we'll get better over time but we need to be prepared for our ideas and suggestions to be shot down because of factors we still weren't aware of.
Does that make sense?
SCJP, SCJD, SCEA 5 "Any sufficiently analyzed magic is indistinguishable from science!" Agatha Heterodyne (Girl Genius)
Good point. This section is a reference to the concepts of Deliberate Discovery (look up Liz Keogh's blogs for some interesting material on this topic as well). The question is not trivial, of course. There are many ways to learn if you are actually delivering valuable features, ranging from just showing the users as early as possible (standard Agile/Scrum practice) to actually setting up metrics to measure whether a new feature is used, and how much revenue it generates, when it goes into production (I have clients and know companies that do this a lot). And you are right, of course - you need to be prepared to fail, and adapt accordingly (again, standard Agile practice, really). BDD/Deliberate Discovery just flushes this out and tries to trigger the failures/learning opportunities earlier rather than later.