The phyrric victory: a lesson in product management

• product
Back

If we are victorious in one more battle with the Romans, we shall be utterly ruined. — Plutarch

The Pyrrhic victory

The year is 279BC. The greek king Pyrrhus of Epirus, often considered one of the greatest generals of antiquity, engaged in full battle against the Roman empire. Despite eventually winning at the Battle of Asculum, he lost a great part of his army, and was abandoned by many of his friends and principal commanders.

Although this conflict took place more than 2000 years ago, the term "phyrrhic victory" is still used to refer to victories that make us wonder if we even won anything at all. Not every win is a victory. Winning at all costs rarely results in a true victory.

Today I want to take the lessons learned from the Phyrric victory and derive from it one learning that applies to managing software products: The success of software projects depends greatly on good estimation of their costs.

Product management is a scheduling problem

A product manager essentially has two jobs. First, he needs to decide what to change in the product. Then he needs to decide when to change it. Every time a decision is made to modify the product (add, remove or modify a feature) is what I call a change.

In fact, we can think of a product manager's job as an algorithm that takes tasks from the set of all possible changes and produces an ordering by priority.

A good product manager will pick an ordering that delivers increasing value over time.

Now imagine that you need to come up with this ordering and you don't take cost & complexity into account?

I'll tell you what will happen: Most of the time things will be just fine. Week after week you'll deliver useful features to users and everyone will be happy. People will complement you on how much value you're adding to the organization. Users will praise you for picking the right features to add to the product.

Until one day, ignoring task duration, you will take on a gargantuan task. You will run massive delays and you will eventually blow up.

It sounds almost obvious, but it happened to Steve Jobs. In 1978 he began the development of the Apple Lisa. An incredibly ambitious project which eventually took 5 years (3 year delay) and was eventually released at a price tag of $9,000 ($21,000 in 2021 prices). The Apple Lisa built all the right features, but was eventually a comercial failure.

Final thoughts: it's all about the ROI

The reason the Apple Lisa and Phyrrus are considered failures is not because they didn't delivered on what they promised. The failed because they didn't deliver a good return, relative to the costs of the project. Investors have a practical solution to this problem: measure the ROI.

Again, It's sounds obvious, but I very often fall for the trap fo optimising for value without taking costs into account. I hope this article serves as a reminder for you, dear reader, as well as for myself, so that we keep an eye on our budgets and keep delivering great software.

If you found this article useful, consider following me on twitter. I write about once a month about software engineering practices and programming in general.

I'm also developing SynthQL. A type-safe HTTP client for PostgreSQL and I would love to get your feedback.

Other posts you may like...

© Fernando Hurtado Cardenas.RSS