I wholeheartedly agree. I was very surprised to see the Technology first perspective. This is a path to band-aids and incongrueties. When I read the worked exa

I wholeheartedly agree. I was very surprised to see the Technology first perspective. This is a path to band-aids and incongrueties. When I read the worked example, I see something quite a bit different. The worked example seems to suggest integrating basic threat modeling practices into product/feature development user stories/use cases. This is a bit better, and I'd suggest a bit more aligned to your "value in educating product owners" comment. For me, it's quite straightforward ... what is the revenue generating aspect of your product/service? Let's assume mal intent, ignorance, user error, etc. are all likely, but not equally so, and come up with ways the service can be broken. Top down look at the options to protect against those - which are often a combination of people/process/technology, and then weigh up the additional complexity that introducing them adds. You basically end up with a threat/risk register, with mitigations, etc.