I was very excited by this--to send it to the people I work with to explain to them a lot of my mental model--but was sad that the examples all seemed to be steeped in the world of an already well-established product with a large team. When thinking of "risk-first" the prototypes that come to my mind--due to how I am usually working on the small team that is trailblazing new territory, as well as simply thinking about what comes "first"--is how to ensure that the initial work being done is most directly derisking the entire concept of later execution plans, as we might have no clue of what we are trying to do is even possible: and so like, I spend my time arguing with people about how "sure we could build that UI out but we don't even know if we understand whether that easy UI you want is feasible yet, so let's try to build what we considered to be our killer feature first and then build the UI around it once we know what settings it simply has to have... in the mean time we can use a low-level command line tool" or "in three months I am going to come to you needing to be able to buy something, but I have no clue what that will be yet: I realize you are used to being given concrete goals, but I need you to start setting up payment channels and finding partners who are on board to be flexible with the changes that will be coming in two months without then getting ahead of yourself and starting to commit to things we aren't ready for". The examples I was seeing here were thereby "great" in the sense that they were "correct", but I could see showing this to someone and them getting the misimpression that the risks described and assumed--relating to integration with existing code and misunderstandings surrounding existing features leading to duplication and waste of work on a large team--will cause everyone I want to show this to to think those are key risks even for an early project... where in fact the biggest risk might be "we spend $5 million building a fancy product without ever once realizing it doesn't work so hard it couldn't even be done, because we front-loaded low-hanging fruit instead of having the engineers mitigate long-term risk from day one". If would be really interesting to have another version of this written from the perspective of a different place in a product lifecycle, starting at the very first things one does on a new project (which might include analyzing doing the risks of business deals at all ;P).