The approach mentioned in the reading significantly differed from the design processes I’ve used before, especially during my internships. During my internship as a software engineer, I was told to hit many milestones throughout the summer, and thus I focused on producing as much output as I could. In fact, we were encouraged to produce more output: we would ship versions of code, and if there was a bug or an update, we would just ship out new versions. I never thought about the difference between output and outcome. However, I do agree with what the reading is saying: in the grand scheme of things, the whole point of output is to produce outcome.
This approach also differed from the documentation processes I’ve done before as a PM. As a PM, you’re taught to track metrics, both quantitative and qualitative. I focused a lot on the quantitative–they’re easier to track, such as number of page views, etc. Qualitative is fuzzier and harder to track, but this reading emphasizes that qualitative aspects are important as well. After all, it’s the most direct way to track customer satisfaction and outcome. I’ve also learned to write very detailed documentation (and have done that at prior internships before), but this reading pushes back and argues that it’s not what’s written down that is the most important–it’s what people remember. Reading this encourages me to stress less on having the 100% perfect documentation, and focus more on how I’m telling the story.
