Carmen DeArdo and Naomi Lurie

Carmen DeArdo: Hi, I'm Carmen DeArdo, Senior Director, VSM R&D at Tasktop. I work on products to support organizations' project-to-product transformations in order to improve their time to market and predictability.

Naomi Lurie: And hi, I'm Naomi Lurie, VP Product Marketing at Tasktop. At Tasktop, I help spread the word and support the adoption of value stream management as a fundamental discipline in the shift from project to product. Today, Carmen and I are going to talk to you about the five stages for navigating the shift from project to product. So let's dive in.

Naomi Lurie: According to Gartner, in a 2018 survey, 85% of respondents said they had adopted or had plans to adopt a product-centric model. That means the majority of enterprises were beginning this transition, motivated by a desire for faster delivery and a need to support the transformation to digital business. So here we are, four years later, and just like everyone else, we were very curious to examine how organizations are traversing this complex multi-year process.

Naomi Lurie: Because this shift is literally our business here at Tasktop, we've been lucky enough to have front-row seats to the transition at many of the world's largest enterprises. In addition to that, we've also recently launched an assessment to complement what we were seeing boots on the ground with the industry's experience at large, and that's what we're going to be looking at today.

Naomi Lurie: In today's talk, we're going to talk about the five stages of the shift: what does the journey look like at a macro level, and how do companies actually advance step by step from project to product? Then we're going to talk about the seven dimensions of change that must be completed to reach maturity, and they weave through those stages. Then we'll share early findings from our research into the state of the industry: how advanced are organizations in operationalizing this new model and reaping its benefits? Finally, based on those findings, we're going to share some practical advice for getting through the hardest parts of the journey, how to avoid some anti-patterns, and how to manage the cultural shift.

Naomi Lurie: We'll also be sharing, during the presentation, how you can self-assess where your organization is at in the shift, which stage you are, and how you can recenter your efforts to be able to advance to the next stages.

Naomi Lurie: Back in 2018, the industry didn't have tools designed to support the shift from project to product. Discussions about organizations' efforts to move to a product-based model were mostly based on collective knowledge, experiences, observations, and research. But here at Tasktop, since around the middle of 2019, we've been supporting organizations with the journey with a turnkey value stream management platform called Tasktop Viz, where we are explicitly measuring the shift for the entire technology portfolio.

Naomi Lurie: Thanks to Viz, we've had first-hand evidence from the world's largest organizations about their current state and the steps that they're taking to navigate the transition. That intimate view of those transformations, including the flow metrics and insights that we have from their value streams, has allowed us to describe the journey from project to product as five major stages. So turning to you, Carmen, maybe you can start by walking us through those stages at a high level.

Carmen DeArdo: Sure, Naomi. The five stages of a project-to-product transformation are starting out, experimentation, expansion, operationalizing, and approaching maturity. So let's break that down a bit.

Carmen DeArdo: In traditional IT organizations, your starting point is typically a situation where you're operating fully in a project model. That means all work, except perhaps run work, is done in projects with an annual funding model. As such, teams are constantly being formed, stormed, normed, and then just when they're becoming productive, disbanded. Lots of time is spent in project-related meetings. Application integrity is hard to manage. Dependencies aren't visible and are also hard to manage, which leads to large batch size projects and long, highly coordinated release cycles.

Carmen DeArdo: What's your ticket out of stage one? It's being able to articulate and measure the negative business consequences of the current state and creating a hypothesis of the positive business outcomes you could achieve through a shift to a product operating model.

Carmen DeArdo: This leads to step two, experimentation, which is typically done on a well-contained, highly visible, external-facing product because it naturally lends itself to more rapid innovation and there is a strong business incentive to speed up delivery. This is where you're learning, through trial and error, what your shift actually entails at an individual product or product-line level and proving out the value.

Carmen DeArdo: After experimentation, you start expanding, giving more and more portfolios the same treatment. What we often see at this stage is that principles are not necessarily applied evenly to all IT assets, like internal products and platforms, which means there's still plenty of process and product dependencies that prevent faster lead times.

Carmen DeArdo: Operationalizing is where you work these things out based on the understanding that every product needs an independent and rapid path to production and customer feedback within a quarter. Here's where metrics and OKRs emphasize achieving business outcomes and better flow.

Carmen DeArdo: Finally, when you're approaching maturity, the last pieces all fall into place. You have more responsive and flexible funding models, and you're on shortened planning intervals. You have really well-defined interfaces between systems, patterns of self-service, and the capability for independent releases with dark launching options and a strong product management discipline. Even at Tasktop, which has always been in a product model, we're still getting better and better at doing it. Maturity means understanding all different types of products, not just the customer-facing ones.

Naomi Lurie: That's a great overview, Carmen. In the book Project to Product, which was published in 2018 by Mik Kersten, who's also Tasktop CEO and co-founder, Mik laid out the seven differences between project and product operating models in terms of budgeting, time frames, the definition of success, how risk is handled, how teams are organized, how work is prioritized, and how visibility is achieved.

Naomi Lurie: Because this is a multi-year process and it can be quite easy to lose one's way or become disoriented, we found a way to reframe those differences as seven dimensions of change that must occur gradually as an organization progresses through the five stages. These dimensions create a model for self-assessment, so you can figure out where you are in the shift and then recollect yourself in order to take the next step. By understanding the dimensions of change, you can keep your focus and muster the strength it takes to persevere and keep the momentum going.

Naomi Lurie: Here are the dimensions. They're similar to the differences, but stated slightly differently, so you can ask yourself a question: team organization and resourcing, customer centricity, the definition of value, backlog management and prioritization, dependency management, feedback speed, and delivery team metrics.

Naomi Lurie: In each of these dimensions, we've observed four progressions. For example, let's take number three: how clear is the definition of value? In a project model, the emphasis, of course, is on being on time and on budget, so most individuals would be hard-pressed to explain how they contribute to tangible business outcomes. When you begin the shift, some leaders will start to be able to articulate the business drivers. As you get closer to a product model, most product managers can articulate the value they provide to their customers and the business. At maturity, value is so well-defined that it serves as a focal point for every single team member, even if they are on a platform team or working on an internal product. Product teams are focused on the incremental delivery of value in order to achieve very well-understood business outcomes.

Naomi Lurie: Organizations do not necessarily move from stage to stage evenly across all dimensions. For example, a large financial institution is improving on backlog management and prioritization, but they still cannot revise their plans rapidly based on customer feedback because they have only a few highly governed release windows a year. Another example: an insurance company has its entire portfolio organized in continuously funded cross-functional build-and-run teams, but still, only a few leaders can define the value.

Naomi Lurie: You can take the five-minute assessment that has these multiple-choice questions and take the pulse of your organization's progress. We'll help slot you into a stage, you'll get a read on where you are, and some pragmatic recommendations of what to do to be poised to take the next step. The assessment is still open at tasktop.com/assessment, and we encourage you to take it now and help define the state of the industry. But we already have some early findings from people who've taken the assessment. So let's ask ourselves: how is the shift going? Where are more organizations at in this process?

Naomi Lurie: Our early findings show that the majority of the organizations, 78%, have not fully yet operationalized the shift where the true ROI is captured. You can see they're clustered in experimentation and expansion. So two hypotheses here: expansion is proving difficult, or expansion simply takes a long time. Given that so many organizations are in those two stages, we thought we'd focus the next section on providing some practical tips and advice: how to do experimentation, and how to get through expansion. Carmen, let's start with experimentation. Can you give us some good tips for that stage?

Carmen DeArdo: Sure. Thanks, Naomi. Like any experiment, you need to define your success criteria in advance. It's very important to establish that clarity up front. Then you need to carve out a complete product or an experience from ideate through deploy and support. Set up a team with an empowered product owner. Give them some funding that they can manage themselves for the duration of the experiment. Even though you're still perhaps in an annual funding cycle, identify some money that was going to improve this product or experience, and then allow that team to manage that for themselves.

Carmen DeArdo: Next, map and measure lead time from the customer's perspective and any other metrics that matter, like throughput, quality, and efficiency. You want to understand all the dependencies through your shared internal and platform teams so that you can potentially tackle them to mitigate delays this product is experiencing and start experimenting around them. This is where you start developing the patterns that can later be expanded upon. Finally, make the improvement work itself visible. Don't hide it. This work is very important and needs to be visible along with the delivery work the team's doing. Your leaders and peers need to understand the capacity and effort that has to go into this.

Naomi Lurie: Yeah, great tips. What I'm going to add to that is that it is possible that organizations rush into expansion before they've really maximized their learnings from their experiments. Here are some tips for making sure that the experimentation is solid enough to see you through a successful expansion.

Naomi Lurie: First, don't rush until you've developed good, solid patterns for operating in a product model. Patterns include turning SLAs into self-service for things like test environments; testing, including routine performance and security testing; releasing on demand; and monitoring. Another pattern can be having a dedicated consulting team for certain capabilities that require a deeper level of expertise. Codify these learnings in sustainable and repeatable patterns by creating a playbook of patterns that other people can use and you can expand upon in the future.

Naomi Lurie: Where we see expansions failing is when they don't know how to apply a product treatment to internal and platform products. So experiment with products of those natures too before expanding. Then you'll really know what to do during expansion, and you won't be limited to treating only the external-facing products but none of their dependencies. Also, make sure you take the time to tell the stories of your experiment to the organization to drive that cultural change, and make sure that you're also getting the attention of the leaders by tying your success stories to tangible business results: things that are benefiting the top line, the bottom line, talent retention metrics, all those things are super important. Lastly, understand that additional learnings will come from scaling, and that's okay. This is part of the continuous improvement process. You have to leave time for refactoring patterns using future learnings.

Naomi Lurie: Carmen, acknowledging that funding is the last thing to change in the shift, as you expand and operationalize, what can you do to empower the product manager or the product owner and the product teams to provide some flexibility until there's a process that naturally does this?

Carmen DeArdo: Yeah, it's a great question, Naomi. Even in annual funding, you can allow that strategy to be at least revisited regularly, monthly or quarterly, to adjust funding levels across products. First, investments should now be made by product rather than initiative, and this should cover all types of work. For example, build and run, which includes not just the feature work that you're doing, but defects, compliance, security work, and technical debt.

Carmen DeArdo: Second, these investments should determine the product team size. Throughout the year, perhaps quarterly to begin with, determine if the business or market needs require these priorities to change, and adjust the product funding level. These changes in product funding should then drive any resizing of teams as required.

Carmen DeArdo: Next, the value stream product owner needs to be empowered to fund and prioritize the work, which reduces the time from idea to work starting. That means extending your visual management boards to the left to visualize the work that occurs prior to work entering the Agile development backlog. In a project model, this is where hundreds of days can be lost, and you're trying to prevent that.

Carmen DeArdo: Next, try to embed these business roles as part of your team and co-locate them with the team. Staff the team itself with full-stack abilities to do work across technical domains and assets using techniques such as intersourcing, which eliminates needs for complicated resource planning and demand processes and many meetings and back and forth to adjust that. You'll find that you can replace eight-week cycles of meetings and documentation with a few focused two- to four-hour sessions.

Naomi Lurie: Great. So now tell us, Carmen, about some anti-patterns to avoid.

Carmen DeArdo: Thanks, Naomi. First, an anti-pattern is starting with a big paper reorg without first starting small and experimenting and learning what works. As Naomi pointed out, that's where you maximize your learning, with those first experiments. You don't want to shortchange that effort.

Carmen DeArdo: Next, not having clear metrics to measure success on the journey. Those metrics are your compass. They tell you, as you're moving, that you're moving in the right direction, or perhaps that you're not and you need to refocus or redirect what you're doing.

Carmen DeArdo: Then, basing the journey on time rather than on progress. Don't force this, especially at the start. Don't assume it's a one and done. Rather, it's a continuous improvement journey.

Carmen DeArdo: Another anti-pattern is applying local OKRs and local optimizations. Remember, all the habits have been developed over years. A lot of those habits have been around silos and OKRs and driven local optimizations. We want to be on watch to make sure that we're not continuing that habit as we go through this journey.

Carmen DeArdo: Then, we can't ignore these internal and platform products. These are the innovation engine of the organization. Investment in improving the flow in those products pays off many times by the external customer-facing products that are using their services. So they need to be treated as first-class products.

Carmen DeArdo: Finally, we have to consider the human element. We know that culture is the biggest factor in change, and that human element has to be front and center in your mind as you're going through this process.

Naomi Lurie: Yeah, absolutely. Because you can technically do all the right things and still lose the people. The paradox is that although people desire change, they resist change, and the shift from P2P is a huge one. Change will naturally introduce risk and uncertainty and force people to get out of their comfort zone. There's also kind of an unspoken accusation that what you've done until now is not good enough, and there's a little shame and loss of face that could be associated with that. If you don't approach the shift with the necessary sensitivity to the human and cultural aspects, it won't succeed. We have six tips to manage the culture change. Carmen, kick us off with the first three.

Carmen DeArdo: First, this is not just for the cool kids. Although experimentation typically begins with a business-visible digital product, try to make it as inclusive as possible. Reach into the deeper layers of your internal products and supporting platforms, and include some of them in the initial experiment: some of those legacy systems or legacy products that may have been ignored up until now.

Carmen DeArdo: Second, prepare for fixed mindsets. It's fair to assume that many people in your organization will be of a fixed mindset, for whom change is very threatening. Make the journey as non-threatening as possible. Don't be overly critical of the current state. It got you where you are, which is likely a Fortune 500 or Fortune 100 company. Rather, emphasize how their experience is important and valuable to the new initiative.

Carmen DeArdo: Third, empower the teams. Again, we sometimes forget it's the people doing the work who are in the best position to determine what changes and improvements to make. This goes back to Deming's view of quality circles. We hire external consultants many times to tell us all the things we're doing wrong, when really the teams themselves should charter their own transformation journey. As a start, provide the team with metrics that reflect their current performance. Don't use these metrics to compare them with other teams. Just make them available for their own consumption, and then give them license to be creative and experiment. You'll be amazed at what they come up with. Celebrate even small improvements and reward participation in the continuous improvement process.

Naomi Lurie: Yeah, that's great. I'm going to add three more. There's nothing worse than getting people all excited about an experiment or a change and then putting up barriers to their progress, and then you do it again and again. If you do it three to four times, you've killed their motivation. No one wants to feel like a Ferrari surrounded by a herd of sheep. Make sure that your experiments are not blocked by red tape and slow approval cycles. That's a recipe for cultural disaster. Instead, make sure leaders can keep up with the energy that people have.

Naomi Lurie: Next, don't throw out ideas just because they aren't ripe. Not every good idea can be completed and implemented today, but that doesn't mean it's not a good idea. Be very careful not to dismiss people's good ideas just because the organization or the environment are not quite ready for them today. Instead, experiment where possible and create a backlog of good ideas to return to when the environment is ripe.

Naomi Lurie: Last, don't let perfect be the enemy of good or better. Software development in the modern enterprise is vastly complex. Progress can be slow, which can lead to frustration, so make sure your teams can appreciate how far they've come by reminding them how it was just six, 12, 18 months ago. Granted, there is more to do, but there is still value to all that's been achieved. At large, complex organizations, progress will come from a continuous series of baby steps and not from a big bang.

Naomi Lurie: So what did we learn? We learned it's a long process with a lot of change that needs to be driven and sustained across multiple dimensions, all the while making sure not to fall into the pitfalls and anti-patterns. If our early findings are correct, then this is much longer than a four-year process. This is maybe eight years, 10 years. Wow. So you need a map for that journey. The view of it as stages, and that you can advance step by step by attacking the different dimensions, is a very helpful guide to that journey.

Naomi Lurie: We really recommend taking the assessment to figure out where you are on the journey and reorient yourself. You can even have multiple people in your company take the assessment and see if you're all getting the same results, if you have the same perception of the journey. You will be helping us as an industry understand the current patterns, the challenges, and where, as a community, we can help more. Thank you so much for your attention and participation.

Naomi Lurie: Thank you, Carmen.

Carmen DeArdo: Thank you, Naomi, and thanks everyone for attending.