Customers Don't Know What They Want

The phrase "customers don't know what they want, but they know what they don't like!" is one of my favorite phrases. I usually toss it out when a customer requests a change after testing one of our deliverables. The developer did what was asked, but that's not what the customer wanted. When the developer gets flustered, I remind them that sometimes you have to see the deliverable to realize what you actually want or communicate what you want correctly.

I'm not sure where the phrase came from originally, but I learned it working as a web developer. It is something my boss used to say. The phrase seems intuitive enough, but it occurred to me the other day that this phrase is connected to agile concepts.

For some background, I used to work at a small web development shop called Orajen in 2007. We partnered with design firms like Turnpost to create beautiful and functional websites. At the time, CSS was not very advanced or consistently implemented, so the website designs tended to push the limits of what could be implemented. I saw a YouTube short today discussing some old websites that are still online and they poked fun at the table layout one of the sites still has. In the younger years of the internet, tables were the only good way to get a website to layout consistently across browsers. "The Semantic Web" was still a new idea back then. We did whatever we could to just make websites work in Internet Explorer and Safari.

As part of the website development process, a client would share their budget, provide whatever input they could, be informed of current trends, and then eventually be presented with several designs. This is the first point when the customer can change their minds or reimagine the result. Changes would be made collaboratively and the customer would pick a design to move forward with. Then, a Photoshop file of the refined design would be sent to Orajen for implementation. My job was to create a Dreamweaver template of HTML, write the CSS & JavaScript, and wire up any features, like signing up for newsletters. We used lorem ipsum to create filler text content so the client could get an idea of what the website would look like once all the content was in place.

Once a draft of the website was complete, we would post it to a QA region and share the link with our partners at Turnpost and the customer. This is when the customer would get their first look at the design in a web browser and, invariably, something wouldn't be right. Now that they could see it, the font would be too small, not the right font face, etc. So began the feedback loop. They would request changes and we'd make the changes and push them to QA.

Orajen wasn't formally an agile development team, but I believe that we did embrace parts of the Manifesto for Agile Software Development. For example, our customers tended to be local to the area and we often met them at their offices or they would visit us. Our office was near the Turnpost office, so we also met with the designers regularly. Those activities are very much in line with "individuals and interactions over processes and tools". Working closely with our customers and partners meant that we were also collaborative and quick to change. Finally, since we built websites, you could argue that our QA region was the "working software" over any documentation. (A little weak since we wouldn't document a website, but close enough!)

I believe the concepts of Agile have endured for so long because they are practical and have humanity in them. Agile codifies the idea of getting people together to solve problems and build solutions together. I also like the idea that we should not put so much energy into delivering perfection. Deliver something, get input, and then make improvements. Reminds me of another saying: "Perfect is the enemy of good."

Cheers!