tl;dr: I've shut down my private consulting practice and stepped down as CEO of ThingM. On Monday I start my job with the Innovation Services group at PARC, a technology and strategy consulting team within the research organization formerly known as Xerox PARC.

Full story
I've been a consultant for most of my professional life. I started as an undergrad at the University of Michigan in 1988 helping people format their resumes with Microsoft Word ("tabs, not spaces!") and mount reel-to-reel tapes on Michigan's proprietary mainframe operating system, MTS ("fixed or variable blocking?"). I then moved on to Presence, where I helped both Hollywood studios and hot sauce shops develop their first web sites. At HotWired, I started a user research group that became a kind of in-house consulting group for the company, researching HotWired's own products, and then after Lycos acquired it, Lycos' portfolio. Then there was freelance user research consulting and the founding of Adaptive Path, the UX consultancy. Since I left AP in 2004, I have expanded my user experience design practice as the landscape of digital technology has broadened and diversified. What I do now includes the design of most kinds of digital devices and emphasizes the relationship between devices, online services and business strategy. Nevertheless, the form of this work has largely not changed: I'm still consulting.

There's a second thread to my work: making electronic things. In college I did installation art, video and performance. During the HotWired and Adaptive Path days I spent much of my free energy on Burning Man art projects and constructing theme camps (I can tell you how to power 3/4 of a mile of Christmas lights, a sound system and a full kitchen on one 15KW diesel generator!). ThingM has been the most satisfying project of all, and working with Tod Kurt for six years has been one of the most educational, creative and fun of my life. We just sold more blink(1)s in the last six months than all of our products combined over our first three years. Today, it looks like the momentum toward making ThingM into a successful consumer electronics company has finally started. To use Eric Ries' term, we have finally figured how to get our "engine of growth" going.

Six months ago I was sure that my future was going to be more about making things with ThingM than UX consulting. Then, as happens perhaps only a couple of times in life, a unique opportunity came along and everything changed. As I was looking for consulting projects at the beginning of the year, I contacted my old friend Victoria Bellotti at PARC to see if she knew of any interesting UX consulting projects. She said she didn't, but she'd keep an eye out. Some months later, she kept her promise and I was introduced to Patrick Cook, the director of PARC's new Innovation Services group, who connected me with a project inside PARC that needed some user experience strategy and design assistance (more on that project in a later post). For the next five months I had one of the best consulting experiences of my life. I worked with an experienced, smart, focused and creative team inside PARC on a project that balanced bleeding-edge technological innovation with a pragmatic business focus. These are both important to me, but I find them together rarely. It had the energy of a startup without the freak outs, and the intellectual rigor of an academic project with the polish of a commercial product. I had known of its reputation, of course, but working there I became increasingly impressed with the level of technical sophistication, deep wells of knowledge, and work process at PARC.

When Patrick asked me to join his team on a permanent basis, I said yes. I start at PARC's Innovation Services group on Monday. The group brings PARC's deep technical resources (in everything from ultraviolet LEDs to machine learning, computer vision and social network analysis), industry connections, and user research experience to organizations looking to create new technologies, develop new services, and identify new business opportunities. In other words, it's a business consulting organization with the resources of a world-class research lab, backed by an enormous electronics manufacturing and document services company.

I admit I'm daunted by the prospect of working for such a famous organization and I hope that 13 years of being my own boss haven't made me unable to work for someone else. But this was an opportunity I couldn't pass up. I'm very very excited to work with old friends and brilliant new colleagues.

As for ThingM, I'm stepping down as CEO, though my close relationship with the company will continue. I am still an active advisor and co-owner, meeting our (growing!) company staff on a weekly basis. Right now I'm working to get blink(1) into traditional consumer electronics sales channels. Tod and I have started planning the blink(2), which we hope to release this quarter or next.

My independent consulting business, however, is on hold for the forseeable future. And I'm glad. I love the variety of consulting and I have had great clients and worked on challenging and rewarding projects. But the life of an independent consultant means preserving the headspace to do good work while juggling multiple projects and constant business development . At PARC we will have all these same challenges--every consulting organization does -- but I'm looking forward to not having to do it alone.

That said, I'm still consulting! I will be delighted to work with organizations that are interested in world-class ethnography, technology development and user experience design. PARC can provide all of these -- at competitive rates and with the some of the most talented and experienced technology developers on earth.

Email me and I'll give you more details: mikek at parc.com (after Monday ;-).

I just gave a lightning talk at the 2010 Open Hardware Summit. In it I tried to describe three situations where openness and business practice have intersected in our running of ThingM. Here's the transcript:

Intro
Hi. Thank you very much Alicia and Ayah for organizing this event. Since this is a lightning talk, let me cut to the chase.

I'm Mike, co-founder of ThingM with Tod E. Kurt. We design and manufacture ubiquitous computing products. Our current product line consists of BlinkM smart LEDs. These are ultrabright RGB LEDs that have an integrated driver that runs firmware that abstracts away the complexity of creating light effects. Someone with no experience with electronics, programming or color theory can use our stuff to make a smoothly fading, blinking light effect in a relatively short time without an additional microcontroller or any other hardware. Our smart LEDs even have their own input pins to change behavior on the fly and they're used in everything from car dashboard prototypes to (as we have been told) Lady Gaga's stage show.

The vast majority of our code and designs are open, but not everything, and I'll explain why in a minute.

First, let me preface by saying that ThingM is our day job. In the four years since we started it, we've always treated it as a profit-making business that needs to sustain itself and us. So, just as any small business, we're always thinking about money, and that frames my perspective on the value of Open Hardware as part of a larger business strategy.

I want to describe three situations where ideas of Open Hardware intersected with our business decisions. I haven't been watching the summit, so excuse me if this has been covered already.

Case 1
We sell a product called the MaxM. It's a two-part smart LED. There's a controller and an LED cluster. When we first came out with it, one of our distributors asked if they could sell the LED cluster alone. With thought, "Why not?" and made some extras. They sold pretty well, but we made very little money on each one, maybe $1, because they were cheap. After the first run sold run, I ran the numbers and realized that for every cluster we sold instead of a MaxM, we lost somewhere around $5 in potential profits, and our customers got a product that wasn't nearly as interesting as a MaxM. Thus we would have to sell five clusters to make up for every potential lost MaxM sale. Was that actually happening? I don't know for sure, but the numbers didn't imply it, and there were indications that we were in fact hurting MaxM sales.

We decided to cancel the LED cluster, and we told the distributor. They said "OK, but if you don't mind, we'll just make our own. It won't look like yours, but it'll basically be the same thing." They didn't have our Gerber files or our LED supplier, but we share the schematic and it can be replicated very easily. Of course I said yes, since they're good friends of ours, but I felt like we had developed a product that cannibalized our primary market, while giving someone with better marketing and distribution resources than we had another opportunity to compete with us.

What did we learn? Well, we kind of screwed ourselves twice, and if our hardware wasn't as open, we may have only screwed ourselves once. Would we do things differently? Probably not.

Case 2
A couple of months ago I was having a really good conversation with a big electronics catalog, trying to talk them into carrying our products. I thought things were going pretty well and they were going to pick up our product line, when their buyer casually said "Can you send over your UL certification? We can't carry your product unless it's been UL certified." I said, "uh, let me look into that." So I did. It costs between $10,000 and $20,000 for our type of lighting product. To do all of our products would cost us around $100K. If we want to get all of the other certifications that are applicable, it would probably cost us another $100K. First of all, we can't afford that. Moreover, conforming to the standards would require us to change our designs in specific ways, which would be great, because there's probably a reason those standards exist, but it's a pretty expensive design rev. If we make our revised designs open, we will be giving potential competitors the product of that standards conforming process, of that improved design that cost us $200K, putting us at an immediate financial disadvantage.

Can we afford to make that gift? I don't know. I'm still thinking about it.

Case 3
Three years ago, about a week after we had started selling and shipping the BlinkM, we got an email. The email was a very nice. The author said that he and his company thought our products were very interesting, but wanted to point out that his company had just been granted a patent on the core functionality of our product, and that he would like to have a conversation with us about it. The patent had been granted that day, so it was clear that he had been quietly following our progress as we documented it on Flickr and our blogs. I immediately called our patent attorney. He asked me to come to his office. When I came in, he had the patent printed out and the key claims highlighted. He asked me whether our product did the highlighted claims. I said, "Well, it definitely does these two things, and if I understand this third claim correctly, then it does that, too." He said "Get out of that business immediately."

Fortunately, we were lucky. I'm stubborn and optimistic. Jeff, the guy who sent us the email was the CTO of an East Coast manufacturing company, and he said that rather than sending his lawyers, he wanted to talk first. He suggested we meet the following week, since he was going to be in the Bay Area. My patent lawyer's half-joking advice was not to go alone and to not meet him in a hotel room. Jeff suggested we meet in a hotel room in Santa Clara, alone. I said OK.

Since time is limited, I'll cut to the chase. It actually went very well. Jeff was generous and I didn't do anything that I regretted in the morning. We negotiated for about six hours and came up with a licensing agreement that allowed us to use his company's IP for free, but we could not make products outside of a specifically defined market, we could not share the technology with his competitors, and that the IP was not transferrable. If someone made something with our products that crossed into his company's market, he would treat it as a patent infringement, and we would be held at least partially responsible. Thus, we could not make the core part of our product, the firmware, open, since that would violate the agreement.

That's when I realized that IP, whether it's open or controlled by patents or trade secrets has a different quality when held by small companies than patents held by large companies. Large companies think of themselves as knights in armor and treat IP like a battle axe, but for small companies, if you're dealing with someone reasonable, a patent or an open hardware design is just a letter of introduction between two companies with a mutual interest in a technology. Their interest is, or should be, to do mutually beneficial business with each other. And that's how I've treating IP ever since. We have filed some patents and trade secrets, but most of our products are open. However, we have to decide which is which on a case by case basis.

The main thing I learned from these three experiences is that there are many shades of grey in Open Hardware. I try to keep ThingM as open as possible, but every decision has an effect on the financial health of the company, in the short term and the long term. Openness is a strategy for long-term technological influence, and perhaps profit, but it carries with it both short term and long term costs that have to calculated as part of a business model.

The blog of future think design consultancy PSFK interviewed me by email.

In the interview I talk about the book (of course) and ThingM's upcoming products. I also took the opportunity to think about how I've noticed the trend of services that provide data streams, rather than just units of data:

I think that there’s a really interesting trend in opening up data sources. Pachube works as a free data stream brokerage that sits on top of TCP/IP and HTTP to provide a kind of semantic resource location technology for small net-enabled devices that has been missing. This kind of data openness is being matched by things such as the US Governement’s open data initiative at data.gov.

The trend I see here is a combination of openly sharing data sources and streams and creating business models around making technology layers that make those data streams meaningful and valuable. Both Pachube and data.gov are a kind of search engine for data streams, rather than documents, which I think is a very powerful concept.

This is definitely related to the discussions around syndication that have been going on for years (since the launch of RSS), to micro-content, and to various services that add structured semantic information to Web-accessible data. However, I think what we're seeing now goes beyond those largely abstract discussions to create a more pragmatic understanding of what it means to create meaningful sources of data, rather than just meaningful units of data.

It means, as my last sentence implies, that there are enough data sources--whether it's sensor data automatically collected, organized and tagged by Pachube or the human-created sources of data presented by data.gov--that we can start having search services for such data. The conversation becomes again about "wrangling" information shadows, as I discussed in my NASIG keynote two years ago.

In that discussion I talked about how journal subscriptions--which are a kind of knowledge white hole, wellsprings of specific kinds of information--represent a model for how information shadows can be organized and managed in the future. Well, it looks like we may be closer to that, and that the wrangling may be a combination of automated tagging and human curation.

Does this mean that Google will soon be automatically cataloging data streams? I'd be surprised if they're not already.

As has been obvious in the recent past, I've been a bit focused on how and why disciplines, especially disciplines relating to ubiquitous computing, are named what they are. I'm not a language precision pedant most of the time--words mean what we want them to mean, when want them to mean those things and to the people we want to understand--but the titles of large ideas have a particularly strong impact on how we think about them. They, in effect, set agendas. If the scientists had called Global Warming something else, say "Global Weather Destabilization," that would have changed a lot of our expectations for it. People wouldn't nitpick about whether one degree is a lot or a little or whether an unusually cold winter in Michigan means that it's all a sham.

Similarly, what we call disciplines we involve ourselves in sets a lot of expectations for the agenda of those disciplines. Lately, I've been thinking about why "ubiquitous computing" has such problems as a name. When I talk about it, people either dismiss it as a far-future pipe-dream, or an Orwellian vision of panoptic control and dominance. I don't see it as either. I've never seen it as an end point, but as the name of a thing to examine and participate in, a thing that's changing as we examine it, but one that doesn't have an implicit destination. I see it as analogous to "Physics" or "Psychology," terms that describe a focus for investigation, rather than an agenda.

Why don't others see it the same? I think it's because the term is fundamentally different because it has an implied infinity in it. Specifically, the word "ubiquitous" implies an end state, something to strive for, something that's the implicit goal of the whole project. That's of course not how most people in the industry look at it, but that's how outsiders see it. As a side effect, the infinity in the term means that it simultaneously describes a state that practitioners cannot possibly attain ("ubiquitous" is like "omniscient"--it's an absolute that is impossible to achieve) and an utopia that others can easily dismiss. It's the worst of both worlds. Anything that purports to be a ubiquitous computing project can never be ubiquitous enough, so the field never gets any traction. The mobile phone? That's not ubiquitous computing because it's not embedded in every aspect of our environment and doesn't completely fade into the background. A TiVo can't be ubiquitous computing because it requires a special metaphor to explain it. The adidas_one shoe isn't ubicomp because it doesn't network.

The problem is not with the products, it's with the expectations that the term creates.

I see this problem with a lot of terms: artificial intelligence has "intelligence" as part of it, so nothing can be AI until it looks exactly like what we would call intelligence. Machine learning, that's not AI because it's just machines doing some learning. That's not intelligence. Pervasive computing can't exist until we have molecule-sized computers forming utility clouds, because nothing can be pervasive enough until then. Ambient intelligence is an amazingly bad term using this metric: TWO words with implied infinities.

As Liz (Goodman, my wife and fellow ubicomp researcher ;-) points out, when these terms are coined, they are created with a lot of implicit hope, with excitement and potential designed to attract people to the potential of the ideas. But after the initial excitement wears off (think AI in the 1970s) they create unmeetable expectations as the initial surge of ideas gives way to the grind of development, and setbacks mean that the results are never as ubiquitous, intelligent, pervasive, or whatever, as observers had been led to believe. AI was doomed to be a joke for a decade (or more) before they renamed themselves something that implicitly promised less, so they could deliver more.

So what to do about this? Well, I've done a couple of things: I've used one term ("ubiquitous computing") rather than creating ever more elaborate terms to describe the same thing, and I've tried to use it to describe the past as well as the future. In my past couple of lectures I've been arbitrarily setting the beginning of the era of everyday ubicomp as having started in 2005. It's not something in the future, it's something that's in the past and today. Is that a losing battle? Do we need to rename "ubicomp" something like "embedded computing product design," something that promises less so that it can deliver more? Maybe. I still like the implicit promise in the term and its historical roots, but I recognize that as long as it has an infinity in part of its term, there will always be misunderstandings. Some people (like the folks in New Songdo City) will actually try to create the utopian vision, and invariably fail. Some will criticize the field for even trying, while at the same time doing the same thing under a different name.

Me, I'm going to keep calling it "ubiquitous computing" or "ubicomp" until it's either clear that the costs of sticking with the name overweight the benefits I believe it has, or until a better term, one that's less likely to let everyone down, comes along.

(the title of the blog post references Finite and Infinite Games, a book I've never read, but which friends of mine tell me is quite good)

[2/18/09 Update: Michiel asked me (in email, because I have blog comments turned off) what I thought about "The Internet of Things" as a term. I've written about it before and I think it's a pretty good term. It's not as unbounded as the terms I mentioned. "Internet" is something people are familiar with and "things" is a large set, but not an infinite one. There's some internal confusion because "the internet" is seen as ephemeral, and it's hard to imagine how that ephemeral idea translates to the very literal world of "things." Likewise, there's an implication that all things will become part of this new internet, which is also potentially confusing. However, those criticisms aside, I don't think it's a bad term, but only if it's defined well and used precisely. I don't think it's exactly the same idea as ubiquitous computing, for example, since I see it as more about individual object identification and tracking, rather than smart environments, or ambient displays. If it starts to be yet another synonym for ubicomp, its value will diminish.

William sent me the following note:
Interesting observations! Two related bits:

One is Martin Fowler's thinking on "semantic diffusion":

http://martinfowler.com/bliki/SemanticDiffusion.html
http://martinfowler.com/bliki/FlaccidScrum.html

Another was a recent conversation I had at the Prediction Markets conference with an econ professor. He mentioned that the incentives are such that whenever a term develops a positive value, people attach themselves to it until its value swings negative. I think that basic model is too simple, but from it you can develop a richer model that explains a lot of what people get up to with terms.

I like the economic idea, though I agree that it (feels) too simple. ]

Several people have asked me to describe the ubicomp UX book I'm writing. As time allows (and it doesn't allow much), I'll try to post some information about it. For now, I'll start with an annotated outline. A big caveat: the final product may little resemble this, but this this is the outline I'm writing to. I've removed some of the detailed description because I want to surprise you and I because I may change my mind.

Smart things: the design of things that have computers in them, but are not computers

[this will probably not be the final title, but it gives you the gist of what I'm trying to say with it]

0. Preface

Writing about ubiquitous computing is like trying to draw a plane as it's flying by you at 600 miles an hour. The best you can hope for is that the general outline is right, because there are certainly going to be many details that aren't.

1. Introduction: The Hidden Middle of Moore's Law

PART ONE: Frameworks

2. Broad concepts

This chapter will introduce the background issues that underlie some of the broad conceptual frameworks.

• The relationship between industrial, interaction and service design
• The importance of context.
• The design of social devices.
• Each new class of ubiquitous computing devices is essentially a new tool.

3. Information processing is a material

Embedded information processing acts like a material and creates new capabilities, and imposes new constraints.

• Behavior as competitive advantage. When a designer can include information processing in a product for very little cost, the calculation becomes not one of engineering complexity, that’s relatively cheap, but one of competitive advantage.
• How information processing is a material.
• Some qualities of information as a material.

4. Information Processing as Material Case Study

5. Information shadows

Nearly everything manufactured today exists simultaneously in the physical world and in the world of data.

• A digital representation is the object's information shadow.
• Information shadow can be examined and manipulated without having to touch the physical object.
• Coates' Point-at-things.
• Sterling's wine
• Design with information shadows.
• Physical/Network mashups.
• Identification as the cornerstone of the Internet of Things.

6. Information Shadows Case Study

7. Devices are Service Avatars

• When the same information can be accessed and manipulated through a variety of devices, value shifts to the information, rather than the device that’s communicating it.
• Devices become projections of services. A number of familiar appliances--cell phones, ATMs--are worthless without the networks they’re attached to. They are physical manifestations, avatars, projections into physical space of abstract services, but are not services themselves.
• Objects become subscriptions.
• Types of avatars.
• Products and services co-design.

8. Service avatar Case Study

9. Applianceness

[all props to Bill Sharpe]

• Defining applianceness. When computation is cheap, we no longer have to make general-purpose computers. There is no longer the need to think about a one-to-one computer-user relationship that terms like Human-Computer Interaction imply. One human to a multitude of appliances, some of which use information processing.
• Applying applianceness.

10. Applianceness case study

11. Applianceness case study 2

12. Granularity

Ubiquitous computing devices can come in all sorts of sizes and the user experience design for them must take this into account. General purpose computers traditionally have interfaces that are person-scale. They’re designed to be used in a wide variety of ways, and what typically makes sense is to make the input device about the size of your hands and the output about the size of your head.

• A powers-of-ten scale ubicomp experience design.
• Location-based services. How to size up the world.

13. Granularity Case Study

14. Interaction metaphors for ubicomp

Why metaphors are important in UX design. Existing ubicomp metaphors.

• Weiser's calm computing
• Home automation
• The metaphors in the names of subfields
• Magic

15. Metaphor case study

PART TWO: Techniques

16. Design from observation

• Introduction
• "Design Ethnography": it's not ethnography
• Observation techniques
• Design probes
• Learning from vernacular technology
• Cross-disciplinary precedents

17. Cross-disciplinary iteration

The importance of cyclical development processes that cycle through all, or most, of the design disciplines required to create a ubicomp product.

• Intro to rapid iteration
• Sketching in hardware
• Hardware hacking: hardware as tracing paper
• Video prototyping
• Interaction vocabularies: Saffer's gestures, Arnall's RFID interaction, etc.

18. Augmentation of existing objects

Since the concepts are so new, one particularly successful way to create new Ubicomp UX is to take an existing object and augment its functionality through technology.

• What
• How much
• The right kind of augmentation
• Functional vs. decorative
• Physical-Web mashups
• Smart furniture
• Wearables

19. Scenarios

• 10X
• Demography is destiny, maybe
• Mapping between domains
• Realistic bounds, overly positive/negative scenarios, the return of Unintended Consequences

20. Simulation

• Looks-like/Works-like prototypes
• Wizard of Oz
• Elmo++

21. Common design challenges

• Configuration. Out-of-box and beyond.
• Device interconnection. The promiscuous Wiimote holds a lesson.
• UX consistency between devices.
• Introducing novel functionality.

22. Explaining disruptive technologies

There's a lot of potential for disruptive technologies in ubiquitous computing, and explaining the potential disruptions to relevant stakeholders and potential customers is a challenge.

• Is a new technology genuinely disruptive? Don't believe the hype.
• Design for disruption.
• Explaining the value of disruption to stakeholders.
• Explaining disruptive technologies to customers.

23. From calm computing to everyware

• Ubiquitous computing is here
• As user experience designers we have a responsibility to think about how to design for it explicitly, rather than trying to use methods from Web design or industrial design.
• In the last 20 years, the understanding of what ubiquitous computing means has likewise grown significantly, and has moved from the idea of office-based productivity that disappears into the background to encompass just about everything except the office.