PMO Directors Series: Thoughts on the evolution to product-based teams in 10 Steps

Note: You’ll notice that I’m not including any posts on “how to sell this concept to executive leadership.” That’s because I’m assuming that the transformation has likely kicked off and you, as the PMO Director, have been brought in as part of the leadership team to help with the execution. The only caveat I make is that whatever transformation the company is going through, if it’s a tech product, please be an advocate for product based teams at their core: durable, cross-functional teams aligned to a goal/outcome. If the transformation is simply to implement Scrum (or some other agile process), then your organization will be missing a substantial part.

Okay – so now you and your leadership have bought in to durable, cross-functional product delivery teams. What do you do?

Below are some first steps – all of which can be done while your team members are working on their current projects. The new framework needs to be about 90% baked before any implementation can start – otherwise you’ll burn cycles with a number of unknowns, confuse team members and have some opportunity cost by disrupting the work in-flight.

• Step 1 – get your product and engineering (and maybe UX/Design) leadership at the table and look at your product offering holistically. How could ownership of areas be carved up to be given to the teams to own and improve? Don’t worry about priority yet, just figure out distinct areas where domains can be owned within the product as a whole (I’ll get into the governance of the entire product in another post).
• Step 2 – Once you have your list, where do you need to prioritize investment? That can mean continuing to improve/evolve something that’s currently working, something that needs some attentioin and/or a new domain that hasn’t been explored yet. Set Goals/Outcomes and Key Performance Indicators (KPIs) for each of the teams/areas.
• Step 3 – Once you have your prioritized list of domains/product areas, flag any areas that need specialized skillsets and note what that skill set is.

Note: You’re probably thinking – what about infrastructure and traditional backend teams that do the “guts” to support the work of the front-end teams. There are a variety of ways to organize this work, and I’m only focusing on what are traditionally “feature” teams in this post.

• Step 4 – Next look at your organization, and start with those who would function as the Product person on the teams (note, I’m not getting into whether this role is a Product Manager, Product Owner, Mini-CEO, etc – the title is irrelevant at this point). Constrain the number of product delivery teams to the number of Product persons you have because a product delivery team without product representation will not set you up for success.
• Step 5 – Align your Product persons with the prioritized list of product areas (put names in boxes) – this is where skill sets, domain expertise, knowledge about the product/company come into play. Go as deep into your prioritized list as you feel comfortable.
• Step 6 – Now start building out the rest of the team leads – next is that Engineering person, a UX person, a “QA” person, etc. Call out any gaps where you don’t have a full lead team.
• Step 7 – Now add the non-lead roles, developers, testers, designers, etc. Also, remember to assign any special skillsets that you noted in Step 3. Use the general guideline of a full team not being bigger than 6 to 8 people (including leads). This is also where you assign project managers. A project manager can usually handle anywhere from 2-3 teams at the beginning, and then up to six when the teams become more mature.
• Step 8 – How far down the list did you get? If your organization is about 100 people, you probably ended up with 8 to 10 teams, with some folks remaining in functional management roles and in infrastructure/BE roles. I’ll also go into functional and discipline management vs. work management in subsequent posts.
• Step 9 – Now you have the end state and gaps where you can prioritize recruiting (bet you didn’t anticipate that as a benefit!). Take a look at the top 3-5 priority teams to start – what are the leads (Product, Engineering, UX) currently working on? When will they begin to free up to start Discovery for their product areas? The preference would be that all three are available to start at the same time, and this may mean that some folks need to leverage the time for learning their new role while waiting for others to free up.
• Step 10 – As the leads free up, get them started on Discovery (usually the leads free up earlier than those doing the hands-on work), so that allows for some buffer time for the team members who are focused on Delivery to come in at a later point after their in-flight work is completed. Co-locate the leads and then the rest of the team members – have them sit next to each other (see the Allen Curve for the importance of physical proximity in teams), or if there are remote team members, get tech that can facilitate closeness and on-demand conversations.

Note: It may seem efficient and effective to try to convert an existing project team working on a project for a prioritized product area mid-flight; however, I have seen that go off the rails because of the mix of processes. Usually, it was simpler to start fresh with a new set of work and mindset after wrapping up what’s in-flight.

Note 2: Also, don’t forget to look at opportunities to STOP projects that are in-flight that might not deliver on the assumed value to convert to this model. This may seem scary; however, I have seen it be the appropriate call to get the team working on higher value activities, especially validating assumptions in Discovery.

So, as a PMO Director, where do you get involved? That was a long explanation that seemed to impact Product – why would I, as the PMO Director, get involved?

Well – everything that was laid out is a plan that requires knowledge and keeping track of who’s working on what; estimates of when it will be done and what the person’s next “assignment” is to be assigned to the durable product delivery team; detailing where there are gaps (i.e. risk), the budget impact from filling those gaps and managing the execution of the plan and adjusting as needed. You probably also have a point of view on skill sets needed for the teams, opinions on who is a subject matter expert is in an area and any dependencies that need to be tracked and managed.

Let’s also not forget the other teams (infrastructure and BE) that I haven’t covered – what’s the process for working with them? That needs to be defined and documented.

That’s how you can enable this transformation. Oh, and there’s also working with Finance, HR and other stakeholders to help inform them of this shift and work through any other company-wide processes that need to change, e.g. annual budget and/or capitalization. All of these require you to leverage your strong stakeholder management skills.

The transformation can also benefit from your change management and change leadership skills, as well as your eye for continuous improvement once the changes begin to be implemented.

There’s plenty of work for you – if you’re up for it. Product and UX leadership will need to ensure that their teams are master Discoverers, Engineering leadership has a host of work that needs to be done to remove coding dependencies and allow for teams to work autonomously (especially if the current state is a monolithic codebase situation). You can also begin to define the operating model: What’s the framework for monitoring how the teams are doing against their KPIs? How is there transparency and communication regarding what teams are all currently working on, their needs and their major decisions? The answers to these latter questions will depend on your organization needs.

The next post is on other activities that need to take place to support this transition.

Previous: Product-Based vs. Project-Based      Next: Other activities to support the transition

Shortcut: All PMO Directors Series Posts