英文原文来自：https://medium.com/the-black-box-of-product-management/the-time-value-of-shipping-6deaf8d7d565

---

产品推出的时间价值

从“形成推出产品的特点”得出的模型

BY   Brandon Chu    翻译：Kevin嚼薯片

“形成产品发布的特点”是产品经理的一个核心原则。它指出你永远无法去构建一个完美的产品，所以你需要去学习什么时候和怎样去上线运行你不完美的产品，因为用户去使用产品才是真正重要的。

作为一个产品经理，我已经试图在用这个原则作为我的工作指导，但我总觉得缺少了一个实实在在的模型，用于给利益相关者去管理和合理化最小可行性产品（MVP）。

“产品发布的时间价值”是应用这个原则的模型。它借鉴称为金钱时间价值的金融基本概念，包括以下这个：

今天的一美元比明天的一美元要值钱。

原因在于价格随通胀而逐渐上涨，意味着你的美元在未来能买的东西越来越少。

一个简单的例子

今天一个篮球标价12美元。如果你一个月挣1美元，一年后你将有12美元，但因为通货膨胀，你仍无法购买这个篮球。

如果通货膨胀为5%，这意味着一年后篮球将标价12.60美元（+5%），两年后则为13.23美元，如此类推。

你必须等到第13个月的工资才能买到它。

类比到产品

1. 什么时候去买篮球就像什么时候去给你的用户发布产品，尤其是你的最小可行性产品

2. 篮球的价格就像你用户对产品的期望值（适时地给到的一些功能点）

3. 随着你团队不停构建功能，你将获取这些用户价值的总和。

你的工作是随着时间的推移去赚取足够的金钱去支付篮球。以下图表揭示了大多数组织对产品价值和MVP的看法。

纵坐标：用户价值；横坐标：时间；横线：用户期待值；斜线：用户价值；蓝字：价值缺口，通过迭代增加的额外价值

这幅图表主要的特性是用户期望值是平的和静态的，这意味着从项目开始到推出产品时用户想要的东西都是一样的。这不难看出人们容易落入这种线性的思路中…

“经过研究,我们知道我们的用户至少想要x和y，所以一旦我们仅仅只有x和y的时候，我们就发布产品。”

这听起来完全是理性的，直到你去深入挖掘受到时间影响的用户期望值。

产品发布的时间价值

如同下面一样，我重新绘制加入了时间影响因素的图表。

纵坐标：用户价值；横坐标：时间；线：用户期待值，用户价值

与金钱的时间价值类似，产品发布的时间价值同样有一个简单的概念：现在能提供的用户价值回比后来的多。

如果你选择更迟地才去提供价值，你需要去考虑用户期待值的通货膨胀，并且为了更好地补偿，你最终上线的产品需要是比之前的更好。

用户期望值曲线和用户价值曲线轨迹的不同之处清晰可见。前者随时间呈指数式增长，而后者则平稳甚至停滞。

用户价值的停滞是因为产品经理优先排期了影响度最高的工作，而因此价值的增长就会自然而然地随之减少。

用户期望值的加速增长，是因为当用户等待他们问题被解决的时间越长，他们就有更多时间去切换到替代产品。要让他们继续留下来，你需要提供的不仅仅只是他们现在想要的，还有他们未来想要的（当有更丰富的选择时尤其如此）。

简单的，140字以内对这个模型的思考是：

最小可行性产品的范围越大，产品发布所需的时间越长。

图表揭示了什么

运用产品发布时间价值时，MVP仍然时很容易被识别的（本例中是曲线的切点）。

纵坐标：用户价值；横坐标：时间；上曲线：用户期待值；下曲线：用户价值；蓝字：价值不足；

但当你开始调整一些条件时，这个模型会呈现一些有趣的分叉在图表上。

首先，在上述的示例中，可能只是刚好有一个点（切线交点）你能发布产品以及满足用户 。

这对于产品经理来说这是可怕的事情。

其次，如果你团队在时间表上有所疏忽，就会发生以下情况：

纵坐标：用户价值；横坐标：时间；上曲线：用户期待值；下曲线：用户价值；红字：绝望的差距；

整个价值曲线已经下掉了，这意味着你将永远不能提供足够的价值来满足用户的期望。在这一点上，有两种措施：

1. 放弃这个项目，转移到你可以有一个点去满足用户期望值的项目上，或

2. 召集更多的资源去粗暴地把你的价值曲线拉回到有交叉点的位置

随着公司意识到他们不能在个别领域跟上创新的步伐从而转变到能触及到用户期望值时，这个“绝望的差距”是支撑大多数产品轴心的东西。

这对于产品经理来说这是真正可怕的事情。

最后，你不应该总是发布一个MVP（即不应该总是在第一个曲线的交叉点发布）。

相反地，应该在价值和期望值之间有最大差距的时候去发布：

纵坐标：用户价值；横坐标：时间；上曲线：用户期待值；下曲线：用户价值；红字：最大的差距；

这是违背MVP公理的，但产品发布时间价值表明，有时候推迟发布（即使它已经符合预先期望）反而是最优的。

这怎么可能呢，难道你不应该在第一个交叉点就发布，并进行迭代吗？

好吧，如果你相信临界点，推迟发布是完全合理的。优秀的产品不只是满足用户需求，它们还通过被取悦用户的病毒式地传播而获取回报。产品发布最初的市场推广后收益会逐步递减，而这种情况会被由发布所带来的网络效益大大加强。

这对于产品经理来说这是最可怕的事情。

一个开始，另一面透视镜

还有很多有趣的东西我的介绍并没有涵盖（为了简洁），像竞争力是如何影响曲线，如果你们觉得有趣的话，这我将会保留到另一篇文章中。

如果产品发布时间价值的目标对产品经理来说是一个真实产出量而已，那这仅仅还是一小步。把在真实世界中的平滑的小曲线图表化，往往是没有缘由的，只是建立在一些假设上。

相反地，它却是真正地给产品经理每天要做的复杂、多变的决策添加了另一面透视镜。那是我们称之为直觉的东西。

所以，下次你在计划路线图时，别只是去问用户现在需要什么，想想在你发布产品时他们会需要什么。

如果你觉得这篇文章有价值，请在文章底部为我的文章点和打赏。

---

The Time Value of Shipping

“Shipping as a Feature” gets a framework

BY    Brandon Chu

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

1. Buying the basketball is when you ship to your customers, usually your MVP

2. The price of the basketball is your users’ expectations of the product (at any given point in time)

3. 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.

The Time Value of Shipping

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 product grows the longer it 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:

1. Abandon the project and move to one where you can meet customer expectations at a point in time, or

2. 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’sreallyscary.

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.