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

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

  1. @Flowchainsensei AFAICS what I wrote is in line with what Wikipedia has on Inventory in the TOC context. From wikipedia: “Inventory is all the money that the system has invested in purchasing things which it intends to sell.”

  2. The idea of “investment before sale” is a valuable one. It is potential waste, or potential value. It’s certainly uncertain, and eliminating the uncertainty is valuable.

    As @Flowchainsenei says, inventory links closely into Goldratt’s ideas, and there we talk about stacks of inventory being a sign of inefficiency, although it may be that the customer has already promised to pay for these yet-to-completed things. (Bad for cashflow, good for company value.)

    So in that scenario (which is not product development) your definition doesn’t quite align with Goldratt’s, even though you are saying something valuable.

    To avoid this confusion — and more importantly, to avoid your message being lost in that confusion — I wonder what would happen if you used a different word, something other than “inventory”?

  3. @pigsaw Actually, if you take the wikipedia TOC page’s definition of Inventory
    “Inventory is all the money that the system has invested in purchasing things which it intends to sell.”

    and mine:
    “everything that represents investment before a sale is made or a customer is served”

    They seem to be *very* similar, no?

  4. Yes, agreed with that. I didn’t see the “customer is served bit”. As long as the word inventory serves its use that’s good.

  5. I really liked the idea of defining what inventory is, because this term can have quite a load, and it can also be overloaded if we are to look at this post and think of software development. After reading your post there are some questions that were raised in my mind ..and that I would like to share..

    In other industries, inventory has a physical form, piles of something. In software, inventory is more abstract and represents more than that. Speaking in the context of software development, should one include in inventory all produced but not shipped items (code, ideas, infrastructure) ?

    Experiments are one of the main ways of gathering knowledge and learning. It is well known (and I believe you agree) that not all experiments end up with something viable and ready to ship, but still we can not call them useless, because of the learnings that were extracted from them. Do we include in “inventory” the deliverables of these experiments ? According to your’s post logic these would be bad assets.

    Now, it is time to answer your questions ..
    What do you think?
    I believe you have an extreme approach, that divides things in two polarizing groups. It seems you try to adapt some non-software development notions to the software development environment, without taking into consideration the specificities of the software development business model.

    Do you identify with the description above?
    I identify only partially with the above description, but the discussion is welcomed, as this is a good step towards a better approach and understanding of the lean principles and views, from manufacturing to software development.
    Do you see this happening at your work?
    Up to some extent I see it happening in the company I am working for. There is a lot of work that could have been done better but most similarities seem to be when looking at started but not finished projects. I believe this is the most dangerous and toxic software development inventory item, as they tend to both consume resources and impede new investments.

    How would you solve the Inventory problem?
    First, I would adapt the notion to the field, and customize for each company what inventory means. Apparently the accounting metrics currently used, also in software companies, are not adapted too well, as inventory has a different meaning in their books. If I were to attempt to solve this problem, this is where I would start, because most companies exist for creating and maximizing monetary value, and as long as software development inventory is not tied to some accounting metric, it will have no clearly visible value associated. Most companies keep an eye on their inventory, and try to optimize it to suit their needs and goals, and this is not yet happening in software. This is done party with the project based approach on software development, financial departments keeping the tabs on the expenses and revenue of a project, tracking the inventory in an indirect manner.

Comments are closed.