(if you don’t see the slides, go here to Slideshare)

Recent slides for a talk in Steve Blank / Eric Ries’s class on High-Tech Entrepreneurship
Yesterday I had the pleasure of giving a talk at Steve and Eric’s class at Haas on the topic of Minimum Desirable Product – if you haven’t read the original article, it provides some useful context. I included an set of slides above on the topic, updated from my talk yesterday, which you can peruse at your convenience.

After you’re done, you can read my extended remarks below on some stuff I learned along the way. Frankly, any of these could probably be its own blog post but I’ve been feeling lazy lately so you get a couple sentences apiece instead

“Viable” means different things to different people – my usage is meant to be pretty specific
Eric noted during my talk that I use a very narrow definition of “viable” within Minimum Viable Product, which is true. I believe in his usage of it, the focus on viability is actually a conglomeration of IDEO’s concept of desirability, feasibility, and viability. It’s frankly a coincidence that IDEO and the Lean Startup use a common term, though I believe they mostly overlap. I prefer IDEO’s framework because it allows a bit more precision in describing the class of issues you’re concerned about, but frankly there’s a ton of gray area. (Is a low-priced X a desirability thing or a viability thing? Honestly, both.)

Viability-first strategies do work, and may be the right thing for you
Many companies have come and gone that make products that aren’t that great, don’t generate a lot of consumer value, and yet still pull in a lot of money. It’s a strategy that can work, and I’m not arguing the opposite. However, I’m convinced that if your goal is to make a mainstream web property that has daily engagement, starting with the goal of creating lots of user value is probably the way to go. Similarly, if you have a highly transactional business like ecommerce, designing for daily engagement is probably overkill – in that case, reducing your cost of customer acquisition might be the right way to go. So it’s all very situational, and frankly, very personal based on how you want to run your product.

Minimum Desirable Product is just a starting point – you still need to figure everything else out
I also want to note that my message isn’t just to build for any random group of users and then the rest will take care of itself. That’s far too idealistic. Instead, it’s just a starting point for how you think of the problem. Ultimately, all your product ideas still need to be filtered through the lens of whether you can market them, that the market is big enough, and that the technology issues aren’t insurmountable. There was a recent Times interview with Steve Jobs on the iPad that illustrates this perspective:

… surely Apple stands at the intersection of liberal arts, technology and commerce? “Sure, what we do has to make commercial sense,” Jobs concedes, “but it’s never the starting point. We start with the product and the user experience.”

Metrics can be oriented towards user value
I’ve written before on some of the short-comings of using metrics-driven product strategies, such as here and here. An analytics dashboard is ultimately just one tool out of many that help you optimize whatever goal you want to set. If you are very focused on validating your business model and spend all your time tracking metrics such as viral factor, ARPU and conversation rates, then you will make those go higher. If you use your metrics to define user benefits and optimize those (I’ve begun calling this “Metrics of Love”) then you’ll make your value proposition go higher. So depending on your perspective and where you want to start, you’ll end up in different places.

Highly desirable consumer products also have minimalist featuresets
In consumer products, unlike some enterprise products, there’s a big focus on simplicity and immediate value. In some ways, the idea of a “minimum desirable product” is kind of misleading because highly desirable products may also have minimum featuresets also, perhaps even more minimal than an MDP. The important part is that they are the right features, and in fact, it often takes a longer time to simplify your product and boil it down to the core value. I think that’s an interesting paradox that exists in consumer products, and one that I didn’t grasp for a long time.

Learning about your business and learning about your product desirability are different things
One of the interesting points that came up yesterday was that if you view your company as a learning machine to validate your business before you run out of money, then you may see that worldview clash with wanting to deliver maximum product desirability. In many cases, shipping a 50% done feature may teach you a ton about the market, and very quickly you will learn what you need and want to move on. The problem is, it may turn out that going from 50% to 100% in user experience actually continues to increase value to the user, by making things more refined and more compelling, even if you stop learning about your business. This is a hard thing to trade off, and requires situational judgement. As Steve noted during yesterday’s discussion, deciding when you stop and just consolidate and refine what you have, versus packing in new features – well that’s the place where entrepreneurship is an art and not a science

OK! Back to blogging vacation See you guys later.

Just a quick FYI on an upcoming conference – here’s the details if you’re interested:

Startup Lessons Learned is the first event designed to unite those interested in what it takes to succeed in building a lean startup. The goal for this event is to give practitioners and students of the lean startup methodology the opportunity to hear insights from leaders in embracing and deploying the core principles of the lean startup methodology. The day-long event will feature a mix of panels and talks focused on the key challenges and issues that technical and market-facing people at startups need to understand in order to succeed in building successful lean startups.

• Conference agenda
• Speaker list
• Where it is

I’ll be on a panel on Minimum Desirable Product with Dave McClure and others. We’ll be talking about the dynamics of incorporating design into a lean startup methodology, with all the difficulties and tradeoffs that entails.

25% discount if you use the link below:

Register for the conference.

I’m on blogging break right now, but I may expand the below notes into a series of posts when I have more time. Brb!

–
How to get have sustained viral growth:
– Have a great product (ideally in communication or social content)
- Convert user growth ideas into Excel-based hypotheses and clear user funnels
- Build and track each step of your funnels
- Get an initial stream of traffic (Adwords is OK)
- Optimize until every user is bringing in a new user
Timeline: weeks to months

Getting scientific about user acquisition:
– Start with your laundry list of acquisition ideas
- SEO, tell a friend, Twitter, etc.
- Convert into 2-3 testable hypotheses
- “Buy users for $1, monetize at $5″
- “20% of registered users will import addressbooks, >5 of their friends will register”

Viral loops in SaaS/enterprise
- What things do people share? What tools do they use for communication?
- files, wikis, Outlook, Excel, USB keys, etc.
- These are your viral channels (vs Newsfeed/Notifications on Facebook)
- If your value prop can align with a channel, then you might make it viral
- Case studies: Yousendit, Dropbox, Wikis, Basecamp, etc.

How quick-hit viral loops work for consumer products
– Cialdini’s “Influence: The Psychology of Persuasion”
- Quizzes: Social norms
- Top friends, eCards: Reciprocation
- 8 invites left: Scarcity
- But what’s the followup?
- Hide quoted text -

Value propositions for viral loops
– Best value prop is like Skype
- great for both parties (inviter and invitee)
- build deeply into the product (takes 2 to tango)
- Worst value prop is like lots of FB apps
- little to no value for the inviter/invitee
- lots of churn, feels spammy
- Sustainable viral growth is key for long-term value creation

Different acquisition models work for different kinds of businesses
– Vertical social networks -> SEO/SEM
- SaaS/enterprise -> SEO/SEM
- Consumer/communication/social content -> viral
- Themes, decorations for blogs/profiles -> widgets

Optimize your funnels by brainstorming levers
– Lets say you have funnel of Signup -> Download -> Install -> Fill out profile
- Lots of ways to improve
- change the order of steps
- remove steps
- combine steps
- use lightboxes, or longer pages, or progress bars, or lots of other UI tricks
- To optimize just the download-to-install step, you have dozens of options
- headline
- button placement
- “hero” photo or video
- target their OS
- size of download
- AIR
- small installer vs all-at-once
- installer filename
- etc.

Books and more resources
– Adam Penenberg, “Viral Loop”
- Robert Cialdini, “Influence, The Psychology of Persuasion”
- Tim Ash, “Landing Page Optimization”
- David King and Siqi Chen, “Metrics for Social Games” (Slideshare)
(lots of other resources on Slideshare)

Congrats to my sister Ada Chen, one of the first 10 employees at Mochi Media. I introduced her to Jameson (Mochi’s CEO and co-founder) back when she was first moving down to the Bay Area, and she turned down many other opportunities to go to Mochi. I remember she said she really loved the team, the opportunity, and thought she would learn a lot – which she has. I’m very happy it worked out for her. You can congratulate her at @adachen. (Oh and she’s also getting married this year to @sachinrekhi, another startup guy – congrats on that as well!)

From now, I know people will say, “omg you’re Ada Chen’s brother?” It’ll be great.

When I first moved down to the Bay Area, I originally met Jameson, who was nice enough for me to crash at his old place in the Mission to attend the GDC. He ran Mochi off of a couple tables in his living room, where he lived with Bob in a work/live condo. They’ve gone a long way since then! Congrats to Jameson, Bob, and the rest of the team – well deserved.

Here’s some of the breaking news from the Wall Street Journal:

BEIJING—Chinese online game developer Shanda Games Ltd. agreed to acquire U.S. online game network Mochi Media in a deal valued at $80 million, furthering its global expansion ambitions.

Under the deal, which the companies expect to announce Tuesday, San Francisco-based privately-held Mochi will receive $60 million in cash and $20 million in shares of Shanda Games, a Nasdaq-listed, Shanghai-based company known for creating some of China’s most popular massive multiplayer online games.

…

Also more here at Techcrunch and Paidcontent.

Interaction design and rapid prototyping
Recently, I’ve been on a big kick to develop a much stronger opinion about design, particularly interaction design, and to build products prioritizing desirability over a business/metrics/optimization point of view. I’ve recently wrote about this perspective here.

Here are some of the books that have helped me in my thinking:

Inmates are Running the Asylum
This is probably my favorite book that I read all year. Alan Cooper’s classic book that builds a business case on creating products from a user-centered view rather than business or technology. Introduces the definition of “interaction design” versus other design disciplines, the creation and use of personas, how engineers design software experiences, etc. Really needs to be updated for the agile programming movement, but still a very solid book.

IDEO’s Human-Centered Design Toolkit (PDF)
World-famous design firm IDEO published a toolkit documenting their human-centered design process. It’s longer than it could be because it lists all the methodologies inline, but it’s the deepest look inside IDEO’s design process that I’ve found. The important part is reading about how they go from user research to an insights framework to their “How Might We” questions that drive the creation of many low-fidelity prototypes. I’ve read a ton of books about personas but it wasn’t until I understood this process that I connected the dots on how to go from user research to prototypes to a final product – otherwise, it’s tempting for personas to become a useless artifact that doesn’t drive the product creation process. Read this, but my tip would be to skip through the methodologies on the first read – it’ll make more sense. Also, here’s a related PDF from the Stanford d.school here.

The Design of Business: Why Design Thinking is the Next Competitive Advantage
Artful Making: What Managers Need to Know About How Artists Work
Both of the above books cover similar ground, on how to relate innovation to the broader framework of ideating, designing, deploying, and growing successful products. In Artful Making, the discussion is around “artful” versus “industrial” processes, the former which emphasizes learning by doing and rapid prototyping, versus the factory floor process which emphasizes reliability and efficiency. The Design of Business looks at new product design as the process of moving from “mysteries” (new markets, new ideas) to “heuristics” to “algorithms” to “code” (efficiency-oriented, repeatable processes). The common idea from both books is that new product innovation is very different than metrics-focused efficiency processes, and shouldn’t be treated in the same way. That’s not to say you can’t have a strong, deterministic process around design innovation, but it just requires a different way of thinking.

Serious Play
This book deserves a much longer writeup, since I found it incredibly fascinating. Serious Play is about the notion that spreadsheets are to finance what mockups are to product, and what rehearsals are to theater. They are all models (or, if you prefer, prototypes) that allow people to simulate the future without incurring the full cost of actually doing it. The book touches on many of the first and second degrees of using spreadsheets, clay models, and other artifacts to drive decision-making, including politics, imperfections of models, and what kinds of industries excel at rapid prototyping versus others. Before reading this book, I never really saw the connection between spreadsheets and design mockups, but the author makes a compelling case linking the two as simulation tools.

About Face
Alan Cooper (see above) wrote a more tactical book about the actual “How To” around his Goal-Driven Design process, as mentioned in Inmates are Running the Asylum.

Just for fun
The below books are not necessarily related to startups, but I found them fun and compelling to read.

The Monk and the Riddle
Randy Komisar, a partner at Kleiner Perkins, wrote a philosophical book on life and startups a few years back that I would highly recommend. The core of the book is the idea that too many people try to live what he calls the “Deferred Life Plan,” where you do something you don’t love with the plan to eventually get to your real goals.

Coders at Work
Different profiles of engineers who have worked on important software projects.

The $12 Million Stuffed Shark: The Curious Economics of Contemporary Art
An economist dissects the world of contemporary art, the different players, what drives the economics, etc. I found this interesting from the perspective of art as a virtual good – his view of what causes high prices very much confirms this viewpoint.

Complications: A Surgeon’s Notes on an Imperfect Science
Atul Gawande provides a deeper perspective on what medicine is really like – the mistakes, the uncertainty – all the things you don’t really want to hear as a patient

I also have an older book list here.

Want more?
If you liked this post, please subscribe or follow me on Twitter. You can also find more essays here.

A large number of them related to freemium, which tells you how much interest there was in making money in 2009 Perhaps with the economy returning, there will be a shift of interest towards growth again.

Enjoy.

1. How to create a profitable Freemium startup (spreadsheet model included!)
2. Built to Fail: How companies like Google, IDEO, and 37signals build failure-tolerant systems for anything!
3. Free to Freemium: 5 lessons learned from YouSendIt.com
4. Product design debt versus Technical debt
5. Friends versus Followers: Twitter’s elegant design for grouping contacts
6. 5 warning signs: Does A/B testing lead to crappy products?
7. Freemium business model case study: AdultFriendFinder ARPU, churn, and conversion rates
8. Which startup’s collapse will end the Web 2.0 era?
9. 2009 conference schedule for the digital media industry
10. Does every startup need a Steve Jobs?
11. Why low-fidelity prototyping kicks butt for customer-driven design
12. What if interviews poorly predict job performance? What if dating poorly predicts marital happiness?
13. How to calculate cost-per-acquisition for startups relying on freemium, subscription, or virtual items biz models
14. 5 crucial stages in designing your viral loop
15. Age (and ARPPU) ain’t nothing but a number: Data on how age impacts social gaming monetization

To all my subscribers, thank you for reading!

To summarize the main differences:

• Big blue buttons for everything
• Drill-down sidebar after a search
• Emphasis on filtering by time – so you can get the “latest”
• Search across their properties, including News, Blogs, Books, Forums, Shopping, etc.
• Features I haven’t seen (except in labs?) such as Timeline, Related Searches, Wonder wheel, etc.

Really a ton of changes!

Here are the photos: First, the homepage…

And here’s a search results page after an egosurf:

Here’s the expanded sidebar:

There are lots of changes, you can check out all the screencaps below:

UPDATE: Interesting – I’m noticing that the sidebar is switching between all text vs icons + large text, on a page-by-page basis. Plus they are changing the content around by quite a bit. Seems like they are still testing the exact nature of the sidebar.

Want more?
If you liked this post, please subscribe or follow me on Twitter. You can also find more essays here.

I had a recent quote in the NYT article on the Fitbit, and wanted to give a couple quick thoughts about using the device so far. (This isn’t a gadget blog so posts like this will be far and few between).

In general, I love the form factor and the fact I can clip it on and pretty much ignore it for the rest of the day. People that I show it to always remark on how small and cute it is, and I’ve gotten several tweets on how they’re jealous that I have on already. One funny thing is that I find myself checking it absent-mindedly the same why I check FML on my iPhone. In general, it has made me much more aware of my incredibly sedentary lifestyle, and the daily goal of 10,000 steps is a tough one to hit. I’m usually hovering around 5-6,000 steps at most, and have to actively work to get to 10,000.

The web integration is nice although I don’t find myself checking it that often. They just recently added some social features to it, and I’m sure when my girlfriend, friends, and family get these devices it will be fun to see how I am doing relative to them.

Anyway, it’s a basic device and does exactly what it’s supposed to do really well. I’m excited to see when it gets more gadgety and does more with the data.

For a more detailed review, check out the Engadget review or the CNet review.

What’s a minimum “test” of your product? And what are you testing?
A hypothesis-driven approach to product development dictates that you build as much as you need to test our your product, but not more and not less. But what are you “testing” your product for?

One possibility, as lean startups guru Eric Ries has stated, is to test your product for “viability.” He’s coined an important term, called Minimum Viable Product, and I’ll excerpt his excellent blog post below:

The idea of minimum viable product is useful because you can basically say: our vision is to build a product that solves this core problem for customers and we think that for the people who are early adopters for this kind of solution, they will be the most forgiving. And they will fill in their minds the features that aren’t quite there if we give them the core, tent-pole features that point the direction of where we’re trying to go.

So, the minimum viable product is that product which has just those features (and no more) that allows you to ship a product that resonates with early adopters; some of whom will pay you money or give you feedback.

He goes on to state that another example of this idea would be to set up a landing page and test for clickthrough rates and signup conversions, to see if there is any interest in the product. You could also stick a priced offer on the landing page to see how that affects peoples’ interest in registering for the site.

Viability is certainly one bar you can test for, but a related (and overlapping concept) is around testing product desirability. Let’s discuss this further.

Viable versus Desirable
In a previous post, I discussed an IDEO framework for how to think about desirability (user-focused) versus viability (business) and feasibility (engineering) – you can read that post here, called Does every startup need a Steve Jobs?

The idea here is that different companies often pursue products with different primary lenses – a business-driven company might try to assess viability upfront, thinking about metrics and revenue and market sizes. A feasibility (engineering) oriented organization might try to pick a super hard technology first (P2P! Mapreduce! Search!), then try to build a business around it. And a desirability-focused team might focus first and foremost on the target customer, their context and behavior, and build a product experience around that.

Thus, a Minimum Viable Product tends to center around the business perspective – what’s the minimum product I have to build in order to figure out whether or not I have a business? You might do that from testing signups on landing pages, try to sell products before they exist, etc. Putting up price points and collecting payment info is encouraged, because it helps assess the true viability of a product.

But what if you come from a human-centered perspective, and you want to build the Minimum Desirable Product? I think this is a subtle difference with big implications. A minimum desirable product (MDP) would focus primarily on whether or not you are providing an insanely great product experience and creating value for the end user.

Let’s define it as such:

Minimum Desirable Product is the simplest experience necessary to prove out a high-value, satisfying product experience for users

(independent of business viability)

To build an MDP, you will have to actually deliver the core of a product experience so that your customers can make a full assessment, rather than simply providing a landing page. Instead of measuring YOUR conversion rates and revenue generated, instead you might figure out the metrics of what benefits you are providing to the user. (I wrote about Benefit-Driven Metrics a while back) Similarly, you might make extensive use of qualitative research techniques such as the ones detailed by IDEO’s methodology card deck.

This also relates very much to Marc Andreessen’s definition of product/market fit, which he defines in purely market “pull” terms and not based on business ideas or viability. You could view the the Minimum Desirable Product as the simplest product that has a credible shot at providing that product/market fit.

Examples of MVP versus MDP
Let me make some quick distinctions about sites that might be Minimum Viable Products, but perhaps not Minimum Desirable Products, and vice versa.

• If you build a really viral social network that is profitable but has terrible user churn – you have built an MVP but not an MDP.
• If your profitable dating site gets lots of users to buy subscriptions at $20/month, but none of them find hot dates they were promised, you have built an MVP but not a MDP.
• If you build a magic box that spits out money whenever you hit a button, that is certainly desirable but not viable at all.
• If you create an amazing board game that your friends and family love and are addicted to, but you can’t get a game company to distribute it, you have created an MDP but not an MVP.
• If you have created a website with 20M+ uniques/month where people can tell each other what kind of sandwich they are eating, that has probably passed the desirability test but not the viability test.

(btw, I am writing this blog while drinking a soy latte at Cafe Epi in Palo Alto, but not eating a sandwich, for those who are curious)

Is desirability more important for consumer internet startups?
One of the key reasons why I began to think of this question is that it strikes me that consumer internet companies often don’t care much whether or not they have viable businesses in the short run. If you are building a large, viral, ad-support consumer internet property, you just want to go big! As soon as possible! This is particularly true for ad-supported sites where you need to break through a certain size to start talking to the brand ad agencies who can pay up on CPM. (More on that here) As a result of that, the goal becomes to hit product/market fit as soon as possible, and figure out the business model later.

Similarly, the key risk for consumer internet startups tends not to be technical risk or execution risk – it tends to be market risk. That risk may manifest itself as questions on whether or not there’s enough consumer value, or whether or not the market is big enough. These are things that may be proven purely based on desirability-oriented questions rather than getting into the business or technical side at all.

Minimum Feasible  Product?
The last though I will leave you with is, perhaps there are markets where the engineering portion is the most important – and thus the most important concept of Minimum Feasible Product.

For example, for a drug company curing cancer, the focus wouldn’t be on minimum viable product because if you have a cure for cancer, you’ll be viable. Similarly, you may not focus on desirability, because your product would clearly have pull from the market. You don’t need to do landing pages or user-centered research to figure out that curing cancer is a big deal from a business and user point of view.

Instead, the focus would be on Minimum Feasible Product – what is the smallest amount of work necessary to field a credible candidate for an “in lab” solution to the product?

For consumer internet, perhaps there are similar examples of this.

Want more?
If you liked this post, please subscribe or follow me on Twitter. You can also find more essays here.

As all industry eyes look to the iPhone, the iPod Touch is quietly building a loyal base among the next generation of iPhone users, positioning Apple to corner the smartphone market not only today, but also tomorrow. In terms of Life Stage Marketing, the practice of appealing to different age-based segments, Apple is using the iPod Touch to build loyalty with pre-teens and teens, even before they have their own phones (think: McDonalds’ Happy Meal marketing strategy).

When today’s young iPod Touch users age by five years, they will already have iTunes accounts, saved personal contacts to their iPod Touch devices, purchased hundreds of apps and songs, and mastered the iPhone OS user interface. This translates into loyalty and switching costs, allowing Apple to seamlessly “graduate” young users from the iPod Touch to the iPhone.

An interesting thought, for sure.

Read more here.

David Shen, an Apple alum and now prolific angel investor, wrote me to chime in on my recent post on Steve Jobs.

UPDATE: I also heard from Kristee Rosendahl, who co-founded Apple’s Human Interface Group and worked directly on Hypercard, and posted her reply below as well.

I reposted David’s message below, with his permission, where he discusses the indirect effect that Steve Jobs has on the Apple design culture. He says Apple is still ruled by the business and engineering guys, but that his indirect effect is providing a central design vision as well as removing the politics around product design.

David writes:

great post, but i actually have a different viewpoint.

have you ever worked in a big org like apple? it’s filled with competing viewpoints, and is always run by business guys, never design guys. always design guys are relegated very far down the chain, and so thus engineering and business seem to drive the day on any decisions. this is often where we find “fake desirability”. [ed: fake desirability, which he defines "by this i mean that some people said they designed for users, but in actuality they only designed for themselves."]

when i was at apple, it was certainly better than other companies. but still it was a guy who used to be at IBM germany who was CEO at the time from 1990-1993, after john sculley was removed. and design reported still a level or two below the CEO, but lucky for apple the culture itself supported UX and its products were consistently better.

when steve jobs came, he killed the political bullshit that made great products even better. everything runs through him and if he doesn’t like it, it’s too bad. so you have to suck it up to work at apple, doing steve’s bidding or else you will not survive in there.

he is a design dictator of the company. and it’s fortunate for apple and the world in general, that they have him because without his ironhand, the company would soon devolve back into a political, consensus driven company. it would still have great products from a certain point of view, but i doubt that they would ever have the game changing, superiority they exhibit now. committees would grow, politics would ensue, control battles would happen, and superior products would be hampered by all this. steve removes all that; he makes the final decision and pushes details that no one else would have the authority to push. and being at the top, you have to listen to him or else you’re fired. that’s it; end of story.

and thank god he is right most of the time.

so i would argue that benevolent dictatorships are the best form of govt in the world, including both for companies and for countries, where one person has both the right vision and the ironhand/cut-thru-the-bullshit attitude and style to do the right thing. think if obama ruled the US like steve jobs. he would just do the right thing, and nobody could do a single thing about it.

the probability of another steve jobs occurring is vanishingly small. i doubt that another startup could produce a steve jobs. it is a combination of intelligence, market savvy, strong personality, and ruthlessness that makes him successful. not many people can exhibit all those qualities to make it work.

believe me i have seen people try. but they just end up pissing everyone off and they fail when nobody can work for them, or they think they have supreme market savvy but really they are exhibiting “fake desirability”. remember that steve took decades to develop his ability to this day; a 20-30 year old is very very unlikely to have enough world experience to be able to match that. so maybe you could say that zuckerberg or larry/sergey are in that camp. but there are other tons of people out there who are not. so the probability of finding someone like that (or being someone like that) is pretty darn small….

Very interesting…

UPDATE: David added some additional thoughts in the comments.

I should clarify that I don’t think that Apple is run by business and engineering guys solely now. I think it’s probably one of the most balanced orgs, power-wise in any corporation I’ve seen. What other companies have their head of design reporting into their CEO? I can’t think of any!

But CTOs almost always report into the CEO, and certainly the business structures, like business units, general managers, etc. always do.

Authority and importance are often driven by how high in the org chart you are. Having a voice at the table as high up as possible means you get to be heard and your issues taken seriously, and your influence felt. It also means that the CEO has now told the company: “the guys who report to me are also the most important to me. That’s why they report to me.” If the design lead does not report to the CEO, then how can design truly have a voice in the strategic decisions of the company? It could only be translated through the voice of his manager, and so on, upwards until they get muddied and washed out by the time they reach the top…or just lost.

A clarifying point about indirect design influence: 

I actually think Steve has a direct influence on design on many products, and that the effect of this design influence creates what I’ll call “design philosophy inertia” which propagates through the org, across product lines and down product lines. This is where his indirect influence can be felt. But it is clear to me there are products that he cares most about, and these he will put his attention on all the time.

As I said in the post above, thank god we have Steve. I doubt we’d see the world be filled with such superior products without him.

UPDATE: Some thoughts from Kristee Rosendahl below on Apple and what startups can (and can’t) take away from process.

My comments about Apple have to be taken in the context of when I was there 1984-1990, as things continue to change there like any company. After 1990, I’ve been an external observer of Apple’s culture, just like the rest of us.

I think Steve is a design dictator when it comes to the products close to his heart. The good news is that his approach and sensibility is so baked into the culture of Apple that everyone inside Apple considers themselves design advocates. So other products get the advantage of that. It’s an amazing example of how leaders set tone, culture, and priorities. When I went to work for Apple, even as a consultant first, they gave me this little cubical with a Mac. Then the person said be prepared for Steve to walk in at any time and ask you what you are doing. The implication is that I better be able to defend my work at any moment. That set a tone from day one! He never showed up in my office, but talk about creating an environment based on that.

I also think Steve is in his own class, because he is not only a designer, he is an incredible marketer. I agree with you though that there is still lots of room to improve and elevate design within an organization. The issue will be that most CEOs can’t really talk about design. There are almost no classes in biz school that really address design – I sure hope that changes. So most biz or tech guys running the show are not apt to go there, its not their language, and not their safe zone. One of the major ways I have seen companies overcome this is with two partners as head – one who handles the biz side but totally appreciates and respects design, and the other is the creative lead who has respect and can partner with a business oriented person. The other option is to hire a really good design lead. Mostly, though, companies hire consultants, or agencies. When the job is done, there is no one in house to keep advocating from the top…design has got to be on the executive team and by the water cooler to make it work.

[...]

I would add that, in this discussion about design, remember Apple is a consumer products company. Most of what they are lauded for is their product design, ease of use, delight, coolness, etc. Designing real products people carry with them, work on, and use for entertainment purposes, is a far different design effort than creating a social media website. While both require design, their development time, designer’s skill sets and to-market time are not similar. Sometimes we need to make that distinction when we talk about design efforts in various different kinds of companies and start ups.

When a CEO who is starting up an online business says they want their product ” to be as simple as Apple”, we all know what that means. What start ups forget is how many people’s efforts and hours go into making Apple’s products that clean and simple. In my experience, it has been a real challenge to convey how much longer a simple solution takes over a complex one. A truly simple and elegant solution just demands more time and cycles than most people understand. So I’m delighted when you can hear designers talk about their process and the timeline. A simple product demands patience, lots of iterations and hence, additional expenditures.

At the same time, I’ve unfortunately seen small companies and many startups waste thousands of dollars and person hours spinning about the design of the product because they don’t have a clear idea of the core benefit. So in the end, they could have spent the same amount of money but had a very different outcome – a much better product. They need to get better at doing their homework… see attached Seth Godin post.

This is what Jobs understands and why removing the corporate bs is so important. The company politics or personal aesthetics can take down a good idea or product in no time, even in a tiny company. David also talks about “design by consensus” and I think that’s part of any startup. The group is typically so small, that to leave someone out of the design process early on doesn’t emphasize the “team” spirit of the start up. This can be a big mistake. Not everyone is involved in other parts of the processes – I don’t critique code, for instance. I leave that up to people who are experts at that function. But many people want or think that being part of the design decisions is part of their inherited right as an early team member – it’s fun, distracting and everyone has an opinion. My advice for a startup is to be very careful about how the process is handled. As a designer, this is part of my role as well – to design the process by which this can all happen smoothly. In the end you can get a mediocre design by consensus that looks cool to the internal team but does nothing for the potential customer.

A product’s design success also depends on whether you perceive design as merely a decorative skinning of the product once its developed or as an inherent part of the product development process. I get calls all the time from companies who are launching in 8 weeks, the product is in development, and they need a designer to come in to apply some look and feel to it. This is the antithesis of how Jobs works. And it shows. And it impacts the financial success of the product.

I think we designers also need to keep doing a better job at being part of the development teams. I’ve seen many a designer complain about having to attend development meetings – they just want wireframes and then they can do their magic. I think this is partially why developers have taken on some design roles. And I want to say here, I consider developers designers in their own right! Someone has to make choices early on, and if a designer isn’t there, the product gets developed either way. Designers need to get more agile, iterative, and more transparent in what they do. Today’s products demand that of us.

Lastly, I’m including my absolutely favorite post from Seth Godin. I think it sums up so well many points that would help both startups and existing businesses get a little shot of that Apple DNA. Seth’s observations are a good summary about how equally important fostering innovation is vs being an innovator. Steve Jobs does both pretty well. For now, pick one role and do it really well.

[Seth's post on How to be a great client]

Thank you Kristee!

What does Steve Jobs really do for Apple?
I had a recent conversation on Apple’s incredible design culture and what it would take to create that in a startup. In many ways, it seems like an insurmountably difficult challenge to play the role of Steve Jobs, with his god-like sense of product aesthetics and interactions.

And yet, Apple has hundreds of products and experiences – hardware, software, HR materials, commercials, etc. Steve Jobs certainly doesn’t have time to work on the design of every Apple product, and of course has 35,000 employees to manage. So what does Steve Jobs really do, to create the amazing design culture at Apple?

And more importantly, can a startup hope to even start to capture the same kind of culture?

Well, let me give you my best guess

IDEO’s product framework for Desirability, Feasibility, and Viability
First, let’s take a quick detour and talk about IDEO’s perspective on new product development – this is documented as part of their 100+ PDF on human centered design, but also recounted to me by my patient girlfriend who works there.

The idea is that all products ultimately come from an epic struggle between three perspectives: Desirability, Feasibility, and Viability. IDEO focuses on new products from the desirability side, which means they think about how to make sexy products with clear value propositions, and think technology and business goals flow from that. Most of their Fortune 500 clients do not act this way, of course, which is why they have to hire IDEO.

Here’s the diagram included in their HCD toolkit:

The way this was retold to me is that these factors map into functional parts of a business:

• Viability = Business focus (marketing, finance)
• Feasibility = Engineering focus (technologies, agile process, etc.)
• Desirability = Design focus (customers, aesthetics, etc.)

Business-focused product perspective: Viability
For business-oriented products, the focus might be on any of the following:

• “hot markets”
• making money
• funding potential
• distribution
• metrics

The idea there is that you get to a product via one of these first-order items. A business-oriented entrepreneur might identify a market, then try to come up with a product within the market – for example, “wow, Zynga is making $250M/year, and fish games are big. I should come up with a social gaming product too.”

I would also argue that “corporate” thinking (including MBAs and biz plan competitions) fundamentally revolve around this approach – the most important thing becomes the analytical discussion around the business, rather than the core user experience itself. Financial metrics and market sizes become the dominating point of discussion – I would argue also that most venture capitalists fall into this bucket.

The big “religions” in this perspective are frameworks like Built to Last, Crossing the Chasm, Customer Development, Blue Ocean Strategy, even Efficient Market Hypothesis. You might also count Six Sigma, all the stuff in McKinsey quarterlies, etc.

Engineering-focused product perspective: Feasibility
For technology-oriented products, the focus might be on the following:

• programming language and development stack
• cool technologies or libraries
• engineering processes (agile or otherwise)

For people who use this as a first-order filter, you might end up with a line of thinking like, “BitTorrent is really cool, how do we build a business around it?”

I would also put engineering processes like agile into this, because that can easily become a first-order item in how to build a product as well. Agile won’t work for every team, for every product, in every situation, and yet it’s viewed as an all-purpose hammer – does that really make sense?

The big “religions” in this perspective are frameworks are agile, scrum, open source, etc. I might also count the “ecosystems” like Rails as a unique culture with its own set of beliefs and conventions. Frameworks like “Lean Startups” ultimately combine both Business and Engineering goals, via Customer Development plus Agile.

Design-focused product perspective: Desirability
For design-focused products, the focus might be on:

• context, culture, and goals
• customer goals and product experience
• design aesthetics and interactions

The first-order filter in this case might be “Sick people go to hospitals and have a terrible experience – how do we improve that?” The tools employed at this initial stage might include user research, development of personas and user goals, and rapid prototyping to explore many product concepts.

The big “religions” here are led by Apple and their aesthetics and standards. And of course folks like IDEO and their “design thinking” ideas.

How business and engineering goals encroach on the desirability of a product
Reading through the above, perhaps you have identified yourself as prioritizing one versus the other. And in general, the prioritization of the three different goals drives what kinds of product experiences you can build.

From the perspective of making a sexy, highly desirable product, you’ll find lots of objections from business or engineering:

• “spending money on visual design is too expensive”
• “polishing a product will make the process too slow”
• “this product is boring to implement”
• “can you redesign this product so we can build it in 1 week sprints?”
• “this target user is great, but we want the product to be more powerful and support more audiences”
• “but Zynga doesn’t do this, can you just copy them?”
• “why build so many prototypes that get thrown away? That’s costly and slow”
• “if you added X to this product, it would put us into strategic market Y”
• etc.

How do you handle questions like the above?

All of them are great questions, and of course the right answer means you have to find a balance in the approach. But what is the expense towards the core of your product experience?

Back to Steve Jobs – what does he really do?
Long story short, my hypothesis is that Steve Jobs is one of the rare CEOs who is very focused on product desirability. In battles with the business and technology goals, desirability will almost always win out.

So his role isn’t that of a designer, but rather Chief Design Advocate. This means:

• he makes it clear that products should be “insanely great”
• he recruits a top design team, and protects them from competing goals
• he is willing to spend money, adjust technology processes, all for the goal of highly desirable products
• he convinces financial analysts, industry pundits, etc. that product design is very important

To me, the amazing part about this is: Any company can do it.

Maybe not as good as Jobs, but they can decide to make it a priority – but few companies do. With the pressure of quarterly earnings, what competitors are doing, and employee aspirational desires, the focus moves off of killer experiences for customers – that’s no good.

If the above is true, then any of us can be the Steve Jobs of our team. Start by prioritizing design and desirability, and place it on a better footing relative to engineering and business goals. Learn the tools, develop your own religion, and start building great product experiences.

It almost sounds so easy!

Want more?
If you liked this post, please subscribe or follow me on Twitter. You can also find more essays here.

Go here if you want to check out some of the threads going on. I’ve been following via the RSS feeds of new topics.

Here’s the info from the main site – thought I would give it a plug. The guy who runs it is named Rich Collins.

Let’s build a community focused on learning from lean startups.

I’ve recently been captivated by the ideas introduced by Steve Blank and Eric Ries. I’ve been reading their articles, watching their talks and listening to their podcasts. What I haven’t found is a community of other startup founders with a similar interest in lean startup strategies and tactics.

I would like to create a community centered around building lean startups. There will be a website with a forum, wiki, chat and Hacker News style social bookmarking. The focus will be on sharing battle stories and numbers from actual startup campaigns. I will also organize events for members to attend.

In true lean startup form, I created this website to gauge the interest in the formation of such a community. After 24 hours of having the site up, 131 people showed their interest by submitting their email address. As a result, I’ve created a Google Group where we can start the conversation.

Have fun! Hopefully there will be some interesting stuff to come out of it.

Incrementalism creates Technical Debt, and also Product Design Debt
Most startups these days build products using the various philosophies of agile – both in the formal sense but also the informal sayings of “deploy early and often,” “fail fast,” “ship and iterate,” etc. Coupled with A/B testing, customer development, and thinking through business problems in a scientific, hypothesis-driven way, you end up with a powerful cocktail of techniques to build a modern startup in the most iterative way possible. This kind of incrementalism is mostly great, and people should generally do more of it.

The interesting part is when you get a couple months into your product cycle. You often end up with lots of half-done experiments lying around, an infrastructure that isn’t built to scale, and a mishmash of code that needs to be refactored. Most engineers know that in this kind of a case, the best practice is NOT to rewrite your code, but rather refactor it continually and take down the so-called “Technical debt” so that it’s always under control.

However, there’s the other side of the coin, which is the product design. After you’ve added a ton of new features and stuck them all on the homepage, you create Product Design debt. The Amazon tabs at the top are a great example of this – you have a design philosophy built around tabs, you scale it as far as you can, and then you have to refactor your design.

Arguably, MySpace is a company that never paid down their product design debt, and their traffic has been impacted as a result.

Anyway, let’s dive into this topic more, starting with technical debt.

Technical debt
Most of my readers are probably familiar with the concept of technical debt, but just to re-summarize from this great article on the topic:

The first kind of technical debt is the kind that is incurred unintentionally. For example, a design approach just turns out to be error-prone or a junior programmer just writes bad code. This technical debt is the non-strategic result of doing a poor job. In some cases, this kind of debt can be incurred unknowingly, for example, your company might acquire a company that has accumulated significant technical debt that you don’t identify until after the acquisition. Sometimes, ironically, this debt can be created when a team stumbles in its efforts to rewrite a debt-laden platform and inadvertently creates more debt. We’ll call this general category of debt Type I.

The second kind of technical debt is the kind that is incurred intentionally. This commonly occurs when an organization makes a conscious decision to optimize for the present rather than for the future. “If we don’t get this release done on time, there won’t be a next release” is a common refrain—and often a compelling one. This leads to decisions like, “We don’t have time to reconcile these two databases, so we’ll write some glue code that keeps them synchronized for now and reconcile them after we ship.” Or “We have some code written by a contractor that doesn’t follow our coding standards; we’ll clean that up later.” Or “We didn’t have time to write all the unit tests for the code we wrote the last 2 months of the project. We’ll right those tests after the release.” (We’ll call this Type II.)

Of course, we are mostly interested in the second type. Eric Ries has a great article advocating for why it’s OK to Embrace Technical Debt. Another great article is from Joel on Software called Duct Tape Programmer. All of these articles are worth reading.

I won’t focus too much on the definition since those other posts do such a great job – instead, I think it’s worth talking about why an iterative approach tends to produce technical debt. I don’t think it happens all the time, but there’s always a temptation for it to happen.

Ultimately, the problem is that if you are trying to learn something about the business, and your technology is meant just to support that experiment, 99% of the time it’s not worth it to do things the “right way.” The reason is that you don’t know if something is going to work, and as a result, you don’t want to invest in scale or perturbing your entire codebase for something that might be disposable. So instead, you just put a 10% or 25% version of the product out there (now commonly referred to as the Minimum Viable Product) and do as little coding as possible to get there.

The problem is, when the feature is successful, very rarely is a team going to then go back and rewrite it – every experiment creates more questions, and the temptation is to move on to the next question.

Product design debt
A similar problem to this is Product Design debt, which impacts the user experience rather than the underlying technology. The same temptations that lead to technical debt also lead to product design debt, because it’s always harder to do things the “right way” and it’s almost never a rational investment of resources. Show me a site that has great visual appeal, and I’ll guarantee that they don’t A/B test.

Product design debt happens because of scenarios like the following:

• “I want to test this new feature, where should we put it? How about the tabs?”
• “Can we throw this experiment on the homepage and see if people click on it?”
• “Our navigation is kind of getting out of control, but if we fix it, most of the site’s features will lose a ton of traffic”
• “We just added a Lists feature and we want to promote it, can we just add a button next to everyone’s name?”
• “Yahoo just bought our startup and they are going to stick us on their homepage!”

(just kidding on the last one)

The point is, as a product experience grows deeper, at some point the initial design philosophy of just adding more links to a page or more tabs or more buttons just stops scaling. Yet it’s often hard to reorganize the whole site, especially if it means taking a short-term dip on traffic, so the “safe” thing to do becomes to incrementally add things until the user experience is horrible.

Kudos to Facebook for looking at their product and deciding that they needed to refactor everything first into a big newsfeed stream of “stuff,” and then all their features into a generic container of apps. They’ve also done a lot to actually remove options from the menu and navigation.

Why homepages becomes a Las Vegas visual experience
Incrementally-developed UIs that are never refactored often turn into a Las Vegas visual experience over time. Ya know, something that looks like this:

Why does Vegas look this way? I’d speculate that all these buildings are ultimately infringing on the public good of aesthetics, and light pollution becomes a tragedy of the commons. If all of those buildings were to power down, it may be that the relative distribution of business would remain the same, but we’ll never know since that will never happen

Important navigational areas like homepages, inboxes, notifications, etc are all the same way. Each incremental menu item is not a big deal, and provides a lot of value downstream, but a slight incremental cost. But do this enough times, and you’ll start to pollute the overall design aesthetic, which is a public good that all features share.

For startups, this shouldn’t be a huge problem because you should have a product person who manages the whole experience and can resolve the public good problem. But there’s a danger in bottoms-up startup cultures where anyone can throw up an A/B experiment, which on one hand is great, but on the other hand creates UX pollution. The other class of cultures where this becomes a problem is short-term optimizing cultures, which may have a “feature of the week!” they want to focus on, which they need to exaggerate each feature each week.

For established companies with multiple teams competing with each other, this may become a key problem because then it really is a public good within the company.

Product types that are most susceptible to design debt
Ultimately, I think product experiences that provide a million little features are the ones that need to watch out the most.

This means:

• Social networking and Community sites that want to unify chat, forums, polls, videos, blogs, etc.
• Portals that want to unify news, communication, tools, etc.
• Games that want to unify lots of different missions, communication, characters, revenue-generating activities
• Retail products that want to unify lots of product categories and SKUs
• Classifieds sites that want to sell lots of different services, products, people, etc

All of the above products are hard to design for because they are meant to be open and support lots of diverse activities, but refactoring the UI constantly becomes a strong need as the initial navigation paradigms probably will not scale.

I wrote an article a while back specifically on social community sites, called Social Design Explosion.

Ideas for when and how to pay down product design debt?
For entrepreneurs out there who are building metrics-driven products but also committed to a great user experience, I would love to hear when and how you pay down the product design debt. Please comment!

Want more?
If you liked this post, please subscribe or follow me on Twitter. You can also find more essays here.

Upfront design and agile don’t mix well
It’s an interesting problem to try and mix traditional design tasks – visual polish, user research testing, etc. – to an agile development process. A weekly development cycle doesn’t leave much room for several iterations of mockups, the immense effort of recruiting and interviewing users, and all these other important tasks.

Anyway, I was sent this recent link I’d encourage you to read on 12 emerging best practices for adding UX work to Agile development.

Here are the list of 12:

1. Drive: UX practitioners are part of the customer or product owner team
2. Research, model, and design up front – but only just enough
3. Chunk your design work
4. Use parallel track development to work ahead, and follow behind
5. Buy design time with complex engineering stories
6. Cultivate a user validation group for use for continuous user validation
7. Schedule continuous user research in a separate track from development
8. Leverage user time for multiple activities
9. Use RITE to iterate UI before development
10. Prototype in low fidelity
11. Treat prototype as specification
12. Become a design facilitator

In general, the best practices are about taking the down the level of fidelity in the design process and trying to work ahead of the engineers so that they get the fast feedback they need. Definitely worth reading.