Project-based Funding

If your company is one that still allocates product development funds based on approval of projects, then you still have the old “project-based funding model.”  This is mostly a situation in either large companies, or those that have an IT-style legacy, but the mindset often exists even in small companies too.

Unfortunately it’s a very bad model.

I have written about this before but not as explicitely as I am here.

There are three fatal problems with the project-based funding model:

1. You very likely have no real clue when you propose a project for funding if you should really even be pursuing the project.  Even though you might pretend otherwise with a cleverly crafted “business case” the truth is that you probably have no real evidence if your customers are going to like this, and you probably also have no real idea how much it will cost to build (because at the project proposal stage, you don’t even know what “it” is).  So you don’t know the revenue and you don’t know the required investment, so of course the ROI estimate is less than meaningful.
2. Creating strong products is not a series of projects that come in sporadic bursts of a few months each over several years.  Strong products result from getting your concept in front of customers and rapidly and continuously learning and improving.  Further, to make this progress, you need not just continuity of investment, but also continuity of the team.
3. Very often in good product work we find that our initial ideas are not quite right but if we change direction somewhat, which we call a “pivot,” we can often uncover major new sources of revenue.  These are the very sources of revenue that companies depend on for another several years of rapid growth.  However, with project-based funding, the consequence is that this sort of pivot is effectively discouraged.

The project-based model is not only bad from the product and customer point of view.  The model is very bad from a financial point of view.

The financial business cases that the decisions are based on are unacceptably flawed.  The inefficiencies and lack of velocity caused by the lack of continuity means we get less from our money.  The accountability so desired by finance is missing because you don’t know if the problem was that the team did a poor job executing, or if the problem was that the leaders picked the wrong project to pursue.  And most importantly, it doesn’t generate the business results we need or expect.

The main alternative to the project-based funding model is the dedicated product team model.  In this model, rather than funding specific projects, you instead are funding product teams which work on distinct products.

Rather than have the teams focus on delivering specific features or projects, they are accountable for delivering against prioritized business KPI’s.  The team decides which features or projects or other work is necessary to deliver the necessary business results.  Some of the ideas will pan out and others will get quickly killed.  The product team is empowered to decide what is most appropriate to deliver, yet they are also held accountable to the results.

Product teams can be funded and staffed at any time, but they usually last for at least a year or two.  You can also decide to increase or decrease the allocation of staff to that team as the needs of the business change.

One of the reasons that the project-based staffing model is often found in old IT-style legacy companies is because it fit well with the outsourcing model of staffing projects and the associated “Statements of Work” style of working.  But just to be very clear, this model doesn’t work for product companies for the reasons above and more.

In any case, the dedicated product team model will not only help your money go further, but most importantly it generates better results in terms of speed to market, degree of innovation, and business results.

This is just one of the important dimensions of product portfolio planning.  If you think your company has issues in this area, you’ll want to read Principles of Product Portfolio Planning, Dedicated Product Teams and The Product Scorecard.