Category: ProductManagement

Marketing killed the telephone. Is it killing email?

I still have a landline telephone, albeit reluctantly. While it’s theoretically useful to have a phone number where we can be contacted at home, the theoretical usefulness of this concept is destroyed by the mounting avalanche of calls that promise to lower our credit card bills or switch us to a different electrical provider, to say nothing of the hangups, the “hello? are you there?” calls, and the well meaning seekers of local office. Of course all of the above come from our area code and exchange, meaning that it’s impossible for us in a thirty day period to tell whether the call coming through is from our child’s school or from a telemarketer using neighbor spoofing to look like they’re calling about something of local interest.

This is old news. I would guess that if you’re under 50, the only reason you have a landline is that it came as a bundle with your internet and TV service. (That may be the only reason you have old-fashioned TV as well.)

But what I’ve watched with dismay over the last few years is the mounting marketing avalanche that seems determined to kill my email inbox, just like it did my landline.

Oh, don’t get me wrong. I’m not talking about enlargement spam, or any of the other overt pests that used to fill our mailboxes. By and large, modern mail services and mail clients take care of that.

I’m talking about aggressive email marketing campaigns from companies that I actually do business with.

I have no idea why I receive three copies of newsletters from that bow-tie company in Vermont (though I suspect having filled in a different forwarding address somewhere along the way has something to do with it) or four copies of every email from Organizing for America. At least the latter is entertaining, since you can sometimes watch them test different optimizations for the subject line. But five or more emails a week from the kitchen store or the online music store, none of which reflect my interests or purchase history, seems to me like a bridge too far. 

That’s even before you count all the emails going to stupid people who think that my Gmail address is theirs. I’m looking at you, Teresa Jarrett and Taijah Jarrett and Ted Jarrett and all the other people who just can’t remember that they don’t have their first initial plus their last name at gmail dot com.

It adds up. I’m regularly deleting more than 50 emails a day unread. It’s worse sometimes when Teresa or Taijah or Ted sign up for a site that does its own marketing emails.

What kills me about this is that the failure of this communication channel that’s been a locus of my personal and professional interest my entire adult life is caused by the same thing that killed my landline. It’s marketing gone amok.

I have done marketing (of a kind) for a living, and I know the pressure of building the “top of the funnel.” The problem is that you can touch a heck of a lot of people at the top of the funnel and make your marketing numbers look great, only to have none of those people convert into business because they weren’t ever really interested in your product to begin with. But the challenge is that if you go the opposite route and try to target too precisely, then you’re dealing with the kind of surveillance technology that gives Internet marketing a bad name.

So what are you going to do? Well, it turns out there are a few sites that I regularly get email from where I actually read the emails. Religiously. Even though they update a couple times a week. Discogs is one, because it emails me about things that are relevant to my vinyl collection and my extended interests. But that’s information I gave them, not that they observed by watching over my shoulder. I think that’s the key — the information sharing has to be consensual and I have to get some genuine value from giving away my data. 

Improving PM, part 2 – When not to listen to customers

This is part of a short series about the talk I gave at Product Camp Boston, entitled “Getting Better at Getting Better: A PM Kaizen.” A general introduction to the talk is here and you can view the slides.

The hardest thing for me as a PM has been to learn how to listen to customers, and when not to.

I know, I know. Customer centricity is a key tenet for growth, if you don’t listen to customers you die. But I’d argue that you can get yourself in real trouble if you listen to customers too much, or listen the wrong way.

Here’s the thing. Customers will tell you really important things about how your software works, or doesn’t work, for them. But sometimes you have to really dig for the key information. I can’t count the number of times that a customer request came into my email, passed along by a well-meaning co-worker, that when I dug in turned out to be a completely different issue.

The reason is that we all try to solve our own problems. Customers know their workflow better than anyone else, and so as they think about something that irks them about your software, they’ll consider lots of possible ways to solve the problem within what they understand to be the constraints, and discard the ones that won’t work for them. Then they’ll think of other problems and revise their solution, and ultimately pass along a solution that is so specific to their use case that it may actually not solve the problem for other customers, and may even create new problems.

So I tend to follow the rule of Five Whys. Because what is tremendously valuable is understanding the root cause, the underlying customer problem, that sparked the communication in the first place. Sometimes customers are inspired to identify good solutions, but often their understanding of the constraints, lack of knowledge of other features you have in your roadmap (or under development), or thought process constrained by their local environment results in partial workarounds that don’t solve the root issue.

So much for the microcosm of customer feature requests. What about your roadmap? Surely that should be customer centric?

Well, to a point. But you have to be keenly aware of who the customers are who are influencing your roadmap and who they represent—and what stage your product and your market are in. I find the Crossing the Chasm model helpful for understanding this part. A lead customer for a pre-chasm offering, or a mainstream customer for a post-chasm offering, can provide helpful feedback. But if you’re in the middle of a market disruption, listening only to your existing customers can be a recipe for disaster.

That goes double for when you get successful. Large software product teams get very good at listening to their existing customers, and miss out on the customer pain points that lead some prospects to choose other solutions. If you couple the crowded PM calendar with lots of feedback from existing customers, you can get into a trap of the Urgent Now and miss the signals that your market is shifting.

So how do you stay focused on longer term, bigger picture problems? How do you avoid being dragged into that tire fire in your inbox? It turns out that the tools you need to stay focused on the right things may be closer to hand than you think.

Improving PM, part 1: the calendar

This is part of a short series about the talk I gave at Product Camp Boston, entitled “Getting Better at Getting Better: A PM Kaizen.” A general introduction to the talk is here and you can view the slides.

The number one complaint I hear from PMs is the tyranny of the calendar. “There’s no time.” “I’m in meetings all day, all week.” “I’m staying until 8 to get work done.” “I’m logging in after the kids are in bed and staying up until 2.” “Let’s meet, two weeks from now when I have free time.”

The net result is a calendar like the above, with about three or four free hours scattered throughout a work week. There are all kinds of problems with this way of working. One of the worst problems is something I recognized first in working with building software for developers, and that I recognize in my own calendar: the time to build context.

Knowledge workers, like software developers and product managers (and marketers and others), rely on an understanding of the context in which they’re doing their work to be effective. As a software developer, you can’t effectively debug a problem unless you first build a mental model of how that part of the software works. That’s time-consuming, and if you’re interrupted you have to start all over again. (There’s a great illustration of this challenge for programmers by Jason Heeris.) And for some PM work—strategy, building roadmap, understanding user problems—you need that mental model time too. A half hour or hour here or there doesn’t really cut it.

But many PMs that I know are achievement oriented. We like to make lists and check off items. So what do we do? We spend all our downtime getting stuff done. It isn’t the strategic important stuff that needs a half hour of context building, because we don’t have time for that. It’s responding to email, putting out fires in inboxes, answering customer feedback.

The strategic, in other words, gets crowded out by the tactical.

There are many ways you can solve for this problem. One of them, which I heartily recommend, is becoming more effective at saying “no.” That has its own challenges. You can just say “no” and leave the requester with no way to fill that request. Unless you’re uninterested in the welfare of your customers and the bottom line of your company, that’s often not behavior that maximizes long-term outcomes. So you may find yourself trying to understand the breakdown in the system that led that person to your desk and left you as the only person in the organization that can help them solve their problem, and suddenly you’re back to square one.

If you’re good at saying no when you can, and diagnosing organizational breakdowns when you can’t AND taking steps to shift the permanent solution elsewhere in the organization, then that’s an effective way to keep your calendar clean. That means, though, that “just saying no” isn’t really within reach for most PMs.

So what’s the alternative? I would argue that we have to find a way to systematically think about our work, in such a way that we don’t constantly have to reconstruct our context before we can move the work to the next step. I’ll discuss this more next time.

Follow up reading: The challenge of being “the only person in the organization that can help solve the problem” is covered extensively in the writings of W. Edwards Deming; he calls the process of finding these “only people” identifying the constraint in a process, and recommends that you find ways to elevate the constraint by redesigning the process so that it is subordinate to the constraint. There’s some practical discussion about elevating constraints in the context of software development and IT in the classic DevOps novel The Phoenix Project.

 

Getting better at getting better

On Saturday I attended my first ever Product Camp Boston. This event, an unconference devoted to product management and product marketing, was massive in terms of attendance (over 500) and content covered (some 58 sessions). I was fortunate enough to nab a speaking slot. I debated what to speak about, and ultimately ended up giving a talk on applying agile scrum to the work of product managers to help a team improve their PM craft.

About now my non-engineering friends and family are looking at me with a little white showing in their eyes, and my engineering savvy readers may be skeptical as well. But I’ve written about this idea before in the context of agile marketing, that by committing to work up front for a limited period of time, documenting what we work on, publishing what you achieved, and being purposefully retrospective (what went well, what didn’t, what will we change), we can improve our effectiveness as individuals and teams.

For PMs the big payoff is in slowly transitioning out of firefighting mode and into bigger-picture thinking. It’s too easy to succumb to the steady pull of today’s emergency and tomorrow’s engineering release and lose strategic focus. Our kaizen has given me the ability to think farther ahead and be more purposeful about the work I take in.

I’ve posted the slides for the talk, and will write a little more about this topic soon.

“One thing”

Rands in Repose: One Thing. A good description of some of the psychology behind the Deming principle of minimizing work in progress.

You cross the threshold of inbox usefulness when you begin to mistake the act of managing the importance rather than acting on the importance. Speaking as a human who has crossed this uselessness threshold multiple times, I am prepared to declare that I am 100% done with productivity products. There is a better, simpler, and more productive way.

“Uncontrollable innovation”

New York Times: Why Samsung Abandoned Its Galaxy Note 7 Flagship Phone. Like John Gruber, I am curious about the closing quote, from Park Chul-Wan, the former director of the Center for Advanced Batteries at the Korea Electronics Technology Institute:

“The Note 7 had more features and was more complex than any other phone manufactured. In a race to surpass iPhone, Samsung seems to have packed it with so much innovation it became uncontrollable.”

Uncontrollable innovation? That’s an interesting claim.

I think the thing that’s forgotten here, as in so much of the smartphone feature war, is that features aren’t useful if they can’t be used, or safely manufactured, or if they don’t meet a customer need.

It doesn’t sound to me like the problem was out of control innovation. It sounds to me like the problem was an engineering culture that created a product that was untestable, and a management culture that made it impossible to react rapidly to new developments in the marketplace.

On the airing of security grievances

I had a great day yesterday at DevOpsDays NYC. I gave a talk, but I also learned a lot from the other speakers and from the conversations. The format of DevOpsDays is half traditional conference with speakers, half “unconference” with open proposals of discussion topics and voting to establish which topics go where. They call it Open Space, and it’s a very effective way to let attendees explore the conversations they really want to have.

I proposed an Open Space topic on the “airing of grievances” around information security. What emerged was really interesting.

Attendees talked about companies that confused compliance and security, with disastrous results (hint: just because your auditor counts you compliant if you have a WAF with rules, doesn’t mean that those rules are actually protecting you from attack).

We talked about advances in declarative security, in which you could specify a policy for which ports should be open and closed via tools like Inspec.

We talked about the pains of trying to integrate legacy appsec tools into continuous integration pipelines (which happened to be the subject of my talk). I heard about people trying to integrate on-premise static analysis tools into their Jenkins toolchains when the application caused the scanner to exhaust all the memory on the machine. About on-premise dynamic scanners that run for eight hours. About the challenges of determining if an attack has successfully made it past a web application firewall.

And then Ben Zvan said (and I paraphrase), “We have a man-in-the-middle firewall (proxy) between our desktop network and the Internet that screws with security certificates, so I can’t use services that rely on certs for secure communication.”

And the floodgates opened. I talked about the secure mail gateway, intended to prevent phishing, that pre-fetches links in emails and thereby breaks one-time-use links intended for secure signup to new services. We talked about endpoint protection tools that can’t keep up with the MacOS update schedules, and thus make the user choose between taking the OS update and having the endpoint protection tool break, or not taking it and remaining at risk of exploitation of a dangerous newly-announced vulnerability.

The conclusion that we reached is that it’s a deadly dangerous irony that security tools actively stomp on security features, but it’s also the new reality. The complexity of the information security toolstack increases every year, with more and more vendors entering the space and CISOs being forced to become system integrators and figure out which tools conflict with which.

The lesson is clear: If security solution providers are serious about security, they need to build for reduced complexity.

The Trap of ‘First’

Keith Houston, I Love Typography: The Prints and the Pauper. Otherwise sound history of printing that falls into the classic rhetorical trap: can we call Johannes Gutenberg the “father” of printing despite the fact that he didn’t invent movable type?

This is the same sort of rhetorical trap that lots of otherwise smart people in technology fall into all the time. I call it the Trap of ‘First’: the assumption that just because you are first to think of, or even implement, something, you should get special credit and deserve special success.

I should know about the Trap of ‘First’, as I was a longtime victim of it. For years I believed, like many Apple fans, that the slew of inventions that came out of Apple during the late 1980s and early 1990s made them more deserving of market success than Microsoft. “But they did it first!” I’d howl: about window based operating systems, computer video, smooth on-screen type, really anything you can imagine.

What I’ve come to understand is that there’s as much value generated in innovating on someone’s solution than in (merely) inventing it in the first place. Look at the iPod. There were certainly other MP3 players on the market. But the unique combination of great UI and (most importantly) the iTunes Store made the iPod the first one that really filled the customer’s need.

Houston points out that early Chinese innovations in printing preceded Gutenberg by hundreds of years. He correctly also points out that they were unwieldy (requiring over 60,000 unique woodblocks), produced poorly legible pages (thanks to the water-based Chinese calligraphic ink that didn’t adhere well to the woodblocks), and generally uneconomical (only printing on one side of the page thanks to the delicate Chinese paper; woodblocks had to be cut by hand rather than cast from reusable metal molds).

Gutenberg’s press, incorporating innovations not only in movable type but also in creating methods to mass produce it and create legible pages with it, was not the first, but I’d argue that is beside the point. The point is not to be first, but to solve enough of the problem that your solution is worthwhile. Hence why “first mover advantage” … often isn’t.

Ripping off the bandaid

Daring Fireball: “Courage.” John Gruber takes a run at the other side of the argument for removing headphone jacks from the iPhone 7 and 7 Plus. Basically, the argument boils down to this: no one is outraged that the future isn’t coming fast enough. As Gruber says:

When we think of controversial decisions, we tend to think of both sides as creating controversy. Choose A and the B proponents will be angry; choose B and the A proponents will be angry. But when it comes to controversial change of the status quo, it’s not like that. Only the people who are opposed to the change get outraged. Leave things as they are and there is no controversy. The people who aren’t outraged by the potential change are generally ambivalent about it, not in a fervor for it. Strong feelings against change on one side, and widespread ambivalence on the other. That’s why the status quo is generally so slow to change, in fields ranging from politics to technology.

Whether you like change or not, it’s important to recognize that there may be benefits that you will forgo by avoiding change. This is any technology product manager’s dilemma: when do the potential benefits justify taking a stand and being an advocate, against the outrage of the proponents of status quo?

I have run into this a lot with big decisions and small. One common version of this is browser support. In enterprise applications it’s historically been a big deal to end support for older browsers. Enterprises like their old technology, because it works just fine, performs its business function, and carries a cost to replace. Unfortunately, that was especially true for web applications that only worked in various versions of Internet Explorer. Thankfully, the industry as a whole got enough courage in the last few years to stand up and advocate for a future in which coddling a poorly behaved, insecure browser with no support for modern standards would no longer be necessary, which makes taking a stand as an individual easier. But when you’re the only one taking the stand it becomes harder.

Me? When I go to iPhone 7, I’ll be using the Lightning to audio jack adapter that comes in the box. I have a nice pair of B&W P3s that I’m not ready to replace yet. But I’ll be looking at wireless headphones the next time I am.

The Whole Product

One of the key concepts that’s stuck with me after reading Crossing the Chasm, Geoffrey Moore’s pivotal book about marketing high-tech products in a world in which buyers react differently to innovation, is the concept of the whole product. It’s one that a lot of product companies, especially those that focus closely on the technology side of product development, don’t get, very much to their detriment.

“Whole product” simply means that which is required to address 100% of a customer’s need. Counterintuitively, it’s almost never met simply by a technology product (the “generic product”), but typically requires partner products, services and other pieces to fill in the gap. Moore cites the example of a web browser as an example of a generic product, and the web browser plus plugins, HTML5 applications, an internet service provider, a search engine, and an easy way to buy goods online as the whole product.

How do otherwise smart product companies fall into the trap of ignoring the whole product? Sometimes it’s just a question of not thinking hard enough about what the customer needs. A customer usually doesn’t need a new Android phone with a high megapixel camera; they need to take better pictures of their kids. So instead of competing solely on megapixel count and similar tech specs, whole product companies will invest in technologies to give the customers a better fit to their ultimate goal, such as image stabilization, easier ways to transfer the photos off the phone, system-wide easy access to photos so they can be shared, the ability to create books and calendars of the photos, and so forth.

But it’s so easy to fall into the “speeds and feeds” trap and not understand where the customer’s full needs are. It’s also easy to misjudge the needs of the customer and misunderstand that something that seems like “just another feature” is actually part of the whole product. Thus, the art of product management and product marketing.

Notes on updating an iPhone in 2016

If you’ve read my blog (and I imagine the three of you currently doing so have done so before), you know I’m an Apple guy of long standing. Of course I was watching the keynote where they announced the iPhone Upgrade program, in which you can update to a new phone every year for a moderate monthly payment with no carrier contract*. But I didn’t fully undersand how the program worked.

Historically, I’ve been on the S cycle for iPhone upgrades, starting with the 3GS, and with a January upgrade date. So I went to the Apple Store to get the scoop on the Upgrade program. Here’s what I learned (or re-learned):

  1. Subsidized iPhones are a thing of the past, at least for the high end models. You used to pick a price point ($199, $299, $399, whatever) and accept a two year contract with the carrier. But that’s a thing of the past. You can basically choose either to pay full price for the phone (starting at $649), or you can pay a monthly fee either to your carrier of choice or to Apple. Net result: you pay more, because your data plan isn’t correspondingly cheaper.
  2. I am paying for too much data. I have a legacy AT&T Unlimited data plan, but I only ever use about 2.7GB of data a month, based on a year’s worth of usage data. I could save a chunk of change by rebalancing my data plan, almost enough to pay the monthly charge for the phone.
  3. There are good reasons to rent your phone from Apple rather than the carrier. For one, the phone you get from Apple is carrier unlocked, meaning you can switch to a different carrier. For another, the monthly price to Apple includes AppleCare.
  4. It’s harder to avoid getting the high end model. My iPhone 5s was 64GB. I could mostly live with that, even with using it as an iPod for a lot of losslessly-ripped music. But I got the 128GB iPhone 6s, because the price difference was basically a latte a month (around $4).

The model has some interesting implications, not least of which the shifting of the accounting for Apple to a recurring revenue model (more predictable), the likely change in Apple’s device mix to higher end devices, an improved customer service model (imagine how much happier Apple’s customers would be if all of them had AppleCare!), and more.

But for now, I’m just excited for a new device. W00t!

Default to the right thing.

One of the things that makes me nuts is when a product gets the default settings wrong and makes me do work to make it do the right thing.

This happens more often than you’d think. Example 1: the stereo in my new car. I love the GTI for a lot of things, including the ride and the compactness of it. But I am really growing to dislike the way they did the stereo. Why? The default behavior when I turn on the car. It should remember that when I turned it off I was listening to music through the phone (either Bluetooth or the dock connector) and go back to that channel. But it doesn’t. Instead, its logic seems to be:

  1. There’s nothing on the dock connector!
  2. There’s nothing on Bluetooth!
  3. So let’s go back to the other thing we were listening to–the satellite radio.

Except, the reason there’s nothing on Bluetooth is that it takes about 30–45 seconds to pair a phone with the car, and the designers surely knew that. So why wouldn’t they just have step 2 wait for a while? That way I wouldn’t have to fiddle with the settings every time I get in the car.

(Why don’t I just plug the phone into the dock connector before I start the car? That works for about 30–45 seconds; then when the Bluetooth connection is established, the phone gets confused and stops playing back through the dock connector!)

The problem with this scenario is that it’s not obvious when you look at any of these pieces that they’re wrong. When you consider the component level, any of a number of choices look like they could be the right one. It’s only when you stitch them all together, and think about how the user would use them, that the right behavior becomes apparent.

I’m pretty sure there’s a product management law that describes this principle, something like don’t make me do more work than I have to. But it’s astonishing to me how often people, and products, get it wrong.

Ten year lookback: the Trustworthy Computing memo

On the Veracode blog (where I now post from time to time), we had a retrospective on the Microsoft Trustworthy Computing memo, which had its ten year anniversary on the 15th. The retrospective spanned two posts and I’m quoted in the second:

On January 15, 2002, I was in business school and had just accepted a job offer from Microsoft. At the time it was a very different company–hip deep in the fallout from the antitrust suit and the consent decree; having just launched Windows XP; figuring out where it was going on the web (remember Passport)? And the taking of a deep breath that the Trustworthy Computing memo signaled was the biggest sign that things were different at Microsoft.

And yet not. It’s important to remember that a big part of the context of TWC was the launch of .NET and the services around it (remember Passport)? Microsoft was positioning Passport (fka Hailstorm) as the solution for the Privacy component of their Availability, Security, Privacy triad, so TWC was at least partly a positioning memo for that new technology. And it’s pretty clear that they hadn’t thought through all the implications of the stance they were taking: witness BillG’s declaration that “Visual Studio .NET is the first multi-language tool that is optimized for the creation of secure code”. While .NET may have eliminated or mitigated the security issues related to memory management that Microsoft was drowning in at the time, it didn’t do anything fundamentally different with respect to web vulnerabilities like cross-site scripting or SQL injection.

But there was one thing about the TWC memo that was different and new and that did signal a significant shift at Microsoft: Gates’ assertion that “when we face a choice between adding features and resolving security issues, we need to choose security.” As an emerging product manager, that was an important principle for me to absorb–security needs to be considered as a requirement alongside user facing features and needs to be prioritized accordingly. It’s a lesson that the rest of the industry is still learning.

To which I’ll add: it’s interesting what I blogged about this at the time and what I didn’t. As an independent developer I was very suspicious of Hailstorm (later Passport.NET) but hadn’t thought that much about its security implications.

Five things I learned from Steve Jobs

Steve jobs think different

Last night’s news about Steve Jobs hit me hard. Not that it was a surprise; Steve was the one CEO I know who was most in touch with, and open about, his own mortality. Of course that was out of necessity; it’s hard to sweep pancreatic and liver cancer under the rug. But Steve’s response to it was like so much else: instead of ignoring it, he acknowledged it while publicly focusing on where things were going next.

It made me think about the lessons I carry with me as a product manager, and I suppose as a person, that are directly traceable to Steve:

Thing 1: Always look forward

Steve, and Apple as his company, never hesitated to sacrifice backwards compatibility or even whole product categories if they sat in the way of something better. Viz: a whole long list of things–the 3.5″ floppy drive (which Apple helped popularize), ADB, SCSI, and even hard drives and optical media (on the MacBook Air, at least). PowerPC support. Mac OS Classic.

For most of this list, I don’t think we miss the items. And certainly we couldn’t have the products that we have today if Apple had continued to hold onto the older standards past their sell-by dates. By contrast, it’s inconceivable to me that my HP work laptop, just a year old, has a 9 pin serial port. Really? I would bet that not one in 10,000 users has any use for that port. What a lot of money and engineering QA time they’re wasting including that port in every laptop they ship.

I think one of the hardest things to do as a PM is to recognize the things that are standing in the way of your success, especially if they’re features, technologies, compatibility points, that your customers are using. Steve Jobs’ Apple was always the evidence that if done correctly, moving beyond outdated features and standards could have enormous payoffs for you and your customers.

Thing 2: Do fewer things better

When I was a young developer, just starting out, I wanted to make everything I did like the Mac. I wanted to simplify, to reduce the number of options, to make everything clean to use. It turned out to be really hard, and to require a lot of engineering to make things clean and to just work right. But it was almost always worth the payoff.

As a product manager, it’s a lot harder. Instead of keeping a user interface simple, you’re keeping a product offering simple. But again, the payoff is enormous: having an offering that does something so well that it blows everyone’s mind is so much better than a kitchen sink offering that is “just good enough” to check boxes on someone else’s feature chart. There’s time to expand to other areas of the feature chart, if you want to, but make sure they’re done well first.

Thing 3: Think big

The iPod was never about selling hard drive based music players. It was about turning a corner in so many ways: getting Apple into the selling-content-online business, which became the App Store business a few years later; changing how people consumed music, which arguably saved the music industry from Napsterization (though I suppose few RIAA members would stand up and thank Steve for doing so); even transforming Apple from a computer company into … well, how would you characterize Apple today? Maybe a personal computing device company?

Everybody else’s iPod follower was about selling hard drive based music players. There wasn’t a broader vision about changing the market, the customer’s behavior, or how the company was oriented. No wonder they all flopped.

Thing 4: Emotional connections matter

In technology this is such a weird perspective to have. These things we build, they’re just chips and transistors, right? Just bits. But to the people using them, they’re about getting things done that, if they’re worth doing, have a real impact on their lives. Carrying your music anywhere you go. Connecting the Internet to you in the palm of your hand. Creating a great reading and video experience in the iPad. Making computing so simple a four year old could do it. Connecting people in real and tangible ways.

Talking about features, clock speed and such, doesn’t cut it. This is one area where watching the post-Steve Apple will be telling. There was a fair amount of clock-speed talk in the iPhone 4S rollout, and maybe there should have been a little more storytelling.

Thing 5: Life is short; ignore the haters

I think this last one goes to the question of Steve’s awareness of his own mortality. He summed it up in his 2005 commencement address at Stanford, a year after his initial diagnosis of pancreatic cancer, in which he said:

No one wants to die. Even people who want to go to heaven don’t want to die to get there. And yet death is the destination we all share. No one has ever escaped it. And that is as it should be, because Death is very likely the single best invention of Life. It is Life’s change agent. It clears out the old to make way for the new. Right now the new is you, but someday not too long from now, you will gradually become the old and be cleared away. Sorry to be so dramatic, but it is quite true.

Your time is limited, so don’t waste it living someone else’s life. Don’t be trapped by dogma — which is living with thae results of other people’s thinking. Don’t let the noise of others’ opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.

Steve, we owe you a lot, but maybe more than anything else, we owe you for that.