Menu

Posts tagged “product strategy”

Instagram's pivot into complexity

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.

Design and status

Nike+ Fuelband

William Kremer’s Why did men stop wearing high heels? is a fascinating look at history, gender inequality, and the peculiarities of seeking status. This part stuck with me:

In the muddy, rutted streets of 17th Century Europe, these new shoes had no utility value whatsoever — but that was the point.

“One of the best ways that status can be conveyed is through impracticality,” says [Elizabeth Semmelhack of the Bata Shoe Museum in Toronto], adding that the upper classes have always used impractical, uncomfortable and luxurious clothing to announce their privileged status.

“They aren’t in the fields working and they don’t have to walk far.”

So, people wore high heals because impractical clothes showed off one’s status. This seems very similar to how expensive sports cars are viewed in our current society. They’re highly impractical if you want to take anything with you where you’re going (or if you have kids), but having one certainly shows that you have a lot of money.

This got me thinking about technology products and their link to status. I remember that before the iPhone came out, during meetings people used to leave their cell phones in their pockets (well, on their belt clips…). Then, once the iPhone came along, pulling out your phone and placing it face up on the table became a status symbol. Suddenly the phone wasn’t meant to be hidden, but meant to be shown off. The iPhone is designed to be seen.

Companies like Nike tap into this sense of status by making the Fuelband extremely wearable. It’s not something you hide away, like the Fitbit. It’s something that’s meant to be shown off. From Dan Hon’s excellent article Fitness by design:

A few hours up the US west coast though, lies a company built upon not just sport performance, but also personal expression, fashion and style. Nike’s FuelBand is worn around your wrist. It looks and feels better, with its black rubber and distinctive pinpricked colour display inviting discussion. […] Though it is a silent device that constantly logs your activity, it is not out of sight — it is permanently visible, a wearable statement. You’re not given the choice of hiding it.

Of course, most technology products are very different from high heels in that they’re actually useful. So I guess some things have changed since the 1600s. Where impracticality used to be a sign of status, with technology we now associate that status with good design — a mix of utility, usability, and aesthetics.

How new features can hurt your product

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.

Improve prioritized feature lists by adding more dimensions

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:

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:

Kano model for Google Docs

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?

Demo Mode vs. Reality Mode in product development

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.

More on the hype, benefits, and dangers of Big Data

When I wrote The hype, benefits, and dangers of Big Data a few months ago I thought it would be my only post about Big Data, and then I’d move on. But 2013 appears to be the year of Big Data, so you can’t turn a corner on the web without bumping into an article about it. Looking at Google Trends, it’s clear that interest is at an all-time high:

So I wanted to point out just a few more articles that range from calling for a more tempered approach to Big Data to an all-out assault on its value and validity. Let’s start with the juicy one…

In A More Thoughtful but No More Convincing View of Big Data Stephen Few reviews the book Big Data: A Revolution That Will Transform How We Live, Work, and Think and uses it as a way to articulate his distaste with the whole thing:

Data exists in a potentially infinite supply. Given this fact, wouldn’t it be wise to determine with great care what we collect, store, retain, and mine for value? To the extent that more people are turning to data for help these days, learning to depend on evidence rather than intuition alone to inform their decisions, should we accept the Big Data campaign as helpful? We can turn people on to data without claiming that something miraculous has changed in the data landscape over the last few years. […]

As data continues to increase in volume, velocity, and variety as it has since the advent of the computer, its potential for wise use increases as well, but only if we refine our ability to separate the signals from the noise. More does not trump better. Without the right data and skills, more will only bury us.

It’s a long article, but very detailed and highly recommended as a well-reasoned counter-argument to the Big Data movement. Others are a little more pragmatic, suggesting that we improve on the promise of Big Data rather than destroy it. In Coffee & Empathy: Why data without a soul is meaningless1 Om Malik states:

What will it take to build emotive-and-empathic data experiences? Less data science and more data art — which, in other words, means that data wranglers have to develop correlations between data much like the human brain finds context. It is actually not about building the fanciest machine, but instead about the ability to ask the human questions. It is not about just being data informed, but being data aware and data intelligent.

It’s important to take this further and say the soul Om talks about needs to come from qualitative methods like ethnography. That’s why I like Dave McColgin’s point in his article How Will Big Data Change Design Research?:

In our field of designing products and experiences, the ‘why’ stays at the center of our process and creativity. Many designers work mostly on new products and services for which there may not yet be reliable data available. […] While Big Data can inform designers on how to improve once they put something out there, it is design research that provides principled guidance towards good solutions all along the way. Big Data can’t help us do that right now.

Tricia Wang’s Big Data Needs Thick Data is another excellent plea for ethnographers to get involved in the Big Data movement, to produce what she calls “Thick Data”:

Big Data produces so much information that it needs something more to bridge and/or reveal knowledge gaps. That’s why ethnographic work holds such enormous value in the era of Big Data. […]

Big Data reveals insights with a particular range of data points, while Thick Data reveals the social context of and connections between data points. Big Data delivers numbers; thick data delivers stories. Big data relies on machine learning; thick data relies on human learning.

And finally, Martin U. Müller and Marcel Rosenbach look at some of the scarier implications of Big Data in Living by the Numbers: Big Data Knows What Your Future Holds:

Is it truly desirable for cultural assets like TV series or music albums to be tailored to our predicted tastes by means of data-driven analyses? What happens to creativity, intuition and the element of surprise in this totally calculated world?

Internet philosopher Evgeny Morozov warns of an impending “tyranny of algorithms” and is fundamentally critical of the ideology behind many current Big Data applications. Morozov argues that because formulas are increasingly being used in finance and, as in the case of Predictive Policing, in police work, they should be regularly reviewed by independent, qualified auditors — if only to prevent discrimination and abuses of power.

I personally think there is the same value in data that there has always been, and that the Big Data movement isn’t so much about the size of the data sets, but the ability to extract more of that inherent value (signal) from the noise. But an algorithm will only take you so far. As always, knowing what and how much is not very useful without knowing why. And Big Data will never be able to tell us why…


  1. What’s that? You think I’ll just automatically link to any article with the word “coffee” in the headline? I resent that accusation, sir or madam! 

Built to last

Jason Fried, co-founder of 37signals, in an interview with The Great Discontent:

People should consider the value of a long-term investment in something. Can you make your idea your life’s work instead of your life’s work being 30 ideas?

I’m more of a fan of constant, steady growth because it feels more sustainable over a long period of time. Creating things that are lasting is what great cultures do. […] What are we creating today that’s going to last for 20, 50, or 100 years? I like to think about that and I’d love to have more people think that way rather than thinking about what they can do for two years until they get bought out.

This is such a good point. We just don’t think about building things that last any more, because that takes time, and we’re not exactly known for our patience. Tangentially related, the recent Radiolab episode called “Speed” is absolutely brilliant — you have to listen to it.

Also see: The elusive goal of lasting beauty in web design.

When Product Managers compete for developer attention

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.

Bitcoin and the growth of "formal-informal" markets

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?

Foursquare: not lame any more

Back in 2009, whenever an overly enthusiastic Foursquare user managed to capture the attention of an unsuspecting potential victim long enough to try to convince them to download the app, the conversation went something like this:

“It’s really cool. See? You ‘check in’ to the cafés and restaurants you visit.”

“Why?”

“Because if you check in enough times, you become the mayor of that place.”

“Why?”

“Because being the mayor is cool!”

“You keep using that word. I don’t think it means what you think it means. I think the word you’re looking for is lame.”

The discussion would usually dampen the Foursquare user’s enthusiasm a little bit, but only for a day or two. Then they’d be at it again, continuing their quest to spread the word about a service they don’t quite understand, but can’t help but be excited about.

Yesterday, Foursquare 6.0 was released for iOS and Android. And it continues a slow, steady move away from a focus on the ‘check-in’ to a way to discover great places to explore. If you squint and look at Foursquare just right, you’ll realize that they are becoming what Path wants to be: a social network for close friends and family.

The new Foursquare home screen continues the trend to reduce the hierarchy of the check-in action in favor of telling you what’s happening in your network, and what places you might like to visit (see left side of the screen below). A tap inside the (much more prominent) search bar brings up the interface to show recommended places to visit within a specified category (see right side of screen below).

Foursquare 6.0

See, what Foursquare realized a while ago is that their real power is not in the mayorships and badges that defined them in 2009. The real power — as usual — is the data. It’s knowing what people like and don’t like. It’s knowing where to find good coffee, what restaurants to avoid, and where you should go when you’re in a new city. And they have been shifting towards that vision with steadfast tenacity. Dan Frommer discussed this when Foursquare 5.0 was launched in June 2012:

So: Foursquare has been evolving to a company that no longer simply answers “where are my friends?” but instead “where should I go right now?” This is smart: Everyone’s gotta eat. That’s why Explore is rapidly becoming Foursquare’s most important feature. This has always been part of the plan, I think. But it’s certainly carrying more emphasis in this new version of the app than ever before.

With Foursquare 6.0, the company’s move towards a discovery engine powered by people you like and trust appears to be almost complete. That said, it’s clear that they’re not done (watch out, Path). I’m sure they are thinking of more ways to make the experience better. So even though there are some design irregularities in version 6.0, those will be ironed out through constant iteration while they’re moving towards a clear vision for the future. Like Anil Dash said at the beginning of 2012 in Foursquare: Today’s best-executing startup:

Foursquare’s removed features from the core app a few times, constantly changes the design of its flagship iOS application, and in general asserts its authority over the experience that users have within the Foursquare application. Yet, unlike every single other major social application, they don’t inspire mass user revolts or negative press every time they iterate. […] Part of this is the small, well-paced timing of iteration on the application where there are always small things changing in ways that aren’t wildly disruptive, but do enough to set a tone that users know to expect the furniture might get rearranged once in a while.

So, with all of that said… If you’ve tried Foursquare before and found it lame, I think you should give it another go. It’s not lame any more. Any service that can help you avoid bad coffee makes the world a better place, right? Foursquare is such a service, and so much more.

Oh, one more thing. Posting your Foursquare check-ins to Facebook and Twitter? Still lame.