Estimation, if there is one concept hard to grasp in product development it will be when things are done. With done I don’t mean the releasable increment from the iteration, but rather what will be in it? or in Product Management speak: “what problem does it solve for our customer?”.

I increasingly am practicing randori (sparring matches in judo) and find it has increased my agile fu. It’s a constant adjustment of balance, creating opportunities rather than waiting for them to unfold, follow through fast or the opportunity we created is gone. It’s hard work, time boxed and most of the time I loose learn.

The key thing in both situations is that we don’t have a lot of time to estimate what will work or not. We can’t plan very far ahead and we have almost no data to make assumptions on, we do know however the extreme boundaries of the assumptions and iterate from there.

A throw that requires lifting the opponent is not best move forward

A throw that requires lifting the opponent is not best move forward

Three steps to fast and reasonable accurate estimation 

1.) Don’t be afraid to be imprecise

My physics teacher out performed our entire class running on TI calculators by applying mental arithmetic and rounding all calculations: the square of two is 1.5, there are 300 days in a year, gravity is 10 m/s2 etc. His answers were always close enough and achieved in at least half the time with less investment.

2.) Decomposition is your friend

Complex things are hard to estimate, but become easier if you break them down. Either they are compound problems (time to build the eCommerce site and the order handling system) or complex ones (the site needs to run 10M users, but what about 1M, or 100k or just 1k users.

3.) Practice

As with randori, you can only learn by doing. Simply by repeating these estimate over and over again you will get better at it. You can accelerate this learning by doing it with team members and explain your thoughts to stakeholders. Not only can they help breaking down the problem, they can also help you sanity check the answers.

4.) Target the center of mass

I have no clue how much my opponent weighs, its more than 50kg but less than 150kg, but if I can move the center of mass, the rest has become irrelevant. In math you have something called the geometric mean to cover this. In compliance with rule 1 we won’t pull the square root of the bounds, but as with judo we will eyeball it by averaging the coefficients and exponents of the bounds.

How does it work?

Let’s take a schoolbook example: how many piano tuners are there in Amsterdam?

Well Amsterdam has about 800k residents, but not all of them would own a piano. Since the city is popular with students, let’s not assume that the average household is 2 and only one in 10 people own a piano. That would make 40,000 pianos.

Feels like a lot, but if they get tuned once a year and a piano tuner can tune 4 pianos per day, for 200 working days per year. Would mean 50 piano tuners. That sounds about right. Now with fermi estimates it’s safe to say: there will be more than 5 but less than 500 piano tuners in Amsterdam.

(Google and Yellowpages turned up 35 different ones after a meticulous search.)

Let’s run an another exercise and determine the need for agile product owner training in the Netherlands.

There are about 16M people in the Netherlands, what would be the boundaries on company size be? The smallest is obviously 1 the biggest? I don’t know, surely its not 100k employees, but 50k might be a good upper boundary. So between 1x10 0 and 5 x 10 4 makes 2,5 x 10 2 which is 250. That is probably wrong, because there are quite a bit of 1 person enterprises.

Lets assume that half the population is employed, that makes 8M people, divided by 250 is roughly 30k companies. Now that is oddly off because the distribution of small-single-person business is different, but the number of business that we can address is in the ball park, after all, by very definition you are your own product owner. Assume half of them is working on products with a high degree of risk and uncertainty that is common for new product creation.

How many people would run product/service teams? wel at least one or two and surely not more than 25. So the mean should be little over 5. This brings the total addressable market to 75k. Not bad for a 2 minute exercise.

Fermi estimates can give you a quick boundary to check if your assumption falls within a reasonable boundary. Teams look up to product owners to give answers fast and decisively. You may not know it exact but working with boundaries that makes sense avoids shooting completely from the hip or responding with a blank stare.


Want to learn more about agility, martial arts and product management? Go order the book from bol.com if you are in the Netherlands or Belgium or sign up to get the international edition.

The Product Manager's guide to Continuous Innovation