This week I read Rework by Jason Fried and David Heinemeier Hansson.  Overall – amazing book.  (And it was a breeze to get through after nearly 700 pages of Ray Kurzweil – see my post two weeks back on The Singularity is Near).

Rework is a little bit unique because it’s actually a book written by a software company (Jason and David are the founders).  The company is called 37 Signals and they’re the makers of online software including the project management app Base Camp.  The book details their secrets to success and philosophy for making great tech products.

Littered throughout the book are great lessons on organizational topics ranging from positive meeting-culture to the downside of workaholism.  However, I was most interested in pulling out the lessons for how to be a good Product Manager.

Here are a few of my key take aways:

1)   Scratch your own itch

For a reason that never quite clicked for me – this is often expressed by the phrase “eat your own dog food”.  Essentially: always been a position where you’re using your own products.  Having first hand knowledge of what’s it’s like to use your own software is the easiest way to understand your user’s wants and needs.

2)   Bigger isn’t always better

Products are as much defined by what they lack as what they have.  Simplicity is a selling point and packing in more features isn’t always the right move.

3)   Ideas are cheap – it’s all about execution

Ideas are a dime-a-dozen, it’s what you’re actually able to accomplish that matters.

4)   Know what you believe in

Whole Foods believes in selling the highest quality natural and organic products – they don’t sell Coke or Snickers because that would go against their values.  Values streamline the decision making process.  Whole Foods doesn’t debate each quarter which products they should carry – their values guide them to the right answers quickly.

5)   Always know the vision you’re serving

Hold your vision very close and make sure everyone knows your long-term goals.  At 37 Signals, their mission is to serve small companies with simple products.  This clear vision makes it easy to dismiss advanced feature requests meant to serve bigger, more complex clients.

6)   Keep things small and agile whenever possible

Adding more people to work on a single project comes at a huge cost – more overhead.  Keep things as small as possible for as long as possible.

7)   Do a few things well rather than everything poorly

Focus, focus, focus.

8)   Decide on the details later

Don’t let the details slow you down.  Start planning a project at a high level and fill in the details as you go.  Often times you’ll find that once you dive in, the details start to work themselves out.

9)   Don’t write down product feedback

Writing down detailed product feedback is a waste of time.  Real product issues will come up time and time again.  If the issues are really important, you’ll have them memorized.

10)   Ignore the competition

If you’re always chasing the competition, you’ll always be behind.  Focus on the user and the problem, not the competition.  Don’t worry about things you can’t control.

More to come on Product Management soon.  In the mean time, let me know what you think about these lessons.

Rework – Lessons in Product Management
  • I think that the process you follow depends significantly on the consequences when things go wrong.

    If you’re building a non-critical website, where the worse thing that might happen if you go down for a day or so is some irate customers and perhaps a few cancellations, you can live in a fast-moving, high-risk world. Why? Because risk * consequence is low.

    Seems to apply to the other advice. “Do a few things well” is essential when you’re selling a web app to a large number of people, because you’re selling a single-purpose tool and there are returns to being best-in-class. Same with “small and agile” (time to market is, like, a few minutes); etc.

    For “don’t write down product feedback” – well, I’m not sure about that. I think it depends on your user base, and how much they provide (and repeat) feedback. On the other hand, if you receive a report from a large organization that files very few, and it obviously took a fair amount of work, you might be inclined to pay quite a bit of attention.

    Or: if you take small amounts of money from many people, sure: treat all customers equally and use frequency as a driving metric (just don’t become naval-gazing). But if you have a differentiated product strategy with some customers providing more than a few percent of your annual revenue, treat the differently.

    Honestly, I think that product management is challenging because it involves a clear understanding between product, customers, and competition. And that’s going to be a function of your customers latency in purchasing decisions, the length of the development cycle, the actual versus perceived need from the customer, the market expectations set by competitors, etc. A lot of stuff that’s very specific to each situation.

    The advice from the book seems to be: “Hey, we did this and it worked, so here’s the tl;dr version that you can apply yourself!”

    Just don’t fall into the cargo cult, i.e. some process worked once, so instead of understanding why/how repeat the same steps in the recipe and hope for results.

  • I’ve been meaning to get to Rework. Given the 10 lessons you shared from the book, I find it amazing that it took Jason and David waited so long to ditch all their ancillary projects and focus 100% on Basecamp!