Jason Crawford

I’m a stickler for the exact use of language. So it pains me when I hear important concepts bandied about. When words become buzzwords, they are used loosely and a lot of the original context for the term is lost. Here are some examples:

“Disruptive.” Often used to mean any big change in a market or industry. But not all transformational innovations are disruptive. In fact, the term was introduced by Clayton Christensen specifically to distinguish certain kinds of big changes from others, which he calls “sustaining” innovations:

Sustaining innovation is an innovation that brings to market a product or service that a company in the market could sell for higher margins to its best customers. In other words, sustaining innovation brings a better product into the market. Some sustaining innovations are simple, incremental, year-to-year improvements. Others are dramatic, breakthrough technologies the transition, in telecommunications, from analog to digital, and digital to optical….

The odds overwhelmingly favor the incumbent leaders of the industry in battles of sustaining innovation — whether they are simple, incremental innovations or breakthroughs.

A disruptive innovation brings to market a product not as good as the products in the current market, and so it cannot be sold to the mainstream customers. But it is simple and it is more affordable. It takes root in an undemanding portion of the market, then improves from that simple beginning to intercept with the needs of customers in the mainstream later.

I call that a disruptive innovation not because it’s a breakthrough from a technological sense, but instead of sustaining the trajectory of improvement that has been established in a market, it disrupts it and redefines it by bringing to the market something that is simpler.

“Pivot.” Often used to mean any change in business strategy or product. But not every change to a business plan is a pivot. In fact, the term was introduced by Eric Reis specifically to distinguish certain kinds of changes from others, which he calls “jumps”:

I want to introduce the concept of the pivot, the idea that successful startups change directions but stay grounded in what they’ve learned. They keep one foot in the past and place one foot in a new possible future…. By contrast, many unsuccessful startups simply jump outright from one vision to something completely different. These jumps are extremely risky, because they don’t leverage the validated learning about customers that came before.

“Refactoring.” Often used to mean any change made to code. But not every change to code is refactoring. The term names a specific type of change:

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. Each transformation (called a ‘refactoring’) does little, but a sequence of transformations can produce a significant restructuring. Since each refactoring is small, it’s less likely to go wrong. The system is also kept fully working after each small refactoring, reducing the chances that a system can get seriously broken during the restructuring.

Refactoring is not the same as redesigning, re-architecting, or rewriting, which can entail much more cost and risk.

I won’t get on your case if you use these words in their more general senses around me. But I make an effort to use them precisely, and you should too. The distinctions they make are too important to be lost. Otherwise you’ll end up founding a startup on a sustaining innovation, thinking you’re being “disruptive”; thrashing about from idea to idea, thinking that you’re “pivoting”; and rewriting your whole codebase from scratch thinking that you’re “refactoring”.

Words matter because concepts matter.

On Quora today I saw a question to the effect of: How do I put up with the stupid people I inevitably find myself working with? Here’s my answer:

I consider myself reasonably intelligent, yet I have had no problem surrounding myself with people at or above my intellectual level. I’ve also had good relationships with co-workers at all levels of intelligence. Unless you’re a world-class genius (statistically unlikely), you are probably mis-diagnosing people as stupid.

I’ll assume that you’re not just lashing out at others as a defense mechanism against your own insecurities (although you need honestly ask yourself that). I’ll assume that you sincerely believe that other people are stupid, probably based on finding it difficult to discuss things and agree with them.

But what you’re really evaluating is their judgment. Differences in judgment are rarely due to stupidity—in work, in friendships or in politics. You can’t address the problem until you identify the real cause. Calling everyone “stupid” leaves you with no next steps.

Here’s a guide for what to do instead:

Before you even decide that you disagree with someone, work to understand their judgment. You may not disagree at all. For instance:

• Do you fully understand what they’re saying? Or are you talking past each other?
• Are you answering the same question? Maybe each of you is answering a different angle on the question (e.g., “what’s our next step?” vs. “what’s the long-term solution?”)
• Are you using terms in the same way? Sometimes disagreements come from differing definitions and terminology.
• Are you talking completely in abstractions? Give examples, and ask them for examples, to get clear and concrete.
• Are you both being clear and precise in your formulations? Sometimes people phrase things loosely or talk in metaphors that aren’t meant to be taken literally.

Ask questions, make sure you understand them fully.

If you decide that you disagree, work to understand their thinking process:

• What are the reasons for their conclusion?
• What is their evidence? What observations or data points are they relying on?
• What general premises or lessons do they take to be relevant? What principles, frameworks, or theories are they applying?
• What goals and values are conditioning their approach?

Ask them (and learn to do it without threatening or intimidating them). You may change your mind through the process.

If not, at least you will understand better how to reason with them:

• Have you seen important data that they haven’t? Maybe they missed a key fact, or they just haven’t seen the breadth or depth of data that you have. Inform them and see if they come around.
• Do you have relevant experience that they don’t? Tell them the observations or lessons learned that lead you to your conclusion (without being didactic or condescending).
• Are you bringing different lessons learned from different backgrounds? If so, which context applies, if either? Maybe one of you has mostly worked at startups and the other mostly at big companies. Which context is relevant here?
• Is either of you making an unwarranted assumption? There are lessons learned and then there are “lessons” that you guessed about and forgot to validate through experience or research. If you disagree with their premises, address that directly.
• Are you guided by different goals and values? If so, you’ll reach different solutions to a problem. Get aligned on goals before arguing about problems and solutions.
• Do you subscribe to different relevant theories? If so, you may not be able to resolve the disagreement quickly, and may need to take another approach (e.g., pick anything reasonable and measure the outcome, or let a third party make the decision).

Throughout all of this reasoning, be aware of the emotional context:

• Are they afraid of the conclusion? Maybe it threatens their work, their reputation, or their self-esteem. There’s no excuse for this, but it happens to everyone sometimes. Good people recognize it sooner or later and let their emotions go. Sometimes a close friend or co-worker can get them to see what’s going on by asking sympathetic questions. (Be sure to ask this question of yourself as well.)
• Are environmental stresses degrading their judgment? Time pressure or having your career on the line can make it hard to do your best work.
• Are they intimidated by you? If you really are smarter or better-spoken, they may be swamped by emotions of insecurity that make it hard to think. You may be unwittingly shutting them down, which begins a vicious cycle. Tone it down.

If you disagree with someone consistently over time, consider these potential cognitive and psychological problems:

• They may have good judgment but poor communication skills. If you repeatedly find that you agree after clearing up initial miscommunication, keep this in mind and account for it. It can be frustrating and it takes patience, but it’s better than arguing and they may even appreciate it.
• They may have raw intelligence, but poor thinking habits—patterns of absorbing, processing, and filing information. Cognitively, they aren’t set up to get to the heart of a matter, to distinguish between essential and accidental details, to form and apply valid generalizations. This too may require patience. It isn’t good, but it isn’t willful, irrational, or stupid. Concentrate on what other virtues and talents they bring to the table, such as creativity, diligence, or relationship-building.
• They may have general insecurities that make them afraid of looking stupid or give them a psychological need to win arguments. There’s no excuse for this either, but you can sometimes work with people anyway if they don’t do this too much or too often, or hold onto it for too long.
• They may have a problem with you personally. Maybe they’ve decided that you’re “arrogant” or obstinate. Maybe they know that you think they’re stupid and resent it. In any case, this will make them less likely to listen to you and more likely to argue with you. They may dig in their heels on a particular issue, or just discount your judgment generally. Admit that you’re part of the problem and work to change.

Bottom line: Stupidity explains only a small percentage of people’s disagreements. Calling someone “stupid” is a dead end—you can’t fix it. Instead, figure out what’s really going on.

Some final advice for the workplace:

• Make sure you’re working in an environment that promotes objective decisions. If decisions are made based on personality and emotions instead of data and discussion, it will make everyone “stupid”. Go somewhere else.
• Choose your battles. You don’t have to get your way in every disagreement. Let other people own their work. Fight only on the decisions that are important and hard to reverse.
• Earn a reputation over time through excellent work. This is much more powerful in commanding attention than intellectual prowess.

I didn’t realize I had so much to say on this topic until I started writing the answer. Quora is doing a great job at getting people to write on topics they never would have otherwise—even folks like me who keep blogs.

In the early days of computing, a software application ran on only one hardware system.  Software plus hardware was, in effect, a single, tightly coupled computer system.

High-level languages, operating systems, and hardware standards eventually decoupled software from hardware, allowing applications to run on a variety of PCs.  What was once a single system had split in two, as if by mitosis.  The result was that hardware became a commodity.  Microsoft captured value; PC makers saw their margins squeezed.

Today we are seeing another mitosis, this time within software itself.  The dividing line now is the public APIs published by companies such as Twitter.  Publishing an API decouples features and UI from users and data.

The result: For an online application, publishing an API commoditizes features and UI, without relinquishing ownership of users and data. This is why Twitter’s API strategy was brilliant.  Twitter focused their resources on the core of the system, retaining strategic, defensible assets while outsourcing non-strategic, indefensible ones.

Twitter’s gain from this, virtually for free: a rich variety of client apps, experimenting and competing with UI and features in Darwinian fashion.  There was far more experimentation and creativity than could have occurred within the walls of Twitter itself.  But now, when it’s time for Twitter to own the client and the user relationship (presumably as a critical piece of an ad-based monetization strategy), they can easily acquire popular third-party clients or create their own.

The lesson many Twitter developers are learning: Building clients and “filling holes” on top of a single platform is a fine hobby, but it’s not much of a business strategy.  The best you can do is build a popular client as a one-man shop (i.e., raising little to no capital) and get acquired, as Loren Brichter did.  But there’s also a lesson for Internet apps: publish an API and cultivate a developer network.  It’s a cheap, strategic way to buy a lot of development and innovation.

In business it’s easy to over-focus on the competition.  Knowing the competitive landscape is indispensable; your product has to be differentiated and ideally you are building defensible assets.  But your primary focus must be on the customer or user and the value you create for them.

I was reminded of this today when I read a post by Garry Tan quoting an article on Netscape and how they over-focused on Microsoft.  Garry says that “having an enemy can focus you in intense ways, but might focus you on the wrong things” (and adds that for a startup, “your competitor is the back button”).  I agree.

I’d go further:  It’s wrong to think of competitors as enemies at all.  Business is not war.  You shouldn’t aim primarily to fight your competitors or to hurt them.  The right model is a sport or game: we’re all aiming to be the best in the same field, we play fair according to established rules (law and contract), and at the end of the day, we shake hands and congratulate each other on a match well played.

You should be glad to have competitors: together you form a market that attracts and retains customers.  You should be glad to have competitors who have gone before you: they educated the market on your product category (creating a new product category is extremely difficult).  You should be glad to have good competitors: bad competitors give your product category a bad name.

When you discuss competitors internally, don’t trash them.  Respect them.  Be sportsmanlike.  Don’t be afraid to praise them for what they do right.  Make sure you know what you do better and where you are uniquely positioned to create differentiated value.  Find your confidence in that, rather than in putting down competitors.

Externally, it’s probably best not to discuss competitors at all.  Amazon has a long-standing policy of not commenting on the competition publicly.  It certainly seems like a no-win situation:  If you praise them, you promote them.  If you criticize them, you open yourself to rebuttal.  Either way, you give competitors publicity you could reserve for yourself.  So maybe it’s best to keep your mouth shut.

So go forth and compete, don’t fight—and may the best man win.

Some managers—the pointy-haired boss variety—think their job is to tell people what to do.  They focus on communicating solutions.  If the website is slow, they tell their people to optimize the database queries.  (Hopefully they at least focus on getting alignment with their reports, instead of managing by fiat.)

Better managers focus on communicating problems.  When they have alignment on problems, they query for judgment about the solutions.  They just point out that the website is slow, and they ask their reports how best to fix it.

I think the best managers, the true leaders, focus at a higher level still—on communicating values. When they have alignment on values, their employees are able to identify the problems themselves, and are motivated to solve them.  They communicate ahead of time that a good user experience is important and that performance is part of that.  When the site is slow, their people notice it themselves and know how to prioritize.

Like many of the best management and leadership techniques, communicating values isn’t something you can do at the last minute.  It’s a long, slow process.  You have to start it early and work on it consistently and patiently over time.  It’s not a way to fight a fire.  But it is a way to grow a garden.

When I have 10 minutes or less, I can inform or entertain myself by checking email or Twitter on my iPhone.

When I have 90 minutes and some table space—and preferably wi-fi—I can be productive on my laptop.

Since getting a Kindle a month ago, I’ve found that it’s perfect for that spot in between, when I have around 45 minutes, maybe not much space, maybe no wi-fi—for example, getting lunch by myself in a small cafe. That’s too long to productively do email on the iPhone, but not ideal for working on the laptop, either.

When tablets arrive, what sweet spots will they fill? Michael Arrington wanted one to surf the web lounging on his couch. Web access in small cafes as well? Reading or even writing on buses and trains? It’s possible to use a laptop there, but not always convenient. Presentations and other business meetings in restaurants? I’ve been in meetings recently where someone pulled out hardcopies of mockups or spreadsheets—we both had our laptops, but there was no room for them, and the upright screen on a laptop isn’t ideal for sharing and collaboration across a table.

The top use case for tablets may surprise everyone. Regardless, the winners there—as with any new platform or medium—will not be those who simply bring old experiences to a new space, but those who embrace the differences of the new space and create new experiences there that don’t work elsewhere.

Google: “The information is out there, we just have to crawl it and index it.”

Amazon: “The data lies in user behavior, we just have to apply the right machine-learning technique.”

Facebook: “If we make it fun, users will enter the data themselves.”

Twitter: “If we build an API, third parties will solve the problem and all the data will just flow through our system.”

How do you get your data?

(PS: People who don’t have an answer to this question yet: most of the social-recommendations apps, all the semantic web guys)

A few things I’ve read lately state or imply that developer experience is what drives platforms.  Paul Graham says: “If programmers used some other device for mobile web access, they’d start to develop apps for that instead [of iPhone].”  Dharmesh Shah says explicitly: “What drives these technology cycles [thin client, thick client] as much as user experience is the developer experience.”

I disagree.  I think user experience drives platforms.

A software platform is a bipartite network of developers and users, with classic bipartite network effects:  Developers want their apps to have the most users possible; users want the platform with the most/best apps.  In many (all?) such networks, one side dominates and controls the network; the other side follows them and often pays all the costs of the matchmaking.  Sellers go where the buyers are.  Companies spend tens of thousands of dollars per hire to get the best candidates.  Men go to the bar or dating site with the most interesting women.

I’m not sure what determines which side of a network will dominate.  It doesn’t seem to be based on which direction the money is flowing (or whether there’s money involved at all).  I suspect it’s based on how many matches each side is looking to make, and how fungible they consider the other side to be.  In commerce, in particular, each buyer is looking to buy one or maybe two cars, let’s say, and the decision matters a lot to him, whereas each dealer is looking to sell many cars, and doesn’t care so much whom he sells to—all dollars are the same.

In software, I think users dominate the network.  Software is primarily an industry; every company has to calculate the ROI of development effort against each platform, and will ultimately choose the platform that gives them the most customers or users.  Even hobbyists are motivated by attention and appreciation; they may not care about making money, but they want their software to be used and liked.  Thus the same bipartite network effects are in play.  (Those who are creating software purely as a personal project are a small minority, isolated by definition, and don’t drive the market.)

So users will go to the platform that has the best user experience, and developers will follow.  Otherwise, why have so many applications been written for Windows?  Most software engineers prefer the Unix development environment.  But Unix, written by and for software professionals, dominates only in the server market, where the users are technical people—developers and admins.  (Graham claims that “Our horror at that prospect [of developing for Windows] was the single biggest thing that drove us to start building web apps.”  But I find it hard to believe that this was the primary driver, rather than free distribution, rapid iteration, and all the other benefits of apps in the cloud.)

Apple’s platform strategy with the iPhone was exact:  First, build a large user base without relying on third-party apps—just by building a better phone. Then, once it’s the hottest device on the market, open the platform to developers.  Now, by writing for one device, developers are on a platform getting 100 million downloads a month, several times the rate on other platforms.  The consequence is that as much as developers hate the App Store and its review process, they will continue to develop for iPhone until another platform gives them the same ROI.

The only hope for Android or any other platform is to appeal not to developers, but to users.  Like the downtown bar that offers ladies’-night specials in order to attract the men, attract the users and the developers will follow.

Sean Ellis is blogging again.  I like his blog and his approach, “based more on observing universal truths than inventing some type of methodology.”

His latest post summarizes a lot of what he (and Steve Blank and Eric Ries) have been saying lately.  The whole thing is worth reading, but since it’s long (over 1500 words), here are some highlights.

Ellis recommends finding your “core gratifying experience” early on:

Your objective should be to remove complexity from the initial user experience and messaging in order to highlight this core user perceived value.  Often this means burying or even completely eliminating features that don’t relate to this gratifying experience. [Emphasis added.]

On metrics:

Metrics don’t matter until you achieve product/market fit – then they are critical to your success. . . .  Most of the tools out there provide way too many irrelevant metrics and miss the essential few.

On “extreme customer support”:

Now that you have a business model in place, your first marketing expense should be to expand the customer support team.  Anyone that cares enough about your solution to contact customer support is a great source of insight about your target market.

On building a great customer experience:

While startups often realize the importance of brand experience, they focus on it too early, fine tuning things that customers don’t care about.  Instead, wait until you understand why certain customers love your product; then obsess over every element of this customer experience.

Go read the whole thing.

After yesterday’s post, I found some other folks who have written about the cycle between smart/dumb terminals, thick/thin clients, and centralized/decentralized computing.

Dharmesh Shah wrote “The Thin Client, Thick Client Cycle” at OnStartups in 2006: “One of the repeated cycles I have seen in my 15+ years in the software industry is that we constantly go through this ‘thin client / thick client’ cycle.”  He seems to disagree with what I suggested yesterday, that Web application technology (including JavaScript) might end the cycle, saying:

My thesis now is that we are due for another cycle.  Why?  For the same reason we had the prior cycles:  Because there are still problems with the current model.  User interfaces for true “thin client” applications basically suck. . . .  The problem goes back to the platform . . .  If I were looking to reproduce the user experience of even relatively trivial desktop applications today on the web, it’s hard.

Unclear whether Dharmesh really disagrees with my hypothesis, or if he’s just saying that the developer tools and platforms will evolve to make writing good Web apps much easier.  (He claims, though, that: “What drives these technology cycles as much as user experience is the developer experience.”  Paul Graham implied the same thing in his recent essay: “If programmers used some other device for mobile web access, they’d start to develop apps for that instead.”  I think I disagree, but that’s a post for another time.)

More recently, Hal Pomeranz wrote that “the whole Cloud Computing story felt just like another turn in the epic cycle between centralized and decentralized computing” (“Future Cloudy, Ask Again Later” at Righteous IT, Feb 2009).  He seems to agree with a point I made about the past cycles being driven by economics:

The centralized vs. decentralized cycle keeps turning because in any given computing epoch the costs of all of the above factors rise and fall.  This leads IT folks to optimize one factor over another, which promotes shifts in computing strategy, and the wheel turns again.

Finally, I found a scholarly paper on the subject from 1999 titled “Centralization/decentralization cycles in computing: market evidence” (by D. A. Peak and M. H. Azadmanesh).  Abstract:

Strategies concerning centralized and decentralized commercial computing have been major issues for more than two decades. Using longitudinal sales data consolidated into three major computer categories (mainframes, minicomputers, and microcomputers), we investigate whether historical market data show evidence of centralization and decentralization. Our finding of cyclic behavior leads us to conclude that computing sales data exhibits broadly cyclic characteristics. We suggest that computing strategies oscillate unevenly between domination of centralization and decentralization, and that commercial computing has already experienced two centralization/decentralization cycles. Currently, computing is nearing the end of the second cycle’s decentralization period and is at the threshold of centralization in a third cycle.

Maybe the most important question to ask is:  Why are so many of us in the industry so ignorant of its history?  At least, I feel woefully ignorant of computing history, and I bet I’m not alone.  As with political history in the US today, it seems that most of us only know the history that we lived through.

Anyone know a good source for an overview of the history of the industry, that would cover major trends such as this one?