The social media manager at my friend Paul Cartmel’s company needs to track 3 different Twitter accounts on Klout, so he sent an email to their support team to find out how to log out of their iPhone app. This was the response, which Paul kindly forwarded to me:

Yep. You have to delete the app to log out of it. This example reminds me of what Adaptive Path calls the cake model of product strategy. Watch this short video about it before you continue reading:

What Klout did with their iPhone app is a classic “Dry Cake” approach. Even though they probably have additional functionality planned to make the app tasty with filling and icing, the current iteration is dry and not very exciting since key functionality is missing. You can’t do anything except see the Klout scores of yourself and a few other people connected to you — there is no way to search for other users.

What they should have done is build a cupcake first — an iteration that feels complete, even if it doesn’t have an entire roadmap’s functionality built out yet. It should support basic actions like logging out and searching for other users. And despite not having all the features of the web site, it should be an app that can stand on its own, one that is engaging and desirable with the functionality it does have. It’s so much fun to go from cupcake to cake to wedding cake if that first iteration is something that users are excited about.

So when you think about building your own product, remember to make your minimum viable product a tasty cupcake, not a dry cake with some vague promise of filling and icing somewhere down the line.

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’ve never fully bought into the “user experience cannot be designed” argument. You could say I’m biased because user experience design is how I choose to make my living, but I would (surprise!) disagree with that as well. Consider this paragraph from Chris Dixon’s excellent post The experience economy:

Experiences make people happier than products (a fact that scientific studies support). The popularity of experiences like music concerts has skyrocketed compared to corresponding products like music recordings. Apple, the most valuable company in the world, maniacally focuses on product experiences, down to minute details like the experience of unboxing an iPhone. Customers want to know where their food and clothes come from, so they can understand the experiences surrounding them. The emphasis on experiences also helps explain other large trends like the migration to cities. Cities have always offered the trade-off of fewer goods and less space in exchange for better experiences.

The main argument against experience design is that we can’t control context of use, no matter how hard we try. But the above examples are all cases where we can control enough of the context of use to make a reasonable assumption about the type of experience the majority of users will have. The same goes for web sites — through creativity and a little user testing, we can get to a similar level of comfort with how most users will experience our sites/apps.

So, don’t give up, experience designers. We can build great experiences for our users (while also meeting business goals at the same time).

Chris Dixon in The default state of a startup is failure — a short, powerful post on human behavior and entrepreneurship:

If you are starting a company and wondering why nothing good seems to happen unless you force it to happen, that’s because the world wants to stay the way it is. Customers, partners, and most of all incumbents don’t want to think hard, try new things, or change in any way. The world is lazy and just wants to keep doing what it’s doing.

He points out that because the world is lazy, no one will care about a new product you launch unless you make them.

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.

RIM Admits it is Behind Australia’s ‘Wake Up’ Campaign:

Those assembled [in front of the Apple store] chanted “wake up” and held placards decorated with the same message, while some protesters dressed as sheep, in another dig at Apple’s popular products and cult following.

I don’t understand why companies think that ridiculing Apple users is a better strategy than making good products. It’s what happens when you believe Marketing > Product.

Francisco Inchauste unpacks the difficult process of designing simple products in Simplicity Isn’t Simple. He explains that simplicity isn’t just something you start tacking on towards the end of a project:

It still amazes me how many people ask for simplicity but don’t realize this phase of the design has passed when they’ve already listed out what they want it to do, or in the case of a Website, tell you what needs to be on the homepage.

True simplicity starts at conception. It’s infused into the being of the creators, and by proxy, in the soul of every product they design.

He also outlines some practical strategies for creating simple products.

Andrew Chen wrote a very interesting piece called The Law of Sh-tty Clickthroughs. I recommend you read the whole thing before continuing here. Chen goes into great detail to explain just how ineffective banner ads and other marketing methods have become, and he gives some very astute reasons for why it’s happening:

Customers respond to novelty, which inevitably fades.

First-to-market never lasts.

More scale means less qualified customers.

In short, I loved the article. All the way to the last section. Here is Chen’s proposed solution to the problem:

The real solution: Discover the next untapped marketing channel

The 10X solution to solving the Law of Sh-tty Clickthroughs, even momentarily, is to discover the next untapped marketing channel. In addition to doubling down on traditional forms of online advertising like banners, search, and email, it’s important to work hard to get to the next marketing channel while it’s uncontested.

This is certainly a solution to the problem, but I think there’s a better one: Make an excellent product, and then support the crap out of it. I guess I’m suggesting that we’re entering a post-marketing world where people don’t care about how companies tell them they should feel. In response, we need to shift our focus away from traditional channels to focus on what’s really important: the thing we’re making.

Instapaper is famous for doing no marketing, and yet it’s an enormously successful app. The popularity of Sparrow seems largely due to unsolicited reviews and good word of mouth. Amazon.com has become the de facto place to get user reviews and do price comparison shopping - I’d argue that keeps them top-of-mind more than traditional marketing does.

The lasting benefits of “Word of Mouth” have long been acknowledged, but recently that worthy goal has been derailed by a frantic quest for the short-term benefits of “going viral”. The term “viral marketing” is presumably used without realizing the irony that viruses”¦ you know”¦ kill people.

So I’m not saying that you should try to make a video that millions of people watch on YouTube. I’m saying that there is indeed a formula for effective marketing, and it relies on an unending supply of good will from customers. The formula is quite simple, but unfortunately there are no shortcuts. It looks like this: make great products, sell it to people, support it well, and be patient.

And here’s the beauty of this strategy. This “marketing” method isn’t susceptible to all the issues that give traditional marketing channels such a short shelf-life of effectiveness:

• The novelty of a good product that keeps getting better doesn’t fade.
• There is no first-to-market messaging advantage to lose, because your focus is on the product, not the message.
• And finally, more scale means more and more people to talk about your product.

The other benefit? If the product fails, it will fail for the right reason: it’s just not good enough. Which gives you more time to focus on the next product that will be good enough.

The Heavy Chef asked me some questions about design (and a little bit about this site). If you’re interested, you can read the interview here. Here’s a tiny excerpt:

I think the biggest epidemic in the design world right now is that we open our design software too early in the process. We have to spend time understanding the problem and user needs first, before we grab the mouse. There are so many products out there that look great, but don’t really solve a user need.

Instead, designers should raise their voices much earlier in the strategy discussion, and bring their design thinking skills to the essential practice of finding what Marc Andreesen calls product/market fit. Oh, and we need to use more paper to share those ideas. Sketches are fantastic low-fidelity prototyping tools, and it’s cheap to test and iterate on.

Ryan Singer wrote a very clear and succinct definition of Product Management in Advice for product managers:

“Managing the product” means deciding what we do to the product and then making it happen.

When you unpack that, it involves strategy (what is important to do?), resources (how much time can we spend on it?), managing development (what do we need to build in order to do it?), managing experience (how will it look and work, how does it integrate into what we already have?). And all of it with regard to the bottom line of the business. Given a strategy, resources we have, a user experience bar to uphold ”” given all that, what can we do and why is it worth doing?

It’s a great primer for anyone who wants to understand what PM’s do - especially for people who are considering making a career change to Product Management. There’s one part I’d like to unpack a little more, and that is prioritization. Ryan touches on it as follows in a section entitled “Deciding what to do”:

I try to lead every decision with user experience. What is the user-facing situation we want to change? Or if the motivation isn’t because of a user benefit, but a pure business reason ”” what is the impact on the user, and how can we align incentives so this at minimum makes sense to the user? This is critical.

He advocates for “leading with design”, which is a sentiment I wholeheartedly agree with. But how does this work in practice, particularly in large organizations with a variety of product lines and a gazillion stakeholders? We’ve spent a lot of time trying out different ways to solve the problem of prioritization, so I naturally gravitated towards that section in Ryan’s piece, and hoped for a little more detail. Ryan, if you’re listening - I’d love to see a follow-up post where you explain your process a bit more.

This is important because I believe the hardest part of a Product Manager’s job is answering the strategy question that Ryan uses in his definition: What is important to do? Once you know what to do, the how isn’t necessarily easy, but you’ve at least started the race and you know what you’re running towards. You’ll work with developers to understand technical requirements. You’ll work with designers and guide them through a user-centered design process. Running the race is the fun part. Deciding which race to run is the excruciating part, and it makes or breaks a product.

How others prioritize

There are many established processes for product prioritization, and we’ve tried most of them on the various teams I’ve worked with. I’m particularly interested in methods that can be used on an ongoing (daily/weekly) basis - not ones that are used every few months for long-term planning. The KJ-Method has a lot going for it:

The KJ-Method is a fascinating mix of independent brainstorming, group dynamics, and democracy. It allows a team to be creative and critical in a productive manner, where strong personalities and politics play second fiddle to the independent perspectives and experience of the team.

Jared Spool claims that he can do this process in under an hour with a team, but my theory is that he can only do that because he is superhuman. I find the 8-step process a little too heavy and time-intensive for day-to-day use. It’s great for longer-term strategic planning though.

The Kano Model is another great technique for prioritization:

The easiest way to think of the model is on a two-dimensional grid.

The horizontal axis represents the investment the organization makes. As investment increases, the organization spends more resources on improving the quality or adding new capabilities.

The vertical dimension represents the satisfaction of the user, moving from an extreme negative of frustration to an extreme positive of delight.

As much as I like this model, it suffers the same downside as the KJ-method - it’s too time-intensive for ongoing prioritization. And then there is Amazon’s approach, which is based on the following principle:

Prioritize themes, not projects - Create a list of themes for your product or business. Examples might be customer acquisition, activation, retention, avg revenue per user, avg visits per user, etc. Pick ~3 that are the most important for your product given its stage.

The gist is that they prioritize based on a project’s potential impact vs. cost:

Look for the projects with the greatest projected impact with the least cost, and do these ones first, quickly. Then move on to the next projects, or the next phases of the early projects that had a greater than expected impact.

How we prioritize

I’ve found a stripped-down version of the Amazon method most effective and realistic in our organization. As much as I agree with the principles of each of the three approaches mentioned above, they tend to be unrealistic in the context of ongoing prioritization. So here is the extremely simple process we’ve used on an ongoing basis, with good results:

1. Have a white board with a permanent two-by-two matrix on it. The horizontal axis represents Business impact (which includes user needs and technical considerations), and the vertical axis represents Level of effort to implement (which includes people and their time commitment).
2. Write product requests and ideas on sticky notes as they come up, have a quick discussion with relevant people to ascertain business value and level of effort, and then put the sticky note on the two-by-two matrix.
3. Write prioritization numbers next to each of the features/themes, starting with those that have the highest business value. I like a 70/30 split between high effort / low effort features, but that’s a theory for a different post.
4. Every week or so, check your roadmap to make sure you’re still working on the right things, and make adustments as needed.

It’s a simple method, and it’s far from perfect. But it has a few things going for it:

• It’s detailed enough to ensure constant prioritization based on what’s important.
• It’s light enough to make it practical for everyday use.

PM’s should spend most of their time managing experience and managing development - two of the activities Ryan points out in his post. I’m sure they don’t skip over the prioritization part at 37signals, but I wanted to give some more context around that because it’s something I struggle with a lot, and I guess I hope I’m not alone. Actually, I know I’m not alone. If we all knew what was important to work on, there would be no failed products.