In part one of this series, we covered the numerous problems associated with the traditional project funding model, mentioning that organizations need to shift away from projects and toward the product model. Now, let’s get into the specifics as to why this shift is so critical.
Why Move from Projects to Product?
The product model offers an alternative approach that helps organizations deliver more value, more quickly, and at a higher level of sustainable quality by addressing the problems mentioned above. What’s more, the product mindset also places more significance on innovation and improvement, which helps keep the organization aligned with the needs of the customer. It does this by moving away from temporary teams filled with borrowed people, replacing them with semi-permanent cross-functional teams comprised of skills from all relevant departments, each team aligned with a product or company value stream.
The goal under the product model (or value stream model) is to create teams that are capable of doing at least 80% of the work they’re called on without the need for additional assistance. As such, it’s common for software development organizations following this model to have teams comprised of:
- Product managers
- Designers
- Front-end and back-end developers
- Quality testers
- Deployment personnel
- Anyone else needed to complete the majority of work delivery
This creates self-sufficient teams capable of working across all stages of product development, from vision to value, without the need for additional assistance. What’s more, changing the focus from projects to product development is useful for tearing down departmental silos and creating a system that promotes genuine collaboration.
Instead of borrowing workers for temporary assignments, teams are put in a healthy situation where their goal isn’t to simply complete projects but to work together to ensure that value is constantly delivered for their product or value stream at a consistently high level of quality, and they have the domain knowledge and relationships to ensure results are optimized to meet the needs of the customer.
Under the SAFe® model, these teams are generally made up of about 10 people, and the work is assigned to the entire team, not individual members. Teams work using Scrum or Kanban, but members are consistently on the same team, no matter the work delivery.
It’s important to make sure that people don’t work with more than one team, as it causes departments to compete with each other for capacity, preventing people from devoting their time and efforts to delivering work effectively.
In a smaller organization with smaller products and a modern de-coupled technology architecture, these autonomous cross-functional teams may be all that’s needed to achieve business agility. But in many cases, larger organizations have to deal with large, complex products with legacy architectures that genuinely require many coordinated teams working together to deliver real value. In this case, Agile teams are grouped into “teams of teams.” SAFe calls these Agile Release Trains (ARTs for short). You’ll see them called flights, tribes, wings, and any number of other local terms, but in any case, they are typically composed of 5-12 teams and anywhere from 50-125 people working on common technological and business goals, so the organization can respond to changes and deliver value more effectively.
The end result is a business model that prioritizes feedback and adaptability over predictive planning. As such, organizations are better equipped to stay aligned with their customers’ needs and expectations, so that they’re able to deliver value and address pain points more effectively.
Re-Allocating Capacity?
While teams are meant to stay working together and aligned with a business domain for long periods of time in the product model, that doesn’t mean forever. It still makes sense to focus productive capacity where it will benefit the company the most.
In the project funding model, this re-allocation happens as projects end, old teams are dissolved, and new ones formed for new work.
In the product model, the idea is to re-allocate capacity on a cadence based on business results.
As much as possible, organizations following SAFe® and other scaled Agile models will put their teams and teams of teams on a shared cadence. Bi-weekly Scrum sprints are synchronized. Mid-range, roughly quarterly, big room planning events are also synchronized. These cadences make coordination within the teams-of-teams and with customers much easier to manage. They also provide perfect break points to shift capacity between products or value streams with minimal disruption.
But how to know whether or where to move capacity?
Outcomes Over Output
In a product model, each product or value stream should be establishing a linked set of early indicators and funnel metrics that make sense for their aspect of the business. These should ultimately lead to revenue or savings or some other bottom line metric. But those P&L types of metrics are often too slow to be useful for steering, taking many quarters to move significantly enough to tell us how things are going. Early indicators and funnel metrics aren’t as definitive, but they change much more quickly, giving us data for decision making.
Examples of early indicators are:
- the number of people who use a new or modified aspect of a system
- the time they spend on a specific screen
- the load that users place on the system as indicated by our monitoring systems
- the number of support tickets (up or down) related to various aspects of the system that we’ve changed
- comments on social media
As we make changes to our products, provided we have invested in sufficient instrumentation, we can tell very quickly whether our customers have noticed and taken advantage of the improvements, and whether they view them as improvements at all. Good early indicators don’t prove that we’ll get better financial results, but they do suggest we’ve generated value for customers. And, the lack of early indicators should be a huge red flag that we’re wasting money and should rethink our assumptions.
If we’re doing things right, early indicators will lead to medium term results that, while still not traditional P&L metrics, are much more mathematically linked in semi-predictable ways. For a typical SaaS software business, a funnel might look something like this:
- A certain number of visitors to the website will download content of some sort
- Of those, a certain percentage will sign-up for a trial of the product
- Of the trial accounts created, a certain percentage will still be active a few days later
- Of those active trials, some number will engage with our sales team to engage in a purchasing conversation
- We will convert a percentage of those to paying accounts after X number of days on average
- Our typical new account will start with Y number of users and generally grow to Z number of users in a year.
- And, given an average seat price, that means we will generate some amount of revenue in year 1 of an account
We could take the idea further, but you get the idea. Each of those ratios will be imperfect. But they will be predictable enough that we can reasonably guess how a change in results up the funnel will flow through to results out the bottom. Rather than evaluating each potential piece of work independently as a business case crosses our desks, we can aim our efforts at changes that will impact our funnel. And everyone knows the funnel so everyone in our teams is in a better position to focus their efforts on results that will benefit the whole.
Investing where we see real results
Over time, we can use these funnel metrics to drive decision making within our teams and the product or value stream they support. We can also use them to help decide where to shift capacity. If one area of our business has had 10 teams for a year and generated flat results in their funnel metrics and another has had half that capacity and produced 50% improvements, wouldn’t it make sense to move some teams? We may not know exactly which features produced those results. It doesn’t necessarily mean the people managing the first value stream are making bad decisions. But we can clearly see where we have productive investment opportunities and where we don’t. And we can shift teams accordingly.
The product-centric approach gives teams and individuals more ownership in their work and responsibilities. Because people aren’t constantly bouncing from team to team, they have a greater sense of accountability. Employees aren’t just concerned with getting the work done and moving on to the next project; they’re also concerned with delivering innovation and continuous improvement, because a product model holds teams responsible for development, support, and maintenance rather than allocating responsibilities to three different groups.
Ultimately, the product model allows teams to move from speculative planning to an adaptive approach. Teams work together to create value through continuous improvement based on the evolving needs of a customer. This, in turn, creates a business culture that prioritizes value delivery over completing projects. By establishing meaningful outcomes metrics for our value streams, we have a means of shifting capacity where it can do the most good. And by taking advantage of synchronized cadences, we have a minimally disruptive way of moving people and teams when required.
Want to learn more about how Planview supports shifting from projects to products, watch the demo, or download our whitepaper on “Lean Portfolio Management for the Enterprise” to see how organizations are turning to LPM to help make the shift to a product-centric model.
