Essential articles about product management

Lots of people write lots of articles about product management and startup strategy, but most just rehash content that originated elsewhere or are about winning the lottery.

Here’s some that I go back to often:

Startup Metrics for Pirates by Dave McClure of 500 Startups is a classic because it quantifies successful product design (Another, medium format; a longer format.

The One Cost Engineers and Product Managers Don’t Consider, derived from a talk by Kris Gale, VP Engineering at Yammer. Probably the most level-headed argument for saying “no” more often, where most people simply assume it must be true because Steve Jobs said so.

How Design Thinking Transformed Airbnb from a Failing Startup to a Billion Dollar Business, derived from a talk by Joe Gebbia. Most people are familiar with the “do things that don’t scale” myth of AirBnB, but the “Let people be pirates” part is arguably more valuable.

We don’t sell saddles here by Stewart Butterfield, founder of Slack.

The Law of Shitty Clickthroughs by Andrew Chen articulates why first-mover advantage applies to marketing, not product. Read alongside Marc Andreessen’s statements on product-market fit and this breakdown of how product-market fit is distributed across competitors.

And read all of Paul Graham’s essays. Some aren’t great, but most are worth it.

A/A/B/B split tests for improved certainty

When split testing with a web tool like Optimizely or MixPanel, you may sometimes see inconsistent results, even with relatively large result sets. At OpenSky, we sometimes see test cases’ performance converge and then swap places over time.

This is arguably the most likely outcome of a test: inconclusive results. (See Evan Miller’s “How not to run an A/B test” for a more detailed explanation of false positives in split testing.)

If your volume supports it, a quick solution is to do an A/A/B/B test (4 simultaneous tests, duplicating each option) instead of a simple A/B test. This way if either the A’s or B’s are inconsistent with their matching test case then you know the test is wonky. (It’s a somewhat easier alternative to running a test twice, at least from an implementation perspective.)

Developer team structures, and growth

Working with a dev team? Check out Scott Porad’s The Best Developer Team Structure blog post.

Notes that I’ve also found to be true:

  • Let people work on their passion
  • WIP is deadly (I’ve begun to recognize it as a likely indicator of problems with the goals, design, or passion)
  • 1 PM to 3-5 devs
  • Teams, not groups of people
  • Teams need time to gel
  • Teams have leads
  • Teams share dirty work
  • Coordinating designs is a hard role and requires lots of back n forth
  • Force people to share work

Money quote:

Okay, saving the most important things for last. As your organization grows, the most important things will be “soft management”. Things like documented organizational values. Documented, as in, written down somewhere on paper (by which, I mean, a wiki). Having your company’s mission, values and vision statement written down. Having your product strategy written down. Having your technical design written down.

Nobody, especially, pointy-haired bosses, wants to spend time on this stuff. Those people are fools. That’s why comic strips are written about them.

The fact is, these are the most valuable tools in helping coordinate teams of people to get a job done. People don’t think of these things as tools… they think of them as management fluff. But, that’s exactly what they are: tools. Devices which help get a job done.

These are the tools that allows large groups of developers to have a shared understanding about the job they are working on, and the expectations for how they are to complete it.

Models for defining a social network user experiences

As we’re making OpenSky more social I’ve been spending a lot of time looking at social networks and recently realized that social interactions on social networking sites can be reduced to verb-noun-verb definitions that:

  • Outline a share-object-consume chain
  • Have simple, well-defined verbs

Here are some examples of those definitions:

Twitter
Tweet links to click
Facebook
Share photos to comment on
LinkedIn
Post resumes to recruit
DeviantArt
Post art to fave
Meetup
Announce meetups to attend
Yelp
Review restaurants to visit

Facebook sort of breaks the definition with their shared focus on both loves and comments, but their feedback loop focuses on notifying sharers (and other commenters) of comments, so I think it’s the more central user experience.

The best share-object-consume chains are designed so the consumption gives the sharer direct positive feedback. In cases like Yelp where attending a restaurant doesn’t feed back to a reviewer, a scaffolding of alternative feedback becomes necessary. This is where Yelp beat Citysearch: their review tags and compliments are likely precursors to the reader visiting a restaurant. It’s a stretch to scaffold the feedback in this manner; Yelp nailed it with solid product design while Citysearch never seems to have recognized the problem.

Another goal for a successful network is making consumption easy, so positive feedback happens often, thereby encouraging additional subsequent shares. This is typically solved by going one step upstream from the consuming action to the indicator of intent: Meetup talks about members more than attendees (and Twitter focuses on followers more than clickers).

Abstracted in this way, social networks are marketplaces where sharers play the role of vendors and consumers are buyers. So social network design needs to solve many of the same user experience problems as marketplaces:

  • Is there a large population of interested consumers?
  • Is it easy for them to find good vendors (where “good” is a function of quality and relevance)?
  • Are consumables cheap to generate?
  • Is it easy to put consumables into the marketplace?
  • Is it easy to consume them?
  • Is it clear to what makes a consumable valuable?

All of this points to designing networks where there’s a clear way to share a specific object via a consistent, easy process, so that it can be consumed in a specific manner (and making sure that people want to consume that thing).

Growth School

A few months ago, I began to focus heavily on driving organic member growth at OpenSky. Since then we’ve seen significant gains to viral coefficient and we’ve only begun to scratch the surface.

Step #1 for anyone should be a hyper-detailed cohort report. Looking at organic growth, I maintain a day-by-day funnel report of how new users come through our system, both the inviters and the invitees. Record numbers at every point where a user can make a choice, because some growth tactics will have a positive impact in one area while damaging another.

Here’s a list of articles and that got me started in this area:

a. Andy Johns, previously from Facebook’s Growth team, explains things on Quora:

And another good growth page: What are some top strategies for conversion optimization?

b. Andrew Chen on growth

From an OpenSky perspective, ecommerce emails in inboxes seems like “the last war,” so we’re actively looking at alternative channels. Honestly, any marketing email is probably a “last war” – while still valuable, it’s a declining option so you need to look elsewhere.

c. Turntable explained by Quora:

d. Mint:

e. Badoo. I thought their recent NYC subway ads were beautifully designed as a “platform with a voice”, so I looked them up and it turns out they know a thing or 2 about growth:

f. And random answer re address book imports:

Dropbox product design

There’s a great thread on Quora about why Dropbox is more popular than it’s competitors.

The answers are not surprising but they are a great reminder of the product design essentials.

Here’s a magic quote from a competitor who tried to beat them in the market:

I ran into the CEO of Dropbox and asked him my burning question: “Why don’t you support multi-folder synchronization?” His answer was classic Dropbox. They built multi-folder support early on and did limited beta testing with it, but they couldn’t get the UI right. It confused people and created too many questions. It was too hard for the average consumer to setup. So it got shelved.

35 tips for writing for the web

During a meeting today someone said “writing for the web is easy, just use proper English!” Sadly, we all shook our heads and replied that no, writing for the web often means breaking the rules that you’ve learned through so many grammar lessons and style guides.

Below are some rules for better web and interface writing, courtesy of Jakob Nielsen and my own interactive product design experience. These are my strong opinions, weakly held – please post comments, corrections, and disagreements at the end of this article.

Here’s Jakob’s why we break the rules for better results. In summary, people scan web pages and apps instead of reading them word by word.

Create scannable text by using:

  1. the inverted pyramid style, starting with the conclusion, then supporting information, then background / framework.
  2. half the word count (or less) than conventional writing. Users read 20% of the words (28% at most). Total % read drops as word count increases.
  3. highlighted keywords (links and bold).
  4. meaningful sub-headings (not “clever” ones).
  5. bulleted lists.
  6. 1 idea per paragraph, in the first few words.

Here are some more “writing for the web” tips from Jakob:

  1. Users scan instead of reading (though new ereaders, e.g. the iPad seem to buck this trend).
  2. Best online content is linear, reader-driven, actionable content composed of specific, comprehensive data. Fragments trump sentences.
  3. Write numbers as integers (1) instead of text (one). It’s better to use “23” than “twenty-three” to catch users’ eyes when they scan Web pages for facts, according to eyetracking data.
  4. Your headline text gets 40-60 characters of attention. It must stand on its own and make sense when the rest of the content is not available.

More rules for writing for the web

These are my own basic style rules, based on ad hoc experience (and therefore shakier than Jakob’s).

Design interfaces for hormonal, ADD-addled adolescents. “What would the NY Post do?” Think tabloids, not novels.

  1. 1 action per page.
  2. 1 idea per paragraph. This typically means 1 sentence per paragraph, sometimes 2. A 4-sentence paragraph is almost always too long.
  3. Numbers, not words.
  4. Lists, whether numbered or bulleted, are your friend.
  5. People look at photos first, especially photos of people.
  6. It’s better to display nothing than default images or filler text.
  7. Semicolons are almost never okay.
  8. Short lines of text are easier to read. Lines of text generally shouldn’t be longer than 34 ems long. (An “em” is generally equal to the height of the typeface – it’s a measurement based on the width of the letter M at the text’s current size.)

You’re always better minimizing visual emphasis. Focus on using fewer words, so they aren’t all competing for the reader’s attention.

  1. You can center 1 piece of information per page. Centering breaks a design grid and thereby becomes the most important thing on the page.
  2. Stick with bold for emphasis.
  3. Don’t present text in all caps unless you know the reader will stop – it destroys the letterforms. Sentence case is best. Possible exception – small words in buttons.
  4. Italics are almost never a good idea. Italic sans-serif is a typographic foul and italics generally distort letterforms too much for pixelated screens. Stick with bold. If you need a backup, try changing your emphasis style to display a highlight color on the text rather than italicizing it.
  5. Use bold sparingly. Words, not sentences.
  6. Don’t use bold, italics, and/or caps together on the same word.

Links are often the victim of “form before function” design thinking. Keep links visible!

  1. Use a very different color from the text.
  2. Include verbs in links.
  3. Include the destination page title in the link.
  4. If you hide everything else on the page, the reader should still know what the link will point to by reading the link text.

Grammar for teh internets:

  1. Log in is a verb. Login is a noun. Same with sign in, back up, etc. You almost always use the verb form.
  2. A lot is always 2 words except when it’s a verb, which is probably not what you mean. Remember it this way: “a pound, a bunch, a lot.”
  3. “It’s” is the contraction, “its” is the possessive pronoun. Possessive pronouns never have apostrophes: his, hers, its.
  4. When creating possessive nouns, use “‘s” for singular nouns, even if they end with s, e.g. “my dog’s collar is silver” or “Chris’s tutorial is helpful.” The latter is optional in some books, but if you always do it this way (“‘s”) you’ll avoid some crazy coding whenever you have to build an interface that creates a possessive noun from dynamic values like usernames.
    Put an apostrophe after the s if the noun is plural and ends in s, e.g. “the 7 dogs’ collars were all silver” or “The Judds’ interview was full of shocking revelations.”
  5. 1 space after periods, not 2. Too much spacing creates visual “rivers” of whitespace within large blocks of text.
  6. “Everyday” means common, mundane, or pedestrian. “Every day” describes the frequency of an occurrence. I wish I could write an epic blog post every day, but I can barely squeak out an everyday post on a quarterly basis.
  7. “Anytime” means “at any time” but I don’t think it’s ever okay to write “at anytime.”

Notes from Kathy Sierra’s Business of Software 2009 conference presentation

I’m a huge Kathy Sierra fan, so I was delighted to have this chance to watch her speak. You’re better off watching this video of Kathy Sierra speaking at the 2009 Business of Software conference, but it’s an hour long, so if you’re in a rush you may find these notes useful – I took them while watching the video myself. Enjoy.

Kathy Sierra video

Kathy Sierra video notes

Before the purchase – sexy marketing material is aspirational.
After the purchase – help docs are not sexy, all about mastering the tools, not why you want to use them.
(Seems like Apple has mastered the post-purchase sexiness factor.)

misattribution of arousal – the brain can’t distinguish between something that caused a strong feeling and everything else around it, e.g. remembering music that played when something important happened in our lives.

Therefore, if you help someone have a great experience, YOU are linked to that great experience.

The more you learn about something, the richer your experience is with that thing.

You win when you create better users, not a better company / product / brand.

Word of obvious, not word of mouth. Don’t make users explain what they’re doing – make it obvious that they’re benefitting from your service / product. Make it obvious to others, and make it obvious to themselves. Get the user to upsell themselves.

Motivate users past the “suck zone” – get them to keep using the product even when it’s not pleasant / meaningful / awesome yet.
Kathy Sierra has discussed this before – find examples.

The superset game – make people better at the bigger, cooler thing that your product / service is a subset of. E.g. photography and self expression instead of just using your camera.

Make your user a superhero of your product / service. What would live on their shirt? E.g. Pivot Table Man.

Talk to the brain, not the mind.
Remember, it’s brain behavior (unintentional), not mind (intentions, goals). Lizard brain, not frontal lobes.
This is important because learning requires that we get past the (lizard) brain’s preference to only focus on fight / flight issues. Life-threatening issues.

“I will learn what I feel.”

What do people pay attention to?
– Emotions – fear, sexiness, etc.
– Cute things – babies, animals, etc.
– Faces.
– Narratives.
– Things that are unresolved.
– Anything out of the ordinary.
– Combo – cute things in trouble!

Brains prefer to conversation not formal.

1. Focus on what the user does, not what you do.
Don’t build a better X, build a better user of X. Alternative from Joel Spolsky: Help $typeOfUser be awesome at $action. If you focus on product you do too many features and disenfranchise users.
Not “what problem do we solve” but “what bigger cooler thing is enabled”.

2. Give users superpowers *quickly*.
Give them an 80 / 20 document – 10 important things as a newbie.

3. Offer better gear and help them justify it to others.

4. Motivate / inspire. Motivation is for things people want do do but don’t, e.g. using your product. What is the “stuck zone” that users are chilling in? This is the real reason they don’t upgrade – because they’re competent at the basic mode.
Make the right thing easy and the wrong thing difficult.
Peter Bregman – harvardbusiness.org.
Motivation comes from belonging to a group. What does it say about your user to be one of your users.

5. Make them smarter.
Exercise makes you smarter – oxygen to the brain.

6. Shrink the 10K hours (from Outliers)
– Show them the patterns.
– Shrink the hours.
– Help them practice while doing other things.
Bruce Wilcox – wrote an AI that could play go. As a result he became awesome at go.
– Make practicing the right thing sexy, fun – contests, games, etc.
– Include cognitive pleasures – thrill, discovery, etc. – look at game design.

7. Make your product / service reflect what the user really feels, e.g. lost / confused.
– Help & FAQ are not enough, b/c written for people who are in a good place.

8. Create a culture of user’s journey. The hero’s journey.
– Be the hero.
– Get people to ask and answer questions. No dumb questions AND no dumb answers. Recently-former-newbies are best for answering newbie questions.

9. Don’t insist on “inclusivity”. Passionate users talk different. Let top users be ass kickers and different. Don’t make them dumb it down.

Evolution of awesome: products -> referrals -> testimonials / benefits.
– “Look at this awesome thing I’m doing” -> “I’m awesome”

…and that’s it. Want more Kathy Sierra? Good luck – she’s disappeared again in what is a real tragedy, but I can’t blame her after everything she’s been through in the past few years. Fortunately, she’s kept the archive of her original blog, Creating Passionate Users, alive so you can find more great writing there.

Producty goodness – May 13, 2010

Interesting post by Andrew Chen:
http://andrewchenblog.com/2010/04/07/minimum-desirable-product-and-lean-startups-slides-included/
Min desirable vs. Min viable product. He advocates that a desirable product is better in some cases (high growth consumer-facing) than a viable product at the outset.

From his slideshare: the IDEO human-centered design toolkit. They offer 2 free downloads as part of the HCD:

  1. HCD Toolkit (PDF)
  2. HCD Field Guide (PDF)

From Dave McClure: startup metrics for pirates. A very in-depth slideshow on metrics that you can match to business success.

Matt Singley’s super fast, simple implementation of the easy power of the new Facebook APIs. I need to slap some of this Facebook stuff on Dub n Reggae – it’s summer so people are using the site! I’m considering using this Facebook Connect plugin for WordPress.

I’m also considering bumping CycloneRanger up to WP 3 so I can play with all the new toys. Also looking at Elastic Themes for design. I know it’s completely non-semantic, but most CSS layout frameworks use this methodology these days. Pragmatism 1, artistry 0.

I just got an iPad and am thinking about these “overlooked lessons about the iPad.” They’re not entirely accurate – the iPad responses aren’t snappy, there’s a significant border of nonfunctional screen space, and Win tried using the famous “Cat in the Hat” book app but couldn’t stop turning the pages backwards. Seriously, who designs an app for little kids and chooses provide “page forward” and “page back” functionality and then distinguish them only by the direction of a gesture? Sounds like a case of grown-ups designing to impress Oprah instead of designing for the end user (kids).

Also, while the point that the iPad represents a new generation of “lean back” devices (yay for media producers), the Good Experience blog overlooks the real strategic objective isn’t touch interfaces, it’s thin clients that are locked into closed cloud-based platforms. Touch screens will be commodity hardware in 2-3 years, if not sooner.