One of the reasons why Twitter works so well is its high information density, enforced by the 140 character limit. All the information is immediately visible in your stream. There is no need to read a subject line and then click through to the content, as with email. In fact, there’s very little clicking required at all — only scrolling. Sure, you can click on a link or a photo if you’re motivated to do so, but only if you believe what you’ll find at the other end of the link is going to be interesting to you. Otherwise, all you have to do is just keep scrolling.

Instagram’s core strength relied on a similar principle. It was just photos you could scroll through. Nothing more, nothing less. You could open Instagram for 10 seconds and check what’s new, or for 10 minutes and get lost in the universe of people’s lives. And you always knew what you were going to get: an endless stream of photos. Just keep scrolling.

Well, not any more. This week, co-founder Kevin Systrom introduced the addition of video content on Instagram, saying:

Some moments, however, need more than a static image to come to life. Until now these stories have been missing from Instagram.

Just like that, Instagram gave up their biggest strength: the simple consistency of giving users exactly what they expect every time they open the app. Now there’s no way to tell if you’re going to see a photo or a video. When you do happen upon a video, you have to stop scrolling and wait for it to load. And if you happen to check Instagram during a meeting and forget to turn the sound off… well, awkward.

This is such a change in direction from the company Kevin Systrom described in 2010 in an answer to the question What is the genesis of Instagram? (my emphasis added):

We decided that if we were going to build a company, we wanted to focus on being really good at one thing. We saw mobile photos as an awesome opportunity to try out some new ideas. We spent 1 week prototyping a version that focused solely on photos. It was pretty awful. So we went back to creating a native version of Burbn. We actually got an entire version of Burbn done as an iPhone app, but it felt cluttered, and overrun with features. It was really difficult to decide to start from scratch, but we went out on a limb, and basically cut everything in the Burbn app except for its photo, comment, and like capabilities. What remained was Instagram.

They wanted to be really good at one thing… The first version was cluttered and overrun with features… They basically cut everything, and what remained was Instagram… Until this week. Suddenly, the app is cluttered and overrun with features again.

The introduction of video on Instagram is clearly a move to compete with Vine, the 6-second video service from Twitter. What’s ironic is that chasing after competitor features is exactly how the photo service Hipstamatic lost their own battle against Instagram. From No Filter: How Instagram Caused Hipstamatic To Lose Focus And Gamble On Social:

For a startup that prides itself on the originality and creativity of its users, Hipstamatic spent much of 2012 chasing many other companies’ ideas. “I can honestly say that there was a lot of talk about Instagram, Path, and social,” [Hipstamatic CEO Lucas] Buick says of his company’s internal discussions. “Ultimately, that’s what shifted our focus away from who we really are.”

Only time will tell if Instagram’s introduction of video represents a similar mistake. But it’s worth noting that they have now introduced a significant amount of what Kris Gale calls complexity cost:

Complexity cost is the debt you accrue by complicating features or technology in order to solve problems. An application that does twenty things is more difficult to refactor than an application that does one thing, so changes to its code will take longer. Sometimes complexity is a necessary cost, but only organizations that fully internalize the concept can hope to prevent runaway spending in this area.

I still love Instagram, but I worry that it’s just the latest example of our obsession to add as many features as possible to products out of fear of losing traction. Instead of lateral shifts into additional functionality, I’d like to see more companies double down on the features they already have, and continuously improve the experience around those features.

Within a week, two articles came out about resisting the urge to add new features quickly after a product is launched. First, Julie Zhuo makes the case for slow, small launches with clear “sunset” criteria in The tax of new, because of the inherent cost of maintaining and improving new features:

The tax that comes with introducing any new feature into your product is high. I cannot stress this enough. Sure, maybe the new feature isn’t hard to build, maybe it only takes a couple days and a handful of people, maybe it can be shipped and delivered by next week. And maybe the additional cognitive load for a user isn’t high — it’s just an extra icon here, after all, or an extra slot in a menu there. But once your new feature is out there, it’s out there. A real thing used by real people.

Jared Spool then wrote Experience Rot, focusing more on the UX and technical debt issues introduced by new features:

The moment a new feature is added — one that wasn’t considered in the initial design — the rot starts to take hold. It’s at this moment that a rethinking of the design has to happen and the seeds of complexity are laid.

If that new feature is close in style and function to the original set of features, the experience rot may not be visible. Yet, because it needs to be retrofit into the original design, it starts down the inevitable road.

As more features are added, it becomes harder to make the overall design coherent and sensical. Soon features are crammed into corners that don’t make sense.

It’s interesting to hear the same conclusion drawn from different perspective, so it’s worth reading both articles.

Ken Norton wrote a really nice post about the problem with prioritized feature lists in product development, using his team’s early work on Google Docs as an example. Specifically, here is the problem he highlights in Babe Ruth and Feature Lists (Why Prioritized Feature Lists Can Be Poisonous):

Our wish list approach also created false equivalence. There was a huge chasm between what #1 meant to us and what it meant to our users. For us, it was first amongst equals. To them it was a painful tumor overdue for removal.

Orders of magnitude separated #1 from the rest of the list. That urgency didn’t come through until we got a bunch of them in the room and let them vent.

It’s worth reading the whole post before continuing, because the context is important. Ken highlights a really important point about prioritised feature lists — they are too one-dimensional to give you enough confidence about the product development decisions you’re making. That’s why it’s so important to plot priorities on multiple dimensions to aid in decision-making.

The method that springs to mind immediately in the case of the Google Docs example is something I’ve written about before, the Kano model. Ken explains that even though they saw text formatting within Google Docs as an important feature to work on, users saw it as a major frustration, and a fundamental bug that needed to be fixed.

Plotting their list of features using the Kano model could have highlighted this disconnect earlier in the process. To recap, 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 take Ken’s original list of prioritised features and plot them on the Kano model. Obviously I don’t have the background that the team would have had, so this is just a guess to illustrate the point:

With these added dimensions (and let’s assume there are 10 or more features on this graph), Product Managers can begin to make plans for what they need to work on by always keeping a balance between Basic expectations, Excitement generators, and Performance payoff features.

Now, I’m sure we could quibble about where exactly each feature should be plotted, but it’s immediately clear from this example that Formatting is a Basic expectation that needs to be very well met for Google Docs to get even close to parity with other word processors. That’s where they needed to start, and only once the basic expectations were met, should they have moved on to adding additional features to Formatting. At the same time, working on features like improved Sharing and Commenting would also have shown users that the product continues to get better over time (while generating some much-needed excitement).

So, with that said, I’d like to add a bit of a “yes, and” to Ken’s post. Yes, prioritized feature lists can poisonous, and one way to make sure that doesn’t happen is to add additional dimensions to the list to improve the accuracy of the decision-making. The Kano model is one approach, and I also discuss a couple more in The ultimate product question: How do you know what’s important?

Rebekah Cox wrote a great post discussing the difference between product Demo Modes (in-store displays, on-stage demos that work without a glitch, picture-perfect product intros) and what she calls Reality Mode:

Reality mode takes time, iteration, data and user research. It takes honestly using what you’ve created and putting it through its paces. It takes asking yourself “is it useful?” and honestly answering. The result may not align with conventional wisdom, you may have to sacrifice that clever hook everyone comments about (but is ultimately useless or worse) and the demo may be boring or nonexistent. But by using your product in the real world and thinking about its true utility and value, you may end up with an enduring product where people are delighted through consistently delivered value instead of just a cool demo.

It reminds me of Marco Arment’s assessment that Facebook Home is “designed for optimal input and failed to consider real-world usage.” This is a very real problem in product development. It takes courage to look your darling project in the eye, find it wanting, and admit to it.

John Naughton wrote a good summary of the Mythical Man-Month problem (the belief that adding more people to a project will get it done faster) in Why big IT projects always go wrong:

Man-months are a hopeless metric for assessing the size of a complex software project. Why? Basically because a big software project involves two kinds of work: the actual writing of computer code; and co-ordinating the work of the dozens — or maybe hundreds — of programmers working on different parts of the overall system. Co-ordination represents an essential but unproductive overhead: and the more programmers you have, the bigger that overhead becomes. Hence Brooks’s law: adding manpower to a late software project makes it later.

I’ve yet to see a large project where this law doesn’t apply.

Jessi Hempel’s The second coming of Facebook is a very interesting profile of the company and where it’s headed. There’s one paragraph in particular that has stuck with me for the past few days:

At Facebook developers choose the projects they want to work on, and product groups compete to woo them. Managers sent out reports highlighting the product teams that were doing a good job. Pretty quickly teams realized that if they wanted to get praised in the weekly memo, they needed to start recruiting mobile developers.

My first thought was that this is a great idea. If you want to get something done at Facebook, your idea has to be interesting and challenging enough to convince developers to work on it, otherwise it just won’t happen. I’m sure this weeds out a lot of ill-conceived project ideas.

But there’s a problem with this approach. If Product Managers have to convince developers to work on their projects, they are going to pitch ideas that have a big chance of being interesting to… developers. Not to Facebook users. So there’s a danger that the product features being pushed out are wild and challenging and extremely interesting, but don’t meet user needs particularly well.

In the example cited in the article, an internal weekly memo effectively changed the company’s entire roadmap by shifting attention to mobile. Not that shifting to mobile is a bad thing, but too much focus on things like who gets praised in an email has the potential to seriously derail a company.

Still, the idea is really appealing: making Product Managers effectively vie for developer attention ensures that the PMs do their homework so that they can sell and defend their ideas to the company and to customers. That’s a worthy cause. It would be great to make some form of user validation part of what happens before projects are pitched, though. I guess I just remain weary of the prevailing myth that we are like our users.

I know very little about Bitcoin, and I’m almost too afraid too dive into the rabbit hole, but I did enjoy Scott Smith’s Bitcoin is just the poster currency for a growing movement of alternative tender. Instead of the usual discussions around its mechanics, Scott focuses on the reasons for the rise in alternative currencies in general, linking it to globalization and the rise of “formal-informal” markets. He also discusses why Bitcoin itself could be doomed already:

“Most of the action I see is around software development—people getting excited by local currency platforms, or virtual currencies,” wrote [Ken Banks, founder of a global initiative to promote economic self-sufficiency Means of Exchange]. “The problem here is that these are generally being run by techies, and we need to lead with the problem we’re trying to solve, not a cool technology. Most of the software being developed is unusable unless you have a degree in computing, or a server that costs about the same as a small car, and is hard to understand.”

You know what’s coming, right? Yep — this applies not just to Bitcoin, but to all product development. If you lead with technology instead of the problem you’re trying to solve, the resulting product will almost always be too complicated. It reminds me of a great line in the USA Today story Berlin airport fiasco an embarrassment for Germans:

Here, again, technology’s getting in the way: It’s so advanced that technicians can’t figure out what’s wrong with it.

So advanced that no one can figure out what’s wrong with it… Perhaps that’s the problem with Bitcoin, too?

I’ve long been fascinated by the links between coffee, craft, and product design. Peter Baskerville’s answer on Quora to the question How do you compete with Starbucks in the coffee industry? is another great example of that. His answer can very easily be applied to building an online product (my emphasis added):

I concluded very quickly that Starbucks was good for tourists and those folk looking for brand association, but their appeal to the quality espresso seeking locals was limited to just one curious trial. I also saw that they were in fact following the age-old successful chain formula of adequate product + brilliant marketing rather than the other way around. So they were not actually targeting my niche unique coffee/service market, which is where I believe the independents fit in.

This is so true for the current state of software development. We used to swim in a sea of adequate products that employed brilliant marketing to convince us they’re better than they really are. Now, the products and services we gravitate towards are increasingly brilliant niche products that don’t have to rely on an overdose of traditional marketing to gain traction. From Dropbox to Clear to Instapaper, people are flocking to quality products after their “one curious trial” of the do-it-all marketing-driven alternative doesn’t quite meet their needs.

Peter goes on to list 8 specific strategies that Australian coffee shops have used to beat Starbucks. With advice like “Quality above all” and “Let your customers own you”, his answer gives product designers plenty to think about.

Some of my previous posts on this topic include Coffee, design, and the nature of craft, and How to get buy-in on your design process.

Kenton Kivestu defines the difference between accuracy and precision, and then discusses what it means in the context of product decisions:

There is a significant opportunity cost in consistently prioritizing precision over accuracy. Accuracy is about launching what the market needs, precision is about optimizing and delivering relentlessly on it. Unless you’ve nailed the former, material effort on the latter is going to be wasted because you’re optimizing something too far from the true north (the accurate goal) you should be pursuing.

This is an important point. Any call for data-driven design (in the quantitative, 41 shades of blue sense of the word) needs to come with a disclaimer that it’s an extremely useful approach to get closer to the middle of a target (precision), but it’s useless if you’re shooting at the wrong thing (accuracy).

(link via @ixhd)

Josh Emerson offers some words of advice that we should all take to heart:

But perhaps the most important thing I want to highlight here, is that the answer to most questions is it depends, and very often in the grey area between black and white. Try not to take extreme views on things, and perhaps see that there is always another level of complexity to be discovered in any decision you make.

We just came out of a season of arguing whether or not Flat Design is the answer to everything. We also heard proclamations that wireframes are dead, designers do in fact need to code, and Photoshop is on its last legs.

But you know what? Screw that. We have to remind ourselves that the vast majority of design is done by people who don’t have Twitter accounts and large public followings. Out there in the trenches they shouldn’t have to worry about what’s cool or what styles they’re allowed to like. They should only care about getting the job done, and using whatever tools they have at their disposal to do the right thing.

Doing the right thing is complex, and messy. Sometimes it has the luxury of involving a content-first approach with interactive prototypes, but other times it involves having to make static wireframes and designing before any content is available. It’s not ideal, but who are we to judge a designer based on what we perceive as the quality of their process? What do we know about the complexity of the project, the relationships they are trying to navigate, and the users they are designing for?

My advice is this. Yes, follow the design zeitgeist. Study the big ideas and explore the edges where the industry is being pushed forward. But don’t get caught up in whatever the cool viewpoint is about any methodology or style. Only you know what your project needs. So be confident, ignore the extreme viewpoints, and use whatever tool will be most effective to help you do the right thing.