We Should Run Our Products Like a Trading Floor

Imagine an investment bank running with the following scenario:

Manager:

“Hi team, we are putting in place a new process for you to help us be more predictable and control our budget and schedules over the next year. By the end of December, we want you to hand in a plan that tells us:

• Which trades you will execute over the next year
• What date you can deliver each trade
• The cost for each trade, and the cost for all of the yearly trades
• The expected revenue you will make for the whole year.

To help you, we will be monitoring the progress every few months to ensure you have made the trades you committed to, on time and on budget.

If you find that a trade is no longer worth executing, please submit a change request form and get sign-off from your manager to remove the trade. If you would like to add a make a new trade that is not on your trading plan, please fill out a separate change request form and send it to your manager. When you are trading on behalf of external clients, please ensure you also get your legal counsel to make the changes to the contract and sign-off on it before executing any new trades not covered in your annual trading plan.

Please send any comments or questions to your manager and we will endeavor to answer them in a timely fashion.

While the scenario above is clearly insane due to changing market conditions and decisions that need to be made in microseconds rather than a year in advance, do they do exactly this with their product teams?

I remember working with a large investment bank at the start of the current economic crisis. I was consulting the product group on how to best to manage their product portfolio and was working with their Agile teams. The bank was running Agile and a traditional waterfall approach in parallel. The bank had a fairly standard annual budget process which required the product teams to submit a roadmap based on the projects they were going to release, complete the resource request, budget, and schedule. The project managers were required to submit a detailed work breakdown of all of the features they were going to deliver for each project release.

The parallel teams had very different approaches. The waterfall teams had a big release planned for their projects at the end of the year when their project was ‘feature complete’.

In contrast, the Agile teams were updating their annual release plan on a quarterly basis to give themselves more flexibility. They were halfway through the financial year and had already delivered four smaller releases to market.

Overnight the market changed and the economy plummeted. The bank reacted by halting all development. The current strategy was clearly not going to work with the changed economic conditions, as the products they were developing were based on a high risk, high return model. When times are good, this is a good strategy, however their customers now wanted security to ensure their money was safe, so the bank needed to shift 180 degrees to a low risk model. The bank also had to make some hard decisions to weather the storm, which meant making some cuts across the organization.

The waterfall teams were back to the drawing board and said it would be another year before anything would be ready to release, and the work they had already done was now unusable.

The Agile teams were able to change direction quickly and start work on these new requests with a first release due in two months time.

Guess which teams they kept and which teams lost their jobs?

We need to run our product teams like the trading floor. We need to be flexible, set targets, but then allow the product teams to change direction quickly without requiring a bureaucratic and slow moving process to make decisions within.

Rather than seeing your software teams as a cost centre, see them as a profit centre. The traders have targets such as ‘hit [x] goal’ each, so why not run your product teams in the same way? You can bet your traders won’t be submitting a change request form each time so don’t hamstring your product teams with harmful bureaucracy.

Give your teams targets and allow them to innovate and make many product decisions (trades) to spread the risk and try as many trades (product ideas) that will generate value as possible, and pursue those. We can’t possibly predict trades a year in advance and products are just as complex and affected by changing market conditions. It’s time to run product development like the trading floor.