Big Rocks in Your Product Agility Journey

You may have heard the term ‘Project to Product’ buzzing around lately. But what does this concept really mean, and why is it crucial for achieving product agility in today’s fast-paced market? In recent years, the focus has shifted from merely being agile to mastering product agility. This is essential for companies looking to be more responsive to their customers, market demands, and competition. Read on to discover the key constraints you might face and how to successfully transition to a product agility mindset.

Background

Since the early to mid 2000s, many companies have been trying to embrace agility. At times, it was heavily process focused, with primary emphasis on iterative methodology. In other instances, it was a part of a larger digital transformation effort. At the core of all of it, companies are looking for a way to be more responsive to their customers, to their market, to their competition, and also have the flexibility to maneuver and pivot not only at the product level or even the product team level, but also across their wider organization.

Project-based thinking and process is often the largest inhibitor of achieving agility, which is what brought about “project to product.” It’s about removing the obstacles that are holding us back from the true promise of agility, through the blending of product, agile, and technology.

Download Whitepaper: From Project to Product: Building the Right Thing in the Right Way

Product Agility Big Rocks

Every organization has a set of constraints, and while every organization is a little different, there are common constraints, what we’ll call big rocks, in your agility journey that may hold you back from achieving true agility.

1. Funding by Project (by scope)

• From Project: With project-based funding, the scope, time, and budget are estimated up front. After this estimate is created, the next step is to argue for a large sum of money to support this initiative, based on the estimate. The team receives this large chunk of money to span however long the project should take until it is “done.” By the time you reach “done” you are left with a gamble when considering the variables that could affect delivery, for example if the market shifts, users don’t want it, or if you go over budget.
• To Product: Let’s flip that in the product world. Instead of funding by scope, leave scope variable, and go after outcomes. We may not know exactly how we’re going to get to these objectives or outcomes in terms of what features we need to provide, but what we’ll do is fix budget and fix time – if we’re building with agility, we can release really any time that we deem we have enough value. This leads to the second big rock.

2. Funding and working as fully dedicated product teams versus project teams

• From Project: A lot of companies have made this switch as part of their transition to agile, but some are still funding by feature. However, it is extremely difficult to fund by feature, especially because you may not even know what the scope is at this point in time. In the project world, you start with the work, which then trickles down to the personnel with those skills to accomplish the work. A major downside to this is the fact that at the end of the project, the team is dispersed and moved to other projects – even though software doesn’t end at the end of a project. Your products don’t simply disappear at the end of a six year or six month initiative. What we really need is for people to continue to grow, to enhance, to sustain and to maintain your products. They also need the historical knowledge gained during that project to stay with the product in its lifetime.
• To Product: Instead, fund based on people and teams. When we work in product teams, we start bonding around the product, the market, that thing that we build, and this will impact customer value. The team will gain solid knowledge and an understanding of not only their code base, but also their market and the people that they serve. It’s also much simpler to know how much people cost. If you have a team of 10 people, you could look up their fully loaded costs. Also, if you invest in three teams over the course of the next six months, both cost of people and release date can be fixed. Now, scope will be the only aspect left variable, which tends to psychologically

3. Separation of IT and the business

• From Project: The shift to digital over the course of the last several decades has affected many large companies that did not previously have software or digital products. The web has increasingly become more entrenched in all of our modern day activities, so organizations need to ensure that their products have at least some level of digital experience. As such, the previous structure that we had of a separation of the business and IT is not effective in making progress toward agility. If businesses and IT are separated and people are not working in product teams, the larger the initiative the more complex and disorganized it becomes .
• To Product: We need to think and act more like software product companies, which is what’s leading many organizations to form product management. This leads into our next big rock.

4. The existence of product management

• From Project: Some methodologies trivialized the role of the product manager. One trap that many companies fall into is constraining the idea of what a product manager or product owner is. In truth, the role is extremely broad and beyond just writing stories.
• To Product: It’s exceedingly important for organizations to have product managers on product teams, so that they are able to make decisions about what we’re building, why we’re building it, who we’re building it for, and in what order and with seamless collaboration. In addition to that, a rising priority beyond building product management skills on teams is helping the product managers and product owners to become more technical, strategic, and customer facing. Indeed, product management must step up to lead in some places where product management wasn’t leading in the past.

Conclusion

Ultimately, change is difficult, but nevertheless, necessary across the organization. Leadership needs to lead by example to accomplish meaningful progress toward true product agility.

We want to produce what people need. But we also want to do it in a way that’s sustainable and doesn’t burn out team members. The move to product thinking forms cohesive teams or programs with people who share a common product vision. They all share the same information and are going to demonstrate the same love for the product, the customers, and the market (bonus: they’re going to care a lot more because they get to be a part of the decisions.)

Project thinking means handing things off and building products like a relay race. With each pass of the baton, a piece of the product story is lost. The shift to Product thinking enables us to adapt to change, adjust as we learn, and respond to the market.

What does that mean? – Better return on an investment! Not because we’re turning the crank faster — because we’re building less of the wrong thing and more of the right thing.

Now that these rocks have surfaced, let’s solve some of your harder problems together. Contact us to learn more about how we can help you on your product agility journey.