Proof of work

Shreyas Prakash headshot

Shreyas Prakash

Showing proof-of-work as a designer is quite simple. 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, 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. These are some proof of work proxies that I’ve explored recently:

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.

Farnam Street https://fs.blog/how-to-improve-the-quality-of-our-decision-making/

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:

  • What’s the primary thesis
  • What is the expected outcome(s)
  • What are the second and third-order consequence
  • What is the worst-case scenario and why that’s ok
  • What is the potential upside beyond the core thesis
  • What emotions am I experiencing
  • What is the opportunity cost (by doing this what am I not doing)
  • What unique advantages or insights do I have in this situation
  • Who is the best person to make this decision
  • What does this look like in 5 weeks, 5 months, 5 years?

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.

Farnam Street https://fs.blog/how-to-improve-the-quality-of-our-decision-making/

Subscribe to get future posts via email (or grab the RSS feed). 2-3 ideas every month across design and tech

2026

  1. How I started building softwares with AI agents being non technical

2025

  1. Legible and illegible tasks in organisations
  2. L2 Fat marker sketches
  3. Writing as moats for humans
  4. Beauty of second degree probes
  5. Read raw transcripts
  6. Boundary objects as the new prototypes
  7. One way door decisions
  8. Finished softwares should exist
  9. Essay Quality Ranker
  10. Export LLM conversations as snippets
  11. Flipping questions on its head
  12. Vibe writing maxims
  13. How I blog with Obsidian, Cloudflare, AstroJS, Github
  14. How I build greenfield apps with AI-assisted coding
  15. We have been scammed by the Gaussian distribution club
  16. Classify incentive problems into stag hunts, and prisoners dilemmas
  17. I was wrong about optimal stopping
  18. Thinking like a ship
  19. Hyperpersonalised N=1 learning
  20. New mediums for humans to complement superintelligence
  21. Maxims for AI assisted coding
  22. Personal Website Starter Kit
  23. Virtual bookshelves
  24. It's computational everything
  25. Public gardens, secret routes
  26. Git way of learning to code
  27. Kaomoji generator
  28. Style Transfer in AI writing
  29. Copy, Paste and Cite
  30. Understanding codebases without using code
  31. Vibe coding with Cursor
  32. Virtuoso Guide for Personal Memory Systems
  33. Writing in Future Past
  34. Publish Originally, Syndicate Elsewhere
  35. Poetic License of Design
  36. Idea in the shower, testing before breakfast
  37. Technology and regulation have a dance of ice and fire
  38. How I ship "stuff"
  39. Weekly TODO List on CLI
  40. Writing is thinking
  41. Song of Shapes, Words and Paths
  42. How do we absorb ideas better?

2024

  1. Read writers who operate
  2. Brew your ideas lazily
  3. Vibes
  4. Trees, Branches, Twigs and Leaves — Mental Models for Writing
  5. Compound Interest of Private Notes
  6. Conceptual Compression for LLMs
  7. Meta-analysis for contradictory research findings
  8. Beauty of Zettels
  9. Proof of work
  10. Gauging previous work of new joinees to the team
  11. Task management for product managers
  12. Stitching React and Rails together
  13. Exploring "smart connections" for note taking
  14. Deploying Home Cooked Apps with Rails
  15. Self Marketing
  16. Repetitive Copyprompting
  17. Questions to ask every decade
  18. Balancing work, time and focus
  19. Hyperlinks are like cashew nuts
  20. Brand treatments, Design Systems, Vibes
  21. How to spot human writing on the internet?
  22. Can a thought be an algorithm?
  23. Opportunity Harvesting
  24. How does AI affect UI?
  25. Everything is a prioritisation problem
  26. Now
  27. How I do product roasts
  28. The Modern Startup Stack
  29. In-person vision transmission
  30. How might we help children invent for social good?
  31. The meeting before the meeting
  32. Design that's so bad it's actually good
  33. Breaking the fourth wall of an interview
  34. Obsessing over personal websites
  35. Convert v0.dev React to Rails ViewComponents
  36. English is the hot new programming language
  37. Better way to think about conflicts
  38. The role of taste in building products
  39. World's most ancient public health problem
  40. Dear enterprises, we're tired of your subscriptions
  41. Products need not be user centered
  42. Pluginisation of Modern Software
  43. Let's make every work 'strategic'
  44. Making Nielsen's heuristics more digestible
  45. Startups are a fertile ground for risk taking
  46. Insights are not just a salad of facts
  47. Minimum Lovable Product

2023

  1. Methods are lifejackets not straight jackets
  2. How to arrive at on-brand colours?
  3. Minto principle for writing memos
  4. Importance of Why
  5. Quality Ideas Trump Execution
  6. How to hire a personal doctor
  7. Why I prefer indie softwares
  8. Use code only if no code fails
  9. Personal Observation Techniques
  10. Design is a confusing word
  11. A Primer to Service Design Blueprints
  12. Rapid Journey Prototyping
  13. Directory Structure Visualizer
  14. AI git commits
  15. Do's and Don'ts of User Research
  16. Design Manifesto
  17. Complex project management for product

2022

  1. How might we enable patients and caregivers to overcome preventable health conditions?
  2. Pedagogy of the Uncharted — What for, and Where to?

2020

  1. Future of Ageing with Mehdi Yacoubi
  2. Future of Equity with Ludovick Peters
  3. Future of Tacit knowledge with Celeste Volpi
  4. Future of Mental Health with Kavya Rao
  5. Future of Rural Innovation with Thabiso Blak Mashaba
  6. Future of unschooling with Che Vanni
  7. Future of work with Laetitia Vitaud
  8. How might we prevent acquired infections in hospitals?

2019

  1. The soul searching years
  2. Design education amidst social tribulations
  3. How might we assist deafblind runners to navigate?