Suppose you have a problem to solve. What do you do?
Well, you sit down and think real hard, and after extensive and careful planning you try the well thought out and rigorous solution that you have thought up. Right?
No, wrong! Bad.
The correct thing to do when you have a problem is:
Think for a short amount of time.
Make sure it is safe to try things.
Try something you think will work.
Observe the result. If you succeeded, yay you solved the problem! If it didn't work, think about what that means for the nature of the problem and try again.
Conventional tech industry product practice will not produce deep enough subject matter insights to create transformative tools for thought.
...The aspiration is for any team serious about making transformative tools for thought. It’s to create a culture that combines the best parts of modern product practice with the best parts of the (very different) modern research culture. You need the insight-through-making loop to operate, whereby deep, original insights about the subject feed back to change and improve the system, and changes to the system result in deep, original insights about the subject.
Thinking [in terms of loops and arcs] allows us to let go of a specific journey or sequence, and imagine dozens of scenarios and possible sequences in which these skills can be learned. This doesn’t mean there aren’t more fundamental skills that other skills build upon, but we can let go the tyranny of how, precisely, a person will move through a system. We’re free to zoom in and obsess on these loops, which does two things for us:
Approach the design of a system as the design of these as small but significant moments of learning.
Consider the many ways these loops might be sequenced, with the exact order being less important.
Getting feedback can be thought of as a form of design research. In the same way that we wouldn’t do any research without the right questions to get the insights that we need, the best way to ask for feedback is also to craft sharp questions.
Fascinatingly, one of the other big complaints people had about agile is no iteration. I don't understand how being in an agile environment makes people less iterative, but somehow that seems to be the case. And I think it's because people misunderstand and think that agile is just about putting features out faster, and not about the important part, which is getting something in front of users faster so that you can get feedback on it and make it better.