Shipping is a Feature* *is a core principle for product managers. It proposes that you’ll never be able to build a perfect product, so you need to learn how and when to ship your imperfect one, because customer use of the product is what really matters.

I’ve used this principle as a guide in my own endeavours as a PM, but I’ve always felt it lacked a tangible framework, both for managing and rationalizing the minimum viable product (MVP) to stakeholders.

*The Time Value of Shipping *is a framework to apply that principle. It borrows from a fundamental concept in Finance called the time value of money, which simply proposes the following:

One dollar today is worth more than one dollar tomorrow.

The reason is because prices rise with inflation over time, meaning your dollar will buy less stuff in the future.

## A quick example

A basketball costs $12 today. If you earned $1 a month you’d have $12 after a year, yet you still wouldn’t be able to buy it because of inflation.

If inflation was 5%, that means the basketball would cost $12.60 (+5%) in one year, $13.23 in two, and so on.

You’d have to wait until your paycheque from month 13 to get on the court.

## The product analogy

*Buying*the basketball is when you ship to your customers, usually your MVP- The
*price*of the basketball is your users’ expectations of the product (at any given point in time) - You
*earn*the sum of customer value that your team builds over time

Your job is to build enough value over time to afford the basketball. Graphing this reveals how most organizations view product value and MVP:

The major quality of this graph is that customer expectation is flat and static, implying that what your customer wants when you begin the project is what they want when you ship it. It’s not hard to see how people can fall into this line of thinking…

“Through research, we know our users want x and y at minimum, so as soon as we have x and y and nothing more, we will ship.”

That sounds perfectly rational, until you dig deeper into the effects of time on customer expectations.

Let’s redraw that graph applying the effects of time, which I’ll unpack below.

As with the time value of money, the time value of shipping is a simple idea: *delivering customer value now is worth more than delivering value later.*

If you choose to deliver value later, you need to account for inflation* *in user expectations, and your eventual product needs to be much better to compensate.

The differences in the trajectories of the customer expectation and value curves are clearly visible. The former grows exponentially over time, and the latter plateaus.

Customer value plateaus because a PM prioritizes the highest impact work, and thus the growth in value over time will naturally degrade.

Customer expectation growth accelerates because the longer a customer has to wait for their problem to be solved, the more time they have to switch to a substitute product. To make them stay, you need to deliver not just what they want now, but what they’ll want in the future (when there will be an even greater abundance of choice).

A simple, 140-character-or-less way of thinking about the framework is:

The scope of a minimum viable productgrowsthelongerit takes to ship.

## What the graphs reveal

When applying the time value of shipping, MVP is still easily identifiable (in this case is at the tangent of the curves).

But when you start to tweak some of the conditions, the graph suggests some interesting ramifications of the framework.

**First**, as in the example above, there may only be *one point in time (*the tangent) where you can ship and satisfy users.

As a PM, that’s scary.

**Second**, If your team slips on it’s schedule, this happens:

The entire value curve has dropped, and it means you’ll *never *be able to deliver enough value to customers to meet their expectations. At that point, there are two courses of action:

- Abandon the project and move to one where you can meet customer expectations at a point in time, or
- Call on more resources to brute force your value curve back to an intersection point

This “gap of doom” is what underpins most product pivots, as companies realize they cannot innovate at the pace of that particular industry and move to where customer expectations are more attainable.

As a PM, that’s *really *scary.

**Finally**, you shouldn’t always ship an MVP (i.e. shouldn’t always ship at the first intersection of the curves).

Instead, ship at the maximum spread between value and expectation:

This is counter intuitive to the gospel of MVP, but the time value of shipping suggests that sometimes holding off on a launch (even when it meets expectations) is the optimal thing to do.

How can this be, shouldn’t you launch at the first intersection and iterate instead?

Well, if you believe in tipping points, holding off a launch is entirely rational. The best products don’t just satisfy customer needs, they reap the rewards of virality that come with delighting users. This is accentuated by the network effects that come with launches, which have diminishing returns after the initial marketing push.

As a PM, that is *the scariest.*

## Just a start, another lens

There are a lot of interesting things I didn’t cover (for brevity) – like how competitive forces influence the curves – which I’ll save for another post if people find this interesting.

If the goal of the time value of shipping is a practical outcome for PMs, then this is a baby step. Graphing neat little curves in the real world is often a lost cause, with assumption built on assumption.

Instead, it’s really about adding another lens to the complex, multi-variate decisions that PMs make everyday. Something in aggregate we call *intuition.*

So, the next time your planning the roadmap, don’t only ask what the customer wants now, think about what they’ll want by the time you ship it.