Back in 2012 I wrote the following about a blind spot I’ve noticed in Agile development:

Problem solving involves not just iteration, but also lots of variation. This often requires time to get it wrong a few times, which doesn’t fit comfortably with the concept of release dates. See, the problem with integrating Agile and UX is not that designers want to hang on to “slow and heavy documents,” “big upfront design”, or whatever you want to call it. The problem is that each iteration further solidifies the chosen path, and there is no time to stop and ask if you’re going in the right direction.

All of that came flooding back when I read Jeff Patton’s Common Agile Practice Isn’t for Startups, in which he puts a slightly different spin on the issue that Agile is not very good at helping us figure out what to build. His solution is a product discovery process (something that’s obviously near and dear to my heart as well). He places the discovery process in the context of a different kind of velocity than is usually measured in Agile—trying to learn as much as possible about customers and the product:

There’s something very different about this process loop: the primary measure of progress during discovery isn’t delivery velocity, it’s learning velocity. And sadly, we can’t measure it in features or stories completed. And, even worse, we can’t plan two weeks of it in detail because what we learn today can and should change what we do tomorrow.

He goes on to describe a Nordstrom process:

Notice the Nordstrom Lab still uses time-boxes, 1 week in this case. But, they didn’t start the time-box by predicting how much they’d deliver, but with learning goals in mind. Then they iterated around the build-measure-learn loop as fast as they could.

The post is hard to quote from, so really, just go ahead and read it. It’s a very interesting approach to making discovery part of a regular Agile process.