The Telescope vs the Microscope

It’s critical to understand how Portfolios, Programmes, Projects and Products — the 4Ps — fit together and how to navigate them in your career. Start here.

I’ve been around the product game for quite some time. I’ve also been a product owner, a project manager, a portfolio manager and a programme manager over my career, so it’s fair to say that I’ve experienced all of the ‘4Ps’. I’ve also experienced most flavours of lean and agile.

In this article, I want to offer a simple definition of each of the 4Ps and show that they share a core skill set. I then want to show the skills that you need to develop to specialise in each area and why mobility is desirable for you and your career.

Short Summary of the 4Ps

Let’s quickly define the 4Ps, so we share the same language:

Portfolio— A portfolio considers an entire organisation’s investment in technology change and allocates money to each programme, project or product needed to meet the business plan. Portfolios ensure that we spend the right money on the right things and that the investment is delivered in the right way. It plans for the long term and controls for the short-term, trading one investment off against another for overall gain. Typically, a portfolio thinks at the level of a programme, project or product and is evergreen — lasting until the organisation dies.

Programme(or program) — A programme blends business change with technology delivery, both inside and outside the organisation, to deliver a new capability. Often running for several years, programmes have multiple constituent projects, workstreams and products, but they are all bound by a single business case or vision.

Project — A project is a temporary organisation tasked with delivering technology or business change to achieve a single agreed outcome in a structured and compliant way. Irrespective of whether the outcome is delivered using an agile or waterfall methodology, the project manager is an expert at delivering against the five constraints of time, cost, quality, risk and benefit. Expertise in managing risk and compliance is the simple reason that we see project managers create products. What distinguishes a project is that it has a clear start, middle and end, which comes when the outcome is met. Although many project managers go on to manage the products they deliver, it’s not mandatory.

Product — A product is an item or service that a customer buys or a user uses to meet a specific purpose. What distinguishes a product is whilst it also has a start, middle and end, the end of a product comes when it is no longer needed, not when the original outcome is achieved. Product managers, therefore, need to focus on the long-term management of the user’s needs and not just the initial outcome. In essence, they need to build the product, attract, onboard, engage and retain users until the product reaches the end of its life.

Therefore, in the 4Ps, only the portfolio is permanent.

Now we have working definitions of the 4Ps, let’s look at how the roles of portfolio, programme, project and product managers overlap and where they are distinct. To do that, we’ll use the Fried Egg Model.

The Fried Egg Model
The Fried Egg Model helps us understand many related fields and see how role descriptions are connected. There are considerable overlaps (egg whites), with the specialisms (egg yolks) being relatively small.

Activities that are common across all the 4Ps include:

Understanding the customer(s) that will be served by the Project, Product, Programme or Portfolio so that their needs and wants are known and prioritised. In many organisations, user experience (UX) or customer experience (CX) people do this full-time;
Understanding the business and how their activities fit into the bigger picture and help the business meet its plans;
Understanding internal and external stakeholders, including their needs and attitudes towards your work;
Aligning stakeholders with your strategy, goals, objectives and deliverables, to minimise disruption and maximise outcomes;
Developing a strategic and tactical roadmap that aligns with other activities being planned by the business;

Communicating intent and deliverables to allow stakeholders to challenge and accommodate your needs and to ensure dependencies are understood;
Converting strategies to plans so that delivery teams can work within the constraints of the business;
Managing budgets and costs within constraints set;
Defining Objectives and Key Results (OKRs), aligning with stakeholders, tracking progress and delivering the required outcomes;
Identifying, resolving and managing risks to outcome and delivery;
Leading multidisciplinary teams;
Getting things done in the context of the organisation. Examples of sign-offs that might be needed include legal, brand, marketing, sales, security, health & safety and so on; and Transitioning to operations.

Whilst we love the DevOps approach of ‘you build it, you support it’, only the smallest organisations can do this in reality. If you have thousands or millions of users, your DevOps teams won’t be staffing the helpdesk; you’ll have a dedicated contact centre, and they need to know how to support users.

These egg whites are relevant to all delivery leaders, irrespective of whether you deliver a simple project, an extensive programme, a software product or a billion-dollar portfolio. Where you need to develop your egg yolks is the subtle challenge that needs to be managed. Some factors you need to consider include:

1.The level of detail you can get to— a portfolio chunks down to projects, products and programmes (the ‘telescope’), whilst a product chunks down to epics, features and stories (the ‘microscope’);

2.The closeness to the customer — a product manager is the most intimate, but a portfolio manager still needs to have a solid understanding of who they serve and why;

3.The extent of the reach of their work — a portfolio manager deals with change only. A product or project manager deals with everything for their product or project only. A programme manager crosses into the business and ensures that full end-to-end capabilities are delivered, but only until the capabilities are embedded;

4.The balance of building vs operating — project managers will hand over to operations at the end of the project, whilst product managers will continue building and operating until the product is retired. Often, though, a project manager will end up being the product manager as they gain intimacy with what they’ve built;

5.The extent of cost management vs revenue management — depending on whether you’re managing an external-facing audience or an internal-facing one, you will be concerned with a different set of metrics and a different investment mindset. All four ‘P’s can face outwards and need to balance investment vs revenue, but they all also face inwards and need to balance investment vs uptake, compliance, or other measures of value generated;

6.The extent of customer choice — if your product is the company’s ERP system, then your customers don’t have a choice. They use your tools, or they choose a new employer. However, if your product is an e-banking app, they can genuinely decide to call instead or move to a new bank. The extent of choice is essential in the emphasis of how we apply our skills. Still, all Ps need to ensure that their users have a positive experience, taking as little time as possible to do their activities and continue using the tool in future;

7.The extent of buy vs build — can you be a product manager if you’re using a Software-as-a-Service product from somewhere else? Yes, you can, but the challenges are different (and more difficult) because you have to balance your users’ needs with the needs of your service producer and manage a relentless upgrade cycle in often complex organisations. For example, you may be the product manager for MS Teams in a 150k person organisation and explain constant tweaks to a constantly catching-up userbase. In many ways, that’s harder than being a product manager for 150k customers where you have control over every aspect of deployment and iteration;

8.The phase of capability development— once a product is in users’ hands — particularly customers — it’s live. You can’t go back. Given the need to comply with many standards, regulations and internal compliance obligations, organisations often choose a project manager to build the initial release. Project managers focus relentlessly on ensuring that what a business releases isn’t going to land them in court. Product managers focus relentlessly on what the customer needs. They aren’t always the same thing. Once a product is in the wild, a test and learn approach is practical, but I have seen otherwise outstanding products scrapped once a project team has unpicked the mess of technical debt and compliance debt that prevents scaling out or scaling up.

There are more factors to consider, but I hope that it’s clear that there is no panacea — complex organisations need a mix of portfolio, programme, project and product people to be successful and they need them to have similar and compatible skills.