Reconciling Core & the happydance

Let's assume for a moment that all software has Context and Core, iterative release cycles (not games), and limited development resources.  If you're already lost, I didn’t write this for you.

OK, great.  So what should development efforts focus on?
Context has a dangerous scoping implications.  Fall out of the context bubble and you lose that selling point.  Advance within the context bubble, and you don't gain sales. Advance beyond the bubble, you have a core candidate.

Core Candidates
Just because your program has the most advanced X, doesn't make it core.
A wiki with the best spell checker does not push the boundaries of core.
More on this later.

A false thought pattern:
For any feature in my product, if I put sufficient effort into it, it can become part of my product's core.
Reality:  All feature work has diminishing returns, and many features don’t merit Core.  If you’re not going to write about it on your website, it’s not core.
Correction :
Given an application with a set of features, there exist some tiers of context:

1. Features below the context minimums for that type of feature.  These are nonfeatures. They probably exist for legacy reasons.
2. Features approaching the context minimums. These are functional, but suck.  However, if they are truly context, then the functioningness of them should be sufficient.  Interacting with these features results in crappy user experiences.
3. Features well within the context bubble.  They're nothing special, but fill some need. Neutral user experiences.
4. Features about to break favorably out of the context bubble. They're still nothing special, but people think they're slick. Good user experiences.
5. Features that go above and beyond all similar implementations of this given context feature.  Your application can convert subtitled cat pictures into PDF's better than any other application in existence.  Good for you; Nobody cares.  This probably took a lot of effort, too, didn't it? Suckaaaaah.

Let's live, for a moment, in a world in which your application is entirely context.  Perhaps your application is the Windows 7 WordPad.  It's a dumbed-down version of Word that come free with Windows 7; Its core, if anything, is that it's free.  It's a lovely little program, but it lives in context.
When living in context land, choices are easy:

Tier 1-2 features generally shouldn't exist. Cut them or push them to tier 3. 

Tier 3 features are fine, but noncompetitive.  I'll talk more about competing on context later.

Tier 4 features are more competitive.  The only tier-4 feature I can identify in WordPad is that it loads extremely quickly.

Tier 5 features, while arguably more competitive than tier 4, are a void.  Time spent on tier 5 features while you have dangling <= 4's is likely a waste.

For those of us who don’t live in contextland, the game is different.  Context quality is a component, but it's only marketable on price.
My sales pitch for using WordPad instead of Word: It’s free and it’s installed by default.  It’s hard to raise money with a sales pitch like that. WordPad’s biggest profits probably come from the fact that having WordPad as a commodity good strengthens Word as a product, since WordPad can open Word documents.

Core candidates:
There are two types of core candidates:

1. A feature which can do something that nobody else can do.  Push a button, it shocks you for 30 seconds, and then teleports you anywhere in the world.  The only context for the feature is price.  If I value not being shocked at $50, and teleportation at $1000, I'll still buy this for $950.  The ROI on reducing the shock to 10 seconds probably isn't worth it.
2. An important feature which can do something that others can do, but better. This is a tier-5 contextual feature.  These are hard, since there will always be 4's nipping at your heels. If teleportation is a commodity, but I can provide it to you with only a 1ms shock...  great, my teleporter is worth $999.  That's wonderful, but a competitor can accomplish the same gain by undercutting me.  A bigger competitor than me can squash me by undercutting me severely.  I can't compete on price, since It's so much harder for me to keep running at 5 then for them to run at 4 or 3.  This is where Word is kicking the crap out of Open Office; Open Office’s only prayer is to undercut Word, but it would have to pay people to use it in order to get cheap enough.

Choose your core well.  Your core is the set of reasons for which a customer will evaluate your product. Your context needs only to be filled in enough to not scare your customers away.

Ok, that was easy.  Now let’s make it more complicated.

Secret aspect #3,  wherein Core and Context interplay:
Joel has a very nice article entitled Controlling Your Environment Makes You Happy. I'm going to refer to it as happydance, since that's more pleasant to type than CYEMYH.

Happydance means that, even if my teleporter is one of a kind, it may still piss you off.
Happydance means that the context par is actually higher than the bottom line: Your electroshock needs a minty aftertaste.
Happydance means that running with contextland in 1 or 2 will put a bad taste in your mouth, and running at 3 means that you're at risk.
Happydance means that context must run at 4, and that 3 is a danger zone.
Happydance means that type-1 core candidates need to run at 4.

Happydance, really, is meta-core.  You can set happydance to be part of your product's core functionality:
My product performs teleportation and happydance.
This means that, alongside teleportation, I'm a 4-star restaurant in contextland, baby.  You're not flying Eastern Airways, you're flying Jet-Freaking-Blue. Happy jetting.

The insight of happydance, I think, is that people are emotional creatures. Assuming that we’re going to behave logically and economically is just wrong.  You have to account for happydance, otherwise your superior product will fall behind.

Happydance’s annoying property:
The scope of happydance is your entire product.  Even if you can push on core or context in one area or another independantly, to push on happydance you still have to push on EVERYTHING.

Thinking internally, I suspect that the cores of my product are:

1. Happydance
2. Best exception handling of any issue tracker
3. Best exception handling of any project management tool
4. EBS

I think there are some budding cores, and there’s also a lot of context.

There were some items identified missing from our set of context features.  Rather than pulling them to minimum, we're pulling them up to Core.  This seems good.

I think we have succeeded in maintaining happydance for Core.
I think we're beginning to fail to maintain happydance for context, especially pertaining to search, the wiki, and the discussion forms.  We know this, and we know the solutions.

The current path is pushing core;  beautiful.  I'm scared, though, because:
We've got happydance in place for our core, but it’s sliding away from our context, and a consistent unhappydance on an ever-growing long-tail of context will strip happydance from our core.

I don't think we'll let it slip, though.  I also think that are current efforts are worth the investment, and they will themselves embody happydance.  The contextland 2's, someday, will be taught to dance again.