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:
- Accordingly to the annual portfolio plan, it was time to kickoff Project A.
- A project manager would be assigned, and begin to work with department managers for resources for the project. It didn’t matter that most folks were still working on other late running projects – the project was going to start on time darn it!
- The project manager would assemble a kickoff meeting, recap the goal from the annual plan and the team members would start the project process – define requirements, create the UX/UI artifacts, develop the code, test the code and then release it out to production.
- Throughout the process, the team would look to the project manager to command and control them. There was no ownership of the “project” within the team, that was the project manager’s responsibility. The project manager understood why the team was doing what they were doing and everyone (including the project manager) assumed that the work was valuable to the market and consumers. Because of that, there was little to no upfront validation of the ideas.
- Change management processes were heavy because any delays to the project being worked on would likely delay later projects on the annual plan, and it’s all about executing the annual plan.
- Once the project was done, the team members would disband and individuals would start to work on new projects. Any learnings of working with each other were also lost. Teams would need to go through Tuckman’s four stages of team formation – forming, storming, norming and performing.
- Ideas were validated with the customer in production (the most expensive way possible), and because the team had already disbanded, there wasn’t anyone to receive the feedback and adapt the work accordingly.
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.
- The focus is on the value (product) being delivered to the market, not the process.
- The product-based (product delivery) teams are focused on a particular area of the product and given goals/outcomes to be achieved, not features, with Key Performance Indicators (KPIs) associated with them. This creates ownership and accountability for the team to meet their goals.
- The teams have all the skills on the team that they need to reach their goals, and the teams are durable. With some exceptions, team members do not swap teams.
- Using Discovery techniques, the teams validate ideas with their customers and market before they begin to build. By using lightweight (cheaper) prototypes, teams can better understand needs before launching into a full-scale (expensive) development effort on an unproven idea, which allows for safer “bets” for how the team invests their time.
- Team success is measured by their outcomes and how they do against their KPIs. I’ve even seen HR policies change where bonus criteria is more heavily weighted to team outcomes vs. individual contribution.
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:
- Marty Cagan’s Inspired v2 (for a preview, you can also check out this post)
- Evan Leyborn’s #NoProjects work, including his presentation at PMI’s Global Conference in 2017. He also recently published the #NoProjects book, where I was fortunate that he asked me to write a case study on how to support this model with budgeting and capitalization.
- Joshua Arnold also has great stuff, including his presentation from Agile2017 – The Agile PMO, Six Things You Need to Nail (my recap can be found here).
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