The Regenerate Web
facilitating the regeneration of software teamsNavigation
User login
Syndicate
Services
Project
Browse archives
| Su | Mo | Tu | We | Th | Fr | Sa |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 |
Analysis
Staff
Who's online
There are currently 0 users and 2 guests online.
Software Product Management
Submitted by regen_r8 on Thu, 2007-03-15 04:33.
leader
Skip Angel (of Random Thoughts of a CTO) has a new blog
called Leaning Towards Agility. His recent post
about making things more difficult was quite amusing.
At the end, he asked a question about products.
A few years ago I was a de facto product manager, running an application team and dealing with product decisions, I learned very quickly that about 40% of our application support calls were actually usability issues. Software usability as an issue is defined as any misalignment between the users expectation for how the software should work, and how it actually works. You may think this is a strange definition for usability, but in reality, if a large percentage of your user base expects software to work a certain way, you are better off building it that way, than you are trying to change the mind of most of your users.
I also used to perform training for this software product. (Wait, this is really relevant) I worked with our HR based training folks to get a basic structure for the training protocol (because I had never built a training protocol before). We disagreed about how to start the training. I felt that it was important to start with an overview of some of the basic assumptions that the software makes (product worldview), that sets expectations and explains the work paradigm that the software implements. I built the training protocol this way, especially because I was rolling out to a new group of corporate users for whom I was replacing an existing vended product, that had a very different worldview or paradigm than my product. I felt that I needed to get out there early to counteract their expectations. While I felt that it was really important to set the users up with an understanding of the paradigm before we entered the "how-to" section. Since I didn't do the training any other way, I don't have a direct comparison to say that what I did was better, but the training was successful, and I got mostly positive feedback from users many of them recognizing that I explained how the software "thinks" and that was helpful to them.
Some of the feedback I received was different though. I was told with some regularity that the software did not work the way some users think. When we look at the logs for support calls, we can see trends that identify these gaps in alignment. I am not advocating that we rearchitect the software to align with users worldview. In a corporate environment that supports work process diversity, one could argue that there will always be some issues with alignment. Just know that we can recognize these patterns from our conversations with users.
Sometimes we can use training or education to align expectations, sometimes we should embrace the users expectations. One job of software product managers is to understand when to do one or the other.
At the end, he asked a question about products.
I
wonder if this happens the same way with products. We
quickly expect
that the products don't work and try to make them do something
different as a result. We don't realize that perhaps we just don't
understand how the product was designed. Once we do understand that, we
may realize that the product is actually working as it should!
A few years ago I was a de facto product manager, running an application team and dealing with product decisions, I learned very quickly that about 40% of our application support calls were actually usability issues. Software usability as an issue is defined as any misalignment between the users expectation for how the software should work, and how it actually works. You may think this is a strange definition for usability, but in reality, if a large percentage of your user base expects software to work a certain way, you are better off building it that way, than you are trying to change the mind of most of your users.
I also used to perform training for this software product. (Wait, this is really relevant) I worked with our HR based training folks to get a basic structure for the training protocol (because I had never built a training protocol before). We disagreed about how to start the training. I felt that it was important to start with an overview of some of the basic assumptions that the software makes (product worldview), that sets expectations and explains the work paradigm that the software implements. I built the training protocol this way, especially because I was rolling out to a new group of corporate users for whom I was replacing an existing vended product, that had a very different worldview or paradigm than my product. I felt that I needed to get out there early to counteract their expectations. While I felt that it was really important to set the users up with an understanding of the paradigm before we entered the "how-to" section. Since I didn't do the training any other way, I don't have a direct comparison to say that what I did was better, but the training was successful, and I got mostly positive feedback from users many of them recognizing that I explained how the software "thinks" and that was helpful to them.
Some of the feedback I received was different though. I was told with some regularity that the software did not work the way some users think. When we look at the logs for support calls, we can see trends that identify these gaps in alignment. I am not advocating that we rearchitect the software to align with users worldview. In a corporate environment that supports work process diversity, one could argue that there will always be some issues with alignment. Just know that we can recognize these patterns from our conversations with users.
Sometimes we can use training or education to align expectations, sometimes we should embrace the users expectations. One job of software product managers is to understand when to do one or the other.