Product and Service cultures

Moving from Silicon Valley to DC in 2001, I found I was leaving the land of Product Imagination and entering the land… of what I’ve come to call Service Imagination.  The two couldn’t be more different.

 

Product Imagination is all about what goes into the product and what’s left out.  The product is a crystallized packaged of functionality which customers can take or leave.  It’s what you get.  Product imagination tunes the package to be most beguiling to the biggest bunch of customers, but there are always features (and therefore customers) who are left out.

 

Service Imagination is just the opposite.  Customer by customer, the organization delivers exactly what that customer wants, and then does the same for the next customer, and the next.  Service Imagination is about faithfully recording and reproducing requirements, and building them on a reliable timetable.

 

An organization built around Service Imagination can’t scale, of course.  There’s only so many customers you can faithfully support per engineering (or product requirements) body in the shop.  More customers require more bodies.  Product organizations don’t  have this problem.  The same development group can serve a customer base of almost any size (of course, some things have to scale, like product support and distribution, but R&D does not).

 

The two kinds of cultures (and hence the two kinds of businesses) hardly ever co-exist or cross over.  A product company is very hard to turn into a services company, and vice versa.  And what usually happens when they try is one of two possible hybrids.

 

Hybrid #1 is a “services organization with a toolkit”.  In this kind of organization, the repetitive element of various customer jobs is built into a kind of ur-product (often called a “toolkit” or “framework” or “template”) which is customized for each client.  The professional services organization which customizes the toolkit then becomes the locus of swelling body count, with the toolkit group emerging as some kind of product organization embryo.  Very rarely, this product organization spins out into a successful product company, but most often languishes on in symbiosis with the PS group.

 

Hybrid #2 is a “product organization bogged down with per-customer versions”.  In this hybrid, the company is supposedly producing a product but in fact modifies it for each customer (or for the biggest customers).  The symptom here is a development group that can’t implement new features because they are too busy with the per-customer modifications.  The company doesn’t turn into a full-fledge services company, usually, but languishes as a product company progressively falling behind.

 

Are there examples you see of the two cultures mixing, merging, or migrating?


This message may contain information that is privileged or confidential. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material (including any attachments and all copies) in its entirety, whether in electronic or hard copy format.

Advertisements

Whatever happened to RDF?

A friend and I were talking the other day, and we realized 1) that we both thought RDF was a nifty idea for organizing graph-oriented stuff and 2) that we had no idea what had become of it.

I looked around a bit and it seemed as if little was happening in the RDF community.  The links all seemed to peter out in the mid-‘00s, and I wondered where, if anything, the innovation was happening in this area.

Please comment if you can point me to cutting-edge companies and research ideas wrt RDF and its stack.

Inquiring minds would love to know.