Combining Classical and Agile Product Management

I was asked to present, at an interview, on how I see the role of the product manager working in an agile scrum environment. The key areas that I highlighted were:
  • Scope and responsibilities of the product manager in scrum
  • Typical product management activities in scrum
  • A typical day in the life of the agile product manager
  • The agile product management framework
  • A case study – the benefits
See full presentation below.
However since the interview/presentation and starting in the new role the company has decided to change direction and combine waterfall with scrum. The idea is that we start off in waterfall mode move into scrum and then finish in waterfall.

Since joining the first thing I noticed was that the current scrum team is being led (as opposed to the team self managing itself) by a contract technical team lead cum product manager who spends part of his time being the scrum master and part being a business analysis.

In order to bring clarity and set expectations from the start I went about working with the head of development and head of product management to define, at a real granular level, the scope of the product manager aka product owner and that of the scrum master who is currently the technical team lead.
The end result was a list of 90+ activities: starting off with documenting the product vision and ending in the release of a sprint. The activities combine classical product management with agile product management – a real hybrid taking the best of both worlds. The roles and responsibilities matrix was signed off by both heads – now the journey begins.

Next week I meet with the development in order to explore the journey we’ll take together in developing the products allocated to us.


  1. I've found this very productive! This really makes sense! Thanks for sharing this video! What I've learned truly counts!

  2. just linked this article on my facebook account. it’s a very interesting article for all.

    Scrum Process

  3. This is a great breakdown. I would say that 'a typical day' is not very relevant though:

    - requirements should be documented as soon as the relevant decision is made (not at certain hours daily)
    - reviewing&grooming the product backlog daily is counter-productive
    - meeting with marketing&sales daily is not a good idea

    All in all practices and tools should be kept to the minimum. For example, release plan and product roadmap could well be one document. Or your backlog system could be the repository for requirements also.