For a generic why are product teams better than project teams see this earlier post. This post is my thoughts on the debate between funding projects or funding products and why this is important.

TL;DR: Fund Products not Projects because, ownership meaning longer term thinking, funding whole product life-cycles, empowering teams and product owners to meaasure outcomes.

Why is funding projects good?

In “theory” it allows you to get the best ROI by allowing your squads/teams to work on the business areas where the highest value ROI are available.

 

Why is funding projects bad?

The positive intention is to fund the highest value items for the business, but this isn’t often the case, here is why:

Pet Projects – The process of securing funding is slow, hard to do and often involves having boards(meetings) where lots of very important and well paid people sit in a meeting room arguing the toss often with the goal of winning for their pet project or department rather than funding the piece of work which has most value to the organisation.

Business Value is a woolly term, there isn’t a one size fits all equation to cover all the different types of business value. In prioritisation meetings there is not usually a scorecard which takes the emotion out of decisions. The projects that threaten the most severe consequences of not being funded typically get funded. Mark Schwartz gives a good summary of the business value problem in his book The Art of Business Value.

Fail to fund the life-cycle of the products – Project funding causes us to fund only the initial development phase, this is in fact a fraction of the cost of a product being developed. There is a huge amount of cost in maintaining, evolving and phasing out a system. Much more than the initial “delivery” cost, funding projects causes short term thinking. This promotes short term delivery behaviour with teams throwing code into production knowing it is a maintenance and evolution nightmare to come but it won’t be their problem.

Not taking it to the Gemba – It is not typically the teams that work with or on the products which make the decisions, it is a group of managers with political battles who often lack the context. Sometimes it’s not even the business people it’s an independent body.

Delivering Scope not Business Value – Even with an agile approach to delivery with funding projects there is still an implicit expectation that all items will get done even if we discover a few weeks into a project that it’s not such a great idea or we have delivered 80% of the value and there are other things of higher value we could be working on. Encouraging us to deliver scope not business value. Less about delivering value and more about delivering to plan.

Dis-empowered Teams – Building on the above points projects are usually tied to specific benefits which are aligned to specific features or work items. There is therefore little chance to pivot or change. Autonomous empowered teams goes out of the window, teams able to find and work on items of greatest value is just a dream. Outcomes are typically not measured. In our projects we have little or no room to innovate – low morale in teams, low empowerment, servant and master relationships and ultimately our products suffer.

Maximum Product instead of MVP – Project funding makes it harder to talk about MVP and deliver value iteratively. Funding projects means stakeholders are likely to argue everything is priority 1 and nothing can be left till later. We hear phrases like there is no day 2 or second release which promotes the we must do everything behaviour from stakeholders. This makes it harder to discuss smaller deliveries and results in bigger projects, which are inherently more risky as proved by various studies. Big projects fail, small projects succeed more of the time.

Conway’s Law – Conway’s Law states: Any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation’s communication structure. By applying Conways Law to funding Projects our software products are likely to become entangled and tech debt is likely to increase. Entangling our applications will make them harder to change and decrease our ability to deliver value.

Lastly and possibly most important decisions are not quick and easy to change – Funding decisions are often made once a year dependant on the organisations funding cycle. Meaning we are likely be less able to change direction and take advantage of new opportunities, innovate or satisfy unhappy customers quickly.

How do we fund Products?

Make your teams truly cross functional or as cross functional as possible and give them a product or products.

New Product Ideas – Start Up

If you have new product ideas, why not use the lean start up seed funding model. Fund incrementally, maybe an iteration? Use the lean start up principles – build, measure, learn loop to encourage the teams to focus on iteratively releasing value. Continue to seed each iteration if the value released warrants it. The length of iteration is up to you, with a preference for shorter iterations.

The advantages of this over project funding is that start up esque funding maintains the focus on releasing value and to measure and show value at each stage.

It is a well used and successful change pattern to treat parts of an organisation like a start up not beholden to old processes.

Existing Products – Product Families – Lump Funding

Like good UX keep it simple, keep it familiar.

If we have products already established again attempt to make your teams truly cross functional or as cross functional as possible and give them a product or products. Fund your product team for a period of time familiar to the organisation with a preference for longer funding cycles. A normal organisational cadence may be every year. Fixing the cost of a squad for a year at say circa 1 million pounds for example, for a 5-9 person team.

Then measure the value the team is providing. Visualise and track value delivered over time. Cost is easy, it’s fixed. ROI should be quick and easy to calculate. The problem now is to define business value and put a pounds and pence figure to things which provide real value but do not lend themselves to this. Become more metric and objective driven as organisations. We can use the UX toolkits and Analytics, A/B testing, WSJF for example to asses value and decide what to work on. One for another time maybe…..

Cost overruns and going back for more money is not a problem. We simply try to optimise the amount of money we get out of the squad for the amount of money we put into the squad.

Why is it better to fund products?

Rather than re-word and copy parts I will refer you to the great article by Sriram Narayan – https://martinfowler.com/articles/products-over-projects.html

Other references:

Staged Architecture Model https://blogs.msdn.microsoft.com/karchworld_identity/2011/04/01/lehmans-laws-of-software-evolution-and-the-staged-model/