Transcript
Transcript: Empowering Cross-Functional Product Teams
[00:00:01: Text appears on screen: Empowering Cross-Functional Product Teams, with Ayushi Roy]
In this video, we'll be discussing building agency for product teams. The video will discuss why this is important, what it means and how it can be done.
First off, why is this conversation even important? The traditional approach to government IT looks something like this.
[00:00:25: Image of steps leading downwards; Text appears on screen: Request for Proposal ]
In order to build a thing, it takes years, and some form of a waterfall approach is often used. In other words, there is a list of requirements that's written about first, then that's drafted into some form of an RFP. Then it takes a long time to not just write the RFP but award the contract. Vendors that are onboarded will then build on proprietary or outdated systems. They often use a black box development environment, which means that the government staff or government counterparts have very little window into what's being built until it's already been built.
Change orders cost a ton of money, especially when there are policy shifts that require a change in the product. And at the end of the day, there's a ton of frustration on both sides leading to a product that costs a lot more money, maybe a lot more time, and doesn't ultimately serve the public that it was intended be built for.
In this traditional approach to building government technology, there's often a long waiting period before value is delivered, and the building often works backwards from the end goal. So, in example, if you're looking to build a car, you already have the vision of what that car would look like in the form of your requirements list. And you'd start off by maybe building a wheel, then building the chassis, then the body of the car, and then ultimately the car itself would be complete.
[00:01:50: Text appears on screen: Building agency for product teams]
However, in a more modern approach to building technology for the government, you're constantly delivering value instead of waiting to deliver that value. What this would look like is you're starting with a very clear need. In this case, in this example, let's say solving transportation or mobility issues. And so, in the first iteration, rather than just building a singular wheel, which does no value delivery, you could start instead with a skateboard, and you'd build some more features, and then maybe you would have a bike and then a motorcycle and ultimately end on that car. And in this model, rather than starting with preset requirements or a preset project plan and working backwards, you'd actually build iteratively forwards, constantly making sure to deliver value to the end user along the way.
In order to work in this sort of agile and iterative way, product teams need to be able to constantly deliver value without constantly asking for permission. It's important for organizational leadership to provide decision making power and remove bottlenecks for project-based decisions.
[00:02:55: Canada School of Public Service Logo of book opening/Text appears on screen: Canada.ca/school-ecole]
