How Nokia helped improve my conversational style

I’ve always fancied myself an efficiency expert, but admittedly not due to any formal education.  Rather, an innate laziness has always ironically motivated me to constantly and intuitively look for process improvement.  Laziness, more than any other factor, is the true mother of invention.

But as successful as I’ve been in streamlining business processes and practices, that did not translate easily to communications.  I was constantly criticized, personally and professionally, for using ten words where two would do.  This has been, in yet more irony, a byproduct of the same storming brain that could identify quantum process leaps that had eluded peers.  So many things rattling around up there at the same time that honing in on one of them has always been a challenge.  In addition, I always wanted to share as much information as possible with listeners.  A job recruiter recently remarked that I am one of those who, when asked the time, tends to describe clock construction.  I had to admit he was right.

Pop goes the Apple

It almost sounds like a Monty Python skit except that it isn’t really funny.  Apple product users worldwide are reporting exploding and sparking iPhone and iPods in what’s becoming an all-too-familiar story over the past few years.

While there’s certainly serious potential for harm in a bursting electronics device, Apple ladles insult on top of injury by extending its legendary micromanaging approach to product returns.  Some customers are being told that they will need to sign very strict non-disclosure agreements in order to have their purchase refunded– a practice that is known to be illegal in many soveriegnties.

 To be fair, this is not entirely an Apple-only issue.  Dell, Sony and Nokia, among others, have had their turn in this spotlight as the rush to wring out more power and life from device batteries increasingly stresses the materials.  But Apple compounds the problem by making those batteries a semipermanent fixture that can’t be easily removed by consumers.

Apple spokespersons have circled the wagons and adopted the usual “not our fault” mantra, the sort of response one expects from a paranoid culture.  They’re blaming users instead of design flaws.  Not exactly the sort of public relations they need to employ as iPhone competition finally gets serious with devices like Nokia’s newly-announced N900.

Hey Apple: I have a much better idea.  Forget this hardwired battery approach; it just adds unnecessary risk and frustration.  Instead, design your products so that the stresses you cite as failure modes will eject the battery.  I don’t mean anything fancy, either– drop the iPhone, the impact opens the battery door and out plops the little guy.  It can’t be too hard… most of my other small devices manage this even without design intent!

I wonder how many lawsuits and/or EU fines it would take to fix this…

Cloudy days for data, Part 3 (conclusion)

After a bit of a delay I’m going to wrap up this series tonight.  In the last segment, I finished up describing the struggle between file independence and data management, ending with the usefulness of metadata and touching on Cory Doctorow’s dissension on that topic.

I’d rather that readers take some time to read Doctorow’s interesting thesis than for me to repeat too much of the content here, but suffice to say he pokes seven disturbing holes into what he terms “meta-utopia” and as I said previously it isn’t easy to disregard his points.  The most troublesome to me concerns the problem of crafting agnostic, universal schemas, which tend to be two-dimensional and thus create difficulties for diverse parties trying to arrive at design consensus.  Doctorow correctly points out that data sets and needs tend to be richer than that, extending easily into three dimensions (my extrapolation) in order to properly define any object.  Just as databases are better than flat files, data cubes are better still– and there has been work along those lines with XML.

Doctorow ends on a somewhat promising note by admitting that, flaws and all, metadata is still useful.  It’s just that those choosing to rely on it as part of any information management or publishing solution need to be aware of the pitfalls going in (his article should be part of the solution design requirements in my opinion).

Can Nokia manage a second shot at the US market?

I’m going to interrupt the Cloudy Days for Data series again to muse this time about marketing…

I’ve been very pessimistic on Nokia’s future prospects in the United States but there’s no distinction in that stance; so has just about every other pundit.  It seems like every time Nokia had something novel to offer, whether it be new devices like the promising internet tablets or a potentially hot service like Ovi, the ball wound up fumbled… sometimes by design.

A large part of that design was the stubborn insistance on model numbers over names, despite the allure shown by competing products like the iPhone and Blackberry.  It’s been long known that this sort of branding resonates loudly with US citizens, so when Nokia portfolio manager Ira Frimere declares in a recent Computerworld article:

“I’ve learned it’s not what I like, but what my customer likes,” he said.

…I have to wonder when this epiphany occurred for him.  No offense meant to Mr. Frimere, but I recall numerous conversations in Nokia US offices over this subject and that was the one consistent theme behind them all.  It did not matter what Nokia executives thought; wrapping product branding and marketing strategies around customer needs and wants is paramount.  Marketing 101.

Cloudy days for data, Part 2

Inspired by blog articles from Michael Dominic K. and Henri Bergius, in part one of this series I touched on the conflict between the order of databases and the freedom of files.  The latter are fiercely hoarded and guarded by information workers who in many cases don’t really care about the object so much as the information it conveys.  But what are files, and why does this issue of managing their chaos even exist?

The modern electronic file is a data or readable text object meant to store and/or convey useful information.  It can constitute one or more records (I’ll even consider a graphic image as a record in this context).  The beauty of a file is its common independence from the confines of enterprise data stores.  This is especially true in the case of files based on open source and highly-accepted commercial formats; they are often accessed by a multitude of viewers or renderers.

But that independence comes at a cost.  The further a file object lives from a data management system, the more risk it can introduce and encounter.  Versioning, detail accuracy and unapproved copying are just some of the risks.   Files also consume storage space often disproportionate to the value they add, especially as they are wastefully replicated in myriad emails and hard drives.  The cheapness of onsite storage has helped exacerbate this, removing old constraints that once encouraged conservation over ease of access.

Request for comment: Community Engagement

I’m going to take a break from my series on the data cloud and interrupt with a request for my readership.  I’m putting together a presentation proposal for the Maemo Summit 2009, titled “From corporations to communities: responsible and effective engagement”  and could use some opinions and experience.  If you have anything to offer on the items below, feel free to comment!

• What could corporations do better when engaging user and developer communities?
• What incentives drive developers to work for free (i.e., Linux)?
• What are some examples of successful corporation-community engagement?  What made them work?
• How can the challenges of working with virtual communities be overcome?  Any examples?
• Are corporations responsible for success of the communities supporting them, vice versa, both ways, or neither?
• How do we strike a balance between corporate commercial interest and community free enterprise?
• Etc

I already have some good material but I really want to hear from the crowd.  If I use your RFC contribution you will be credited!

Thanks.

Cloudy days for data, Part 1

Several years ago I was in a product data management role for a major US manufacturer, assessing our information management landscape and helping my boss develop a road map for bringing the 160-year-old company’s engineering systems and processes into the modern age.  What I discovered shocked me although I really should not have been surprised: the vast majority of our mission-critical business data was sequestered in spreadsheets and shared virally via emails.

This sort of working environment tends to spring up as a consequence of two conditions:

1. Often the information management system(s) are lacking in necessary features, disconnected, difficult to utilize, poorly represented or even non-existant;
2. People want to hold on to their stuff

Anecdotally, I found the latter to be the greater evil.  When information managers try to improve the first condition, they encounter resistance due to the second.  After all, information is power, and the gut feeling is that if we relenquish any control over it we lose apparent value.  So the people who could benefit most from fixing broken sharing systems often hurt themselves by actually becoming part of the problem.