“The software delivery efficiency of [enterprise IT organizations] is abysmal when compared to that of digital startups or the tech giants”
– Dr. Mik Kersten, Project to Product
In an age where new software companies are popping up left, right, and center, traditional enterprises are ill-equipped to compete with these fast-paced digital natives. Most are burdened by legacy IT systems and the infamous waterfall project management model. This leaves them miles behind their digital-native competitors, without the flexibility to adapt to changing business needs.
What gives digital natives a significant advantage is that they commonly organize work around products, not projects.
Having recognized this, many traditional businesses have been funding large-scale digital transformations to harness the advantages of product-based IT. But the risk of failure is high. According to McKinsey, BCG, KPMG and Bain & Company, the risk of failure falls somewhere between 70% and 95%.
So, what’s a company to do to avoid becoming victim to the same mistakes made by so many other organizations? Despite the high risk of failing, the answer isn’t to avoid digital transformation. Rather, the best foot forward is to understand which dimensions to modify and measure throughout the transformation.
The project to product shift is a multi-year process, so it’s important for organizations to stay focused on the end-goal. This will help prevent them from getting disoriented throughout the process.
To be successful, there are seven particular dimensions that organizations need to focus on in terms of how they operate:
- Team organization
- Customer centricity
- Definition of value
- Backlog management and prioritization
- Dependency management
- Feedback speed
- Delivery Metrics
In this article, you’ll get an in-depth look at how each of these seven dimensions contribute to a successful shift from project to product.
Pro Tip: Use this 5-minute self-assessment tool to learn where you rank for each dimension.
What is product-based IT?
Product-based IT is a value-driven approach where customer requests pull value out of the organization. This form of fast feedback lets product owners know what to prioritize next.
Consumer demands and market trends change rapidly, so a product operating model gives you the agility to respond quickly to these changes.
An IT product model is characterized by:
- Greater focus on business outcomes
- Customer-driven prioritization
- Product value streams powered by cross-functional teams
- Agile ways of working
If traditional businesses want to survive in the Age of Software, they need to adopt a product model. But making the project to product transformation is not easy. Realistically, the entire process can span years. Enterprises must overhaul decades’ worth of legacy habits and infrastructure, not to mention a strong culture of project management, which many employees will be reluctant to relinquish.
The shift to a product operating model should be gradual – if you change too fast, you introduce too much risk and uncertainty all at once. Instead of attempting an overnight transformation, aim to make purposeful, incremental changes across seven key dimensions.
What are the seven dimensions of the project to product shift?
Shifting from project to product requires an overhaul of deeply ingrained practices and organizational structure. All the more reason why it’s so important to approach it strategically and introduce changes gradually.
To help traditional businesses transition from project to product, Mik Kersten, bestselling author of Project to Product, lays out seven key differences between project- and product-operating models.
The seven dimensions represent competencies or structures that must change as part of the shift from project to product. If you’re making the shift, it’s important that attention be paid to each dimension. Neglecting even one area could jeopardize your transformation and prevent you from realizing the targeted return on your investment.
Recommended Webinar: The 7 Dimensions of a Project-to-Product Transformation
As a starting point, these dimensions can be used to self-assess your current status so you can figure out how far along you are in the shift from project to product.
1. Team organization and resourcing
Organizations using a project model tend to treat people like interchangeable resources that can be assigned and reassigned to projects. Teams are formed to tackle specific initiatives and disbanded when the project is complete, they run out of funds, or priorities change during the annual planning period – whichever comes first.
The inflexible funding model and project-specific team structure leaves for no room for flexibility to adapt to market changes, even if there is a good business case for doing so.
In a product model, cross-functional teams are organized around products. Team composition is stable and long-term, allowing practitioners to hone their expertise and creativity in a specific area. Funding is allocated between different product value streams based on the business value of the product and the strategic goals of the business.
2. Customer Centricity
At the end of the product value stream is the customer. In the world of IT, the “customer” could be either an internal employee or an external paying customer. Since the customer is the reason you’re doing the work, their needs should determine your priorities. For that reason, it’s important to have fast feedback loops so that customers can have their requests met as soon as possible.
The project model fails in this domain. By the time customer feedback is received, the next quarterly release has been planned, budgeted, and, more or less, set in stone.
3. Definition of value
It may sound easy, but many individuals in traditional IT organizations – including leaders – have a hard time articulating the value of their work. How does each employee impact the customer, and how does their work contribute to positive business outcomes, like increased revenue, lower costs, happier customers, or happier employees?
If you don’t have answers, the project operating model might be to blame. In project-based IT, success is often measured by how well you were able to stick to the predetermined budget and timeline.
By contrast, a product operating model measures success by measuring the effect of new releases on business outcomes, like increased revenue, lower costs, customer satisfaction, and employee happiness. This value-focus, combined with customer feedback loops, helps foster a sense of connection with the end-user, which drives engagement and productivity.
4. Backlog management and prioritization
The project operating model is closely tied to Waterfall methodology, in which large volumes of work progress slowly through a series of steps before finally being released all at once. Projects are extensively planned and coordinated before work starts. And once the ball is rolling, you must stick to the plan because there simply isn’t a mechanism to change it.
This kind of approach might work for projects like building a skyscraper, where there’s a high degree of market certainty and a fixed endpoint, but the same doesn’t apply to software development. For one thing, the market is always changing. For another, the goal of software delivery is continuous improvement, not a fixed end state.
The product model favours Agile methodology instead of Waterfall. In Agile, you regularly add to a backlog of ideas and determine which work to take on next. Prioritization of items in the backlog is dependent on business goals and the long-term viability of the product.
These work items are bite-sized, making them easy to complete and release continuously rather than all at once. By keeping work-in-progress to a minimum, organizations that use a product model can shuffle priorities at a moment’s notice.
5. Dependency management
In project management, a dependency is when the completion of one task relies on the completion of another. For example, developers might have to wait for another team to provision a testing environment before they can test and complete a feature.
Project models are riddled with dependencies. The whole project can be significantly impacted if even one team is behind schedule.
The product model aims to maximize agility and efficiency by reducing dependencies as much as possible. Cross-functional teams break down silos between different functional areas so that work spends less time waiting.
Also, automating certain services, such as the provisioning of testing environments, can help speed things up. In a product model, a good rule of thumb is to automate any kind of work that isn’t value-adding.
6. Feedback speed
One of the cornerstones of product-based IT is agility. This is the ability to quickly respond to market changes and seize business opportunities as soon as they arise. In order to recognize these market changes and opportunities, you need a feedback system that will give you immediate insight into what customers find valuable.
The prerequisites for fast feedback are smaller batch sizes and more frequent releases. But another way you can speed up feedback loops is by integrating your toolchain. With a good integration solution, customer requests from CRM tools appear automatically in your backlog in Jira.
7. Delivery team metrics
If you don’t measure your progress, how will you know if your digital transformation is improving value delivery and efficiency? And how would you know where you need to improve?
Organizations in a project model typically use DORA metrics or story points to gauge productivity. The problem with this practice is that productivity doesn’t always translate to value delivery. Workers could be busy all the time, but that doesn’t guarantee that the right things are getting done, or that they’re getting delivered to customers efficiently.
The best way to measure value delivery is with Flow Metrics. Flow Metrics span the end-to-end value stream and are explicitly tied to business outcomes. They allow you to see the impact of your digital transformation on customer satisfaction, revenue, costs, and employee happiness. They can also show you where your bottlenecks are, whether that’s in funding, approval, development, testing, or release.
Ready to assess how your organization is doing along each of the dimensions?
Spend five minutes and take the Project to Product Maturity Assessment.
Recommended Read: Flow Metrics: A Business Leader’s Guide to Measuring What Matters in Software Delivery
