Review of Do More Faster by David Cohen and Brad Feld

Looking at my book shelf organized with business books, seeing my iPad filled with iBook samples and seeing the New York Times Sunday edition laying around would make you think I’m a big reader. In fact, I’m a fraud. I’m the person that likes to start lots of books, read for a few minutes at a time and hardly ever finishes a book. I pre-ordered Do More Faster by David Cohen and Brad Feld and read it from start to finish the day it arrived.

Do More Faster is divided into 7 Themes: Idea and Vision, People, Execution, Product, Fundraising, Legal and Structure and Work-Life Balance. Within each Theme are several 1-3 page stories written by Entrepreneurs, VCs and other interesting people in the software, internet, product development, startup realm. It’s a great format for the hyper caffeinated, ADHD, check twitter while your reading type of personality.

This book was fun for me to read because many contributors are familiar faces I either work with in some capacity or have seen around the flourishing Boulder/Denver tech community.

Chapters that blew me away and taught me something brand new:

To 83(b) or not to 83(b), There is No Question – Matt Galligan
Usage is like Oxygen for Ideas – Matt Mullenweg
Karma Matters – Warren Katz
Don’t Plan, Prototype – Greg Reinacker

Chapters that reinforced some of my favorite work related topics:

Don’t Suck at E-mail – David Cohen
Get Out from behind Your Computer – Seth Levine
Be Specific – Brad Feld
Get Feedback Early – Nate Abbott and Natty Zola

If you want motivation for anything you are doing I highly recommend Do More Faster.

Why GTD Projects and Agile User Stories are so similar

David Allen’s Getting Things Done (GTD) approach reiterates the challenges of breaking a Project down into Tasks. He focuses on the psychologic barriers people have with the work in front of them. A common example (I’m paraphrasing here) is a person adding “Mom” to their ToDo list. When digging further, David discovers that “Mom” really means “Mom’s birthday is coming up” and there are no Tasks or “Next Actions” defined to move the Project closer to completion. This avoidance is very stressful on the person and a very inefficient way to life a busy life.

We use Rally’s ALM product and the Kanban custom tab to manage our User Story development. I have worked with 2 teams over the past few years and both I consider quite amazing and talented. Ongoing debates about naming conventions for User Stories, the importance of Tasks, and who should be the Story Owner have never been resolved. Our teams crank out great software, but always within a stressful environment.

As I was enjoying a nice bike commute into work last week I was listening to the GTD | Podcasts episode titled “The Do Lectures”. Around minute 10:30 David Allen says that to clarify anything, you have to decide “What outcome are you committed to finish about this?” I realized how similar GTD Projects and Agile User Stories really are.

A GTD Project clarifies the outcome you want.
An Agile User Story describes what the User wants to achieve.

Both GTD Projects and Agile User Stories use Tasks as a method of describing the work required for completion. In both, Tasks probably need to come in some sort of order, will vary in their scope and may require different people’s resource. Also in both, if Tasks can be defined it signals a complete understanding of the work to be done. Granted, you may have missed something, gotten something wrong or encounter changes along the way, but at least you’re on the right track.

My experience in working with fellow Developers is that being asked to Task out a User Story is sometimes treated as some kind of insult or waste of time. We joke a lot about a common Task name we use in Rally simply titled “do it”. Again, the GTD project similarities are strong here. The initial reaction is to keep things in your head and resist verbalizing the steps required to complete the work. Instead, insist on breaking every User Story down into Tasks and agree that the first Task to be worked on or “Next Action” is the most important one.

By leveraging the GTD Projects similarities in your Agile team, hopefully everyone will be more efficient and less stressed!

What Brad Feld and Mark Suster think about Product Managers

I was watching This week in Venture Capital #18 with Brad Feld hosted by Mark Suster and was pleasantly surprised to hear “Product Manager” pop up as a topic. At minute 47 of the interview, Mark asks about the “lack of experienced Product Managers”.

Brad says “One of the hardest roles to fill in a startup is that of an experienced Product Manager.” He goes on to say that one can be trained to be a good Product Manager but that person needs to have a certain personality type. Brad cites a quote from Mark Pincus “Be CEO of your job” and goes on to say “If you are a Product Manager for a specific thing, you have to deal with it just like a CEO has to deal with the whole company.”

Some personality traits that do not help the Product Manager are:

too process driven
not a good mixture of leadership and management
not willing to be uncomfortable creatively with it then button down to drive to the goal line

The conversation wraps up with comments on the changing approach to Product Management as the role has become very formalized in big companies. Brad and Mark talk about the older Product Manager/Project Manager setup at Microsoft and the how today’s “Google style” Product Manager is a very different personality type in a very different role. Mark argues this type of personality (product, engineering driven) is not focused enough on the economics of the business and then Brad counters by saying that he would take a call from any Product Manager for a product at Google in a heartbeat. Brad concludes the conversation by reiterating the notion of owning the whole function and knowing how to allocate resources is a powerful skillset and a “very hard role to find”.

Creating Project Rhythm by following TechStars and Y Combinator’s lead

I admire TechStars (wearing my TechStars t-shirt proudly) and have been a reader of Paul Graham’s blog for years. Both programs have created a vibe and atmosphere that churn out great work and provide endless motivation and contributions to their surrounding tech communities.

Reading the latest post from Paul Graham titled “What happens at Y Combinator” highlighted the relationship between schedule and rhythm and the role this plays in projects. Both the Y Combinator and TechStars programs are roughly 3 months long, similar to the quarterly Agile Release schedule that we use. The rigid schedule both programs use inspires and creates massive pressure for teams to work hard and deliver.

Because teams in TechStars and Y Combinator live and breathe their projects they are able to devote almost all of their time to it. The rhythm these programs develop include dinners, hackathons, presenting at local tech meetups and renting out conference spaces to host big demos. While a typical team can’t take things to that level, there are lessons to be learned.

Here’s the schedule I am using for our new project:

Product Summit – beginning of Quarter
A 2-3 day onsite working session full of multiple topics (business and technical) with a tight agenda and after work dinners. The goal of this effort is to have a general gameplan for the upcoming quarter for the whole project, not just development. In a distributed team like ours, it’s a rare chance for the entire team to spend time together.

9 Weeks

Monday
9a – Project Management conference call – a weekly update of anything to do with the project including budgets, contracts, etc
9:30a – Daily Standup

Tuesday
9:30a – Daily Standup
10a – Weekly dev team meeting – a weekly meeting to discuss technical details of upcoming work, review Kanban Board and Release Burndown

Wednesday
9:30a – Daily Standup

Thursday
9:30a – Daily Standup
Noon – Weekly demo to Stakeholders
1p – Weekly call with a Customer

Release retrospective – end of Quarter
A 2 hour retrospective answering questions like “What did we accomplish?”, “What was our Velocity” and “What can we change in the next Release?”

Summary
The rhythm I am trying to build for this project begins with a big kick off because lots of things need to be figured out up front and agreed on, then a strict weekly schedule to pull everyone along when things start to fall off the rails, then a decompression and review to let the dust settle. The schedule I have designed is nowhere near as cool as TechStars or Y Combinator but it’s a step in the right direction (I hope).

Related Articles:

The Rhythms of Life on Feld.com

Being more Productive on ktinboulder.com

TechStars