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

Read more

  1. Breadboarding, shaping, slicing, and steelthreading solutions with AI agentsproduct-management
  2. How I started building softwares with AI agents being non technicalagentic-engineering
  3. Legible and illegible tasks in organisationsproduct
  4. L2 Fat marker sketchesdesign
  5. Writing as moats for humanswriting
  6. Beauty of second degree probesdecision-making
  7. Read raw transcriptsknowledge
  8. Boundary objects as the new prototypesprototyping
  9. One way door decisionsproduct
  10. Finished softwares should existproduct
  11. Essay Quality Rankerobsidian
  12. Export LLM conversations as snippetsbrowser-extension
  13. Flipping questions on its headinterviewing
  14. Vibe writing maximswriting
  15. How I blog with Obsidian, Cloudflare, AstroJS, Githubwriting
  16. How I build greenfield apps with AI-assisted codingai-coding
  17. We have been scammed by the Gaussian distribution clubmathematics
  18. Classify incentive problems into stag hunts, and prisoners dilemmasgame-theory
  19. I was wrong about optimal stoppingmathematics
  20. Thinking like a ship
  21. Hyperpersonalised N=1 learningeducation
  22. New mediums for humans to complement superintelligenceai-coding
  23. Maxims for AI assisted codingai-coding
  24. Personal Website Starter Kitai-coding
  25. Virtual bookshelvesaesthetics
  26. It's computational and AI everythingai-coding
  27. Public gardens, secret routesdigital-garden
  28. Git way of learning to codeai-coding
  29. Kaomoji generatorsoftware
  30. Copy, Paste and Citecuriosities
  31. Style Transfer in AI writingai-coding
  32. Understanding codebases without using codeai-coding
  33. Vibe coding with Cursorai-coding
  34. Virtuoso Guide for Personal Memory Systemsmemory
  35. Writing in Future Pastwriting
  36. Publish Originally, Syndicate Elsewhereblogging
  37. Poetic License of Designdesign
  38. Idea in the shower, testing before breakfastsoftware
  39. Technology and regulation have a dance of ice and firetechnology
  40. How I ship "stuff"software
  41. Weekly TODO List on CLIcli
  42. Writing is thinkingwriting
  43. Song of Shapes, Words and Pathscreativity
  44. How do we absorb ideas better?knowledge
  45. Read writers who operatewriting
  46. Brew your ideas lazilyideas
  47. Vibescreativity
  48. Trees, Branches, Twigs and Leaves — Mental Models for Writingwriting
  49. Compound Interest of Private Notesknowledge
  50. Conceptual Compression for LLMsai-coding
  51. Meta-analysis for contradictory research findingsdigital-health
  52. Beauty of Zettelswriting
  53. Proof of workproduct
  54. Gauging previous work of new joinees to the teamleadership
  55. Task management for product managersproduct
  56. Stitching React and Rails togetherai-coding
  57. Exploring "smart connections" for note takingknowledge
  58. Deploying Home Cooked Apps with Railssoftware
  59. Self Marketing
  60. Repetitive Copypromptingwriting
  61. Questions to ask every decadejournalling
  62. Balancing work, time and focusproductivity
  63. Hyperlinks are like cashew nutswriting
  64. Brand treatments, Design Systems, Vibesdesign
  65. How to spot human writing on the internet?writing
  66. Can a thought be an algorithm?product
  67. Opportunity Harvestingcareers
  68. How does AI affect UI?design
  69. Everything is a prioritisation problemproduct-management
  70. Nowlifestyle
  71. How I do product roastsproduct
  72. The Modern Startup Stacksoftware
  73. In-person vision transmissionproduct
  74. How might we help children invent for social good?social-design
  75. The meeting before the meetingmeetings
  76. Design that's so bad it's actually gooddesign
  77. Breaking the fourth wall of an interviewinterviewing
  78. Obsessing over personal websitessoftware
  79. Convert v0.dev React to Rails ViewComponentsrails
  80. English is the hot new programming languagesoftware
  81. Better way to think about conflictsconflict-management
  82. The role of taste in building productsdesign
  83. World's most ancient public health problemsoftware
  84. Dear enterprises, we're tired of your subscriptionssoftware
  85. Products need not be user centereddesign
  86. Pluginisation of Modern Softwaredesign
  87. Let's make every work 'strategic'consulting
  88. Making Nielsen's heuristics more digestibledesign
  89. Startups are a fertile ground for risk takingentrepreneurship
  90. Insights are not just a salad of factsdesign
  91. Minimum Lovable Productproduct
  92. Methods are lifejackets not straight jacketsmethodology
  93. How to arrive at on-brand colours?design
  94. Minto principle for writing memoswriting
  95. Importance of Whytask-management
  96. Quality Ideas Trump Executionsoftware
  97. How to hire a personal doctor
  98. Why I prefer indie softwareslifestyle
  99. Use code only if no code failscode
  100. Personal Observation Techniquesdesign
  101. Design is a confusing worddesign
  102. A Primer to Service Design Blueprintsdesign
  103. Rapid Journey Prototypingdesign
  104. Directory Structure Visualizercli
  105. AI git commitscli
  106. Do's and Don'ts of User Researchdesign
  107. Design Manifestodesign
  108. Complex project management for productproducts
  109. How might we enable patients and caregivers to overcome preventable health conditions?digital-health
  110. Pedagogy of the Uncharted — What for, and Where to?education
  111. Future of Ageing with Mehdi Yacoubiinterviewing
  112. Future of Equity with Ludovick Petersinterviewing
  113. Future of Mental Health with Kavya Raointerviewing
  114. Future of Tacit knowledge with Celeste Volpiinterviewing
  115. Future of Rural Innovation with Thabiso Blak Mashabainterviewing
  116. Future of unschooling with Che Vanniinterviewing
  117. Future of work with Laetitia Vitaudinterviewing
  118. How might we prevent acquired infections in hospitals?digital-health
  119. The soul searching yearsentrepreneurship
  120. Design education amidst social tribulationsdesign
  121. How might we assist deafblind runners to navigate?social-design