Site icon Joanna Vahlsing, PMP

PMO Directors Series: Product-Based vs. Project-Based Work

Note: This post is specifically for tech product development work. There will be subsequent posts on how work is managed in non-tech product development situations. I’m starting with tech product development work because it’s the area where PMOs need to evolve the most in order to support tech product delivery. I’ve included go-to-market activities in my definition of “done” for work, so any marketing, sales training and/or customer communications are considered.

One of my early and biggest “Aha” moments was when I realized the goals weren’t about the process, it was about the product. So much of how the teams operated was project-based, meaning, a group of people came together for a set period of time (with a set budget) and a vague goal about the project that was placed on the annual plan months prior. The product is what provides the value for the customer, whether it’s a software application or a service.

Project-Based Work Management

The usual project-based process looked something like this:

If the goal of an organization is “building the thing right,” this type of process will mostly work because it focuses on a repeatable, somewhat predictable, process – and it felt good, safe and predictable. However, it doesn’t factor in whether the work is “the right thing” and/or “if the value is being delivered when it needs to be based on the market,” and it’s a sure way for a company to be superseded by one that is focused on the customer and creating products customers love (when they need them).

Product-Based Work Management

The following is a summary of product-based work management, however, my suggestion would be to dig deeper into this area vs. me going to the very low levels of the approach.

To give an example, let’s say the technology product is a subscription website that offers tools, content and community to subscribers. One product delivery team is focused on the sign-up/conversation funnel. An easy KPI might be to increase conversation rate from X to Y by Z timeframe (e.g. Q2, EOY) because that would increase the number of subscribers with a certain lifetime value, directly tied to the company’s top line revenues.

The team isn’t charged with “implementing PayPal,” their goals are simply to improve the conversion funnel by a certain amount. They can work with their customers to understand what tactics are required to do that – are there barriers (i.e. is the UX clunky), tech debt/bugs, new payment methods needed, is it confusing, are there trust issues with handing over credit card info, is it cumbersome, etc?

Because the team is durable and charged with an outcome, they have the autonomy and empowerment to decide how to achieve that goal. The cross-functional team where the Product person has an opinion on value, the Engineering person has an opinion on feasibility and the UX person has an opinion on usability. (Note: I intentionally left off any titles here).

The team can then get into a cycle where they’re constantly learning and adapting their work to meet their goals and customer’s needs.

There are a number of books and articles on product-based teams and work management. My favorites are:

Hopefully, this helps better understand the mindset shift that needs to happen. Notice that I haven’t gotten into any of the mechanics yet because it’s this shift that needs to happen at the highest levels before any of the various tactics would be successful.

Subsequent posts focus on how to help shift this mindset and answer some common questions like annual planning, budget management (and capitalization), compliance, etc.

As always, if you have any questions, just ask.

Previous: My Story                                                     Next: Evolution to Product-Based Teams

Shortcut: All PMO Directors Series Posts

Exit mobile version