Points of Interest

Joel Spolsky did me a favour and wrote an excellent article on “program managers”.

It might have happened that you misdesigend a feature in one of your products. Matching the user’s expectations has several advantages. Besides your very own personal pleasure, it helps to reduce support costs, get a better user reputation and, last but not least, make the work of your sales people easier. Joel writes:

The first thing I had to do was figure out what customers needed, which I did by talking to as many customers as I could until I started to get kind of bored because I kept hearing the same thing.

Sounds time consuming, and it actually is. You need to listen and to understand what users want to do, then you need to filter out the edge cases and put the rest together in a manner that it fits the requirements of most of your users as well as the existing software model and the sales department. Additionally you need to listen to your coders and to decide what you really can achieve in the given timeframe. This probably means that you have to drop planned features, as painful it is (well, not absulutely, which led us to the discussion about features, quality assurance, marketing and related questions).

As soon as you think you got the “big picture”, you need to document them as “functional spec“. Some people think that it is just a waste of time to write specs. It isn’t. Specs are not there to be set in stone. Specs are there to be changed, and it is way easier to change specs than code. It’s your job to write specs as a guideline for the people who actually write the code, just to make them more efficient. But of course you also need to resist the temptation to overspecify the details.

Obviously it is useful to know how software development is done.

I am pretty good in sitting down and to work hard until I solved a problem. I wanted to have an easy to use tool to make backups of the memory contents of my synthesizers. So I sat down, learned some C++ and created SimpleSysexxer. I wanted to have a GUI for exchanging data with my GPSr gadgets. So I sat down and wrote Gebabbel, a graphical frontend for gpsbabel. I wanted to use POIs from openstreetmap data, so I sat down and wrote osmpoicreator. I wanted to use them in Maemo Mapper, so I learned some Ruby and SQL and wrote code to do it.

But I’m not a real coder. I neither studied the basics of computer science, nor am I efficient in writing code (not to mention its readability) . If I was a coder, I would either not do the job I’m currently doing, or probably fail miserably. So do not misinterpret what Joel writes:

A program manager doesn’t care how the development team implements things internally.

He writes that a program manager does not care how things are implemented. This does not mean that the program manager must not understand how things are implemented. For my job it is essential to have at least a little clue. It helps me when discussing planned features with the guys who actually do the hard coding work. If they object, you need to understand what they are talking about. If I knew anything about hacking, it would be much harder for me to get the respect necessary to get my job done, and it was much harder to get a clue what was realistic to achieve.

Joel continues:

Truth be told, I didn’t know anything about anything. Fresh out of college, I didn’t have enough experience to develop the code, test the code, write the documentation, market the product, or do the usability tests.

Usability tests are an interesting point. You might not have the time to actually do them, maybe due to the narrow release cycles of your product. You may believe you did a good job and trust that the product serves your audience well. I learned from experience that you can be damn wrong. Having some testers who work with your code and provide feedback is important.

Joel also writes:

Typically, the program manager wants something simple and easy to understand for the users, featuring a telepathic user interface and a 30″ screen that nonetheless fits in your pocket, while the developer wants something that is trivial to implement in code, with a command-line interface (“what’s so unusable about that?”) and Python bindings.

This does not necessarily mean the program manager has the best possible solution to offer. Instead, also coders have a valid point. As a consequence, Joel postulates that both need to discuss the design as peers. This was not given if the developer reports to the program manager, so the program manager has the final saying.

There are examples out in the wild where coders have written user interfaces, which only can be used if you have read and understood the manual, if any, in great detail. Even the most brillant coder may fail as soon as it comes to user interface design, known as the “software vs. user model” issue. This results in less intuitive designs, with a flat learning curve, which in turn requires more documentation. Joel has an article on the issue as well, and here’s a quote from my usability paper:

Last but not least, clever software design reduces the amount of documentation needed; developers dislike writing documentation as well as users dislike reading it.

This does not necessarily mean, though, that a program manager does better user interfaces. Even if you think that you “know your audience”, you can fail miserably. Thus the peer-approach is a good point. It is an important part of my job “to build consensus and bring people together”, including users, developers and marketers.

I really enjoyed to read Joel’s posting, though one does not learn much when just reading the very own point of view. I need to read the books he recommends anyway :) .

This entry was posted on Saturday, March 14th, 2009 at 16:28 and is filed under Products, Software. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.