Products over Projects, why our customers are increasingly going this way

I was having a beer with a fellow app development agency owner the other week. We were talking about how our customers finance their apps and digital initiatives and tackle making progress. I realised that Pocketworks customers were slightly different in how they finance and run their digital growth.

Image Credit: Lulu, my 3-year old daughter decided to make a laptop!

More and more, they are opting for products over projects, where they fund a team to work on a problem rather than a defined scope.

They are also assigning agile budgets where the goal is to achieve business outcomes instead of concrete deliverables.

Underpinning this is a push for being product-led; they want to win sales by letting their digital products demonstrate value to customers in order to shorten sales cycles and lower customer acquisition costs.

This didn't happen immediately. No, only over the last few years have I noticed a shift in how our customers invest in their app development and digital product development.

It starts with the need for agility.

I'll take the agile option

I'm hearing this more often. Businesses have a choice when they embark on their journey to building an app, website or any digital service. 

1. Waterfall: Define the scope upfront, set a budget for the project, and deliver the scope.
2. Agile: Define the strategy, allocate a budget for the team, and let them run at the problem.

What I've noticed recently is that most companies we work with might have started with option number one, but over time have ended up switching to option two.

Why?

Here're a few real-world quotes I've heard when I asked clients why they want to take the agile option:

"We were building in an echo chamber"

"Our world is changing too quickly we need to be flexible"

"We don't know all the answers right now, we need to just get moving"

The "echo chamber" comment was a brave thing to say. Sometimes you have an idea and build it and then it doesn't work as well as you'd hoped. You realised you didn't have enough customer input, instead just bouncing ideas around in your own peer group.

A better way could have been to build something smaller, getting feedback from customers constantly, and adapting to that feedback as you go. This can't be done with a defined upfront scope and budget. 

Speaking of scope and budget, Agile Budgets are also something gaining ground here at Pocketworks. These are necessary if you want to work in an agile way. If anyone says they work agile without having business leaders allocating agile budgets, they misunderstand what agile is. Agility has to come top-down and leadership have to understand it.

With an agile budget, you fund the team rather than the project. It's like saying "how much cash do we need to run this team for a year to solve problem X?" and then chucking the money in a pot. You have a clear idea of business outcomes, and you review progress toward those outcomes regularly. The business can now respond to changing market conditions. The team can involve customers in the development process and adapt to their feedback without worrying about "the scope". The outcomes suddenly become most important.

Products over projects

In the old days, IT would manage a project development such as a website or app. It would be delivered and paid for, and then the business would move on. Come to think of it, this still happens a lot today.

I like to call these projects "fire and forget" or "build and run".

In cases where the product can drive substantial business growth, this approach doesn't work. This is because it's so incredibly rare that you can achieve substantial outcomes and then take your foot off the gas. Success creates new challenges and opportunities, and if you snooze you lose. 

If you deliver a project and have great results, what happens when the team has moved on to another project? You end up waiting, which means you miss opportunities. 

Some companies learn this the hard way. Others start with a "product" rather than a "project" and decide to allocate an annual budget and secure the team to run the product continuously. This allows them to constantly deliver, measure, improve and respond to customer feedback.

This blog post on martinflower.com is worth a read to understand this more deeply.

Product led, not sales or marketing-led

Sales and marketing play a hugely important role, but they exist to drive the growth of the products.

Once your digital product or services becomes your key strategic pillars, you start optimising the business around their development. They are the foundations for driving customer growth and retention. 

I've seen marketing-led clients start building products as an experiment to learn from. The promising results then lead to further investment. Over time, their sales and marketing functions shift to pushing customers into the products; they eventually became product-led companies. 

Other clients had chosen to be product-led from the start. They had had already set themselves up this way. 

Amplitude, an analytics company, has a really good blog post on it here.

Some tips for implementing an agile budget

If you're like  many businesses, the people who sign the cheques might not be quite ready for agile budgets yet. Allocating a budget with no clear scope is a big ask. Fortunately, there are ways to get close to this using traditional waterfall budgetting techniques. 

1. Have a best-guess scope of work  

In the part of your contract or side-letter that outlines the work, have a clause saying that it is permissable for the buyer and supplier to agree changes to scope when new information comes to light. This makes the scope list more of a "here's what might do" list rather than "here's an exact list of what we'll deliver" list.  

2. Add an iteration line-item to the scope

Add 20%-50% to the budget for iterating which will be used to fine-tuning what you develop. This increases the chances of the work actually creating desired customer and business outcomes. Buyers usually want certainty of success, so having a nice buffer to increase their chances makes a lot of sense. 

With these two tips, you've made your contract more agile because the scope can change and there is wiggle room for adapting to new information and iterating on the work done. We've seen this work to great effect, even with large manufacturers who often have strict stage gates and ample red tape!

That's it for now. I hope this has been a useful overview of agile budgets, product over project and product-led.