How does this approach differ or complement the design processes you’ve used before?
I had mostly worked in Research Divisions before coming to Stanford, so I was always handed over the “requirements.” (We need x% accuracy), and whenever I wanted to see some usage statistics of how our users were using my software, it was something not available to the research division. So I always left disconnected from the users and how they were using my software. Whenever I used to ask higher management to share user stories with me, they were like why do they matter to you? I think using the examples from this book might have been a nice answer to those queries (Because I want to make minimal output and maximum Outcome).
I really liked the Idea of Minimum output and maximum outcome, it goes against what I had learned earlier as a software developer, but it makes so much sense. We need to survey our customers and see their demands and prioritize what they need. I think this style of thinking is what leads a team towards MVP.
Another idea that I really liked from the blog was the idea that written documents are like holiday pictures without the background story, and you really need to get together with your team and discuss. It was really powerful to me as I have been reading code documentation all my life and wondering why this function was prototyped like this. Thinking back, I can clearly see which functions were written with user stories in mind and which were not. Some of them just have whole loads of parameters, and some are just so easy to use.
I’m not sure if I would be able to express my feeling with this blog post as, again, this is a written form of communication, and I’m not sure if they are effective anymore.
