Trusting Your Customers
February 8, 2005 – 10:05 amIn his recent blog posting, “Tenets of Transparency”, Eric Sink says that if independent software vendors (ISVs) aren’t willing to trust their customers, they won’t have any. When customers buy software from you, they trust that:
- your product will work on their machines;
- you will help them if they have problems;
- you will continue to improve the product;
- you will provide them with a reasonable and fairly-priced way of getting those improved versions;
- you are not going out of business anytime soon.
So, they have to trust you; Eric’s question is, how do you show that you trust them in return? His answers are:
- Have a corporate weblog, so that customers can keep track of what’s really going on.
- Offer web-based discussion forums, so that they can talk to you, and to each other.
- Don’t hide your product’s problems.
- Don’t annoy honest people with measures designed to block the dishonest few.
- Offer a painless demo download.
- Offer a money-back guarantee.
- Share a little about your financial standing.
- Talk about your future plans.
I’m not an ISV, but I am involved with some open source projects, and university courses, so how do they measure up on this scale? Most open source projects now have a weblog of some kind, and they’ve always had discussion forums; their problems are out in the open, they don’t include anti-piracy and licensing cruft, and the “demo” is the product itself.
But what about the money-back guarantee? As many people have observed, “free” software is only free if you think your time is worth nothing; you can easily waste hours or days trying to install, configure, and debug an open source package, and if you do, no one will give you that time back. As for Eric’s last two points, they’re mostly about giving people confidence that you’ll still be around next month or next year, so they won’t have to throw away what they’ve done and start over with some other package. Open source falls down here—except for very large projects (like Apache and Python), there’s a very real risk that people will lose interest, have to go earn a living, or squabble, all of which can lead to the project suddenly being dead in the water. Take Groovy, for example: twelve months ago, it was the Next Big Thing in Java, but now—well, there’s still a pulse, but I don’t think anyone’s expecting it to ever ship anything useful.
What about university courses? It may seem odd to compare them to commercial software, but I think it’s helpful to think of courses as products, which are “bought” when students enrol in them. Most courses don’t yet have a weblog, although Trac automatically generates one for my students’ CSC49X projects, and I’ll use one for course announcements the next time I teach a regular classroom course. Web-based discussion forums? Sure, we’ve all got those. Hiding the product’s problems? Well, students usually find problems (errors in notes, ambiguities in assignments) before profs do, and they’re encouraged to post their findings.
How about not annoying honest people for the sake of preventing dishonesty? I think this is one of the places where courses have to be measured differently from products. As instructors, our goal is to educate, but we’re also responsible for assessing students; we can only do that fairly if plagiarism and cheating are i, even if it means making honest students’ lives a little more difficult.
Offering a demo doesn’t really apply (unless you count keeping last term’s notes on-line, so that students can see what they’re getting themselves into). Offering a money-back guarantee is an interesting idea: when I was a student, I thought universities should let each graduating class vote on what their worst course had been, and refund their tuition for it. Now that I’m an instructor, I can see a lot wrong with that idea…
Financial standing? I don’t think it applies (although the next time I run a course, I’m going to keep track of how long it takes me to write lectures and create exercises, and post that on the course web site). Finally, I think it makes a lot of sense for instructors to talk about future plans, i.e., to tell students how the material they’re learning fits into what they’re going to do next term, next year, or after they graduate.
One Response to “Trusting Your Customers”
I don’t think it is particularly helpful to think of University courses as a commercial product. When I buy a software, I expect that it will just work, and I won’t have to think too hard about how to make it work. Students need to work and think hard to get value out of a course, and they have many responsibilities.
The presence or absence of a weblog is a red herring. Instructors have a responsibility to provide information to students about the course, but whether it is a weblog, a simple web page, paper handouts, or a series of in-class announcements, is only mildly related to the quality of the course.
Creating a learning environment is not the same as selling a product. It is not helpful to students to “spoon-feed” them the course material. It is not helpful to the students to reveal to them everything about the course.
I also do not think how much time I spend preparing lectures and assignments is relevant to the students. Is amount of prep time is an indication of quality of the lecture or assignment?
Tooo many students already have a view of themselves as customers receiving a product rather than participating in a process. Too many students see the final grade as the end goal rather than what they have learned.
Many University courses, and indeed the whole University system, could be impoved, but commercializing courses wll make matters worse.
By Karen Reid on Feb 8, 2005