I was talking with a friend of mine the other day.  He’s a former tech exec who now works in real estate development and his business has been a bit beaten up by the state of the economy.

We got to talking about the current state of things and a couple of notions dropped out that I thought I’d share.

I’ve never taken an economics class in my life, so of course I’m thoroughly qualified to be an expert on the topic.  In general it seems to me in general that the economy does best when the government leaves it alone.  Ideally, the government should ignore it all together — the further they are from tweaking it, the better I feel about the health of the economy overall.

And I’m really not kidding about that.

Why?  Well whenever I hear someone talking about the economy at large, they make frequent reference to agriculture numbers, manufacturing output, volume of durable/white goods etc.  Is that really what drives the US economy at this point?  Doesn’t seem so to me.  Not to mention that the unemployment figures are so massaged, filtered and tweaked at this point as to be meaningless.

Viewing the economy as a machine that can be adjusted to "work right" is all very well in theory, but as I put it to my friend during our chat, :

"I’m just not convinced that the dials they are reading are connected to the knobs they’re twiddling"

After I said it, it occurred to me that I’d stated a rather common entrepreneurial problem too.  We have a lot of metrics that we informally pay attention to (do people like the product, is dev moving forward, do folk get what we do etc), and we make changes to what we do to get the outcome we want to see.  But it’s easier than you’d think to connect an outcome to the wrong input…

So before you make changes in your business, especially big changes, you really need to dig in and see if the outcome you think you’re going to be altering is _actually_ connected to the change you’re making.

Case in point:  our pitch.  We thought the lack of success was driven by the fact that we couldn’t demo much of what we were talking about in a pretty product.  It turns out that is only partly true.  Having a sexy demo definitely helps, but speaking exactly the right language about where we fit in the corporate eco-system has proven to be equally important.

Fiddling with the product would have only gotten us so far.  If we hadn’t realized that the outcome was being driven by more than that, we wouldn’t have made any progress…

Categories: Old Posts
1552 Comments »http://blog.nicholasnapp.com/2008/02/15/knobs-dials/Knobs+%26+Dials...2008-02-15+16%3A17%3A00NickN

As I mentioned, I was half-dead last week with some kind of MTD (miscellaneous toddler disease) I picked up from my daughter.

Last Friday I had a meeting I didn’t want to cancel, so I dragged my Nyquil-soaked butt to the meeting.

This was a meet and greet, not a serious pitch.  And thank god the guy we were meeting with had a sense of humor.  I repeatedly referred to the Opera browser as the Oprah Browser (the one product she doesn’t seem to promote yet) along with a number of other mumbley nonsensical statements…

So be warned… Pitches and Nyquil are not friends.  Proceed with caution.

Categories: Old Posts
154No Comments »http://blog.nicholasnapp.com/2008/02/14/the-dangers-of-pitching-while-on-cold-meds/The+dangers+of+pitching+while+on+cold+meds...2008-02-14+15%3A01%3A00NickN

I need a new phrase.  You’re doubtless familiar with the old adage "it never rains but it pours".  It’s usually taken as a bad thing — you don’t just get a drop of rain, you get buckets of water.

But I’ve found that good things happen in much the same way…and I don’t have a good phrase for "sometimes good things happen in bunches".

I’ve consistently found that life, the universe and everything tends to unfold in a rather odd, clustered  & lumpy manner.  Today was a great example.

In just one day:

• One of the investors we’ve been talking to has committed to taking some serious next steps (we’re still some distance from a term sheet, but this was a big formal step forward)
• We gained a provisional commitment for some modest (but useful) friends & family style funding
• I reconnected with a very experienced executive I haven’t talked to in 10+ years.  This guy is a superstar with a ton of experience in some key markets we play in and a rolodex that would blow your mind.  You’d probably recognize the names of all of the companies on his resume.
• We got an email from another person we respect and will be meeting with him soon

and on the personal front, my newly arrived niece is now safely at home and doing well.  She arrived quite a few weeks early but is doing incredibly well.  Go Carmen!

And all of this after weeks of silence on a number of fronts.  The product has been moving forward nicely but in entrepreneur time-warp land, it’s felt as though things have been slow of late.

Not any more!

Categories: Old Posts
153No Comments »http://blog.nicholasnapp.com/2008/02/13/life-the-universe-and-everything-is-weirdly-lumpy/Life%2C+the+Universe+and+Everything+is+weirdly+lumpy...2008-02-14+02%3A54%3A45NickN

It’s been a long time since I wrote a dead tech post. 

Logan (CTO) and I are almost exactly the same age.  I’m not sure which of us was online first — probably him since he started coding pretty much in-utero.  Before the web, we both used tools like email, gopher, and telnet.  I even recall using telnet and the Unix "talk" command to IM a girlfriend I had in college. 

Yep.  I’m seriously old in internet years.

We were both also very early users of the web, back when NCSA Mosaic was the tool-de-jour and there were only two porn sites on the web (which represented about the same percentage of the web back then as porn sites do today).

But one of the things I had forgotten about until recently was the joy of sending attachments via email "back in the day".

Without getting well beyond my technical knowledge & re-writing history, email was basically designed to handle ASCII text — letters of the alphabet.  There was no direct support for binary files e.g. a jpg (bad example, JPG wasn’t around then) or other image.

So you went through a nifty process called UUEncode, which converted a binary file into chunks of ASCII text, something like this:

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/

and there would be pages and pages of it.  More often than not you’d have to split the text across multiple emails. 

The recipient would then have to paste all the text back together and run UUDecode to get back to the not-yet-invented JPG you emailed them.

Sounds like fun, no?  I know a lot of folks hate Outlook, but trust me, it is a _slight_ improvement over the way things used to be…

Categories: Old Posts
152No Comments »http://blog.nicholasnapp.com/2008/02/12/ye-olde-schoole-email/Ye+Olde-Schoole+Email2008-02-12+23%3A13%3A00NickN

We had a question come up during a pitch the other week about where we draw the line between buy versus build with parts of our technology.

I’m a fan of not re-inventing the wheel when you don’t need to, which tends to put me at odds with many software engineers.  I’ve often found that software engineers err on the side of recreating everything from scratch on the assumption they can do it better.  But that misses the point — it’s not a matter of skill, it’s always a matter of time.  The exception to the rule are engineers who’ve released a bunch of products.  Experience is a great teacher

Fortunately, Logan (my trusty CTO) is a veteran coder and is more than willing to explore off-the-shelf pieces when it makes sense.  So the short answer is that we creatively use off-the-shelf code whenever we can. 

However, there are two caveats to that statement: 

a)    Critical components.  If we are considering using off the shelf code for a critical component, we have to have a high degree of certainty as to the reliability and efficiency of the tool. For example, we looked at an open source library to generate tags, but the code wasn’t nearly optimized enough for our kind of deployment. 

b)    Security.  Data security is big concern for us.  We must be able to clearly demonstrate that a customer’s data is secure under a variety of circumstances.  If using something off-the-shelf results in the slightest degradation of our security, we’ll pass.

But that’s really not the whole story.  As a startup, off-the-shelf can be deeply appealing.  There’s a huge volume of open source code that is readily available, and an equally vast array of odd little utilities that someone somewhere developed, and all of it is readily findable (thanks, Google).

However, there’s a hidden cost, which was really brought home to me by some events that occurred on Friday. 

Working with someone else’s code is orders of magnitude slower than working with your own. 

For the non-coders out there, it’s like inheriting a marketing plan that was written for similar but-not-identical business and trying to shoe-horn it into your business plan without (a) making changes to it or (b) anyone noticing.  Not as easy as it might at first seem.  Think about all the little tweaks you would need to make throughout the rest of your plan in order for integration to be seamless…

Logan has been working on some email integration functionality so that Unifyr can support email archives, and part of that process relies on off-the-shelf tools and someone else’s standards.  The net result is that what was theoretically trivial has taken much longer than he hoped.

But compare and contrast…  On Friday we had a very interesting lunch meeting.  On the drive home he had an epiphany about some functionality we’ve been dying to show but have been unable to spend the time to develop.  I would guess he got home around 3pm.  By 6pm I had a working prototype.

And this is a big deal piece of the Unifyr puzzle.  So big, I can’t tell you what it is yet.  But it puts us in a league of our own.

And it was accomplished in less than three hours.

Now okay, that’s a bit like the old saw about Picasso drawing on the napkin and charging thousands for it ("It only took you five minutes", "no, it took my whole life").  A lot of work was put in to giving the core of Unifyr exactly the kind of flexibility that let Logan deliver this so quickly. 

But it doesn’t change the fact that moving a mountain with your own code is often faster than shifting a molehill with someone else’s.

Choose carefully!

Categories: Old Posts
151No Comments »http://blog.nicholasnapp.com/2008/02/11/buy-versus-build/Buy+versus+Build...2008-02-11+15%3A52%3A00NickN