Clarity

 View Only

Projects-to-Products: RC Product Budgeting vs Project Budgeting

By Brian Nathanson posted Feb 07, 2020 11:55 AM

  
We have our second reader comment (RC) based post. In response to my prior post about product managers, James Ifill asked several good questions to which I immediately responded and suggested I would build on over time. I expanded on his first question in this post. Now I'm tackling his second question: "How does finance - especially budgeting - differ between the 2 [projects vs products]?"

Product budgeting provides greater discretion to the product manager than project budgeting does to a project manager. In essence, when you choose to fund in a product model, the organization elects to fund the product itself (fund Product ABC for $100M for FY20) because the product as a whole has recognizable value that is worth investing in. The specific work that will be done for that $100M, however, is up to the discretion of the Product Manager. When the Product Manager (or Product Management team for larger products) decide which features will be included/enhanced throughout FY20, then are essentially allocating budget in making those decisions.

Some features may be highlighted at a high level in justifying the product's funding amount (what you might call marquee features -- see my post on value elements for more details), but you certainly would not breakout the work to the detailed level necessary for delivery. This is in contrast to typical project budgeting and business cases, where the entire scope of work is specified and estimated as part of the business case in order to justify the funding level.

A product model works better for agile organizations because it pushes decision authority down to a management level that can be reasonably expected to know all of the particulars that should go into making a decision about whether to invest as opposed to retaining that authority at a higher level with executives that are unlikely to have all of the proper data/details without consulting others, which then forces availability-challenged execs to convene hard-to-schedule meetings just to get up-to-speed and make necessary decisions.

Instead of funding specific business sponsored capabilities, you fund the release train and trust that the Product Manager will steer in the right capabilities. By "leaning out" the funding process and taking away detailed funding control of exactly what is to be built from the business, you will need to "over rotate" toward communication that what is being built is what they need. If you take away control and don't provide visibility and accountability, this whole model will fail quickly. This is where roadmapping comes in: Roadmapping is the process (and the resulting artifacts) by which product managers communicate the plan for evolution of the product and build consensus in support of that plan.

One related question you might ask centers around capitalization: How do you handle CapEx vs OpEx in a product model? If you are in a pure dedicated product model where individuals only work on one product or one related set of products, then you can generally use a percent allocation method for dividing between CapEx and OpEx -- usually grounded in historical time tracking data on what proportion of time has typically been spent in activities before and after technical feasibility and production launch.

Things get more complicated if you have individuals work across products, which means that a pure percent allocation may not capture the true nature of the work being performed. Sure, Product ABC may have a 60/40 split, but if the team member works on Product ABC half the time and Product DEF half the time -- and Product DEF has a 70/30 split -- now I have to know, at a minimum, how much time they spent on each product and -- more likely -- need to know what type of work they contributed to each product. In the aggregate across individuals, the splits may be what was estimated, but auditable records for how you got there will likely require time tracking or some other basis for allocation. This is part of the reason (although not the primary one) that dedicated teams make sense if you can afford to have them.
0 comments
34 views

Permalink