I’m very happy to finally announce that I’ve written and published a new kid’s picture book, Field Guide to the North American Mommy, with the help of an amazing illustrator, Elisa Hung.

You can find it on IndieBound, Barnes & Noble, and Amazon.

View fullsize

View fullsize

View fullsize

View fullsize

I travel quite a bit for work.  

I'm also mildly OCD, so I have a mini-ritual of sorts whenever traveling to a new city of buying a new Lonely Planet "Encounter" travel guide for that city before traveling there.

They're handy little books, pocketable at 6x4 inches.  They contain a condensed listing of major sights, restaurants and the like, with a decent detachable map at the back.  I appreciate the density of the information and also the slightly offbeat selection of places each editor includes which a more conservative guide might skip over.

The ritual part is that I enjoy adding a new book to my collection slightly more than I do using the things.  On my bookshelf, they are a visual representation of where I've been and gone, all in a nice orderly set, each city marked by a unique color on the spine.  When I arrive back home, I take the book out, place it next to its brethren and stand back to admire the set and reflect a bit on my trip.

I've gone so far as to buy a book for a city I've visited in the past and don't necessarily intend to visit again, just to pad the collection.  Some of the places I visit don't have a book in the series and so I am forced to buy one of their larger books as an ill fitting substitute, and this irks me more than I care to admit.  

Many people have this sort of relationship with travel.  One of the most cliche visual representations of a traveler is a weathered suitcase covered with stickers from various locales.  I know fellow travelers who collect kitschy souvenir spoons or refrigerator magnets in a similar way.

Ultimately, what we traveler/collectors are attempting to do is collect experiences, and yet, the actual experiences are often much more mundane and anti-climactic than our collections might belie.   

To the Product-mobile!

There are any number of travel products in the world, from television shows to books to websites.  All effectively seek to create a repository of information about places one could visit.  The good ones winnow down the vast world to a manageable list of places one should actually visit.  The best ones offer a glimpse into the experiences of people in those places, be they visitor or inhabitant.

That's all well and good, but in my experience, the place is really not the thing I'm after.  I often arrive at a location I've heavily circled in one of my trusty travel guides, only to be profoundly disappointed because it didn't match my imagined expectation of what it would be like to be there.  

It's the experience rather than the place that I'm after, and travel guides often lack clues as to how a traveler should engage with a place once they've arrived.  Also, some experiences worth having don't really have a locale at all.  Some exist in time.  Others can only be had by being with people.

So, how about a travel site that is focused on these experiences instead of just places?

What does an experience look like?  To me, the format for sharing an experience is a narrative and chronological description of a span of time.  Something like:

"I woke up in the early dawn, still acquainting myself with the time change, and bored, I grabbed my camera, hopped a train to Shinjuku station and walked around the neighborhood.  Tokyo is a very different place at 5am.  The bustling crowds are replaced by occasional pairs or threesomes of still drunk stragglers from the izayakis, squinting at the daylight as they stumble to their beds.  An army of somber men in little helmets and orange vests comes out to clean the streets and pick up bags of garbage set out the night before by the businesses and homes.  Most of the shops are closed and their garish displays of baubles shuttered behind steel doors."

This content should be richly linked to locations on a map, business listings, photos, and other related content.

The core use-cases for a minimum viable product would be something like:

• Contributor posts new experience. 

• Traveler searches for experiences related to a place, time or person. 

• Traveler "pins" an experience.

View fullsize

View fullsize

View fullsize

View fullsize

I'd eschew a commenting system in favor of a more simplistic bookmark/like system.  I think that provides the right degree of moderation without distracting from the content.  It may later still be worthwhile to provide a feedback mechanism for readers to interact with contributors, though I envision this as being a private exchange.

This "pin" system could also serve as a way for travelers like myself to collect those experiences that I've already shared with the author.  This may require a second "done that" pin that segregates future vs. past experiences, though I'd want to observe how people use a single "pin" feature before deciding on that.

Advertising is an obvious source of revenue, high-traffic travel content is generally quite valuable, though incorporating it would need to be done with some care lest it cheapen the experience.

It might also be interesting to consider a "pay what you want" or even fixed subscription model with revenue sharing amongst the top contributors.  This would greatly encourage contributors to post high-quality content and would foster a sense of innate value in the community that would lead to a more engaging experience.

To go to market, I'd begin by launching a closed beta, inviting notable travel writers/bloggers to try out the platform.  This would serve to create an initial nucleus of high-quality content and would accelerate the iteration of the design and function of the site towards the easy creation and beautiful presentation of that content.

The rest is left, as they say, to the reader.

Done?  Okay, perhaps not, but my takeaway from his book is that it's your responsibility to do anything and everything to find people with general intelligence and who work hard.  

That doesn't, on the surface, sound very complicated.  Our brains are basically hardwired to be able to make these kinds of snap judgments  and if Malcolm Gladwell is to be believed, we should listen to this intuition.  But then, why do the hiring practices of most of the companies I've worked for often fail?

I think one reason is the tendency for people to breakdown teams into roles.  They think of their teams as being made up of big squarish building blocks with pretty colors indicating where they belong in some grand scheme.  They jostle them around occasionally, repaint the blocks, write long winded job descriptions about them.  

And it's only natural, building a team is a thicket of interdependent decisions that have to be made promptly and at great risk/cost.  Theoretical physicists call this simplification process:  "idealization".

It's a perfectly reasonable way of solving complex problems.  And in the main, for a large company with a sizable base of employees with diverse talents, role-idealization is a reasonable enough approximation.  They can absorb a less than ideal person because there's a better chance that some arrangement of all the parts will be able to accommodate them (including the arrangement where you hide them in a corner so they stay out of the real team's way).  

But for a small team, one bad hiring decision can be deadly.  There's a reason why people use the euphemism "role-player" to denigrate a person who is useful for some specific task now, but will someday become useless.

A slightly better approximation for thinking about fit would be to think of roles in the same way we think about skills.  Each candidate is going to have some mixture of roles they can play, each with a degree of competency.  Instead of thinking about a person as "a developer", think of them like "a developer who knows how to manage people and run a project".  

Start by making a map of roles that are needed to be successful:  A base of product management, a dash of people management, a hunk of sales, and 2 cups of developer.

Then figure out how the multiple roles of the existing team fits together against that recipe.  Assuming you still have some gaps (and often you don't really, you just think you do because you have money burning a hole in your accountant, or because you're desperate to go faster) you are now ready to hire.

Sourcing multi-dimensional candidates is tough in a world where people search for jobs by role, job boards are all organized by role and recruiters filter resumes using role-related keywords.  You can try to play job description mash-up, "Project Manager/Developer/Marketer", and while this may attract just the right person, you're actually much more likely to just accumulate a blizzard of lower-quality resumes for each of the roles.

So choose a primary role, write the job description to emphasize that you're looking for a flexible candidate rather than list a litany of "responsibilities", and let your recruiter know that you're looking for people with a range of experience.

Once you've winnowed the candidates down, how do you go about interviewing them?

I've always been an advocate for measuring candidates by watching them do the thing you want them to be doing.  For development, this involves asking them to bring in a laptop with an IDE installed.  For product management, this might mean giving them a hypothetical product to build and asking them to create a backlog for it.

As you construct an interview loop, assign a person to each role you wish to test the candidate against.  Multiple separate interviews for any role you're particularly keen to fill.  Include a lunch or cool down interview with a leadership type, but think of it as your opportunity to sell your company to them as opposed to the more typical interview for "team fit".

What if you don't have an [INSERT ROLE HERE] to interview them for [ROLE]?  It might not matter.  Have someone who works closely with that role conduct the interview anyways.  A good developer will know what a great backlog looks like and a good product manager should know what great coding looks like.

After the interview, get all the interviewers in a room and have them secretly cast a yes/no vote for their interview.  Do NOT include the person who did the lunch/cool-down, as this has a high likelihood of being a false-positive/negative.  Briefly review what you were looking for in a candidate in the first place, then have everyone show their votes.  

There are no hard and fast rules on how to consolidate the feedback into a decision.  Sometimes one thumbs down is enough.  Other times the person is such a great find in one role that this trumps their unsuitability for every other role you care about. 

What you're looking for is for the group to come to a consensus on whether or not to hire.  The team should have a working knowledge about the challenges they're facing and you should expect a healthy debate about "what we need" vs. "is this person the right one".  At the end, if you can't reach consensus, then pass on the candidate.  Either you don't really know what you need yet or the candidate isn't really the one you need right now.

On the one hand, users of an application, as they gain expertise, demand sophisticated and nuanced features that allow them to do more varied tasks and create more efficient workflows.

On the other hand, new users to an application are intimidated by large menus and palettes of buttons that deter them from getting basic value from the application.  

More often than not, designers err on the side of features/functionality because they are necessarily experts of their own product and thus subjectively over-value those features that broaden and deepen the experience.

This, as some established product teams eventually learn, can be a recipe for failure as they race ahead of the mass of potential users waiting behind their early adopters.

One interesting way to look at this problem is to consider how, for people, choice can be a bad thing.  

At first blush, this seems very counter-intuitive   

In almost any domain, it always seems better to have more and varied choices.  More styles of clothing, more flavors of ice cream, more ways to get to work in the morning, more colors of paint.  And companies work very hard to give consumers these choices.

And there's no denying there are a lot of good things about choice.  

Novelty is one of the strongest human emotions.  So too is self-identity, and a plethora of choices allows us to construct for ourselves an experience to suit and, sometimes, identify it to others.  The t-shirt is one of the the most elegant vehicles of self-expression ever invented.  Imagine explaining to a Victorian how people would someday display, emblazoned on their chests, their current thoughts about philosophy, culture, and ideas.

And yet, people complain bitterly about the complexity and pace of change that these same choices induce.  We're punished each day by thousands of decisions, some important, some trivial, but many made poorly because of lack of time or energy.

The Rise of the Curator

I signed up recently for Bombfell.  Their service is to deliver you an article of clothing on a set schedule (i.e., monthly) and for a set amount ($69).  You choose some parameters for what you'll receive, like your sizes and preference for long vs. short sleeves, and a personal shopper picks something within those parameters and sends it to you.

I signed up out of interest for their model after reading an article, but after 4 deliveries, I'm quite enamored of them.  

The clothing they choose for me often falls somewhat outside of my standard repertoire, but not embarrassingly so.  As it turns out, this is exactly what I want, though I didn't know it when I signed up.

Another service I started using is Quarterly.  They provide care packages of curated swag, again as a subscription, selected by notable writers, entrepreneurs, organizations or other personalities.  I've yet to receive my first package (from Mark Frauenfelder), but I find myself anticipating it as I would a gift from a friend.

The thread that ties these two services together (and they with this blog post) is that they are fundamentally about taking away choices, rather than creating them.  And they do this while still retaining the novelty and self-expression that come with making good choices for yourself.  

Curation is a bit of a buzzword, even though it's a concept as old as media.  The lasting engagement of broadcast television despite the near-infinite choice available online, is an example of successful curation.  Any story, whether told to friends or written down in a book, is really just a curated set of experiences, arranged to clearly express a larger idea or emotion. 

Both remain compelling, in part, because they liberate their audiences from the tyranny of making endless choices.

When designing a product, it's worthwhile to consider the "cost" of choice in your design.  Walk through your most important use-cases and:

• Score -1 point for each choice the user is presented with.  And, yes, every widget on that toolbar is another choice.
• Score -2 points for each time a user is forced to choose between multiple options in order to continue.  
• Score -5 points for each instance the same choice is presented multiple times without regard to what a user has previously chosen.  
• Score -10 points for every choice that has serious repercussions if made badly ("Do you want to save that?  Yes/No/Cancel", I'm looking at you..)

On the positive side. consider how your application can make good decisions on your users' behalf.  Use your expertise of the domain and your product to provide a guided workflow that shows the user how to work or play without wasted steps.  Share your deep and nuanced perspective of your content by providing curated spaces where users can passively discover and absorb it.

Done well, good decision making on the behalf of the user, like Bombfell and Quarterly, can be a wonderful product in and of itself.

I find this to be roundly unfair. 

Okay, yes, over a pint, I'm more likely to argue with you than agree with you, that's true.  And yes, I tend to be rather critical, and vocal, about things I think could be going better.  I just like to be convinced of a thing before I believe it.  But once I believe a thing, I become its earnest champion, arguing for it and vocally criticising all that...

Okay, perhaps they have a point.

I know the exact moment when I turned.  I was standing at a podium in high-school.  My first debate.

Debate

For the uninitiated, formal high-school debate, the kind the National Forensic League gives out certificates of achievement for, is a peculiar institution.  

It's a highly structured speaking format with lots of rules and lots of insular jargon.  It has about the same relationship with a lively argument as chess does with a fist fight.

There is a resolution is chosen at the beginning of each year that forms the major premise for all of the debates that follow.  My year it was (from Wikipedia): "Resolved: That the United States government should reduce worldwide pollution through its trade and/or aid policies."

An Affirmative team posits arguments in favor of the resolution while a Negative team looks to undermine or refute their claims.  Judges decide a winner based on whether enough of the Affirmative team's arguments are left standing after a few rounds of discussion.

The peculiar part is that to win, you don't have to be right.

Instead, the goal was to be the one with the best Evidence.  Each team in a debate brings with them great stacks of index cards with bits of text glued to them.   These make up all the arguments, counter-arguments, counter-counter-arguments, and counter-counter-counter-arguments that you'll need.  The best teams obsess endlessly about Evidence  and you could generally size up an opponent based on the size of the stash they hauled into the room with them.

Back to the Podium

I was on the Negative.  I'd just heard the Affirmative opening arguments, something about how the US should promote nuclear power, and being pre-curmudgeon at that point, I was quite inclined to agree with them.  Their points seemed perfectly valid.  Nuclear power seemed to be an elegant solution to the world energy problem.  While it had/has problems to be addressed, there's no reason why these technical problems couldn't be solved, in time, with better technology.

I suppose I could have just walked off and dropped the class, but I recognized this as a game, and I liked playing games.  I was good at games.  And also being a good student, I had collected many pieces of Evidence to counter this specific argument, so had a chance here and now to win the argument, even if I believed I was wrong.  

So I launched into a rebuttal of each of their arguments, hand waving and pausing for effect while the Affirmative team scurried about trying to find the index cards with the right counter-counter-counter-counter-arguments.

We won that debate.  My partner and I won all the debates that year.  

(This is nothing particularly to brag about.  This was debate class, not debate club.  The bush leagues of debate.  My teacher later lobbied me to join, but I ignored him because it would have interfered with football, which TV had lead me to believe led to girls, and, well...puberty is its own best rebuttal.)

It was at that moment, for something as silly as wanting to win a game, I began to learn how to suppress my emotional and subjective beliefs from the exchange of purely objective ideas.  Or perhaps more properly, to temporarily direct and shape my beliefs towards a contrary viewpoint to allow me to argue it more strongly and convincingly.

Pessimism About Products

As it turns out, this is a wonderful skill to have.  

Very often, we are put in situations where our beliefs are put into conflict with cold hard reality.  The revenue projections that were missed, a heartfelt promise you made to your team but couldn't keep, or a customer looking confused and concerned at your product roadmap.

In these situations, there is a strong temptation to externalize and rationalize what has happened.  The market wasn't ready, the team didn't work hard enough, the customer just doesn't get it.  Its far better if you can be self-critical, take your lumps, and move forward with a newly straightened perspective.  Better still, if you can see ahead of time when your beliefs are leading you over the cliff's edge.

To an outside observer, this can appear to be pessimism.  Particularly if that observer shares the errant belief that should be changed.  

Most people loathe changing what they believe and fear the uncertainty that follows discovering that they are wrong.  They therefore loathe and fear the pessimist, who seems to be tearing away at the fragile veil that lets them act with confidence.

Those people squander confidence.  Yes, it can inspire a team to do remarkable things.  Terrible risks are sometimes only undertaken because of misguided confidence, and great rewards reaped as a result.  But if you deal in it, and it fails the test of time, you're marked a fool.  Being thought of as a fool is far worse than being marked as a pessimist.

Use confidence at the moment of truth, at the end, rather than the beginning.  When there's one last unimaginable leap to cross and you need the team to come with you.

Now, this isn't to argue that I should be forgiven all my trespasses as a curmudgeon.  I'm a creature of emotion as much as reason, just like the next guy.  Sometimes I argue out of bad habit, rather than any particular insight into a situation.  Sometimes I'm the starry-eyed true believer that can't see the imminent danger just in front of me.  

But, if you're not persistently and actively challenging your own assumptions, then you might try a little pessimism yourself.

Since they were canonized by Dante, seemingly every philosopher/writer/poet has at some point featured them in a essay, story or poem.  This is because they so succinctly encapsulate the motives of every terrible thing ever done by a human being to another.  

More than that, they describe the motives of everything ever done, good or bad, because what underlays them are the raw fundamental forces of our psyche.  You could describe personal fulfillment as somehow finding a homeostasis between them, lest one runs rampant and turns deadly.

So what can a mere product learn from all of that?  Here's a playbook for channeling each into lasting engagement.

Sloth

Okay, this one is a layup.  Everyone is lazy.  The busier you are, the lazier you must be, because every moment wasted on a clumsy tool is magnified 10 or 100-fold.  

Let your users be lazy.

Go through every important flow through your application.  Sculpt and shape every action to minimize time and reduce the number of decisions.  Strip away anything and everything until you can no longer remove any of the parts.  Help your users to magnify and amplify the results of every action they take.

Gluttony

Users always want more more more.  Whether, features or content, they complain endlessly about not having the button that does that thing, or why the doodad they were looking for wasn't conveniently on the nav bar.  Usually you fend them off, with a stick, because they can't see how it would harm the core value you provide, but once in a while, they are right.

There are elegant ways of giving it to them.  

Any content driven application without great search should be ashamed of itself.  It's one of the harder things to pull off because some content requires a lot of curation to make it searchable (video, audio, images) and even text content, especially structured data, has to be finely tuned for the search index to surface relevant results.  Spend the energy and time.  Use analytics to study how people use it.  Find out what they query for and tune your indexes to give better more accurate answers.

Feature laden applications, particularly those with necessarily dense drop down menus and preference pages, should focus on plugability and extensibility.  Is there a good reason why you need to build a calendar into your application?  Why not integrate with a Google calendar instead, even better, support the iCal standard so each user can bring their own.  There are a multitude of other products out there that offer richer functionality than you can provide and cost you very little to implement.

Greed

Money, truly, is a double edged sword.  You want it from them, they most definitely don't want to give it to you.  You can give it away for free, but then you debase the currency of value you've worked so hard to create.

Advertising is a way of selling a bit of your soul (and your users souls) to get some of it, and for some products, with large user-bases and fickle engagement, it's the only game in town.

Times are a changing though.  It's never been easier to take a payment online and people are getting used to opening their wallets online.  

The worst thing you can do is confront the user with a "Buy" button on the first page view.  Freemium and trial-periods are useful for widening the engagement funnel, though can be technically difficult to pull off.  Largish up-front fees can be split across a monthly subscription to lower the perceived cost and also give you incentive to create more lasting engagement.  Pay-per service applications can use first-time free incentives and punchcard-like loyalty programs to gain users and keep them coming.

Most importantly, build value and price appropriately.  Value stems from saving people time, facilitating transactions, providing goods/services, or just plain amusing them.  Figure out what value you're providing and find a parallel product to anchor your pricing against, online or sometimes physical.  Be careful not to mistake having poured your guts out to create a thing for a dispassionate user's willingness to pay.  If all else fails, don't be afraid to start a tad high though and use promotional discounts to test lower price schemes.

Lust

The sexual imperative is so deeply ingrained in all of us that it subjectively shapes everything.  I believe, if Google's search index ever becomes self-aware, it's first conscious act will be to laugh raucously at the human male's obsession with breasts.  Why should they be spend so much energy admiring two bodily protrusions that nearly every woman possesses, that are only really useful to newborn babies and otherwise cause women a great lot of trouble supporting, covering, revealing, augmenting, reducing, and sometimes risking their lives for.  

And yet, if you're a man, then nothing in creation could make more sense then that elegant equation that describes the gentle curve from shoulder to stomach.

This does not mean you should put tits on your homepage.  

Rather the opposite.  Sex is too powerful a force for you to wield responsibly.  Respect it.  Respect that a hormone addled teenager will inevitably post pictures of their penis on your site, respect that some people will want to have open discourse about subjects that others (or even you) will find offensive, respect that some people will want to pick the username "BallsDeep", respect that no viewpoint is invalid and foster a community of mutual respect.  Most especially, respect their privacy.

Wrath

There must be a thermodynamic equation for hatred.  I imagine that a college student "hates" having to wait 30 minutes for a pizza about exactly as much as a cavemen hated having to walk 5 miles to hunt an antelope.  This isn't to say we're spoiled, (though we are), more that we all have a certain amount of cussedness that has to be let out one way or another.

As a product owner, there are ways of channeling and harnessing that energy to create healthy engagement.  Providing a soap-box for your users to vent, whether about the driver who cut them off on their way to work or your product, is a way of delivering value in the form of emotional release.   

When their ire is directed at your product, it's an opportunity to learn from their pain.  Beware becoming a sycophant that react to every barb, but there is a sort of judo where you can turn your biggest detractors into your biggest proponents by simply promising a solution, then delivering.  

Envy

Envy gets a bad rap for being the most tasteless of all the sins.  Jealousy over what you don't have when you've probably got quite a lot, is after all, pretty base.  But the desire to compete is the fundamental force of all positive evolution, whether biological, social or technical.

Products must themselves compete for the over-saturated and multi-fractured attentions of users.  These days, a consumer-facing web application must compete, not just against similar products, but against every search result, every advertisement and every bookmark.

To do it, products should let their users wear the value they get from a product on their sleeve.  Nothing so contrite as a +1/Like button, or god forbid, a forced twitter post.  But with public forums and rich public user profiles that showcase their rich experience with your product.  When new or potential users see established users engaged with your product and enjoying themselves, they'll want in on the action.

Pride

Of all the sins, this is the one I'm most guilty of.  The need to feel just a little bit better than the other guy is hard to censor and easiest to luxuriate in.  I'm able to suppress it, for a time, in order to learn from and collaborate with peers, but there's still an insatiable hunger in me to do better/faster/cheaper than the rest.

Thus, it is one of the strongest ways of creating lasting engagement.  Users who take pride in using your product will form the nucleus for all your success.  They will be the standard bearers that spark viral growth on Twitter and Facebook, they will become the stable source of revenue that frees you to continue to take risks, they will brag about how they were there when and wear t-shirts with your logo on them.

People become proud of a product by feeling they've earned it.  This could be as simple as a badge for participating in a closed beta, as concise as a counter of posts, or as genuine as having their good idea get implemented and their name credited in the company blog.  It's about rewarding your users for their time and energy in making your product successful.

I have at least a dozen different idea caches in various physical and digital forms.

First and foremost, a chaotic stack of notebooks, of many sizes and variations.  A geological strata of ideas going back to spiral bound high-school notebooks to leather bound action item logs.  

On my computer, a semi-haphazard collection of files in folders:  ./writing, ./blog, ./fun/ideas, ./fun/ideas/blog, ./fun/ideas/projects, ./fun/writing, ./dev./projects

Online, I have notes stashed in Remember the Milk (RTM), Evernote, Google Docs, Gmail (3 accounts), Yahoo Mail, this Blog, and an older blog that I keep hidden (because I was stupider when I was 20).

They're on sticky notes on the wall, text messages to myself, they're in the margins of magazine articles, on the back of envelopes, notes scribbled into the wee bit of space on other notes, and on and on and on.

Organizing them is a hopeless endeavor.  After starting an organizational jag, I'm as likely as not to instead find myself writing yet more thoughts about the organizational process itself.

After some self-examination, it occurs to me that perhaps I don't care about the ideas at all.  I'm really only interested in the act of creating them, from thence to be cast off into the nether-regions of a notebook or hard drive.

And yet, there have been times that, moving an old notebook somewhere, a lonely little scrap of paper lofts into the air and upon re-reading it, it ignites a real project.

So, how to wrestle with this beast?

To be perfectly fair to myself, much of the cacophony is caused by my repeated failed attempts to tame it.  

I dove into Evernote a couple of times, in the hopes that digital storage/mobile apps/search might be a solution, but each time gave up on the terrible rich-text editing and cumbersome chore of managing a large note hierarchy.

I started using, and still actively use, RTM because I like the notion of ideas being actionable, but I'm not entirely happy with the number of steps it requires to keep any deeper level of detail about an item.

​I tried, but ultimately disliked Google Docs because the data types it supports have many of the downsides of maintaining a folder of documents, but without many of the upsides.  Google Drive might solve some of those issues, but I'm already using Dropbox.  Most of the rest evolved out of moments of immediate convenience, rather than any earnest attempt to use them for storage.

So, what is my product wishlist?

• Ideas should be like files.  I should be able to send them to someone, copy them, back them up.  I should be able to use any tool I like to produce them, Gimp, Sublime Text, Eclipse, PowerPoint  Lightroom, Excel, etc.
• Ideas should be relatable to other ideas.  If I have two very similar ideas, I should be able to connect them together so when I find one, I can also see the other.  I should also be able to fully encapsulate, and thereby hide, an idea inside a higher-level idea.
• Ideas should have flavors.  I should be able to lasso a bunch of ideas together and color them purple.  I should be able to endlessly sort and re-shuffle them whenever my worldview changes.
• Ideas should be concise and compact.  There should be a constant pressure to shrink and boil-down ideas into concepts that can more easily be kept in human memory and considered when making decisions.
• Ideas should have a lifecycle.  New and nascient ideas should undergo a churning process of honing/refining.  Older untouched ideas should sink to the bottom. 
• Ideas should have value and urgency.  You should be able to rank and prioritize your ideas, potentially in different dimensions.  You should be able to look at a pile of them and get a sense of what is important.
• Ideas should be templatized.  The general structure of ideas should be a thing in itself that you can use to efficiently capture new ideas or help refine old ones.  Creating a new idea take as little time as possible and should provide a skeleton to encourage turning fuzzy ideas into realizable ones.
• Ideas should be sharable.  Both in the sense of collaborative, but also the sense of extensible.  Another person should be able to expand and pivot an idea without interfering with the source.  The default should be that ideas are private.
• Ideas should be narrative.  They should be internally organized into a temporal structure where one part leads to the next.  They should be lists.  They should be stories.  They should be slide show presentations.  To be communicable, to others or a disconnected future self, ideas must provide a road map through the information.
• Ideas should be lovely.  Anything you touch many times repeatedly should be lovely.

I've really no idea how to gel these together into a cohesive product.  Some of these wishes seem mutually exclusive.  Perhaps, being my own customer, I can't see the forest for the trees.  

If I figure it out, I'll let you know...

​

It sort of worked like the merit badge system in a boy-scout troop.  Each competency had a page on the intranet that listed a set of skills associated with it and a test of some sort that you had to complete to prove that you'd achieved it.  Your mentor would work with you as a coach, cheerleader, and eventually, examiner.

Many of these competencies were hard technical skills, like:  Java, HTML, Bug Tracking.  Others were soft ones, like:  Task Management, Document Writing, Giving Feedback.  Even a few recursive ones, like:  Mentoring and Writing Competencies.

The tests to achieve a competency were generally focused on actually doing whatever the competency was about.  Need the Object-Oriented Design merit badge?  Produce a UML object diagram for an online web store.  Need Document Review?  Go review three documents.

HR maintained an online database that tracked what competencies each person had gained, and you could search for people by competency to find someone to mentor you or sometimes just because you needed someone who spoke German for a meeting with a client.  It also provided a sort of career progression tree that listed the required competencies for a given title. 

Want to get rid of the Junior part in your title?  Then you need to go get:  Java, Code Review, Document Writing, Task Management, etc.

At first, it felt a little silly.  But after the kool-aid sunk in, it turned out to be absolutely brilliant.  

You see, there are a lot of things that people desperately need to know to be successful, but are embarrassed to ask about or don't even know they need.  Most companies either try to hire people outright with these skills (see, tragedy of the commons) or toss people into the water, ass over teakettle, to find out if they sink or swim.

The Quidnunc system gave you a simple structure to follow with clear sign-posts to where you should be heading next.  It provided a support system studded with people who were genuinely interested in your progress.  It also established a type of meritocracy that strong technical folks thrived in.

My favorite thing, is that it gave teams a set of common experiences they could draw on to communicate.  I'm still appalled by how many leads/architects don't know UML.  I hated every bit of learning it, but when two people who understand the same visual language for expressing programming concepts get up to the whiteboard, everyone else stand the hell back, you are about to get a bunch of work done really fast.

So Where's the Product Idea?

Gamification, like any buzzword, gets thrown around quite a lot.  It's a gorgeous idea, but hard to pull off.  

Often, it's misinterpreted as making something that is dull...FUN FUN FUN!  But, anyone who's played a Zynga game knows how soulless gamification can feel to a user.  

My interpretation is that it's about leveraging the innate human need to complete patterns and make tangible progress to meet a succession of short-term goals with a long-term payoff.  

So here's the pitch:  Create a trusted online community for skill sharing.  

The core functionality:

• be a repository for detailed self-guided tutorials on how to master a skill

• be a social lobby for people to find and interact with mentors for those skills

• be the authoritative source for finding out what people are experts at

Breaking that down a wee bit, the primary use cases might be:

• Skill Seekers discovering new skills and connecting with Experts to mentor them.

• Experts providing advice/answers to Skill Seekers, encouraging their progression and ultimately evaluating them in tests to award them Expert status.

• Experts proposing new or amended tutorials for skills with an approval flow that involves the other Experts of that skill.  

• External Users searching for Experts in a particular skill to hire or consult.

Here's a mock-up of what the homepage might look like:

How to Make Money​

One way to monetize would be with pay-to-play participation from Skill Seekers, with a cut to the Experts and to the house.  This has a couple of up/down-sides.  The key benefit would be greater engagement from all parties.  The main drawback would be people trying to game the system. 

Another vector could be paid access to searchable user profiles.  The benefit of this would be that outside companies could subsidize the community, while the drawback would be limiting the value to skill seekers who want to maximize their skill profile. 

First Steps

First, you need to build some product, with an initial backlog that looks something like:  

• a collaborative workflow for creating a tutorial

• a catalog of tutorials​

• a searchable database of user profiles

• a collaborative workflow for progressing against a tutorial

Secondly, or actually in parallel as this will be the hardest part, is establishing a small network of experts who will form the nucleus of the community and create the initial tutorials.  It's important that this network be well respected and prepared to actively engage with new users.

Thirdly, time go to to beta.  Use the network of experts to create the seed content and use their stock of friends/colleagues to get the word out and build some buzz.

Fourth...profit!  Okay, there are a thousand details I've left out, but go re-read The Lean Startup and figure those out for yourself.

Opinions vary between:

• what team?
• ​the Ringelmann effect says 5
• I'll take as many people as I can afford​

I personally like a 3 person team.  

One of them should be an extrinsic/extroverted type who can build consensus and orient towards customers or executive management.  One of them should be a died in the wool hacker who will pull all-nighters for the sheer joy of writing code.  One should be a creative problem solver who can think around corners and design elegant but practical user interfaces.  

That doesn't necessarily mean one of each, in fact, it's vastly preferable if each person can hold down one or both of the other two roles in a pinch.  People do go on vacations, or get sick, or decide to quit to pursue their lifelong dream of being a musician.

3 is better than 2 because there's always someone to break ties.  3 is better than 4 or 5 because a larger group never really gets into the "zone".  That magical place where you have a whole day of pure productivity, barely speaking to each other but acting in perfect alignment.

​Another benefit of 3 over larger teams is the possibility of creating product diversity.  Instead of one team of 6, how about two teams of 3 working on decoupled products that serve related goals?  

Ah, but ​you say, why not have a team of 6 develop two products serially?  

Well, because of the law of diminishing returns for both time and risk.  Sure, you'll plan to deliver two products in six months, but in month four when you haven't quite worked out all the features in the first product, it will seem brutally logical to keep throwing the good money after the not-yet-bad.

​Plus, good products need time just as much as effort.  Customers will always come slower than you expect them to and the team will need time to marinate in the problem and marshal expertise with the technology and processes.

But you say, some problems simply can't be tackled by 3 people!  

I'm not so sure.  Every problem I've encountered can be broken down into smaller ones.  Sometimes these sub-problems are coupled, such that one cannot deliver value without the other also succeeding, but in these instances the successful team will probably figure out a workaround to buy the other team some time, or even make their sub-problem irrelevant.  

​And that last point is very important.  Resiliency to failure.  The survival rate from start of development to successful product is something like 40%.   Having more product teams building a diverse set of products greatly increases your chances of at least one being successful.  Ask any successful VC how many baskets their eggs are into.

Subjects were grabbed at random from the flagship store and offered a modest gift card to participate in the study.  Each subject was brought into a small room with a kiosk in the center and a large two-way mirror on one wall.  

A facilitator would begin by warmly thanking them for participating and guiding them verbally through a pre-scripted set of actions.

"You can load electronic coupons onto this card, try to use the kiosk to load a couple onto it...", while handing them a prototype card.

The person would take the card, peer at it oddly, and gamely try sticking it into...the printer slot, look embarrassed, then find the correct opening.  The facilitator would be careful to look placidly unhelpful no matter what the subject did.  On-screen, they'd touch the "Load Coupons" text label next to the big button...wait a moment...touch it again...wait a moment...then finally touch the button.  

On the other side of the mirror, half a dozen people sat in rapture.  A row of three usability high-priests sat hunched over microphones immediately in front of the mirror.  They'd whisper intently, "the subject has tried to insert the card into the wrong slot" and "the subject is having trouble finding the coupon button", while a dozen video screens showed the action from various angles.

It was fascinating, and slightly gut wrenching, to watch a real person flail at the thing we'd worked very hard on for months.  Your first instinct is to blame the subject for "not being computer savvy", but eventually it sinks in that you have to do better.

The study resulted in a dryly written report that lived in a massive binder that weighed 15 pounds.  An imposing and technical-jargon filled document that, ironically, was itself far less usable then the application it was studying.  

I'd guess that I only ever read about 10% of it, and yet, the experience dramatically altered my perspective about products and the importance of user experience.  Products are only as good as their interfaces, and letting a real customer play with it can tell you a great deal about how to make that interface better.  Not by asking them for feedback, but by simply observing them and watching your application fail them, sometimes in the most basic of ways.

Being a network process, as opposed to a procedural one, the difficulty of the problem increases as the number of degrees of freedom increase.  The classic example of a network process is the "Traveling Salesman Problem".

This is why art teachers don't assign their students problems like:  "fill this blank page with something beautiful".  Instead, they give them a set of constraints to work within, they dictate a theme, an artistic style, and a time limit.

In another sense, constraints give a creative endeavor a finite set of tractable starting points.  They imply a form for the eventual solution and provide strong foundation points that can be used to underpin a more fanciful idea.  

Twitter's 160 character limit is an example of this.  Initially a mere technical constraint of SMS, it now serves as the boundary condition for a whole new mode of communication, that, without this constraint, might have reverted to yet another blogging service.  

When confronted with an intractable product decision, I first attempt to layout the forced constraints:  

• How much product investment can we afford?  
• What kind of timeline should we deliver it in?
• What is the technology we're using especially good/bad at?​
• What is the user's problem that we're solving?​

If I'm still stuck, often because the true constraints are still too broad, then I try to apply artificial constraints that force me to think about different aspects of the problem:

• What could we do in a single day?
• What if there was no UI at all?​
• What if our customer's were end-users instead of enterprises?​
• What if we could only charge half as much for the service?​

I often discover that such artificial constraints help clarify what the real proposition is, assist in searching for ideal solutions instead of merely adequate ones, and reveal orthogonal ways around obstacles.

All-in-all, I'm pretty happy with the service.  Shopping in your underwear and having it all magically appear at your doorstep the next day is pretty great.  It's a good bit more expensive then going to the store yourself, with a $7 delivery fee, tip for the driver, and, I figure, about a 20% price premium.  

Trip to Supermarket = 1.5 hours and costs $50
Trip to Amazon Fresh = 0.5 hours and costs $70​

$20 to save an hour is pretty expensive, but add-in dealing with Sunday shopping crowds, parking, hauling bags, etc.; and you can just about justify it​.

The shopping experience itself however, was less than stellar.  Which surprised me coming from the worlds biggest online retailer.  

​It was curiously frustrating.  Nothing that was glaringly obvious at first, just an impression after you've finished filling your cart that, "Phew!  I'm glad that's over with..."  I decided to take a deeper look and break it down into how I'd do it differently.

1. Give Users a Sense of Scale​

People depend on the size of things to identify objects, judge value and differentiate between similar products.  

I've often bought something online to discover once the package arrived that I'd terribly misjudged its size.  I have a mouse pad that covers a quarter of my desk (which it turns out, is brilliant).  Another time I bought a cashmere blanket as a gift for my wife that turned out to be about the size of a handkerchief (less brilliant).  

All of the images in the Fresh catalog are scaled to be the same size in pixels, sacrificing our ability to judge things as you would intuitively do with physical objects.  This forces you to resort to comparing numeric descriptions with your past experience.  Is 15.5 oz a lot of cereal, or a just a little?

​It would take some legwork with a lightbox and a camera, but wouldn't it be nifty if the product images were proportional to their actual size?    Even better, if the product tiles were scaled as well, so that smaller items wouldn't waste a lot of space.

​2. Be Hyper-Organized

​I used to stock groceries at a small grocery store and organizing products on shelves is much harder than it looks.  Products come in lots odd shapes/sizes and there's no stock-boy handbook with a master hierarchy of groceries.  

If you get it wrong, say, by putting the chili next to vegetables because they're both in similar size cans and the same brand, your boss makes you do it over again.  Why?  Because customers who can't find things get frustrated and shop elsewhere.

The problem with Fresh is that the default organization of ​items is by "Relevance".  What the heck is "Relevence" when you're shopping for cucumbers?  I feel certain it's something to do with purchase frequency, but in this instance, my purchase decision has nothing to do with how often a thing is purchased.

It might be better if they just sorted everything by hand.  It seems daunting at first, but I've been there.  You can do a small grocery store in an afternoon, and that's with the backbreaking chore of moving dozens of each item by hand.

​3. Wasted Space = Wasted Time

​A defining time in many designers' lives in when they finally understand the beauty and power of whitespace.  It's magical that just the right amount of nothing at all can elevate a sloppy mess into an elegant collection.  

But then again, sometimes functionality is more important than beauty.  Shopping for groceries is one of those times.​

A grocery trip is an exercise in ​making millions of comparative decisions.  A person must identify thousands of products as they walk the aisles, making judgments about taste, quality, quantity, healthiness, and cost.  They do this while forecasting their future needs, trying to remember whether they already have something and deciding what to have for dinner next Wednesday.

And most don't do it for fun, the way a person might shop ​for clothes or electronics.  They do it out of necessity, a weekly chore.  

On a 1600x900 laptop screen using Chrome, I can see 7 products fully without scrolling on their core product listing pages.  

The space above the products is used horribly:

• two distinct nav bars,
• a large search bar on its own line,
• a full page width breadcrumb
• an always expanded 3 category tree filter/brand filter/product attribute filter
• ​a paging bar with yet another filter and another search box
• a full page width space for an ad​

That's about 460 pixels of rarely used cruft getting in the way of my important San Pellegrino vs. Orangina ​decision-making.

4. Mental Models​

If people had thought bubbles (and man wouldn't it be great if customers had thought bubbles), the air above the aisles in a store would be full of little maps of the store with a personal dotted line snaking through the store with way-points marking the areas they expect to find the items they need.

​This is an oft overlooked aspect of UX design.  Good sites give their users tidy maps they can carry around in their heads so that people can think several steps ahead, and over time, explicit actions can become automatic ones.  This is why people complain about Facebook design changes, they've messed with their users' mental model.  Occasionally it's worth the trouble.

​Fresh commits the sin of forcing the user through three to four different layouts when going from the home-page to the main product pages.​

1. The home page has a large "hero" tile surrounded by a few ancillary promotional tiles.  Users click on the, slightly obscure, "Shop Grocery" link on the upper left to get in.
2. The next stop is a list of top-level grocery categories on the left with a few pretty tiles occupying most of the page.​  Okay, hard right turn, but I can dig it...
3. If you click "Produce", but not on any of the other categories, you get an odd interstitial page with the produce sub-categories now interspersed throughout the page.​  Huh?  
4. Next click and you're finally to the core of the site.  The place where you buy stuff.​  But now the categories are shown in a tree, and inside a sub-window with its own scroll bar.  Am I on the same site?

Any one of these might make a perfectly adequate mental model, but taken together, they are bewildering.  To make it worse, most of the important landmarks you'll depend on to navigate are grey text, while the memorable images are all promotional things that will no doubt rotate the next time you visit.

They should drop at least two of the page layouts.  "Consistent but ugly" will keep more users than "random but cute".

​5. Users and Applications Are Symbiotic

​Another trick of UX design is that interesting functionality can emerge without your exactly designing for it if you just give the user some flexibility.  

A good example is a butter knife.  Great at spreading things on toast.  But it's also a sturdy piece of metal with a thin edge, so can serve as a screwdriver in a pinch or for poking at things that fall into the space under your fridge.

A web app is no different, and you can make up for some of the constraints of screen space by using the customer's memory​.  For example, instead of maintaining a big list of diverse things, as in Fresh's shopping cart, let the customer figure out how they want to organize things.

Imagine a cart that is just an empty box that you can drag and drop items onto.  The user is free to organize them however they wish.   The icons can be tiny and you can leave off the names/prices, because the user remembers selecting it and where they put it.  Just like a physical shopping cart at a store.

Some users might organize items into "might want to buy" and "definitely buy" categories.  Others might pile up the stuff they need for a particular recipe in one corner.  My use case would have been putting "stuff for the party" in one pile and my staple purchases in another.

While we're at it, a simple text box with auto-save would make a nice shopping list as well.  ​No fancy check-boxes or hierarchy needed, I'll figure that out myself, thank you.

1. You Don't Know What the F*** You're Getting Into

It's a truism that parents with older kids love to tell newly pregnant couples and those couples absolutely despise hearing.

You'll have read all of the books/blogs on the subject, you'll have been ​a participant in the process for most of your life and kept detailed mental notes about how it could be done better; but nothing can really prepare you for what it actually is.

The anguish and despair when events conspire to destroy your best laid plans and the pure unadulterated bliss of getting it right.  They fall right off the ends of the spectrum of experience that can be described in words.

And it's probably for the best that you can't comprehend it beforehand.  If it were possible to  objectively weigh all the ups and downs and risks, rational people might decide never to undertake it.  And it must be undertaken and those that do very rarely regret it after.

2. You Cannot Fail, But Will Endlessly Fail

​The stakes are incredibly high.  Real lives are in your hands.  One bad decision could be catastrophic.  And yet, time marches on, and you'll be confronted by a never ending stream of decisions.  You can fail just as miserably by failing to act as by acting wrongly, so you make the best decisions you can and inevitably some of those decisions are wrong.

Any parent ​who has cleaned poop out of a car knows this intuitively.

​But take heart.  Trust that you will make many more good decisions than bad and when you make a stinker, clean it up, learn a lesson and move on.

3. Creating Self-Sufficiency is the Goal

One thing you learn as a parent is that it's far better to teach your child that it's dangerous to cross the street, then to arrange to always be there to hold their hand.  Of course, the balance of this changes with time:  at the beginning you must be constantly vigilant, but as time wears on, you must arm and prepare them to make their own way.

Fortunately, children and product teams are much smarter than their parents and product managers give them credit for.  Let communication and trust be your watchwords.

Now, this is certainly compulsive, but not obsessive.  If I have something on my mind or am walking with someone, it never occurs to me to look, but left to my own thoughts, I'll match my stride to the pattern of lines on a sidewalk as I walk along it.

To my surprise, he said he did the same, but had never really mentioned it to anyone.  At the time, we decided that perhaps it was just one of those odd family quirks, but when we asked our respective groups of friends about it, lo and behold, there was a pattern.

About 1 in 3 of our friends did this or something like it.  Some said that they would look at the regular spacing of trees or parking meters.  Others said that they tried to step ON the lines instead of avoiding them.  Everyone who did admit to crack-watching was in some sort of technical field like a programmer or scientist.

The opposite correlation also seemed to hold true.  Our less-technical friends, people who disliked computers/science, tended to not have any clue what we were talking about.  These friends tended to be in people-related professions, like customer service or marketing.

Now, it's pretty obvious where crack-watching comes from.  It's the brain's tendency to find patterns in otherwise unimportant sensory input (think Jesus's face on a zuchinni) but not everyone feels compelled to hunt for and react to more abstract patterns like lines on a sidewalk.  

The correlation with math/science/computers must be that people with these sort of brains like the abstract patterns you find in technical subjects.

This line of thought had settled the issue so far as I was concerned until I read an article about the increased incidence of Autism in silicon valley.  Specifically, the article had a sidebar on Autism that lists paranoia about stepping on cracks as being a minor symptom.  It went on to describe the milder form of Autism called Asperger's Syndrome that is mild enough to go undiagnosed in many children.  It was a spectrum disorder.

Hmm.  Spectrum...

• Autism
• Asperger's​
• ​Crack-Watchers
• Average People​
• ​Very Sociable People
• ???