How to Upgrade Your Decision-Making Using Paper Models

How to Upgrade Your Decision-Making Using Paper Models


?? Reading time: about 10 min Enjoy this free post.

?? Subscribe for Destructured on Substack to get the full experience.


In a recent chat on Slack, I read the following message:

“I would do a ton of financial and quantitative modeling. I've found it especially good at dealing with high degrees of uncertainty and where gathering more data likely wouldn't be possible. I call it building a paper model.”*

As soon as I read it, I knew I had to reach for the poster and learn more.

The man behind the message was Joshua Herzig-Marx , a seasoned product leader at numerous companies with a startup exit to Google under his belt.

I asked Josh to expand on the paper model idea, and he graciously did so in multiple ways. After explaining how the paper model worked, he formalized his approach in a post.

Today, I wanted to share Joshua’s paper model with you and add on his thinking with a couple of real-life examples.

The Paper Model

Before you move on, I encourage you to read Joshua’s original post:

The Power of “Paper Models” in Decision-Making

Here are the key points:

  • Often, we don’t have all the data to make an important decision.

  • In these cases, we need a framework to help us identify what must be true for what we are after to be worthwhile.

  • The paper model is one such framework. It helps us identify and quantify the key assumptions that must be true for our project to be successful.?

The process involves four steps:

  1. Identify the critical assumptions: what are the drivers that will have the most significant impact on the outcome of your decision? Example: You run a personal finance app aiming to hit a revenue target. The drivers are simply price x quantity of subscriptions.
  2. Quantify your assumptions: assign values to your drivers. You can start with values you must achieve to achieve the desired outcome. These values can be unreasonable, and that’s okay. Example: To achieve $1M revenue from our app by selling subscriptions, we have to assign a value for the price ($96 for an annual subscription) and a value for the number of subscriptions (10,417).
  3. Benchmark your assumptions: How likely are we to achieve the drivers’ values with the resources and time we have? We can do this by 1) examining our capabilities internally and 2) examining market constraints and competition externally. Example: Can we sell 10,417 subscriptions? We may want to discuss this with our marketing team and assess our competition. Does anyone similar to our business sell that many subscriptions in a year? We also need to look at the price. Is $96 for a personal finance app within the price range on the market?
  4. Test sensitivities: some drivers will have an outsized impact on the outcome. A minor uplift in price, for example, usually has an outsized impact on revenue. We can test sensitivities by changing the input values for our drivers and observing how the outcome changes. Example: Through our sensitivity analysis we may find out that price has a major uplift. So, one strategy to achieve our revenue target is to offer a premium product at a premium price. Such changes, however, have trade-offs (see How to Spot Non-Obvious Trade-Offs). In the case of our app, we may consider adding an AI feature. This, however, means that we’ll need to use an LM API, which will increase the cost of the product. We don’t have to figure out all the details at this stage, but we have to flag any known ripple effects.

Let’s give the paper model a test flight:

Personal Finance App

In his original post, Joshua illustrates the paper model with an example of a personal finance app. I’ve expanded on it so we can play around with some concrete numbers and model it in Excel.

The Key Details & Assumptions

We manage a personal finance app targeting young professionals who want to manage their finances. Even though the user base has been growing consistently, over the last two quarters, we’ve seen a decline in the growth rate. In the most recent board meeting, the board members agreed that they would like to see a $3 growth in annual revenue per user (ARPU). This growth would help the company achieve its target valuation for the next twelve months.

One board member suggested that one way to achieve this revenue growth is by building an affiliate marketplace. Our job is to assess how likely a marketplace is to help us reach the revenue goal.

Keep in mind: we are not after accuracy at this stage. We are looking for a directional signal.

Brainstorming a high-level business model

Let’s assume the marketplace will follow a simple business model:

  • Third-party developers and creators can build templates and extensions that are compatible with our platform. From now on, we’ll collectively call them “products”.

  • End users can purchase these products and use them within our app.

  • The marketplace will generate revenue by taking a percentage of each sale.

  • The more sales through the marketplace, the more revenue the app will drive.

1?? Identify the critical assumptions

We can divide the critical assumptions into several categories:

  • Assumptions about the product and the marketplace:

  • Assumptions about the customer:

2?? Quantify the assumptions

Remember that the goal of this exercise is to find out whether a marketplace is the general direction in which we should aim to get a $3 increase in ARPU. We are not aiming for the bullseye. In fact, spending too much time on accuracy at this stage will be a waste of time, as all of this effort may add up to nothing.

We’ll already have internal data for some of the assumptions, and we'll have to do lightweight research for others.

I set up the following basic model in Excel to capture the assumptions below. The blue cells (and the one red cell) contain my input values. I can also change these cells to target a specific output.

Before we build the logic to calculate the outputs, let's review the reasoning behind the assumption values.

  • Active User Base: We are likely tracking this metric internally, so it should be easily available.

  • Average Price: I approach this assumption in two steps:

  • Take Rate: Researching what similar platforms charge, I saw numbers gravitating around 10-20%. I decided to go with a number in the middle (15%).

  • Users Exploring Affiliate Offers: we’d have no data on this, and it’s unlikely to uncover any meaningful information available for free. I went with 30%, assuming that we can probably get that number this high by actively promoting the marketplace within the app.

  • Users Making Purchases: The number you see in the screenshot is too high and too accurate for this exercise. I use it as a plug to arrive at my Estimated ARPU. Put simply, if we hold everything else constant, we’ll need over 2x the users exploring the marketplace to be actively purchasing. More on how that works is below.

  • Average Number of Purchases/Year: Since we make money per purchase, I’ve assumed four purchases per year or one per quarter. I don’t have any data to support this assumption, so I went with what seemed reasonable.

The Logic

To calculate the revenue, we need to multiply the following values:

  • Active User Base

  • Revenue/Purchase (calculated as Average Price x Take Rate)

  • Users Exploring Affiliate Offers

  • Users Making Purchases

  • Average # of Purchases/Year

We take the result of the above and divide it by the Active User Base.

3?? Benchmark your assumptions

We have already done that part by researching input values.

4?? Test sensitivities

In doing such exercises, we want to run several scenarios. We have two goals in doing this:

  1. Assess how sensitive the output is to each assumption. The higher the sensitivity, the more important it is to get that assumption right. Typically, when it comes to revenue calculations, price is usually the biggest lever.
  2. Get a sense of what the numbers will look like under the best, worst, and most realistic scenarios.

When I’ve done such analyses, product leaders have usually come back to me with requests like:

  • What if we increase the price by a dollar?

  • What if the take rate is 20%?

  • How did you calculate the Active User Base? What if we increase growth by 1%?

To turn around such requests quickly, I automate my calculations and set up new scenarios as columns to the right:


Regardless of the scenario variations, I always try to include at least one that hits our target. The best-case scenario above is the one here. It tells us that to hit our ARPU of $3, we need to get 208% of the Users Exploring Affiliate Offers to purchase at least 4 products a year for at least $8.

This 208% is extremely unlikely to happen. I can change some of the other input values; however, their ranges of realistic value are limited.

If I tweak the numbers in the Best Case scenario, I can come up with something more realistic:

I increased the other inputs and decreased the Users Making Purchases to 55%. Overall, however, the numbers look too high to be realistic.

Now that we have this model in place, we can start having meaningful discussions with other teams (e.g. Sales, Marketing, etc.) grounded in some concrete assumptions.


Paper models are remarkably powerful tools. With them, we gain the ability to frame complex problems, understand how various elements intertwine, and identify our key drivers of success. They don't replace in-depth research or the need for data-driven decisions. However, they are the right tools to use early on when solving a problem or looking for a general direction. If you find yourself tackling big, ambiguous decisions, consider applying this framework – it may be the key to cutting through the fog and charting a clearer path.?


?? Subscribe for Destructured on Substack to get the full experience.

Joshua Herzig-Marx

Startup founder, acquired by Google, coaching founders and solo PMs. I build products and organizations.

7 个月

I think you explained it better than I ever could!

要查看或添加评论,请登录

社区洞察

其他会员也浏览了