Dominica DeGrandis

This talk comes in response to many people asking questions about how they should organize their teams when they are moving to a product-centric way of working. The questions revolve around: what roles do we need? What skills do we need? What kind of knowledge do we need to bring to the team?

As I have been working with large enterprises as they start this journey and go through this transformation, it has become evident that there are new roles emerging to help make it run smoother, faster, and all around easier. That is what this talk is about today.

I spend a good amount of time facilitating exercises and designing experiments to improve flow, to enable change. Nothing provokes a good conversation more than putting some data up there and having people try to prove it or not. That is what I do in my new role now as Principal Flow Engineer at Tasktop. Flow Advisor at Tasktop. Oh, the engineer stuck in there, didn't it?

The project-to-product movement is clearly cooking. About half the talks at DOES London in June mentioned it in some fashion, one way or another. The project-to-product pivot is becoming a movement, and it is a movement that is useful to transform the way organizations work, and one that CIOs are starting to see as critical to their success.

But what does project to product really mean? There is this fantastic book that Mik Kersten wrote on the topic, but I am going to give you my 90-second summary of the takeaways.

The first one is that the product team's job is to create business value. By value, I mean whatever it is that makes your company successful. It might be profit, revenue, risk reduction, or the number of lives saved. Mark Schwartz wrote this book called "The Art of Business Value" that goes into every detail about what value means, so you can dive deep in there, but to me it is whatever matters to your company.

This is very different than optimizing for scope, budget, and schedule the way project-centric projects are managed.

Second up is that with products, work is brought to cross-functional teams that stay together over the long haul. They are not split up to go work on another short-lived project once a bit of functionality has been delivered.

Lastly, but maybe most importantly, shifting your thinking from project to product allows you to shift your thinking on your cost centers. When you move from project to product, you move from cost-center thinking to product-center, to profit-center thinking, where the teams that actually build, deliver, deploy, and maintain the product can be invested in.

There are a couple other good reasons for this shift. Here are two of my favorites. One is that there are fewer dependencies from fewer conflicting priorities. Two is that the focus is on business outcomes and not activities. Activities essentially involve counting.

Let's look at this. Because projects come and go, you have a relatively big batch of work that gets handed off to a different team, and they need to sustain it, while the previous project folks run off to work on another project that they were probably supposed to start working on two weeks ago.

Unless there is really good documentation, that handoff is not smooth, or the details tend to get lost. Raise your hand if you receive really good documentation when you are handed off work. Yeah. Okay.

Now people are wondering, where do I find the configuration settings? They have to go interrupt the previous project people to get that information. There are a lot of interruptions that occur. Should I work on the old project or the new project? What is my priority supposed to be?

Then you have three out of the five time thieves trolling you after projects get handed off because of context switching, unplanned work, conflicting priorities, and invisible dependencies.

When you manage work by product, you get to keep that domain knowledge in-house because you keep the team together. It is not handed off. There are fewer dependencies. I am not saying we are going to get rid of all the dependencies, but we can reduce some of the most costly coordination-type dependencies. Keep in mind, every dependency increases the risk of starting something late or finishing something late by 50%.

With projects, people are brought to the work. They are treated sort of like fungible, interchangeable resources. Versus when you bring the work to the people, the people are treated as knowledge workers with their expertise. You know exactly who to bring the work to. You bring it to the product teams, the product group. They have the expertise needed to modify and maintain the product.

Next up, product teams live and die by generating business value. As such, we measure product value streams by business outcomes. When you make value visible, it is going to provoke these necessary conversations for change. From a visibility perspective, the metrics that we capture for product value streams focus on what really matters, and that is the business needs. They need to go fast, they need to deliver it so that it works right, and they need to not burn their teams out while doing that. We need to maintain sustainable work so people can remain happy.

Versus, if you look at the red-yellow-green report, it represents opinions. I think it is an "I don't want to get yelled at" opinion, too.

I did a stint at a PMO for a very large telecom. I was a project manager, and I once submitted a project report that had red in it. A VP promptly called me into the office and embarrassed me, or pretty much shamed me, in front of a lot of other leaders, saying that it really was not red. That is why they call these watermelon reports, because a lot of people know they are red on the inside but green on the outside.

Did I mark another project report red again? No. I updated my resume.

I think there is a lot of change happening in PMO with the way things are getting reported. We do still see a lot of red-yellow-green reports, but I was doing a talk at an event just last week and there were a couple of project managers there. They voiced a concern of feeling like their jobs were at risk. It is sort of like PMO is walking through a minefield, having to justify their value.

I was just talking to somebody this morning who said they were talking with their senior director of their program management office, who is terrified, that those teams are terrified of losing their jobs with this new shift from project to product.

I can surely empathize with that because my job went away. I think the writing was on the wall back in 2006, 2007, 2008, as the build and release team. We were pretty much automating our way out of work. We were automating builds, automating deployments, and our releases were smaller. We had consumed a lot of our time with branch-and-merge strategies and our configuration management tools, and that was starting to go away. That expertise was no longer needed.

I think this is the nature of working in technology. We constantly have to reinvent ourselves as jobs change, as evidenced here by this World Economic Forum chart about the future of jobs survey, which shows how new technology changes the job market.

If you are a PM, PM as in project manager, or you have project managers that report to you, what are you seeing? Do you see fearful, nervous people updating their resumes?

If we look at roles, they come and go. The full-stack engineer role has only been around for about 10 years. According to this Stack Overflow survey, developers who consider themselves full-stack engineers have doubled over the last six years. But now that seems to be changing. There is a new white paper that was just published on it that I was delighted and honored to be part of, on why the full-stack engineer role can be problematic.

What we found was that the probability of finding people who actually have knowledge of the entire stack is not very high. When you do find them, they have no availability because they are all at Netflix.

Cognitively, we know the human brain just cannot do it all at the same time. Physicians do not have all the knowledge and experience needed to know everything there is about the human body. You have to go see a specialist, a medical specialist. Do developers really know everything there is to know about today's stacks in a large enterprise?

The guidance from the paper basically is we need better cross-team communication and to avoid making one person responsible for everything.

What does this mean for the PMO? Remember, the whole point of project to product is to improve business value. It makes sense that if you are going to transition from a scope-based outcome to a value-based outcome, the PMO would transition to effectively optimize business outcomes at the program level.

We are starting to see organizations whose PMO is transitioning into a VMO, a value management office or value management organization. PMO can be part of this shift because they bring strong business relationships and business knowledge to the table, and they have skills that transfer over. They know vendor management, risk management, cost management, and revenue management. These skills make a difference, and I think they can be applied in a product model that is focused on driving value.

Kristen Biddulph has a talk out there on making work product-centric up on YouTube, where she talks about their journey and how they looped in other people upstream of their teams to optimize their workflow.

I think there is opportunity for project managers and program managers to make a move to product. These new emerging roles are going to offer some of that career growth.

There are three new roles: Value Stream Architect, Value Stream Product Lead, and Product Journey Owner.

When we first start out, we have the team together and we are doing some exercises, and people want to know, "Who's supposed to be on the team? Who should I bring to this workshop, Dominica?" I say, bring your team, or if it is too huge, bring a nice representation of your team. Bring people who are upstream from you and people who are downstream from you. Bring somebody who knows the product really well. Bring your customer or bring somebody close to your customer, and that is a really good start.

As they continue on this journey, and start to invite teams that are further upstream and further downstream, we discover that there are gaps on the team that these new roles start to fill.

Value Stream Architect is finally a role that is focused on optimizing the flow of the value stream, of the tools that are used to develop your products. It is not an architecture role in the sense of how to structure software components or identify implications of new tech. It is a role that is more about optimizing the pipeline itself.

But it is not just about speed. There is an emphasis on speed. We heard a talk earlier this morning that said it is all about speed. Speed is very important, but it is also about visibility, because one of the number one complaints we hear from our customers upstream is, "Where's my thing? I can't see where my thing is. It's invisible."

It is bringing this business-level visibility into the flow, and that is something PMO has been asking for ages, getting more visibility because a lot of the work has been invisible. I would think that would be a dream come true for PMs, to have this kind of visibility.

The VSA role is also about ensuring good feedback occurs so we can catch problems earlier, and then driving experiments for improvement. Value Stream Architect is an optimizer for sure. They study bottlenecks. They are familiar with the theory of constraints.

They are also an influencer because they are going to be putting stuff in the product backlog, but in order to get that approved and prioritized, you have to have support upstream from product owners or businesspeople. They need to be in a position of influence to do that.

They are part consultant because they are working with product owners and product managers to drive change and higher-level decisions about workflow tooling. For example, if you have multiple value streams and a product value stream that are dependent on each other, but they use different tools, how do you get visibility on the relationship between parent and child work items across that value stream?

Here is a picture to represent that. You could have an application platform, and the output of that is a product that is used by your external consumers or used by other developers to build upon.

There is a quote from Satya Nadella here about the most important thing for an engineer to work on is a system that drives productivity. It is the tools that we use to develop all the business on that is the important product. At BMW, it is the plant that is the most important product. It is not the cars. It is how the cars come off the assembly line. They need speed for that.

Next up is Product Journey Champion. Do not put too much weight into this job name. These are emerging. They are going to change over time. If you Google that, you will get sports ball caps.

We are out working with large enterprises, and the CIO is all bought in: yes, 100%, we are going to move from project to product. But we start working with all these program managers and project managers who, for most of their career, have managed work by projects. There is really nobody that we can partner with on that enterprise side, and that is what we hope this role can build up, so that organizations all have a product journey champion on their side.

Somebody is able to help the enterprise on their journey make this transition. They work with executives. They work with managers. It is sort of a cross-cutting, consultative role. It sits above all the product value streams. That role could maybe be part of the VMO, the value management office. They have a bit of political savviness, obviously, because they need to influence not just leadership but also practitioners.

A famous quote from Carmen DeArdo: you have a process. Are you in control of it, or is it in control of you? And the need to treat your delivery pipeline like a product.

Not that you could ever replicate a Carmen DeArdo in your organization, but I think it is so valuable to have somebody on the inside who can work versus just having an external coach try and guide you through. Somebody dedicated to coach and champion, move things forward. Somebody not afraid to point out that if you want to move faster, think about your toolchain as a product.

Then we have the Product Value Stream Lead. The emphasis here is more about a strong emphasis on the customer and team staffing. It does come with budget responsibilities. They do have intimate knowledge of products and customers. They are working to staff and level up the skills on the team. They have an emphasis on team happiness.

This is team happiness of the product value stream. It is not measuring team happiness of all the developers, or all the testers, or all the designers. It is everybody on that product value stream. How are they rating their happiness factor? That is an interesting number.

We always get asked, "Well, what about the product manager?" I tried to lay out the differences here. For the product manager, they are really focused on prioritization and feature design. The product lead is more focused on staffing and setting objectives for the team and making sure that they are getting trained up.

There may be a little bit of overlap. The product manager role has only been around for 10 to 15 years. The Product Value Stream Lead is brand new. It is emerging. We are finding that, yes, we need both. It depends on the size of your organization, but if you work in a large organization, you need both. Even at our organization, which is relatively small, we do have both.

These roles are important. We have dojos that spend time training our engineers on new technology to improve the pipeline. Can we add some of these roles, the skills and knowledge that are included in these roles, into dojo training too? Can we have those classes? Maybe that is part of what the VMO implements.

This is my giveaway for you today. I always like to give the attendees something they can take back to their organization and start using. This is a skills matrix. On the left, it includes some skills and knowledge that are useful for people who are moving to a product-centric way of working.

How it works is you hand this out individually to your team members and ask them to self-rate themselves. Do not rate them. They self-rate themselves. There is a legend on a scale of zero to four. Zero would be a learner, like a newbie, just a student studying and learning this stuff. One is you could fly with the instructor: you could do something, but you need a partner, you need to pair with somebody who can coach you. Two is you could fly solo; you can do this on your own. Three is you can teach it; you can train others, you are an instructor. Four is you are a master, you are like a Blue Angel.

As the individuals rate themselves, the Product Value Stream Lead could work with the Value Stream Architect to compile all the answers, put this into the spreadsheet, and now you have a heat map of where you need to train the teams up.

If you have three orange zeroes in a row, that is a visual indicator that we need to put some training in how to identify dependencies on teams upstream and downstream from us. Or on the right, in the third and sixth vertical columns, there are folks who are zero at many of these skills, so there is an opportunity to train them up. In blue, like in the first column, you can see somebody who has threes and fours, so we have somebody who can instruct then.

The thing is, it is a little harder to cheat on these. If you ask people to fill that out independently and not see the others yet, you may get a more honest answer. I remember doing this once for myself, and we could see everybody's scores, and I thought, "Julia only gave herself a two. Well, if Julia thinks she's a two, then I'm clearly just a one." There were folks on the other side who maybe rated themselves a little bit higher. On this, if you rate yourself as a three or a four, that means you will get put into a position where you are teaching or putting on a training, so you really do need to know what you are talking about.

It also gives the opportunity, when it comes to organization changes, to split teams into two where there was only one. If you have at least two people who are at threes or up, then there is an opportunity to pull that one out and put them in a team with some other learners and fly-with-instructors. If your organization is growing and you need to bring more people on board and upskill, that is one way to build it up internally.

This is an example of something that can be fed into the daily work and the general culture of an organization. It is an example of one of the ideals in The Unicorn Project, called Improvement of Daily Work.

Often we think of debt work as just technical debt, refactoring software components or self-service performance testing. But debt work also includes training, leveling up the skills of teams, getting them to be able to shift into a new way of working. Gene talked about it in The Phoenix Project, and he is talking about it again in The Unicorn Project as one of the five ideals. Spoiler alert: five ideals. I am focused on number three right now, Improvement of Daily Work. How do we enable improvement by helping these teams learn new skills?

What does it mean for organizations shifting from project to product? I mentioned the gaps in some of the knowledge, and the need to level up some of these skills. That is why the skills matrix is so helpful. It makes the gaps visible. People can discover what knowledge is useful and valuable, and you get to see potential in people with value. They are sitting right in front of you.

You could avoid attrition risk if you do not want people updating their resumes. You can take your valuable person with their valuable knowledge and give them the opportunity to level up their careers. People like to know that their knowledge is valuable, and it is.

As humans, we want to be good at something and spend a lot of time mastering it, and then it gets automated, and what you were really good at five or 10 years ago sort of disappears. This is going to continue to happen.

I think project to product is going to allow people to reinvigorate and elevate their skills and knowledge and continue to be relevant. The new emerging roles offer an opportunity to do that. Project managers could move into product management, and product managers could move into Product Value Stream Leads. Your senior people at the highest level with their skills in vendor management and risk management could move up into perhaps Value Stream Architect roles or champions.

If you are headed down the road of product management, managing your work by product, then you are looking at profit centers, hopefully, which means you are going to have the funds to invest in training and teaching folks.

With that, yes, I did bring more "No Less WIP" stickers. If you want some, they are at the Tasktop booth. If you want a copy of this deck and a link to the skills matrix, and also the link to "Full Stack Teams, Not Engineers," send an email to dominica@sendyourslides.com. Make sure you put Flow in the subject. Maybe check your spam filter; it seems like this is ending up in a lot of spam filters.

If you want to talk more about this topic, I am going to be facilitating a Lean Coffee table this afternoon. Those are going to be right upstairs outside of that area. It is first come, first served. There is room for about 100 people, and there are 10 tables. I am going to facilitate one on the topic of what I have discussed today, so feel free to join me there today or tomorrow for questions.

I want to know: have you been talking with any project managers who are very nervous right now? Do you have opportunities for them in your organization currently? Or is it looking like, oh, the writing is on the wall and we do not need those skill sets anymore? Because I think there is a real opportunity here for folks who have a great desire to learn, to upskill. I know I did when I saw that the writing was on the wall for me. I was very motivated to learn and study and become once again relevant.

That is it. Thank you so much for your time.