Proof of work

06 Dec 2024

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

Read more

  1. Home is where the feeling of home residesreflections
  2. Notes on doing most good, doing some good, and living goodphilanthropy
  3. Notes on Londontravel
  4. 18 key ideas from reading Henrik Karlsson this monthwriting
  5. Stop arguing, and start drawing circles togethermathematics
  6. The whole world is just the snake eating its own tailmental-models
  7. Life lessons and hot takes from my 30slifestyle
  8. Building a skill for coherent science illustrationsscience
  9. My agentic engineering workflow (step by step)agentic-coding
  10. Hammock driven developmentagentic-coding
  11. Peculiar ways number three fits into our funny little brainsmental-models
  12. AI sandwich as a defacto principle for anything agentic engineering relatedagentic-coding
  13. Authority in the guise of evidencecritical-rationalism
  14. Map is not the territoryphilosophy
  15. Self hypnosis as a manifestation ritualmeditation
  16. Hegelian dialectic for structured reasoning with AI agentsphilosophy
  17. How I prepare for tough negotiations nowadaysnegotiation
  18. When should we steelthread somethingproduct-development
  19. Breadboarding, shaping, slicing, and steelthreading solutions with AI agentsproduct
  20. Healthy conflict in teams have a tipping pointteam-building
  21. How I deslopify AI writingwriting
  22. How I started building softwares with AI agents being non technicalagentic-coding
  23. Read raw transcriptswriting
  24. Legible and illegible tasks in organisationsproduct
  25. L2 Fat marker sketchesdesign
  26. Writing as moats for humanswriting
  27. Beauty of second degree probesdecision-making
  28. Boundary objects as the new prototypesprototyping
  29. One way door decisionsproduct
  30. Finished softwares should existproduct
  31. How I periodically rank my rough draftsobsidian
  32. Flipping questions on its headinterviewing
  33. Vibe writing maximswriting
  34. How I blog with Obsidian, Cloudflare, AstroJS, Githubwriting
  35. How I build greenfield apps with AI-assisted codingagentic-coding
  36. We have been scammed by the Gaussian distribution clubmathematics
  37. Classify incentive problems into stag hunts, and prisoners dilemmasgame-theory
  38. I was wrong about optimal stoppingmathematics
  39. Thinking like a shipmental-models
  40. Hyperpersonalised N=1 learningeducation
  41. New mediums for humans to complement superintelligenceagentic-coding
  42. Maxims for AI assisted codingagentic-coding
  43. Virtual bookshelvesaesthetics
  44. It's computational and AI everythingagentic-coding
  45. Public gardens, secret routesdigital-garden
  46. Git way of learning to codeagentic-coding
  47. Style Transfer in AI writingagentic-coding
  48. Understanding codebases without using codeagentic-coding
  49. Vibe coding with Cursoragentic-coding
  50. Virtuoso Guide for Personal Memory Systemsmemory
  51. Writing in Future Pastwriting
  52. Publish Originally, Syndicate Elsewhereblogging
  53. Poetic License of Designdesign
  54. Idea in the shower, testing before breakfastsoftware
  55. Technology and regulation have a dance of ice and firetechnology
  56. How I ship "stuff"software
  57. Writing is thinkingwriting
  58. Song of Shapes, Words and Pathscreativity
  59. How do we absorb ideas better?knowledge
  60. Read writers who operatewriting
  61. Brew your ideas lazilyideas
  62. Trees, Branches, Twigs and Leaves — Mental Models for Writingwriting
  63. Compound Interest of Private Noteswriting
  64. Conceptual Compression for LLMsagentic-coding
  65. Meta-analysis for contradictory research findingsdigital-health
  66. Proof of workproduct
  67. Gauging previous work of new joinees to the teamleadership
  68. Task management for product managersproduct
  69. Beauty of Zettelswriting
  70. Stitching React and Rails togetheragentic-coding
  71. Exploring "smart connections" for note takingwriting
  72. Deploying Home Cooked Apps with Railssoftware
  73. Repetitive Copypromptingwriting
  74. Questions to ask every decadejournalling
  75. Balancing work, time and focusproductivity
  76. Hyperlinks are like cashew nutswriting
  77. Brand treatments, Design Systems, Vibesdesign
  78. How to spot human writing on the internetwriting
  79. Can a thought be an algorithm?product
  80. Opportunity Harvestingcareers
  81. Everything is a prioritisation problemproduct
  82. How I do product roastsproduct
  83. The Modern Startup Stacksoftware
  84. In-person vision transmissionproduct
  85. How might we help children invent for social good?social-design
  86. The meeting before the meetingmeetings
  87. Design that's so bad it's actually gooddesign
  88. Lessons learnt interview prepping for product rolesinterviewing
  89. Obsessing over personal websitessoftware
  90. English is the hot new programming languagesoftware
  91. Better way to think about conflictsrisk-management
  92. The role of taste in building productsdesign
  93. Dear enterprises, we're tired of your subscriptionssoftware
  94. Products need not be user centereddesign
  95. World's most ancient public health problemsoftware
  96. Pluginisation of Modern Softwaredesign
  97. Let's make every work 'strategic'consulting
  98. Making Nielsen's heuristics more digestibledesign
  99. Startups are a fertile ground for risk takingentrepreneurship
  100. Insights are not just a salad of factsdesign
  101. Minimum Lovable Productproduct
  102. Methods are lifejackets not straight jacketsmethodology
  103. How to arrive at on-brand colours?design
  104. Minto principle for writing memoswriting
  105. Importance of Whytask-management
  106. Quality Ideas Trump Executionsoftware
  107. Why I prefer indie softwareslifestyle
  108. Use code only if no code failscode
  109. Self Marketing
  110. Personal Observation Techniquesdesign
  111. Design is a confusing worddesign
  112. A Primer to Service Design Blueprintsdesign
  113. Rapid Journey Prototypingdesign
  114. Visualise detailed file structures on CLIcli
  115. Do's and Don'ts of User Researchdesign
  116. Design Manifestodesign
  117. Complex project management for productproducts
  118. How might we enable patients and caregivers to overcome preventable health conditions?digital-health
  119. Pedagogy of the Uncharted — What for, and Where to?education
  120. Future of Equity with Ludovick Petersinterviewing
  121. Future of Ageing with Mehdi Yacoubiinterviewing
  122. Future of Tacit knowledge with Celeste Volpiinterviewing
  123. Future of Mental Health with Kavya Raointerviewing
  124. Future of unschooling with Che Vanniinterviewing
  125. Future of Rural Innovation with Thabiso Blak Mashabainterviewing
  126. Future of work with Laetitia Vitaudinterviewing
  127. How might we prevent acquired infections in hospitals?digital-health
  128. The why to endure any howentrepreneurship
  129. Design education amidst social tribulationsdesign
  130. How might we assist deafblind runners to navigate?social-design