Kevin Kelleher in Facebook’s Growing Silent-Majority Problem:

This third group – the silent majority of Facebook users – hold the key to the company’s future. Facebook is never going to win over its harshest critics, and it’s unlikely to alienate the people who see it as part of the fabric of their everyday lives. If the company can persuade that silent majority to become more engaged in the site – interacting with bands, liking consumer brands, clicking on the ads targeted to their surfing habits – its future looks pretty bright.

I always find it useful to think about engagement metrics on the web in terms of the three A’s:

• Acquisition. Getting new users to sign up for a site/service.
• Activation. Getting those new users to make their first contribution/purchase.
• Activity. Getting the first-time contributors/purchasers to repeat that activity over and over.

Facebook certainly doesn’t have an acquisition problem (yet), and their ramp-up process is very good, so I also don’t think they have an activation problem. But I can definitely see the argument that they might have a serious activity problem on their hands. Kevin shares some interesting engagement stats, as well as how he thinks Facebook can solve this problem.

(link via @mobivangelist)

The air of ‘meh’ surrounding Apple’s iPhone event this coming Wednesday is almost palpable. A wave of pre-disappointment is sweeping much of the tech blog world, with proclamations like this one from Andrew Couts:

As bored as I am by the new iPhone’s purported growth spurt, I’m not particularly interested in any of the other realistic features Apple might add to some “dream phone” either. NFC? Yawn. Quad-core processor? Psh. Wireless charging? Whatevs. All these features would be great, I suppose — but they have been done before, and will be done again and again and again by the time the iPhone 6 makes its way into the world around this time next year.

I’ve been wondering why so many people have gone all “Everything’s amazing and nobody’s happy” on Apple with this particular event. And I think the answer lies in an unlikely place: a product development theory called the Kano Model.

The Kano Model, developed in the 1980s by Professor Noriaki Kano for the Japanese automotive industry, is a helpful method to prioritise product features by plotting them on the following 2-dimensional scale:

• How well a particular user need is being fulfilled by a feature
• What level of satisfaction the feature will give users

The model is generally used to classify features into three groups:

• Excitement generators. Delightful, unexpected features that make a product both useful and usable.
• Performance payoffs. Features that continue to increase satisfaction as improvements are made.
• Basic expectations. Features that users expect as a given — if these aren’t available in a product, you’re in trouble.

Here is a visual representation of the Kano model:

Now, let’s look at the iPhone in this context. When it was first introduced it was all Excitement generators all the way. From the touch screen, to the scrolling, to the tiniest of UI details, the thing was just a joy to use from start to finish. And since no one had seen anything like it before, we thought it was a piece of magic that could do anything:

(Image source: Cyanide & Happiness)

Eventually the novelty wore off and the iPhone’s Excitement generators became Basic expectations since everyone started doing it (oh hi, Samsung!). But there were still plenty of Performance payoff features to work on. Continued UI refinements, 3rd party apps, enterprise support, push notifications… as those features were introduced and improved, we kept liking the device more.

This couldn’t go on forever, though. The natural evolution of most products is that the Excitement generators become harder to find, so you tend to spend more time on the Performance payoffs and Basic expectations1. For example, by the time cut-and-paste came to the iPhone, it was no longer an Excitement generator, but the most basic of expectations. All the features Andrew Couts talks about in the piece I quoted above are Basic expectations as well. John Gruber wrote about this back in May:

iOS is by no means feature-complete. But it’s getting harder to identify the low-hanging fruit — the things you just know Apple has to be working on, not just the stuff you hope they are.

There is nothing wrong with this. It’s a natural evolution of a product, and we should be happy with the incremental progress. But that’s just not good enough for us. We can’t move beyond the amazing 2007 keynote where we first saw the iPhone. That’s where Apple set the bar, and now it’s almost impossible to reach it again. So, even though every year the iPhone and iOS keep getting better and better, we become less and less impressed because we have an unrealistic expectation that everything Apple does has to fit into the Excitement generator category. It’s impossible. No one can do that ad infinitum.

We should stop hoping for an avalanche of Excitement generators in this week’s announcement of the new iPhone. Instead, we should realise that Apple is doing what any company should do with a mature product: focus on ways to increase customer satisfaction steadily with Performance payoff and Basic expectation features, without getting caught up in a wild goose chase to re-invent a product that already re-invented an industry.

---

1. Also see the Local Maximum theory, which suggests that each design has a limit where it’s as effective as it’s ever going to be. ↩

One of the questions that really interests me is why certain digital products succeed and others fail — even if they look great and are easy to use. What can we learn from the failures to ensure that there are less of them? Is there a process that can help increase the likelihood of success?

The answer to these questions is the focus of my first article for A List Apart, entitled Usable yet Useless: Why Every Business Needs Product Discovery. From the intro:

All around us we see beautiful, empty monuments erected not for their users, but for the people who built them—and the VCs who are scouting them. Even sites and apps that go beyond beauty to usability often fail because they can’t find a big enough market.

Why can’t some interactive products find enough users to be sustainable? Why are there so many failed startups, despite a renewed focus on design? Most importantly, what can we do about it?

It was an absolute pleasure to work with the ALA team. I especially want to thank Sara Boettcher for being such a tough, gracious, and encouraging editor. I learned so much through this process — lessons I’ll take with me in my all my writing going forward.

So if these are questions you struggle with as well, have a look at the article. My hope is that we’ll see more businesses trying out the Product Discovery process as a way to build products that people love.

Greg McKeown’s The Disciplined Pursuit of Less is an article about careers, but his solid advice also applies to software product development:

If success is a catalyst for failure because it leads to the “undisciplined pursuit of more,” then one simple antidote is the disciplined pursuit of less. Not just haphazardly saying no, but purposefully, deliberately, and strategically eliminating the nonessentials. Not just once a year as part of a planning meeting, but constantly reducing, focusing and simplifying. Not just getting rid of the obvious time wasters, but being willing to cut out really terrific opportunities as well. Few appear to have the courage to live this principle, which may be why it differentiates successful people and organizations from the very successful ones.

Jason Calacanis believes The Age of Excellence is here, and I agree:

You see, in the old days, it was about distribution, location, marketing spend, celebrity endorsement, traffic buying or the black art of search engine optimization.

Today it’s about getting a positive net-promoter score and making your five-star histogram look like a gun: a lot of five-star reviews coupled with some four-star reviews make the barrel. A dramatic drop-off to three stars, followed by slightly fewer two- and one-star reviews, makes the handle of your gun.

No amount of marketing or gamesmanship is going to flip the upside-down gun over. If your product sucks, it’s over. Transparency is a bitch.

(link via @jonaspersson)

Joel Spolsky wrote a great post on some of the hidden costs of software development. From Software Inventory:

The “cost” of code inventory is huge. It might add up to six or twelve months of work that is stuck in the assembly line and not yet in customers’ hands. This could be the difference between having a cutting-edge product (iPhone) or constantly playing catchup (Windows Phone). It’s nearly impossible to get people to buy Windows Phones, even if the iPhone is only six months better. A lot of markets have network effects, and being first has winner-take-all implications. So getting rid of inventory in the development process can make or break a product.

He goes on to propose an alternative to Backlog Grooming — one of the central tenets of Agile development:

The trouble is that 90% of the things in the feature backlog will never get implemented, ever. So every minute you spent writing down, designing, thinking about, or discussing features that are never going to get implemented is just time wasted. When I hear about product teams that regularly have “backlog grooming” sessions, in which they carefully waste a tiny amount of time and mental energy every day or every week thinking about every single feature which will never be implemented, I want to poke my eyes out.

His proposed solution is quite radical from an Agile perspective, and I’m not sure how it would work on large redesign/replatform projects, but it’s certainly worth considering.

Two articles on company culture caught my eye last week, both about what it’s like to work in organizations with no formal structure and communication. First, from the always excellent Design Staff, Design at Valve: collaborating and innovating in a flat organization is an interview with one of the designers at Valve:

It’s everyon’s job at Valve to recruit peers to help ship an idea. If I’m unable to recruit an engineer to help me ship an idea, it probably means either the idea isn’t solving an important problem, or it’s just not timely given our current priorities and ongoing projects. As individual contributors, w’re each constantly asking ourselves “Where is my time best spent?” The answer changes as projects ship and as new opportunities emerge.

For these self-selecting project teams to work, it’s important that we keep up on the various efforts happening around the company. Ther’s no top-down communication, so this typically happens by chatting with one another over lunch, or checking in with people to learn what’s happening.

Second, Brandon Keepers wrote about what it’s like to work at GitHub, and it struck me as remarkably similar to Valve’s culture:

Anarchy works wonderfully in a small group of individuals with a high level of trust. Everyone at GitHub has full access and permission to do whatever they want. Do great things and you earn respect. Abuse that freedom and you violate everyon’s trust.

Each person at GitHub has the responsibility to sell their ideas to the rest of the company. I quickly learned that if I can’t get anyone else interested in the project that I want to work on, then either I poorly articulated my vision, or more likely, it does not benefit the company. You can still work on it, but you will likely be working alone.

Both posts are worth reading, because they also explore some of the challenges of working in such environments. The teams seem well aware of the downsides of the cultures they’ve created, and they’re working hard to address those because the upsides vastly overshadow the downsides for them. And I guess that’s the key phrase — for them. I don’t think this type of environment will work in every company, but it’s encouraging to see how systems based solely on trust and self-governance can create productive environments and (extremely) happy employees.

For both companies, the measure of success is the quality and value of the products they ship to customers. That is fantastic, and could be the beginnings of a new era of true user-centered organizations. We need more experimentation that does away with conventional hierarchies and corporate structures so that we can find new ways to create value for our users.

I like this mental image of the “product in search of a solution” phenomenon we see so much of of these days:

Your organization invents something no one else does. The rest of the process goes like this: I have this tail. I put it on the donkey. I spend money testing and fixing the tail to get it closer to what the donkey wants it to do. I also spend money on marketing and sales people to convince the donkey I have what it needs.

There is, of course, a better way.

I was encouraged to read these words by Matt Mullenweg in his post Radically Simplified WordPress:

As John Borthwick put beautifully today, “A tablet is an incredible device that you can put in front of babies or 95-year-olds and they know how to use it.” How we democratize publishing on that sort of platform will not and should not work like WordPress’ current dashboard does. It’s not a matter of a responsive stylesheet or incremental UX improvements, it’s re-imagining and radically simplifying what we currently do, thinking outside the box of wp-admin.

This is great news, and I’d like to offer my 2 cents on what an ideal mobile WordPress platform might look like. Because despite several attempts I haven’t been able to figure out a good workflow for publishing to WordPress from my iPhone or iPad.

Let’s take this post as an example. I read Matt’s article in Instapaper. I used the awesome “Create Note in Simplenote” feature to send the above quote to my preferred writing app. I am writing these words in Simplenote for iOS using Markdown. Writing down the words is a breeze; geting those words to my blog is a mission (and usually results in a big time delay). I’m going to wait until I get home, open my laptop, and wait for nvALT to sync with the text I entered into Simplenote. Then I’ll copy the Markdown into MarsEdit, add some URL and keyword specifics, and hit Publish.

The WordPress iOS apps are not helpful to me, because they don’t allow you to add custom fields and URLs. For example, for link posts I have a custom field that turns the title of the RSS entry for that post into a link that takes the reader directly to the original article. I can’t do that in the iOS app.

But here’s the thing - I don’t want a better WordPress iOS app. I don’t even want a mobile-optimized WordPress Dashboard. Instead, I want all the apps I already use to integrate seamlessly with the WordPress backend. So my ideal mobile WordPress experience is this: make it dead easy for text editor apps to publish to WordPress.

Once I’m done writing this post in Simplenote I would like to tap a link that says “Publish to WordPress.” I would then like to see a customizable dialog that lets me add/edit all the fields I have chosen to include, hit Post, and be done. It could work similar to Tumblr integration on Instapaper, except with customizable fields:

Maybe this is already what the WordPress team is thinking about - I certainly hope so. Either way, I know that this kind of seamless integration would truly free us to publish from anywhere, and will put a final nail in the coffin of the “iPad is only for consuming” argument.

It would be great to get more insight from the WordPress team on what they’re working on for mobile.

This story has been passed around quite bit, but in case you haven’t seen it, Mat Honan’s How Yahoo Killed Flickr and Lost the Internet is a fascinating story:

This is the story of a wonderful idea. Something that had never been done before, a moment of change that shaped the Internet we know today. This is the story of Flickr. And how Yahoo bought it and murdered it and screwed itself out of relevance along the way.

It’s a well-written and thoughtful account that’s well worth the (long) read. Honan’s core argument on what went wrong is this:

All Yahoo cared about was the database its users had built and tagged. It didn’t care about the community that had created it or (more importantly) continuing to grow that community by introducing new features.

All the wrong decisions that Yahoo made can be traced back to that single issue: that they didn’t understand why people use Flickr. Instead, they made the common and fatal mistake of placing profit before product.

Unrelated, but until I read this article I had no idea that there is an app that adds cats with laser eyes to your photos. That is awesome. And now I’m really going off on a tangent, but there is a certain poetry to this 1-star review of the app:

It only gives you a small amount of cats to choose from and if you want another small amount of cat head stamps it costs 99 cents more. This app needs at least three times the number of cats to make it worthwhile. Don’t buy.

It needs at least three times the number of cats to make it worthwhile!

So, while we’re on a tangent anyway, I’ll indulge myself in posting this picture of the setting I was lucky enough to read this Yahoo article in. Vacation is hard.