The Life Of Projects In A Product Organisation
What happens to Programs and Projects when you become a product company.
I spend a lot of my profession helping companies become more customer-centric, Agile and Innovative, through the notion of becoming a product-led company. Or put it another way, helping customer implement and evolve product operating models.
What’s common from customer feedback directly and public feedback, especially since writing a Forbes post on Transforming The PMO (Project/Program) Into A PPO (Product Portfolio Office) To Become A Product-Driven Enterprise, is the question around what happens to Projects when you become a product company ?
Interestingly this becomes a hotly debated topic where some assumptions include that there are no places for projects in product organisations, usually with the assertion that product teams discover their own value and focus on outcomes not outputs. To that sentiment I would heed caution to the risk of throwing the baby out with the bathwater. So lets explore some of the areas contributing to this debate in more detail to gain a better understanding of the shift.
1. Let’s First Define A Project
At a high-level a project is an temporary event with a goal or objective, which is often weighted towards the deliverables or requirements. A defined goal or initiative is established, and resources are brought together to deliver the specifications, typically with a desired or target date for completion. When the project is delivered, the resources are released or disbanded, or assigned to another project.
2. Let’s Define A Product
A product is a defined entity with provides value by solving or reducing the limitations of specific customer or user problem or need. I extend this to mean solving the identified problems or needs repeatedly, or on an ongoing basis. This can also mean a product could encapsulate a Service or Platform as well, where these are a form of product. This can include physical or digital solutions.
The notion of providing value over time is a key factor, as for me this is an important distinction to delineate the difference between a product, project and a bespoke service - see Solution Ratio Model.
3. Let’s Explore Product Relationships And Dependencies
When you look at most if not all customer facing products, they are the sum of many parts. This surfaces the distinction between Product (P) which is the entity the customer pulls, to product (p) which are the internal products, platforms, component and services which make up the sum of the whole. This distinction is very important, because it will directly impact your companies Product Operating Model design and culture.
When looking at the component product level (internal products), these can consume and/or serve many other internal or customer facing products and therefore many customers as well. The relationships between these are vital to call out, as they impact the delivery, risk and cost for their customers and subsequent value-streams.
4. Let’s Explore Initiatives And Events
Whether you have a project or product culture, your business operates in an environment which will inherit events, or factors which are time based which could significantly impact your top line growth. Here are just some examples of what I mean by events :
a. Seasonality - Shifts in consumer spending behaviour over time. Consider summer fashion trends, winter Christmas spending patterns etc. You could also consider sport seasons such as F1, Football etc.
b. Marketing Events - Specific events to promote spending. Think of Easter or January Sales, Amazon’s Black Friday or specific Marketing campaigns and events.
c. Build Initiatives - Specific events where investment is made to achieve a result by a given time. This could be physically building a store to open by a given time, developing a new capability etc.
Whichever resonates with you from the above, environmental events and opportunities will exist and require recognition to maximise the potential of tapping into customer behaviours.
5. Project & Product Governance Defines Culture
Many companies today, even those that profess to be Agile, are Project Driven. They bring the teams to the work, not the work to the teams, and they track roadmaps and deliverables in a more output and requirement way. Iterating against a plan which rarely changes is not business agility in my opinion. A lot of the time the product roadmaps are pretty static and the feedback loops are minimum. The PMO in these environments, focus mostly on commissioning projects and initiatives and manage the costs, variance ,dependencies and risks around these.
When companies are deemed to be more product driven, there is a shift from passengers to drivers. Product teams are formed and have Ownership of how to achieve results and innovate. Work is brought to the teams, and the teams are stable and empowered to find new ways to solve the problem and learn. In this environment, plans are more akin to objectives and are more directional than prescriptive. This is where the Product Portfolio Office adds value as it lifts up lower controls and features to objectives and outcomes/ goals.
Can And Should Projects And Products Co-Exist ?
Yes Indeed! Not only that but so does some degree of planning. A product organisation is not one which creates factions of rogue states, this is a sure fire way for waste and inefficiencies to creep in. The balance needs to be struck where Products are owned by stable product teams, and these teams are informed and are guided by strategic objectives. And as raised in point 4 above, environmental events around customer behaviour present opportunities, which need to be co-ordinated exist.
It’s here the balance is struck. Product teams are focused, have clear ownership and with that provide clearer stable topologies. It’s clearer who makes decisions, who owns what and how and where to interface between each. They have flexibility to the How? when solving problems and analysing feedback, which informs the What? And all of this feedback and learning informs the Why?
Projects in this environment are higher level, where programs and projects help co-ordinate/observe products teams move towards goals, around events. If a company sets a goal to capitalise on an event (e.g. Amazon’s Black Friday), many product teams will need to work together to achieve the goal. A capability is needed to orientate this level, and it’s not efficient to push this down into small internal product team who has a marginal view of the functional spread of the organisation and impact of larger goals, hence the need for a PPO.
Programs and initiatives can be complicated to manage and required co-ordinated management to connect aggregated views for performance and cohesion. Program management can help here and add significant value, freeing up product teams in terms of effort to develop, iterate and learn close to the customer. But these programs don’t prescribe detailed requirements to products teams.
An Example :
A project in a product company (High-Level) could be where for instance a supermarket has an initiative to say reduce refrigeration costs for 20%. The initiative would impact all the product teams who deal with cold storage from supply-chain and refrigeration areas. In a product company it would be very clear which teams are impacted, and they could be brought into the fold for exploration to inform the idea. They plan together and inform the art of the possible.
These product teams would be able to explore and inform the potential for changes to reduce cost and the feedback is continuous and evolving. They don’t need to be prescribed detailed requirements, but high-level objectives and relevant details of success. The initiative or project is established, context set and a close relationship is managed with a collective product team-topology and taxonomy. If the data is mature these product teams can set their own KPI’s and these can be aggregated into the project performance dashboard. A PPO would be able to report on progress, each product team has it’s own release cycle and is de-coupled so can move quickly or easily and makes it’s own decisions. Obviously where the campaign is more customer facing such as branding change etc, then the required detail from program leads would need more information.
Summary
Shifting to a product driven culture has significant performance benefits for company performance and culture when it comes to innovation, centric, employee engagement and more. However establishing product teams and promoting Agility, doesn’t mean that projects don’t exist. There is a shift in the granularity and role of projects, which play a higher level, more strategic role. Projects co-ordinate value deliver against company strategic objectives, initiatives and events. And managing product performance over the long term is a developed capability which is openly communicated through the organisational layers.