Practical Prioritisation

Dwight D Eisenhower famously said in 1954 “What is important is seldom urgent, and what is urgent is seldom important”. It seems he did not invent the idea. He merely articulated it. And this has left a significant mark on how managers have prioritised team efforts ever since.

More recently, Stephen Covey popularised this as a time management quadrant. Covey considered tasks according to importance and urgency and drew a prioritisation quadrant.

Covey Quadrants.jpg

The trick to using the prioritisation quadrant is to put every entry in your To Do list into one of the four quadrants.

  • Quadrant 1: Necessary
    Important tasks (you must do them) that are urgent (they have deadlines you do not control). You have no choice but to get them done, but they may not get you closer to important goals. Things like completing timesheets on time, submitting a tender for a new project, filing expense reports, and taking the bins out on collection night.
  • Quadrant 2: Where the magic happens
    Important tasks that are not urgent. These are strategic tasks directed toward goals. Things like exercise, planning, strengthening relationships, relaxing, and deep thinking. You should maximise the time you spend here. You might impose deadlines on these tasks, but that is your choice.
  • Quadrant 3: Distractions
    Unimportant tasks that are urgent. They do not align with your goals. Things like attending unnecessary meetings, checking your Facebook feed several times during the day, or producing reports that no one reads. Clearly you should minimise time spent here.
  • Quadrant 4: Waste of time
    Unimportant tasks that are not urgent. Things like checking your Facebook feed every 15 minutes or blankly watching TV for hours in the evening. These are a waste of time, so you should just not do them.

Then sort your To Do list as follows:

  1. Plan to spend as much quality time as possible in Q2. For example, if you are a morning person, block off periods to work on Q2 tasks first thing in the morning.
  2. Use gaps in quality time to tick off tasks in Q1. You need to plan time in your schedule to do the important urgent stuff.
  3. Minimise distractions (Q3), and only allow yourself to do these at certain times of the day, for example immediately after lunch or afternoon tea.
  4. Avoid anything in Q4 like the plague. If a task is important and not urgent, you don’t need to do it, so remove these tasks from your To Do list. If it is important to you, promote it to Q1 or Q2.

That’s all there is to it.

Now, let’s look at the prioritisation quadrants, as interpreted for Product Managers.

How do you prioritise a feature request? For our purposes here, let’s assume you have a way to decide how important and how urgent a feature request is (that’s a topic for another time).

Here’s the advice, reduced to a modified quadrant diagram.

PM Quadrants.jpg

  • Quadrant 1: Necessary
    Escalate it and do it now. If a feature really is important and urgent, you’ll need to get it done ASAP. An example might be to close a loophole in GDPR compliance.
  • Quadrant 2: Where the magic happens
    Plan for it in your roadmap. Your product roadmap should be an ordered list of these features. Important but not urgent. In other words, these features are aligned with your strategic goals, where you determine the timing.
  • Quadrant 3: Distractions
    Try to delay or delegate things that distract the team from what really matters. An example might be where a feature request is required to sell to one important new customer, but the feature is not aligned with your strategic goals.
  • Quadrant 4: Waste of time
    Just say no. These are features that make the product more complex, more disjointed, or less aligned with your strategic goals. You don’t need them in your life.

Clearly the quadrant approach is a simplified view of prioritisation, when it comes to product feature requests. However, it is a good place to start if too many feature requests are overwhelming your planning efforts.

The key thing to focus on is optimising the time you and your team spend in Q2. At the end of the day, that’s where the magic happens!

Org Structure: You Get What You Wish For

Alfred Chandler of the Harvard Business School famously wrote in 1977 that “structure follows strategy”. In the types of companies around for the first three quarters of the 20th century – big players in “bricks & mortar” such as oil companies and industrial manufacturers – this was sound advice. Organisation structure was put in place to enable execution of the organisation’s strategy.

Typical of the time were “command and control” models, steered from the top down, and continually homing in on being a well-oiled machine with perfect repetition as the end goal:

Org 1

In large forward-thinking organisations, this also led to divisional structures, where each division owned a product or brand or market sector, and had autonomy over functions such as marketing, sales and service:

Org 2.png

This naturally led to the development of the product management function – product management being the management of a product (or brand) and everything related to getting the product (or brand) out into the market and successfully used.

Software products are different. Separating product management from product development is not feasible, for several reasons.

  1. Software products are typically innovations that have never been seen before, so the proper product or solution is only arrived at incrementally and in response to customer feedback and continuous change
  2. Product development never ends
  3. The marginal cost of “manufacturing” (or duplicating additional software) approaches zero, so therefore product management need not spend time on manufacturing because it simply does not exist

As a result, a more feasible organisation structure is to embed product creation into the product management function, an equal partner alongside marketing, sales and services:

Org 3.png

Is Chandler’s famous assertion that “structure follows strategy” really true, in the new world of software products? Given the new paradigm that combines continuous product development and change with the other product management disciplines, perhaps a better way is to flip this assertion on its head. Perhaps strategy follows structure. Another way to say this is “you get what you wish for”, at least when it comes to optimal organisation structures for product management.

How is your organisation structured? Does product creation (development) live in a separate vertical, perhaps called “Engineering” or “Technology”? Does this lead to disconnects between marketing, sales, services and product development?

It is time to rethink traditional organisation structure, because in many cases they are ensuring structure is not following strategy!