Deadly Engagement

The Seven Deadly Sins has been a meme since long before there were memes.  


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.


I just like  Sloth ...

I just like 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.


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.


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.


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.


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 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.


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.

Organizing Ideas

I am a voracious, probably pathological, hoarder of ideas.  I write little notes to myself about them, I lovingly organize and re-organize them and crumple them up into balls and hurl them into the trash bin, only to haul them out 30 minutes later "just in case".

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...

Free Product Idea: Skill Hub

My first job was with an ambitious managed service consulting startup called Quidnunc.  They had an interesting mentorship system, wherein, new employees were assigned a seasoned consultant to act as a mentor and given a stack of "competencies" that they needed to attain in order to progress in their career.  

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.

Cellular Product Teams

A good way to start a lively debate in a group of P* Management types is to ask "what the right team size is".  

Opinions vary between:

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.