For OneNote, I wanted to do things differently. It seems obvious, but I wondered why we couldn't ship "version 3" the first time around. Why ship the product before getting substantial feedback on whether it was the right set of features - in fact even a worthwhile product or not? The standard answer is that to do so would be following the “wait until its perfect” approach: you couldn't get substantial feedback until version 1 was more or less design complete. If the user feedback showed massive changes were needed, you'd essentially be skipping version 1 and going on to version 2, taking way too long to get something out for the real world usage that you really need. I agreed, but I felt that the problem that forced the skip to version 2 was that the standard Office way of developing software did not bring in user feedback soon enough. In fact usually broad user feedback is accepted only late in the process, to determine if the software is stable and works well in the huge variety of real-world configurations. The design has been locked down early on. Of course usability tests are done on the designs and they are adjusted to make them work in the lab, but getting deep feedback from real people in real situations is hard for Office - even sending out a beta to hundreds of thousands of people only generates feedback from a few thousand. There are reasons for that - a lot of it is just that people assume we know what we are doing and don't question the design of features even when they don’t work for them. I could go on about the difficulty of getting beta feedback another time. But for OneNote, we decided to try to do things differently, which I'll talk about in my next post.