Product-centric funding

How to configure the software development funding process to incentivize measurable product outcomes

Download white paper

Enterprise organizational structures impede product design 

The traditional enterprise operates using a modular architecture with separate disciplines and segregated responsibilities. For example, marketing, sales, customer success, IT, support, and many other groups co-depend on each other for successful business outcomes—yet exhibit siloed behavior. 

Software projects often originate inside the customer success teams (e.g., an SVP of lending identifies an opportunity). However, the projects get delegated to either internal IT or partner vendors for implementation. In other words, customer success is not equipped to build software. Moreover, while the budget originates from the customer success team, the IT team consumes the budget to produce results and ultimately delivers on the ROI presented in the business case.

This misalignment presents a conflict of interest. The customer success team wants the maximum number of features to guarantee success with customers, while the IT team wants the minimum amount of risk (and shortest path to completion) to make sure the project stays within schedule and budget. 

The IT group is not necessarily interested in the customer as their ultimate responsibility is to build the product according to the specifications. Now, if the business does not adhere to the specification, IT is free to request additional funding, shift resources, or extend timelines. 

Over time, the business stakeholders become jaded and lose all trust in the IT department’s ability to deliver. IT continues to play defensively, shifting blame to the requirements, inadequate specifications, rigidity of underlying legacy architecture, and other limitations or demands from the business. 

The issue with this traditional operating model is the scope and success of the product fall outside the influence of the team building the product. True ownership is not possible. Luckily, we can leverage learnings from the broader software industry and our tenured experience on how to best address these issues by treating software as a product.

Continue to:Treat software as a product