Skip to content

On Proof of Work

6 min

The way to test the quality of your decisions is to test the process by which you make them. Daniel Kahnemann, Nobel Prize winner and dean of biases, argues that using a decision journal is the best solution.

A recent challenge which I’ve been facing through my current transition as a Product Manager is the difficulty in communicating the clear value you bring to the table. Previously, as a designer, it was much more convenient as the artefacts were much more tangible.

You made an app, you communicated the output product and exhibit how the product evolved over time ranging from the paper napkin sketch, low fidelity, high fidelity prototypes and finally a fully fledged product. The iterations need not just be tangible, but can be verbal too.

Similarly, for an engineer the proof of work is also quite solid. You can mention how you helped improve the efficiency of X from 70% to 80%.

However, things get a bit murky especially in people-driven, decision making roles such as that of a product manager or other leadership roles such as CEO, early stage founder etc. The proof of work in these roles are the decisions you make taking into account all the stakeholders, designers, engineers and the end users into account.

How do you communicate the complexity and subtleties of the decisions? I sometimes do feel that these nuances cannot be bluntly put up as a bullet point on your resume, and sometimes, we do need more effective methods to communicate these subtleties. Although a resume does have some significance especially when we are quite short on time and have to come up with something which can communicate your caliber.

I've observed some of these methods in communicating the proof of work as a product person.

Decision making journal

Farnam Street puts up a brilliant journal to outline the various decisions which were made by the product manager. In this case, you scope in the time, complexity, factors involved and even consider the various limitations of the decision taken into account. As and when a key decision is made, the product manager logs this information into this journal. They also put in an element of reflection–can we look back at the decision made and see what the shortcomings were?

One advantage of such a process is to put an emphasis on decision making and accommodate periodic reflection: probably the best way to get better at it is to keep reviewing the decisions of our past.

The way to test the quality of your decisions is to test the process by which you make them. Daniel Kahnemann, Nobel Prize winner and dean of biases, argues that using a decision journal is the best solution. Kahneman said:

Many years ago when I first met Danny Kahneman, and Kahneman is one of the preeminent psychologists in the world who won a Nobel Prize for economics in 2002, even though he’s never taught an economics class.
When I pose him the question, what is a single thing an investor can do to improve his or her performance, he said almost without hesitation, go down to a local drugstore and buy a very cheap notebook and start keeping track of your decisions. And the specific idea is whenever you’re making a consequential decision, something going in or out of the portfolio, just take a moment to think, write down what you expect to happen, why you expect it to happen and then actually, and this is optional, but probably a great idea, is write down how you feel about the situation, both physically and even emotionally. Just, how do you feel? I feel tired. I feel good, or this stock is really draining me. Whatever you think.

The key to doing this is that it prevents something called hindsight bias, which is no matter what happens in the world. We tend to look back on our decision-making process, and we tilt it in a way that looks more favorable to us, right? So we have a bias to explain what has happened.

When you’ve got a decision-making journal, it gives you accurate and honest feedback of what you were thinking at that time. And so there can be situations, by the way, you buy a stock and it goes up, but it goes up for reasons very different than what you thought was going to happen. And having that feedback in a way to almost check yourself periodically is extremely valuable. So that’s, I think, a very inexpensive; it’s actually not super time consuming, but a very, very valuable way of giving yourself essential feedback because our minds won’t do it normally.

An example of a template followed by Shane parris of Farnam Street to make a real decision is given here

Whenever you’re making a consequential decision, either individually or as part of a group, you take a moment and write down:

  1. The situation or context
  2. The problem statement or frame
  3. The variables that govern the situation
  4. The complications or complexity as you see it
  5. Alternatives that were seriously considered and why they were not chosen
  6. A paragraph explaining the range of outcomes
  7. A paragraph explaining what you expect to happen and the reasoning and actual probabilities you assign to each projected outcome (The degree of confidence matters, a lot.)
  8. The time of day you’re making the decision and how you feel physically and mentally (If you’re tired, for example, write it down.)

Others also include:

I've written these questions in the form of code as they are highly modular blocks used for various situations (almost as if you are executing a piece of code for a particular kind of situation).

I use this occasionally on Roam Research whenever I have to make a critical decision. I also timestamp this for review after 6 months to look back at the decision made. Reflecting on the decisions made in the past help make future decisions much more effective.

Product teardowns

Another way to highlight your proof-of-work as a product manager is to showcase your product teardowns of existing products being launched. This is a nice way to give an example of our observation and articulation skills when it comes to a product role.

Iteration logs

While launching a product from zero to one, there might be a lot of variation of the product and the solution. In this junction, it might be particularly useful to understand what were the changes, why were the changes, what was the context under which the change was made. This can get extremely fuzzy for high growth Startups which leads to various number of iteration cycles.

What could be particularly useful here is to understand the feature updates for each iteration and why those key iterations were made in the first place. It would be definitely interesting to see how these change logs can be depicted in a communicable fashion. I’m still hunting for some great examples, and I would personally strive to implement this framework in my own workflow.

Standard Operating Procedures

Another way to gauge the quality of product management is to understand how much of the work has been "processized"

Mauboussin: So the best work on this I’ve seen is by Atul Gawande, who is a surgeon in Boston who wrote a book a couple of years ago called The Checklist Manifesto, and one of the points he makes in there is that when you go from field to field, wherever checklists have been used correctly and with fidelity, they’ve been extremely effective in proving outcomes. So we all know none of us would step on an airplane today without the pilot having gone through the checklist. It’s been a big move into medicine, especially for example, in surgery where checklists have really made substantial inroads in reducing infections, for example, and hence mortality, and other areas like construction elsewhere.

So the question is, how do you become more systematic in applying what you know? And I’ll just mention one other thing on this. There are two; Gawande talks about two kinds of checklists. By the way, this branch is right out of aviation. One is called a do-confirm checklist, a do-confirm, and that just basically says, Hey, just do your normal analysis the way you’ve always done it and been trained to do that, but stop periodically just to confirm that you’ve covered all the bases. So as an analyst that might say, hey, I’m going to do a really thorough evaluation work. I might look very carefully at return on capital trends. I might study the competitive strategy position. You are just going to do all that stuff, but you’re going to stop every now and then, just to check to make sure you’ve done everything.

The second one is called, the second kind of checklist, is called a read-do checklist. This is when you get into a difficult situation, for example you’re a pilot and one of your engines goes out, the redo will guide how you should approach that problem. So you don’t have to think about it so much, you just sort of go through it systematically. And so for an investor that might be hey, what happens when a company misses a quarter? What happens when they have a negative announcement or an executive departure? Sometimes that means sell the stock. Sometimes that means buy more. Sometimes it means do nothing, and a read-do checklist can help guide some of that thinking as well. So it’s really a way to be structured and consistent in your analysis.


Subscribe to receive the latest posts in your inbox.