Tag Archives: product management

Product management

Reinforcing Success in Products and Projects

Posted on by

A fundamental military axiom is to reinforce success.

Reinforcing success is a strategic concept used in many areas of decision making and management. Originally a military doctrine, the term is also used in theories related to parenting, business and other fields. It is essentially a selection criterion, or a prioritizing principle. A course of action is selected from various options on the basis of previous results of similar actions. The basic idea is: if it works, keep doing it; if it doesn’t, don’t invest more in something that’s failing.

Wikipedia: Reinforcing Success

I believe businesses should apply this principle to projects, products and product features. So not surprisingly I apply this as a guiding principle in my own work as an agile programme manager.
Continue reading →

Requirements: State the Problem not the Solution

Posted on by

We all do it. Even those of us, like myself, who should know better do it occasionally. But it is wrong. Or if "wrong" is too strong a word, then it is at least misguided.

What is it? It is the habit of stating a solution when we should be explaining the problem. This habit isn’t confined to a specific role; I’ve seen all members of the team do this … users, product managers, project managers, business analysts, technical architects, developers, user experience designers, testers, and management stakeholders.
Continue reading →

Simon’s Critical Success Factors for a Software Release

Posted on by

I was on leave for a week and when I got back I found a new flip chart was on the wall.

Critical Success Factors when we release:

  • Functionality – Does it do the job?
  • Usability – Does it do it well?
  • Performance – Does it do it fast?
  • Evolution – Does it build smoothly on what is already there?
  • Delivery – Is it ready on time?
  • Comms / Training – Have we told people about it?

Continue reading →

Using a Product Led Matrix in Lean-Agile

Posted on by

I’ve worked in a variety of organisational settings including matrixed and non-matrixed. Based on this experience I thought I’d write up a few observations about organisational structures.

Traditionally companies have been organised into functional teams. More recently, partly as a result of Scrum and Lean for Software Engineering, companies are moving to departments containing cross functional product teams. Some organisations have a mix, for example, design might be a functional department but other departments might contain product teams. Other companies try to combine function and product into a explicit matrix structure. This ensures both product and function are represented on the management team.
Continue reading →

Difference between programme, project, portfolio and product management

Posted on by

P3M stands for "programme, portfolio and project management". Product management is a closely related discipline and as most software organisations do product development I’ll include it in the discussion.

P3M Levels: programme, project, portfolio and product management

P3M Levels:
programme, project, portfolio
and product management

That bit is simple. The tricky bit is agreeing what a project, product, portfolio or programme is. Projects and products are pretty straight forward but definitions vary quite a lot for programme and portfolio. A portfolio for some people is a set of products where for others it is a group of projects. I have, for example, met a portfolio manager who was responsible for some projects and within the same division met a another portfolio manager who was responsible for the product portfolio of the entire division. Programmes are sometimes seen as simply as a complex project or set of projects, or, more interestingly, as an initiative to deliver business benefit.
Continue reading →

Agile Project Scope

Posted on by

According to Wikipedia: Project Management project scope is:

The overall definition of what the project is supposed to accomplish, and a specific description of what the end result should be or accomplish.

We can talk about what is “in-scope”, i.e. what the project is meant to delivery, and what is “out-of-scope”, i.e. what won’t be delivered.

Typically the project scope is a subset of the scope of the product under development.
Continue reading →