This is a rant - mostly.
A couple of days ago I attended a seminar by MathWorks about their products.
MathWorks has its only Indian office in Bangalore. That is not surprising, the bulk of the government hi-tech establishments are located there.
But Delhi too is important, after all it is where the headquarters of those establishments are located:-) So here they have partnered with a local company. They are part of the MathWorks value stream.
The "bandobast" (organization) - venue, registration, refreshments, lunch, gifts- for the seminar was done by the value stream partner.
I was informed, by mail from MathWorks, about my registration and asked to bring a printed copy of the mail. At the registration counter that mail was no help. The guys there had a handful of sheets listing names and organizations. There was a stack of pre-printed name cards. What was the problem in putting them in boxes according to the some ordering scheme? Better still why not keep a couple of small printers and print out the names on the spot?.I have seen electoral rolls checking, which is done by low paid government school teachers and other district staff, done better.
What does it say about MathWorks when its value stream partner does not know enough to put the lists on an Excel sheet? Does it need great administrative talent to allot a unique registration number to each participant? Is it expensive, compared to the expense of the venue, and the refreshments and lunch, to put a couple of laptops and a couple of printers at the registration counter?
The piece-de-resistance was the gift in exchange for the filled feedback sheet. It is good looking table clock. Nice big digits. The instruction sheet needs a magnifying glass. The day of the week cannot be set. Maybe some Chinese company designed it using a MathWorks product:-) Maybe all the clocks were not like that. Maybe, they fixed this one clock specifically for the guy who was making all that ruckus at the registration desk :D
Lesson: If your value stream partner interfaces with the customer, it is vital that you check the customer experience. Dog-fooding is more than eating the lunch served at the venue.
Showing posts with label Dog Fooding. Show all posts
Showing posts with label Dog Fooding. Show all posts
27 November 2010
24 November 2010
A Role Model for Entrepreneurs
This video on what it takes to build a successful venture was recommended by my friend Karnan.
Learn about dog-fooding, about values and vision.
Learn about dog-fooding, about values and vision.
02 October 2010
Movie about Quality
Early today I watched Executive Suite. It is a movie made in the the 1950s. I strongly recommend getting the bittorrent download, or the DVD (available from Amazon), or watch when Turner Classic Movies schedules it again
The terrific cast include William Holden. Holden was a favourite of mine when I was in school. Some may remember him from Bridge On the River Kwai. The movie very convincingly conveys the message about values on which a company should be run, quality in manufacturing, product that the company's people are proud to stand behind. If American companies had paid heed they would not have lost leadership in automobiles. We need to build companies with the same values.
The terrific cast include William Holden. Holden was a favourite of mine when I was in school. Some may remember him from Bridge On the River Kwai. The movie very convincingly conveys the message about values on which a company should be run, quality in manufacturing, product that the company's people are proud to stand behind. If American companies had paid heed they would not have lost leadership in automobiles. We need to build companies with the same values.
Labels:
Culture,
Dog Fooding,
Quality
19 September 2010
Dogfooding - at acmet's Tools BU
We built and RENOVATED compilers at the Tools BU.
But we never used them.
One of the other BUs did applications for the same customer for whom we had built - and were maintaining - a compiler. Unfortunately, the applications were for processors other than the target of the compiler.
We were not eating the dog-food we were making. If we had, our tools team would have been the better for it.
But we never used them.
One of the other BUs did applications for the same customer for whom we had built - and were maintaining - a compiler. Unfortunately, the applications were for processors other than the target of the compiler.
We were not eating the dog-food we were making. If we had, our tools team would have been the better for it.
Labels:
Dog Fooding
06 September 2010
Who Makes Product Specs?
Paul Graham in his essay on what happened to Yahoo says:
"I remember talking to some programmers in the cafeteria about the problem of gaming search results (now known as SEO), and they asked "what should we do?" Programmers at Yahoo wouldn't have asked that. Theirs was not to reason why; theirs was to build what product managers spec'd. "
Asking, "What should we do?" is not the same as, "Why is this required?" The programmers at Google were asking directions. They were not questioning the requirement.
The user requirement must come from the user. The product manager is the surrogate user.
But programmers too are users of software products. If they are building a search engine it should be one that they would willingly use. If the people making the dog food do not like it, neither will the dogs. And as far as finding out how the search engine could be misused, or gamed, the best inputs would come from programmers (if they are good programmers). In the absence of such converstaions what you have is a pin factory.
A good corporate culture would promote conversations between developers and users, or their surrogates. To get such a culture companies must select, and reward, persons who display this talent. Yahoo apparently did not.
"I remember talking to some programmers in the cafeteria about the problem of gaming search results (now known as SEO), and they asked "what should we do?" Programmers at Yahoo wouldn't have asked that. Theirs was not to reason why; theirs was to build what product managers spec'd. "
Asking, "What should we do?" is not the same as, "Why is this required?" The programmers at Google were asking directions. They were not questioning the requirement.
The user requirement must come from the user. The product manager is the surrogate user.
But programmers too are users of software products. If they are building a search engine it should be one that they would willingly use. If the people making the dog food do not like it, neither will the dogs. And as far as finding out how the search engine could be misused, or gamed, the best inputs would come from programmers (if they are good programmers). In the absence of such converstaions what you have is a pin factory.
A good corporate culture would promote conversations between developers and users, or their surrogates. To get such a culture companies must select, and reward, persons who display this talent. Yahoo apparently did not.
Subscribe to:
Posts (Atom)