Top 5 books for aspiring Agile Product Managers

After many years of working as a product manager and managing product managers in agile and non-agile environments I have become ever more convinced that the agile model could enhance almost any project out there. Heck, I even ended up planning my wedding by applying the very same agile principles that I used to build products (it worked out pretty well, since you’re asking).

But when an old colleague of mine asked me recently what books to recommend to product managers in his new company that wanted to make the transition into agile, I realised to my surprise that I didn’t have a good reading list at hand as much of my learning in the early days of agile has come from on-the-spot training, experimenting, and discussing with people who were passionate about agile. So I asked a few agile rock stars around the block and put my own favourites into the mix to give my old colleague and you this list of “Top 5 books for aspiring Agile Product Managers”.

1. Getting Real, by 37 Signals
I always end up recommending Getting Real to everyone who works with me. This is an incredibly insightful piece of condensed real work experience and an eye opener for most people. It will give you excellent reasons to believe in the 80/20 rule of product development (80 percent of the value comes from 20 percent of the features) and you will never want to write a functional requirement document again – although there might still be good reasons why you would have to sometimes. On top of that, the book is available for free on so it is great for sharing with the guy in the corner who still can’t see the point of aiming for the set of Minimum Marketable Features and is too cheap to buy a book to find out. If you can’t get enough of 37 Signals, their new book “Rework” is also good, but not as great as this one.

2. Agile Product Management with Scrum, by Roman Pichler
This book is the latest and greatest intro to the role of the “Product owner” as the product manager is called in the most common of agile process, Scrum. Written by one of the leading Scrum consultants out there this book gives you a good sense of what the product owner role is all about and all the tools you need to do the role. Probably the best single reference guide on this list.

3. Inspired: How To Create Products Customers Love, by Marty Cagan
This great read by seasoned product manager Marty Cagan includes all the basic elements of solid product management that will help you understand how product management fits into the bigger picture of business. More importantly the advice given is in line with the principles of agile and is a great source of practical advice for aspiring agile product managers working for larger organisations. Marty Cagan also gives great advice on the that every agile product manager should subscribe to for a weekly dose of reflection.

4. The Inmates Are Running the Asylum, by Alan Cooper
Alan Cooper has had a profound impact on how the world builds software by pioneering the user centered approach to software development. I must admit I’ve never actually read this book of his, but it comes highly recommended by my old colleague and ex-ZYB’er (now Googler) who said something in the lines of this being the single book that had taught him everything he knew about software development (which is a lot!).

5. Agile Project Management with Scrum, by Ken Schwaber
As an aspiring agile product manager you might find yourself in a place where you need to bring the rest of the organisation along with you on the journey towards agile, so agile project management skills often come in handy. This book is a great hands-on guide to implementing Scrum in your organisation and running an agile process. It’s even written by the one of the “founding fathers” of the Scrum process so it stays true to the original principles of agile.

Words of agile advice
I hope you’ll find this list useful as a starting point to learn the agile method and then liberate yourself from it again to develop your own approach to agile that works for you and your team. The thing is, rigorous methodological approaches don’t really do the trick for product management. So much of this discipline is an art more than it is a predictable process, so general mindsets and frameworks tend to work better than strict processes. However, if you are new to the agile way of working, it’s good to familiarise yourself with a process and structure your work according to it – personally I recommend starting with Scrum. Just don’t be religious about it as this would defeat the most important : “Valuing individuals and interactions over processes and tools”

The best agile blogs
As a good supplement to the books mentioned you could also check out these leading agile blogs

Extra: The other 5 books you also could read as an aspiring Agile Product Manager

Mastering the principles of the agile approach and process is only a small part of the very broad skill set required for a great agile product manager. Here are 5 of my personal sources of inspiration from different fields that all relate to product management in some way:

Getting Things Done When You Are Not in Charge, by Geoffrey Bellman – because as a product manager you are almost never the formal line manager of the people who will actually build your product

101 things I learned in Architecture school, by Matthew Frederick – because architecture is the most closely related field to product management (and has been around for much longer)

Crossing the Chasm, by Geoffrey A. Moore – because you don’t just want to build a product. You want everyone out there to use it, don’t you?

What Would Google Do, by Jeff Jarvis – because the internet demands new product strategies. Why not learn it from the best and ask WWGD?

The Design of Everyday Things, by Donald Norman – because a great product manager needs to understand the basic principles of usability and human-computer interaction. These principles were laid out already in the 80’ies and everything said about usability since is just chrome on top of the fundamentals you will find in this book.

Feel free to add your own reading suggestions below!

Thanks to for inputs to this post.


Posted in Uncategorized | 1 Comment

How to build a product in 100 days

Last week was very busy and very rewarding for me, both personally and professionally. My wife had our second child on Tuesday (a lovely daughter) and on Thursday another “baby” of mine saw the light of day with the re-launch of – global online phone management hub. The latter came to life after a summer of very dedicated and focused work from the team who were only given three and a half months, or 100 days, to build and release it.

When 100 days is your limit it's time for ruthless prioritisation

Anyone can sign up to the new or view some to see the result which I must admit that I am very satisfied with. Those who know 360.com from previous experience will see that the re-launched version is a massive improvement compared to before. In fact, it is no exaggeration to say that we re-built the product, and we did it in time, hitting the exact schedules time for the release.

So how did we do it?

Well, first we improved the feature set without adding a single feature. Instead we took a “” to product management and removed as many features as we kept. By keeping the most important ones and letting go of the rest (including a lot of old darlings) we were able to sharpen and simplify the product dramatically. To inform the decision of what to keep and what to throw away, we looked closely at feature usage stats to identify the low performing features. If a feature was not performing we would remove it from the product backlog, unless there was a clearly indicated user need from our other sources of customer insight.

Secondly we prioritised the display of the remaining features ruthlessly and achieved a remarkable perceived product simplification by building the experience tightly around a very small set of core functionality. Knowing that less than 20% of the users ever venture beyond the most frequent use cases, we moved anything that was not needed ready-at-hand at all times out-of-the-way of the main usage path.

With only the most necessary features on display the new 360.com has a simple feel

Thirdly, we followed a strict and modular approach to product development ( see the ). As we were building the product from scratch it was possible to clearly separate the elements into smaller manageable chunks and build the product one module at a time, allowing us to react quickly to changes and adjust the scope of each module with minimal impact on the overall work, while keeping quality high and hitting within 24 hours of the planned launch time.

As most product managers in agile environments have come to learn, a well prioritised backlog and good processes will take you very far in any product development scenario. But the quality of the outcome and the very short development cycle for the re-launch of 360.com was also relying on some pre-requisites that any product manager would feel confident about. The development team is intimidatingly competent, has a very strong a customer experience focus, and generally rocks. Some of the guys are even veterans from the rock star , including the dev lead, scrum master, and product owner. On the design side the team was supported by a great Agile-embracing UX team and the impressive guys at in New York that I would recommend for any tough design task out there.

Fixing or building a product in 100 days is a tall order by any measure. But by adhering to the principles of first building the minimum marketable feature set, being as agile and empowering as you possibly can, and doing whatever it takes to get best people on board with you – you should be able to pull it off.

Posted in Uncategorized | Leave a comment

Why the best products fail

Many years ago when I was trying to figure out what I should spend my last precious time as a on (the time it takes to research and write a master thesis), my academic mentor at the time led my attention to the wonderfully simple and down-to-earth theories of that are presented in his book “The” from 1962. Out of everything I’ve ever read, nothing has influenced my thinking as a product manager more than this aging set of empirical theory about what actually defines the difference between product success and failure.

(Random product logo...)

Now Rogers wasn’t really a product guy. He wasn’t focused on how to define the right feature set or build a product that would inherently spread (or diffuse as he would call it) in a rapid way. Rather he was exploring how ideas and innovations in general tend to spread via social interaction between people and how – for most people – the decision to adopt was mostly influenced by their peers and notably not by the innovations own objective qualities.

But apart from being the father of the (the one that outlines the dynamics between Innovators, Early Adopters, Early Majority and so on), Rogers has some really great and simple points to make about product management and product marketing in general. The most simple of these being that a user’s decision to adopt or reject a new innovation or product “is always ‘right’ in the eyes of the individual who made the decision” (at least at the time the decision is made). In other words, the user is always right in his choice because his choice is based on his own perception of the product, not the objective qualities of the product.

Good products frequently fail and often those considered to be the best products within a sector or industry, from an insider standpoint, are not the most successful in the market. Why? Because users don’t evaluate products on objective terms. Instead users base their decision on their own gut feeling and recommendations from their brother-in-law (who doesn’t know anything about your product, but has more selling power than all the worlds PR and Marketing teams combined)

As a product manager it’s worth to keep this in mind and understand that more important than building a bigger set of features, a more ground breaking design, or better optimised code than your competitors, is creating the right perception in the mind of the user. To achieve this you need to take a more holistic approach to product management than most people do. Product managers, please say hello to PR, say hello to Branding, and say hello to Behavioral Psychology.

To boil this down to the essence of an executive summary, the best products fail when the user for one reason or the other, mostly through influence from peers, gets a better impression of another product – inferior as it may be to yours.

Think about this the next time you rush into the feature arms race and sacrifice everything else for getting that last feature in before the next release. You might be missing the point.

Posted in Uncategorized | 1 Comment