An exploration of recent thinking around product vs project funding. We look at a number of recent articles reflecting views on a product-centric focus by ThoughtWorks’ Sriram Narayan, Jeff Gothelf, author of Lean UX Author, and Leon Tranter.
Martin Fowler recently published an article titled Products over Projects written by Sriram Narayan, author of Agile IT Organisation Design, which compares project and product funded teams. Narayan describes the concept of product-mode, where funding and delivery are geared towards product discovery under the ownership of long-lived teams. Jeff Gothelf, author of Lean-UX and Sense and Respond, has also recently touched on the benefits of product aligned teams. Similarly, Agile commentator, Leon Tranter recently wrote about project funding models being a contributing factor for what he describes as the technical bankruptcy of a product.
Narayan writes that projects are funded on “benefits projected in a business case” and “staffed from a pool of talent” with the mandate to “build or enhance some system or application and move on.” Contrasting against this, Narayan describes the funding of teams in product-mode:
Teams are funded to work on a particular business problem or offering over a period of time; with the nature (of) work being defined by a business problem to address rather than a set of functions to deliver. We call this way of working “product-mode”
Narayan provides a comparison of the project based funding model with product-mode teams, highlighting that product-centric teams work towards an “evolving roadmap aligned with product/business strategy.” Narayan compares project funding for a preconceived solution, to product-mode where funding is “for building, running and iterating on the solution or even pivoting to a different solution till the underlying problem is verifiably solved.”
Gothelf recently wrote about GE’s move away from product aligned teams using the Lean Startup Method for product discovery. He writes that while Lean Startup is itself a risk mitigation strategy, the market seeks predictable profits, costs and ROI, which he writes, “is not the world we live in anymore and Lean Startup practices make that perfectly clear.” Gothelf goes on to say:
The vocabulary alone immediately sends up red flags during budget meetings — assumptions, hypotheses, experiments. None of these things sound like shipped products (or profits). Instead they sound like shipping delays, purchase delays and profit delays.
Tranter examines project funding as being a contributing factor to poor products and escalating technical debt. He writes that:
when building a software product, the traditional “project” way of funding and managing the work is catastrophically stupid. It encourages teams thrown together and then disbanded, bad product-market fit, death marches to meet arbitrary deadlines, and leaving behind piles of technical debt.
Tranter writes that technical debt often reaches a state where new projects are needed to “untangle the mess and start all over.” He states that this is a point where the “cost of change curve (is) so out of control, that it possesses negative value and consumes all of a team’s effort.” He defines this as a point of technical bankruptcy. In contrast, Narayan writes that product-mode “allows teams to reorient quickly by using short-cycle iterations while maintaining the architectural integrity of their software to preserve their long-term effectiveness.”
Narayan describes how projects encourage teams to make short-sighted architectural choices and ignore the long-term costs of these decisions:
The incentives involved in project-mode put pressure on teams to neglect medium-term architectural integrity in favor of (often perceived) short term feature delivery. Since the team doesn’t face the consequences of that trade off, they don’t benefit from the feedback loop that appears when there is longer term ownership
Gothelf writes that the traditional model of optimising short-term profits cannot apply to a world which allows “nearly anyone to start nearly any type of business with far smaller investments and risks.” He writes that “Lean Startup is the “magnifying glass that reveals antiquated planning practices not suitable for a software-driven world.”
Gothelf comments that in addition to funding incremental improvements on a product, funding models need to change to support the slower drip of innovation. He writes:
a separate funding track has to live in parallel that supports an increased level of patience for innovation efforts and the building and scaling of new businesses. 90% of startups fail. Does your organisation have the patience for 90% of its new ideas to fail?
Tranter warns that it is not sufficient to just move away from project-based funding. He cites seeing an organisation which had forgone projects for a “continual value stream of funding,” yet replaced it with a “push” system. He writes “the poor teams had no say in what the work was, when it was due, what its priority was or how it was to be built.” Tranter makes the case for teams to have full-stack ownership of the entire product such that:
If a team builds a product, they own the product. They own it full-stack, in both space and time. Full-stack in space means the team is responsible for the entire tech stack, from user interface through to API through to datastore. No handovers, no middleware specialists, no component teams… Full stack in time means the team owns the feature or product from its birth through to its death. No handovers, no maintenance group, no operations or BAU team. You build it, you run it, you fix it.
Look out for the final instalment of Narayan’s article on MartinFowler.com; expected to be released shortly after Thanksgiving.
