When I wrote the first edition, it was before Agile was well estab-lished in product companies, and before Customer Development andLean Startup nomenclature became popularized. Today, most teamshave been using these techniques for several years and are more inter-ested in what’s beyond Lean and Agile, which is what I focus on here

In the first edition, I focused more on startups. In this edition,however, I wanted to expand the scope to look at the challenges ofgrowth-stage companies and how product can be done well at large,enterprise companies.

But soon we began to ask ourselves some very important questions:Who decides what products we should build? How do they decide?How do they know that what we build will be useful?

As I sat down to read Automation Awesomeness, I couldn’t help but bereminded of my own journey into the world of test automation.My first job out of college was as an Automation Engineer. Butthere was one big problem: I knew nothing about building qualitysoftware. I remember the first time I saw a script execute a test caseon its own. A lightbulb went off, and I immediately recognized howmuch of a force multiplier test automation could be for the softwaredevelopment industry.

As Pragmatic Programmers, our base material isn’t wood or iron, it’s knowl-edge. We gather requirements as knowledge, and then express that knowledgein our designs, implementations, tests, and documents. And we believe thatthe best format for storing knowledge persistently is plain text. With plaintext, we give ourselves the ability to manipulate knowledge, both manuallyand programmatically, using virtually every tool at our disposal.