I regularly get asked for book references. From employees new to DeveloperTown, to founders who walk in the door and aren’t sure where to start, to people who look at what we do and how we work and ask how we figured all that stuff out. Some of it we figured out, much of it other people figured out and wrote down. We were smart enough to read it, apply it, and adapt it to the way we work. You can too.
Here is my take on the books that best capture how we think about product development. At DeveloperTown we’re big on iterative development (or as Ries puts it – small batches), customer development, validated learning, clean and simple design, and clean and simple business documents. The following books have been very influential in how we build our products:
The Lean Startup, Ries
The Four Steps to the Epiphany, Blank
The Entrepreneur’s Guide to Customer Development, Cooper and Vlaskovits
Business Model Generation, Osterwalder and Pigneur
Rework, 37 Signals
Because we often aren’t just building products, but are also helping founders build companies (and sometimes building them ourselves), I also recommend the following to help navigate venture capital, starting to understand what it’s going to be like working with investors once you get their money, and building and running a business:
When it comes to the specifics of building our software, we use our own flavor of agile development – but in it’s early days it was strongly influenced by Scrum. We develop primarily using Rails and an army of controlled but ever-changing frameworks to go with it, we do everything in the cloud, and we test constantly (much of it automated, some of it manual, a bit of it with users). For those who want to know more about our development methodology and where it comes from, I recommend:
That list doesn’t really touch on some of the development and testing principles, but that’s just because I’m not really aware of any good books out there that capture those concisely. I could recommend a bunch of books from The Pragmatic Bookshelf, and each of them would have a piece of it. But my experience is that much of that knowledge is captured in blog posts, on forums, and in the rich debate that happens between team members when they go to solve a problem. We post about some of those debates occasionally.
Finally, if you’re responsible for getting software out the door, there is another list you might be interested in. It’s the list on getting things done, managing the process, and shipping great software – some of the best works on project management I’ve read (and I’ve read a lot on the topic):
Some project managers may look at that list and say Release It! doesn’t belong there. They are wrong – it does. On small/agile projects, if the person leading the project isn’t constantly thinking of those things, then it’s very likely that no one is. For us, project management is the art of alternating between the strategic and the tactical, balancing tradeoffs, and communicating progress. To do that, you need to be knowledgeable (not expert – just knowledgeable) about all aspects of the product.