Here are the posts in the Agile Economics series:
Gambling Issues	Supply and Demand	Early and Often	Delusions of Grandeur
Scale and the City	Scale 3D	Cost of Change

In order to be in business, we need to answer two questions:

• How do we make money?
• How do we make more money?

Most people focus on the first one, rather than the second one. And rightly so.

Money is important not just because it buys nice things. It keeps the boat afloat (that’s the company) and allows us to expand the product, build others and support our customers.

So all we need is to build something valuable that people will pay for.

Which you’ve probably guessed, is one of the hardest things to do. And it’s not just a start-up thing. Enterprises need to do the same with their products and services.

Money Is Feedback

One of the principles that are part of any agile methodology are feedback loops. Getting money is feedback that people are willing to pay for our product. While that’s the most obvious, and important feedback, there’s an inherent problem with it.

We need a product to prove people will pay for it. That takes time. And a lot can happen until then. The project can get botched up, people can leave, and a competitor can come out with a version of their own. Then, even if we manage to release it, there’s the small risk that people won’t actually like it.

All this work for nothing. All that money we’ve invested in our beautiful idea, not to mention people’s livelihood is at stake.

So how do we build the right thing for fun and profit?

From waterfall to lean start-up

If you understand the problem, you know the solution: Make the feedback loop shorter.

In waterfall, we had big multi-year projects subjected to the same risks. Agile methodologies cut it down to a release (that’s actual release) of a few weeks. We got feedback reduced to a smaller period. If we were right, we would continue to do on the path to an actual release. If not, well, we’ve wasted a lot less money.

There’s actually more than that. If we’ve continued down the wrong way, not only have we wasted the money on our failing project, we also missed the opportunity to work on a possibly more profitable one. Now, compare the opportunity cost of one month and three years. Huge bucks.

Can we sell what we release? Not always. Value is not always in the product. In-app purchases require an app first. Marketing a product may need an actual product, before we start selling. Value is not always counted in money (although, when the two align, we’re obviously on the right track).

You must be thinking: MVPs! That’s the quickest way to make money!

No, they are not. MVPs are not about making money, they are about learning as quickly as possible if we are on the right track. These are experiments, and we do them in the quickest, cheapest way.

Shortening the feedback loops.

The thing is, this is not a one time thing. Since everything we release has an inherent risk in it, everything we release is a gamble, and therefore we’d like to hedge our bets on them. That means we need to conduct these experiments early and often.

And when they don’t make economic sense anymore, we need to start thinking about rebooting.

Now, you maybe thinking a couple of questions, so here are couple of answers

• Lean startup is pretty new, why is it just now that we’re doing experiments?

We’ve been doing them all the time. They were just big experiments that usually failed.

• Surely enterprises know what they are doing

They have some skills in product management, a proven sales force and good marketing. Yet they suffer from the same risks, and are a lot less agile than small startups. Plus, they suffer from the “we know what we’re doing” bias. So the risk is there, it doesn’t feel like a huge one as “the company can take it”. However, “Too big to fail”is no longer true. It never was really.

• You can’t measure everything in money. If that was the case, we’ll always prefer adding a feature instead of fixing a bug.

User satisfaction has value too, and eventually it will have some business impact. So features do not always make economic sense (they are still a gamble, and the bug report from a customer was actual feedback). However, we need to experiment with that as well, in order to see if what we think will increase satisfaction, actually works.

• What about ol’ regular product management skills? Do we drop everything we learned over the years and just open an experiment lab?

You can, but it would be wasteful. A lot of “good practices” can be used to be the framework for the product. That will shorten the feedback loop. But don’t fully rely on those, you still need to validate them.

Agile principles support quick learning and validation. You just need to be able to release early and often to continuously learn if there’s money there. You need things like continuous integration, talking with customers, and the ability to change direction when you learned something new.

Then we can start answering the second question.