skip to Main Content

Moving from Project Funding to Product Enablement

How to Shift Your Funding Structure to Ensure You Don’t Run Out of Time and Money

As you continue to lead your organization through Agile-based product transformation, an important early decision that must be made is determining how your products are funded. A common pain point I’ve encountered in enterprises of every shape and size is when they attempt to fund products as if they were projects. This often happens when the Project Management Office (PMO) oversees the distribution of dollars and governance of work. 

The way projects have historically been planned & funded comes into harsh conflict when teams begin organizing around a product and delivering new capabilities in an Agile framework. Because Agile has typically been seen as a “technical” methodology, finance & planning parts of the business have not yet been pushed to change the way they operate. As Agile moves out of IT and into the business, the efficiency and effectiveness of the product teams are limited because of the fundamental conflicts between planning for projects and managing a product. Because, in a typical project-based funding model, products aren’t able to evolve according to market and customer demand, those limitations usually mean the organizations never fully realize the value of their investments in digital products.

Here’s the (obvious) thing: a project is not a product. Projects are intentionally finite and have a tightly managed scope and timeline — they have a beginning, middle, and end. And through that scope and timeline, there’s little room for changes to the plan, even when the team learns new information about customer needs, scalability of platforms, or shifting business contexts. 

The saying goes: “No [project] plan survives first contact with the enemy” — I have rarely seen a project not forced to adjust scope, time, or resources based on insights gained or delays encountered once the work commences. This need to adapt is often treated negatively and leaves the teams locked-in with little to no ability to adjust based on complexities found or a better opportunity uncovered. 

When the scoped functionality has been delivered and the clock runs out, the project ends and the team disbands. All that newly amassed knowledge goes out the door right along with them. Furthermore, there’s no team to improve or evolve what was built without creating another project. If and when a new project is established, there’s no guarantee you can “get the band back together” in order to quickly regain maximum velocity.

What is a Product Funding Model?

While projects are fundamentally finite, products are ongoing and persistent. Products represent value streams and can essentially live “indefinitely” and are only limited in duration by their lifecycle (build, launch, evolve, maintain, sunset). When you fund a product throughout its lifecycle, you’re funding a team to be accountable for identifying opportunities to deliver the maximum value for the lowest estimated effort (risk and uncertainty). A stable funding structure enables the team to operate predictably within their calculated capacity to deliver at a sustainable cadence. In this context, “Value” is the measurement of benefit provided to the recipient of the work (your audience, customers, users) that will result in providing the desired return on investment (ROI). 

By removing the rigid project scope and finite timeline from the equation, you’re allowing the team to focus on what the “right work” is right now. And prioritizing by weighing the value of the work against the estimated effort, risk, and uncertainty, you provide a level of insurance to proactively mitigate issues before they become problems. 

As long as sufficient value is being delivered by the product — ultimately resulting in an acceptable ROI as determined by the business — the funding should continue. Once that value drops (or the cost to support the value becomes untenable), the product may naturally be at the end of its lifecycle and it may be time to consider sunsetting the product or investing in the reassessment and next phase of the product (e.g. merging with other products, re-platforming, etc).

By adopting a flexible and scalable product funding model, each product team should grow or shrink based on the projected amount of value-added and the number of resources needed to deliver it within the desired timeframe. Investment dollars are used strategically to ramp up for a large push or scale back when there aren’t as significant initiatives in play. And when funding is applied across product teams, the fight over resources is held at bay because the teams have a dependable resource model to plan against.

Why Finance Should Embrace a Product Funding Model

It’s no surprise to anyone that change is difficult, and that seems to be especially true for the financial side of the business. By both proactively communicating the reasons why change is needed is to support innovation you can anticipate resistance and directly address the temporary discomfort and uncertainty in this shift in frameworks. 

Engaging your finance partners as collaborators in the organizational transformation will help to resolve objections and ultimately shift any detractors into advocates. Throughout this transformation period, the best way I’ve found to influence others in adopting change is to listen to their input and feedback and to demonstrate you’ve heard them.

In my experience, the number one thing you can do to show your finance partners you understand their pain is to come ready to show how you’ll measure progress and prove a favorable ROI. Of course, ROI as a metric is literally one of the most lagging indicators of success (or failure) — it only shows results after all the work has been delivered and it doesn’t help inform the product team if they’re on the right track (or give comfort to their leaders that the investment is sound). 

I’ve seen product leaders consistently struggle to demonstrate the connection between leading indicators’ and the resulting effect on ROI. Executive sponsors and finance partners are typically used to comparing dollars out versus dollars in and are usually very uncomfortable with ambiguous (or non-existent) metrics. Here are two things product leaders can do to show that ROI will happen:

  • Establish a mutual understanding when the business is investment spending on a new product or adding features to an existing product — which may result in a temporarily negative or at least neutral ROI. Alternatively, when you’re running the product as business as usual (BAU) and more focused on refining existing functionality, resolving bugs & defects, and removing tech debt — this should maintain or incrementally improve your ROI. The difference is important to articulate.
  • Following each code release, focus on the leading key performance indicators by identifying the measurable attributes which are immediately demonstrating value (e.g. number of daily active users, amount of use or session time, or even a reduction in ticketed issues). The improvements in the metrics here should translate into a positive movement on your ROI calculation.

The Limits to the Product Funding Model 

Being funded as a product does not provide a blank check that lets the product team add any resources they desire. An effective product team has an appropriate mix of business and technical roles in proportion to the relative size of the product (and the expected ROI) during the current funding cycle. Funding is also not a license to build whatever the team feels like doing — there’s no carte blanche for the shiny object du jour. Moreover, funding doesn’t give the team permission to toil in isolation, skip releases, or otherwise go off the rails. The team is still held accountable for delivering results because their funding levels are directly tied to established ROI expectations articulated via KPIs, as described above.

Here are some examples of the benefits organizations see when they move to product-based funding:

  • Eliminate the disrupting “stop-and-start” whiplash and expensive ramp-up time associated with large projects. Continuously funded product teams retain knowledge and understanding of why certain features were prioritized and how it was built. Knowing “what’s under the hood” and “how it is wired together” allows them to keep track of all the moving parts and maintain their velocity of delivery.
  • Enable teams to be truly “customer obsessed.” By now every company purports to have the customer at the center of their strategy, but evolving customer needs are often sidelined in the name of timelines and milestones. By adopting a customer experience and feedback loop within the product management framework, teams can adapt quickly to new information while adhering to the overall strategy. The concept of “innovation” becomes a core part of “business as usual.”
  • Reinforce accountability for delivering value. Product managers and their teams are keenly aware of the cost of each sprint, and an Agile-based approach helps them to make the calculations for value versus effort. The conversation during planning becomes “will we deliver value greater than the cost to build?” Measuring the resulting ROI will validate and reinforce this priority.
  • Shift the discussion around what to fund. Requesting funding for a product now becomes a conversation about how much value is proposed to be delivered within the next funding period, not about how effectively is the team hitting project milestones. And the proof provided is the measurement of how effective the team was at delivering value in the previous funding period(s). The value delivered for the cost to build becomes the key criteria justifying sustained investment or identifying when reallocation of funding is warranted.

Where Do I Start?

A simple place to begin is to test the efficacy of product funding with a single product team through an “innovation lab” structure. Framing this as an experiment gives the team permission to stumble (they will) and learn (they will) in order to achieve success (which they also will). During the setup phase, identify innovative finance partners to serve on the product teams. They will be instrumental in both in the definition of what is valuable to your audience and articulating how that translates to a business ROI. Better yet, this will mean they have skin in the game for this pilot to succeed.

Through the trial period and as the product team matures, builds velocity, and value is being measurably delivered, examine the results to understand how those learnings can extend to other teams in your organization. Planting these seeds of governance will help build support across the whole organization.

Throughout this adjustment period, continue to engage your finance team as contributing partners in the transformation. This includes encouraging cross-team collaboration by bringing Finance and Product teams together during key planning and Agile ceremonies. Continue to conduct annual strategic planning to establish a baseline product budget and assess the team size & structure to ensure the right resources are in place to deliver the proposed value. In addition, leverage quarterly roadmap-level planning sessions to review and confirm you’re monitoring the right metrics, understand how much value was delivered in the previous period, and agree to how much value is proposed to deliver in the upcoming period. Depending on your release cycle, it is also important to include your finance stakeholders in a product increment review to gather feedback and use that to adjust your plans accordingly.

Trying to run before you can crawl generally results in false starts and setbacks, so don’t bite off too much in your initial tests. Acknowledging this is a journey and the desire is for everyone to benefit by moving forward together will help reinforce this is a team effort. And as a benefit, this approach will arm your finance partners with the capability to budget and plan for supporting Agile products at scale. Once the transformation begins to take root, it becomes easy for you to accelerate adoption across teams.

Back To Top