Learning from the “Real World”, inventory in Product Development

In 2000 I was frustrated with the problems I saw in the Software industry, so I decided to study Lean (or Toyota Production System) to see if I could learn something to apply in my projects. As I studied Lean/TPS I discovered a concept that clicked. The concept was Inventory. Inventory is bad (sometimes necessary, but bad). Put simply: Inventory represents money you already spent but has not yet been converted into a sale.

Later, when working on RandomManager.com (my super-cool T-shirt business for intelligent people like you!), I applied what I had learned about Inventory. All t-shirts we print are bought after customers purchase them (positive cash-flow) and shipped immediately after printing (1-2 days typically). So my Inventory at RandomManager.com is small (1-2 days) and only bought after I got paid (inventory is incurred *after* the sale is made). This allows me to focus on what matters: the order I just got, instead of stressing about being able to pay the server bill. In financial terms: it allows me to have a positive cash flow (money in the bank at all times).

This approach alone makes RandomManager.com even possible. If I had to buy inventory in advance I would have a lot money invested in it but no revenues: my cash flow would be negative which means I’d be financing *future* sales without knowing if they would happen. In fact, I would be making a bet on future events - I don’t like that as you probably know from my #NoEstimates posts.

So, I think I can understand why Inventory is *bad* for my t-shirt Startup RandomManager.com, but what is Inventory for Product Development (including software)? And how should we manage it? And what are the consequences of inventory in Product Development? And how can we avoid inventory in Product Development? Read on...

What is inventory in Product Development?

Today I’m going to focus on describing what I think is Inventory in Product Development (including software).

This just hit me: Software inventory is *not* unreleased code. Have to find time to write about this tomorrow... #NoEstimates #Lean

— Vasco Duarte (@duarte_vasco) July 18, 2013

As I published my insight on twitter, Nik Silver linked me to an interesting post where he describes 3 possible definitions of Inventory, let’s explore those different views:

Inventory as unreleased code

Nik pointed to a post that argues for unreleased code as Inventory. Although I understand the argument (and agree with it), I don’t think code is the inventory we have in Product Development. For one, code is not present in all Product Development environments so it does not fit the context I’m trying to describe, but most importantly code is a product of something that happened before: a requirement was created. Just like in my T-Shirt Startup the inventory is not the printed t-shirt, but rather *all* of the money invested into products that are not yet sold. At best we could argue that Requirements + Unreleased Code are Inventory, but that would not cover all Product Development environments.

Inventory as yet-to-be-delivered requirements

The second hypothesis that Nik considers in his post is that Undelivered Requirements are Inventory. Again, I do agree that they can be considered inventory, but where do requirements come from? Is that the complete investment-before-purchase? No. There’s something else that causes Requirements to be written...

Inventory in Product Development is...

My view is that Inventory in Product Development is - just like in RandomManager.com - everything that represents investment before a sale is made or a customer is served. In Product Development there is something that happens way, way before Requirements or even Code are written that represents (and leads to) investment that must be made before any customers are served.

My theory is that invalidated Business Models factors (including hypothesis on customer segments, problems to be solved, distribution chains, marketing needs, etc.) are the real inventory in Product Development (including software).

I’ll try to make this clear with an example. In RandomManager.com if we wanted to provide Same Day Shipping (a service concept) for our t-shirts we would need to have at least 1 t-shirt of each size times the number of colors times sizes available plus a t-shirt printer ready to run (also an investment). Why would we do Same Day Shipping? Perhaps we hypothesized that it would either drive more sales, customer satisfaction, higher prices or all of the above. This is a Business Model hypothesis, made before one requirement is written or a line of code is created. This is the real inventory: something that represents the beginning of an investment without a sale being made.

In Product Development Inventory is the start of the chain of events that will lead to investment that has no relation to actual (money-in-the-bank) sales. In short, Inventory is any investment that can make your business fail. Code, requirements untested code, unreleased code are way down the chain of events that was started on day Zero when you first thought about the Business Model for your business. (Like an Estimate, for example - sorry, could not resist ;)

Validating your business model

This post is large as it is, so I will leave this to a later post (hint: there’s many approaches that help you reach this goal), but for now: what do you think? Do you identify with the description above? Do you see this happening at your work? How would you solve the Inventory problem?

Photo Credit: images_of_money @ flickr