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.

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.

Venture Capital as a Manufacturing Business

Half in jest and half to spur my thinking about our business, I’ve found it convenient to think of venture capital as a manufacturing business.

Most people in and around the venture business think of venture capital as a services business.  Our “customers” are our backers – Limited Partners – whose money we invest (hopefully) profitably.  Nothing wrong with that point of view, except it doesn’t lead you to think outside of the box.  And it’s wrong.

Our backers are, more accurately, our shareholders or our investors.  A limited partnership doesn’t work exactly like a joint stock company, but close enough, and certainly closer than thinking of them as customers.

OK, you might say, if you’re in the manufacturing business, what do you manufacture?   Very simply, we take raw materials – ideas, entrepreneurial talent, intellectual property, and so forth – and turn them into companies that can be sold profitably to a buyer, an exit.  We manufacture exits.

Our customer, then, is the buyer for our exits.  And they come in two forms.  In the B2B form of the venture business, our customers are major M&A acquirers.  Cisco is a VC customer.  IBM is a customer.  Google is a customer.

In the other form of sale, the B2C form, we “sell” the company to the public.  This is a “channel” sale because we use channel partners – otherwise known as investment banks – to distribute our “product” to the consumers.

How does this affect your thinking?  Very few VCs pay much attention these customers or channel partners, and the few who do reap outsized returns.

Mobile Client Wars and Client Diversity

As Android’s market share creeps up on iPhone, the drums of blogerati buzz beat louder on topics such as “which platform will win”, “battle of the titans over mobile”, etc.

A lot of this is just the chattering e-classes chattering (and, btw, Android’s going to win), but there is a trend below the radar here that has longer legs: I call it “client diversity”.

The fact is we are driving toward a computing architecture where different kinds of clients all attach to the network and use network resources (increasingly) for storage, computation, and collaboration.

Smartphones are one kind of client; “new” tablets like iPad (and the raft of Android tablets to be announced at CES shortly) are another.  But the various smartphones have more in common, say, than iPhone and iPad.  We are moving toward an ecosystem where different clients will be used for different functions and will co-exist more-or-less stably.

Most of my friends and colleagues are experimenting with substituting an iPad for a laptop in their road trips (the consensus seems to be that iPad does better for short trips, laptops for multi-city ones).  Most everyone with a smartphone and an iPad is finding that some apps, games, and activities work better on one than another.

Guess what?  Things are probably going to get more diverse.  We have second-class network clients like wireless picture frames, and even the poor Sony Dash.  We have automobile-based clients like media players and on-board nav systems.  (We have in fact nascent clients in all the GPS units out there, longing to be web-connected as well as GIS-connected.)

Why so many?  Because they are cheap enough (eventually) so that it’s more important to have the best client for each purpose than to have one client for all purposes.

Guess what else?  The mobile clients will start to control the non-mobile ones, so that your content from your smartphone will show up on the on-board nav system where the display is larger, although it may still be controlled from the smartphone (whose keyboard is better for input).  Your email will segue to the giant TV in your hotel room when you arrive because it’s easier to see.  This won’t take tech miracles, but it will take a hell of a lot of negotiations, similar to what the wireless voice world went through when it discovered how to do universal roaming.

Java, C, C++: Top Programming Languages for 2011 - Application Development - News & Reviews - eWeek.com

Java, C, C++: Top Programming Languages for 2011 - Application Development - News & Reviews - eWeek.com

Interesting stats for those who think WebApps R All. Not sure what to make of it, though. How is C still being used? C++ seems to be the "must-have-performance" language on the server side, Java is the "IT-blessed" app standard (although most of my tech friends have gone Python or Ruby by now for the business and presentation layers).

What are you seeing? Let me know.

Impressions, Data, Audience, Intent

I’ve been reading through a raft of year-end predictions from the digital advertising-oisie (thanks so much AdExchanger.com for putting it all together).
I’m not an advertising “native” as you might say, but just a humble investor in advertising technologies, platforms, agencies, and next-big-things.  So the vocabulary takes some getting used to.
But something just struck me: most of the predictions are all about using “data” to gain insight into the “intent” of members of an “audience”.
I’ve got a novel idea: why not just ask them?
What made search advertising such a rock-star was that you don’t have to guess what the searcher is interested in: they’re telling you.  Not perfectly.  Not always.  But it’s a big step in the right direction.
All kinds of targeting approaches jump through hoops to try to guess a prospect’s intent.  These schemes are ingenious: if you combine context, history, behavior, offline data, and social network, you know a whale of a lot about the prospect.  But it’s still incredibly hard to know what’s on their mind.
I’m looking for advertising breakthroughs which, like search, piggyback off an obvious indication of intent.  That’s where we should be investing next.
Have you run across anything along these lines?  Let me know…

Backup is dead

Conversations with customers, analysts, and vendors in the storage industry throughout 2010 convinced me that “backup” as we have known it is going the way of CRT tube “burn-in” orarchiving to optical media.  Backup is going away, and will soon be dead.

Consider Storage Newsletter.com.  Or Backup is Broken, by Wikibon.  Or even Steven Foskett, who acknowledges what a chunk of the traditional backup use case is being taken over by “new technologies” even as he tries to carve out a continuing place for backup.

Behind all the provocative language, we are looking toward a future when a “window” of time taken up with data management to the exclusion of all else in the storage system will be a thing of the past.  Whatever forms data protection take in the future – and technologies like replication, snapshots, CDP, etc. are only the beginning – they will be increasingly transparent, seamless, and continuous.  And backup systems, shorn of the obligation to manage the lack of transparency, will increasingly become metadata catalogs with a variety of uses including backup/restore but also including the likes of discovery, content-addressability, or even semantic inference.  The backup system and the file system, in a word, will converge.