“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 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.

The market failure of application security

Part 1 of an as yet indeterminate number of posts about why application security has historically been broken, and what to do about it.

Software runs everything that is valuable for companies or governments. Software is written by companies and purchased by companies to solve business problems. Companies depend on customer data and intellectual property that software manages, stores, and safeguards.

Companies and governments are under attack. Competitors and foreign powers seek access to sensitive data. Criminals seek to access customer records for phishing purposes or for simple theft. Online vigilante groups express displeasure with companies’ actions by seeking to expose or embarrass the company via weaknesses in public facing applications.

Software is vulnerable. All software has bugs, and some bugs introduce weaknesses in the software that an attacker can use to impact the confidentiality, integrity, or availability of software and the data it safeguards.

Market failure

The resources required to fix software vulnerabilities are in contention with other development priorities, including user features, functional bugs, and industry compliance requirements. Because software vulnerabilities are less directly visible to customers than the other items, fixing them gets a lower priority from the application’s business owner so fixing them comes last. As a result, most software suppliers produce insecure software.

Historically, software buyers have not considered security as a purchase criterion for software. Analyst firms including Gartner do not discuss application security when covering software firms and their products. Software vendors do not have a market incentive to create secure software or advertise the security quality of their applications. And software buyers have no leverage to get security fixes from a vendor once they have purchased the software. The marketplace is not currently acting to correct this information asymmetry; this is a classic market failure, specifically a moral hazard failure, in which the buyer does not have any information about the level of risk in the product they are purchasing.

So the challenge for those who would make software more secure is how to create a new dynamic, one in which software becomes more secure over time rather than less. We’ll talk about some ideas that have been tried, without much success, tomorrow.

Catching up

I’m starting to become that guy that I always laughed at at the office–staying up late working while the wife and family go to sleep around him. It isn’t that funny when it happens to you, though.

We’re in the final run to a big release, coming out in a week, and the days are packed between now and then–getting ready for my webinar tomorrow, two back to back big demos next week, lots of work coming on the horizon. I love this feeling when I’m on the cusp of a lot of big things happening, but already I’m looking forward more to beginning the next phase of work than I am to the release. There’s just so much waiting to be built. Maybe that’s why I never took to product marketing. I like building things more than talking about them.

Doing secure development in an Agile world

My software development lead and I are doing a webinar next week on how you do secure development within the Agile software development methodology (press release). To make the discussion more interesting, we aren’t talking in theoretical terms; we’ll be talking about what my company, Veracode, actually does during its secure development lifecycle.

No surprise: there’s a lot more to secure development in any methodology than simply “not writing bad code.” Some of the topics we’ll be including are:

  • Secure architecture — and how to secure your architecture if it isn’t already
  • Writing secure requirements, and security requirements, and how the two are different.
  • Threat modeling for fun and profit
  • Verification through QA automation
  • Static binary testing, or how, when, and why Veracode eats its own dogfood
  • Checking up–internal and independent pen testing
  • Education–the role of certification and verification
  • Oops–the threat landscape just changed. Now what?
  • The not-so-agile process of integrating third party code.

It’ll be a brisk but fun stroll through how the world’s first SaaS-based application security firm does business. If you’re a developer or just work with one, it’ll be worth a listen.

What’s the difference between iPhone and Android?

I work with iPhone users and Android users. I see no end of technology demos from both. It’s clear both phones are wonderful devices capable of doing amazing things.

So why do iPhone reviews make it sound like the device can walk on water, while a lot of Android reviews sound like this?

Unfortunately, these groundbreaking features come with enough fine print to give the White Pages an inferiority complex.

First, the screen… you can’t have a big screen on a small phone. The Evo is nice and thin, but it’s also tall and wide. It is not for the small of hand. People might mistake it for an iPad Nano.

The Wi-Fi hot spot business is slick…. this feature eats through a full battery charge in as little as one hour. (More on the Evo’s amazing disappearing battery in a moment.) And beware: the hot spot feature costs an extra $30 a month.

O.K., so what about Flash? … The Evo runs something called Flash Lite, which is marketing-ese for, “Sometimes works and sometimes doesn’t.” It plays videos on some sites that the iPhone can’t — on Engadget, for example, plus all the blinking ads (a mixed blessing). But it still can’t play the Flash videos on CNN.com or, sadly, TV shows on Hulu.com.

All right, what about video calling? Surely this is the killer app. Imagine: your friends and family can not just hear you, as with normal phones, but see you as well (assuming they also bought Sprint Evos, of course).

Well, let’s hope they’re NASA engineers, because this feature is head-bangingly unstable….

And this?

There’s a sense, not just from reviewers, but from fans of the device, that what Android really needs is just killer hardware.Which is just absolute horse shit.

Android is an asshole of an operating system.

… I discovered software I could find no way to uninstall; programs which hung around after I was done with them with no way to quit I could find; interfaces which featured tiny poorly placed buttons near impossible to click without concentration; inconsistent search functionality where the “it’s right there on the phone” search button worked or didn’t work or did work but not as you’d think it’d work. I nearly started a tumblr called “Jesus Christ I Hate This Fucking Phone” just to document all the utterly asinine behaviors my iPhone-killer-anyday-now exhibited.

There’s an argument to be made (so of course, I’ll make it) that the Android experience failures described above are not technology failures. Android’s technology and operating system are impressive. But the whole package doesn’t seem to add up very well. Compare to iPhone, where (App Store policies to the contrary, and it’s a big contrary) the whole experience is consistent and wonderful and hangs together.

The whole experience part, I think, is the key. One suspects that on most Android phones that there’s no one–not Google, not the handset maker, not the carrier–who is taking responsibility for the whole end user experience. And it shows. David Pogue’s review describes a phone whose makers, if they made tradeoffs between features and constraints at all, traded off things that most people consider essential (size, battery, stability and consistency of experience) in favor of flashy features. The result is a phone that demos well but handles poorly. And Jack Shedd’s experience with the phone describes something that’s inconsistent and hard to use when you consider it as a whole device.

Does any of this — feature prioritization, product packaging design, user experience — sound familiar?

What’s the difference between iPhone and Android? Product management is the difference.

I’m willing to bet that the product managers on the Android phones had organizational limitations on how much of the user experience that they controlled, or edicts about must-have features in which the end user experience carried little weight, and that they could do nothing about those limitations. But show me a product manager who allows organizational pressure to impair user experience, and I’ll show you a product manager who has prioritized organizational harmony against sales success.