Archives For November 30, 1999

We lead.. with our thoughts.
Just kidding, but we do have some thoughts we’d love to share with you.

Expensify in the News

Wow! April was a big month for Expensify in the media. Our Bitcoin Reimbursement announcement drew a large amount of attention. Our CEO, David Barrett was asked to speak on 3 different news programs: FoxBusiness, SkyNews, and CNBC! In addition to television appearances, we had a multitude of tech blogs write up on why our Bitcoin adoption was a big deal. Here are some highlights:  Continue Reading…

"You have no reason to trust me except that I said you should."

“You have no reason to trust me except that I said you should.”

Nearly everybody in Silicon Valley agrees on how a company is supposed to be run. These are codified into a nebulous set of “best practices” — the pre-packaged advice that is handed out to nearly every startup, in nearly every market, under nearly every set of conditions. But if there’s one thing I’ve come to believe is that “best practices” generally aren’t.  Continue Reading…

A little over a year ago we did a post entitled, How to Sell it to the Man. (The Man = your boss, their boss, your accountant, your colleagues, etc.) Since we didn’t spend the last year just twiddling our thumbs, selling Expensify to the Man is even easier for you and we thought we’d give you some updated ammo for the good fight.

Expensify is easier on your wallet.

Expensify vs. our Competitors 

Expensify bills $5/$10 (depending on plan) per active submitter per month, plus the first two for free. What’s the difference? The “active submitter” part. We only charge you for a user if they actually used the product that month – that is, if they submitted an expense report. At the end of the month, no matter how many employees you have signed up, you will only be billed for your active submitters. Each active submitter can submit an unlimited number of expense reports at no extra charge.

Compare this to your current expense reporting costs and you’ll find that in the overwhelming majority of cases our price is simply unbeatable.

Expensify vs. your wasted time

Don’t have an expense reporting software? Using Excel or cut/paste documents? Let’s do the math. Your salesperson earns 50K per year, which translates to roughly $20/hour. It takes them 4 hours and a lot of frustration to fill out expense reports each month.  That’s $20/hour x 4 hours = $80. If it takes them 20 minutes to submit a report with Expensify, that’s $20/hour x 0.3hrs + $5 or $10 for Expensify = $11 or $16, frustration-free.

Expensify is easier on your employees.

Stop making your employees dread that envelope stuffed with receipts that just sits on their desks. No more endless papercuts as they scramble to find that one report your accountant wants to review, NOW.

  • Accessibility: Submit, access, edit, and submit all of your expense information to your Expensify account from anywhere with an internet connection (mobile or web).

  • Organization: Filter your expenses, receipts, and reports by date, type, category, and a multitude of other parameters for quick lookup.
  • Security: We use bank-level security to keep your sensitive financial data safe.

Expensify is easier on your accountants.

Does your accounting department use NetSuite, Microsoft Dynamics, Oracle, Sage, another accounting package? Not a problem, Expensify allows you to export expenses and reports into custom CSV formats, acceptable by your accounting package. Perhaps they use QuickBooks? Awesome, because Expensify connects to your QB account to sync everything back and forth. Save your accountants hours of manual input, save your company money.

Bonus: We also integrate with your payroll solution!

We’re happier to provide you support

You will also have email access to one of the best support teams in the business. With a 24 hour turn around time on emails (and usually quicker), we can get any issues you have sorted out quickly.

Care for a second opinion?

Check out our Twitter feed some time. I don’t know about you, but this is the first company I have worked at and been comfortable saying THAT to a potential user. Our users can’t seem to stop showering us with love! With the usual state of public discourse towards companies being rather negative this is something we are quite proud of.

Do you have a complex, outrageous expense reporting setup?

Not only can Expensify manage it, we can make it simpler and more intuitive for you, your employees, and your accountants. Email our support team and tell us about your current setup. We’ll tell you how we can make expense reporting a quicker, easier necessary evil.

At some point, a startup outgrows its lack of structure, but isn’t yet ready for the real deal. What do you do? There are some lessons to be drawn from how P2P networks grappled with the same problem.

1. Fully Connected (2-4 people)
When a P2P network is very small, every node sits next to every other node. If there’s something you need, you just directly ask the nodes around you, and they can give it to you in one step. This is akin to the early days of a startup: just turn to the left or right and every problem is solved.

2. Gossip Protocol (5-10 people)
As the network grows, not every node sits next to every other. But this is fine, because the network is still small: even if your peers don’t have the answer, odds are they just need to ask one of their peers, and the answer is found. So every question can be answered in 2 steps, which is still pretty good.

3. Supernodes (10-20 people)
However, as the network continues to grow, sometimes gossip isn’t effective: it’s possible that there are nodes sitting more than 2 steps away. In startup terms, this means peers who are off in their own direction, and nobody knows what they’re doing. But because everybody has already accepted there are things both they and their peers don’t know, it’s easy to assume that somebody else knows what they’re up to — when in fact nobody does.  Accordingly, people can be overlooked: they don’t get the support and oversight they need to be effective.

To solve this problem, a small group of well-intentioned employees — generally without any formal acknowledgement — steps up to take on greater responsibility. They don’t have any formal titles; nobody technically reports to them. But everybody knows they are doing far more than being individual contributors: they are “supernodes” who just take it upon themselves to pay attention to more than most. They are the people who walk around and ask questions.  They notice when people are unhappy, overwhelmed, unsupported, or unsupervised. They are the people everyone turns to when nobody knows the answer.  They are the unsung heroes who keep a startup from imploding under the weight of success.

But inevitably, the supernodes themselves burn out. After all, they’re consciously doing more than anybody else — but without any real extra incentives, resources, or authority. And when a supernode burns out, the whole network they support burns out, too.

Up until very recently, that’s where we were. So we’re moving on to the next stage: DHT.

4. Distributed Hash Table (21-?? people)
Because supernodes are volunteers, they don’t necessarily have any formal accountabilities — being a supernode isn’t a job, it’s a calling. And though over time supernodes tend to focus on certain areas, and though all nodes tend to learn what those areas are and act accordingly, those focuses aren’t documented or even formalized. This means new employees don’t know who knows what; people don’t know who is more qualified to make a decision than the next person. A supernode can only do so much as a volunteer: at some point your organization needs to upgrade to a DHT.

At a high level, a “distributed hash table” is a data structure where given any particular question, you can determine who knows the answer — in one step.  No searching, no gossip: just ask the right person and they will know.  In organizational terms, it’s kind of like an org chart: it documents which people are in charge of which areas. Ideally anybody can look at this chart and immediately determine the correct person to ask any question.

But it’s only a partial org chart: only the supernodes are put into the chart, and all the other nodes are left ambiguous. It’s not about strictly defined teams operating under a chain of command — it’s about a mob of people, where some people carry megaphones. Anybody can switch who they follow at will, depending on what they’re trying to accomplish. But those carrying the megaphones coordinate to ensure that the mob overall continues heading in the right direction.

That’s where we are today. Expensify is a mob, with megaphones. Naturally, I reserve the loudest megaphone for myself (as would any benevolent dictator), but more and more it’s the jobs of the supernodes to keep the mob moving forward — with me just helping coordinate behind the scenes.

How long will this last? I’m not sure. Like so many things, our lack of overt structure has worked much longer than I think anybody realistically thought was possible. Indeed, I attribute how well things have worked so far entirely to the fact that we only hire a very particular sort of person who can thrive in this environment. But I’m confident that it’ll keep us moving forward at our already astonishing rate, to whatever level comes up next.

Q: Why not a strict hierarchy; isn’t that more efficient?

A: In content delivery terms, that would be a “broadcast tree” — you have a single source, which broadcasts to the first set of nodes, each of who broadcast to the second set, out until all nodes get the content.  It’s a top-down control network, and yes, it is optimally efficient.  In an established company where all the kinks of the business have been ironed out, everyone’s job is well defined, and the success of the organization rests upon minor tweaks applied top down — yes, it’s ideal.  Most large companies are structured this way for a reason.

But a startup is nothing like that.  At least, our startup isn’t anything like that, and we all quit places like that to come here.

Rather, it’s more like I throw a flaming torch way out ahead of us, and we all try to figure out how to get there.  Sometimes it involves building bridges, blowing up mountains, and occasionally burning our boats behind us.  But my job is only to figure out (roughly) where we need to be: how we get there is up to the mob.  So our structure is optimized to put maximum control into the hands of the most people.  It can be chaotic, confusing, and sometimes a bit scary.  But it’s a lot more productive, and infinitely more fun.

-david
Founder and CEO of Expensify
Follow us at @expensify

My hat’s off to the Yammer team for their $1.2B acquisition by Microsoft!  I think everyone else has already said about everything, but I wanted to add my own spin: the incredible valuation of Yammer isn’t that it’s social — that’s so 2012.  Rather, Yammer’s value is that it is pioneering a revolutionary sales model that is going to wholly transform the enterprise space.  I wager Microsoft bought Yammer not because it needed to plug a social hole, but because they saw it as fundamentally lower-cost-of-sale model that threatens Sharepoint’s long-term success.  This wasn’t about adding Yammer’s revenue, but about preventing an even greater loss of Sharepoint revenue.  This was a defensive move on Microsoft’s part to avoid being disrupted by a competitor they can’t possibly beat.

Said another way, I suspect Microsoft didn’t buy Yammer because they wanted a piece of their $22M revenue stream.  Especially as, so far as anybody has reported, Yammer didn’t get that revenue in a profitable manner.  Rather, Microsoft bought Yammer because they were afraid if they didn’t, people would gradually leave Sharepoint for it.  Even if Yammer can’t profit from those users, Microsoft can, and they want to ensure that they do.

Like anything, I’m sure there are a hundred angles, all of which bear some grain of truth.  But the one I hadn’t heard was about Microsoft’s deep seated fear that whether or not they wanted Yammer, they needed it.

That might sound obvious. I was employee number one, and I’ve been personally involved in hiring everybody else in the company. So I less than anyone should be surprised by what this team can do. But when Tom builds a remote-controlled, webcam/microphone/speaker equipped, four-wheeled robot just so Tony can attend a Thanksgiving party — I mean, who can’t be surprised by that level of awesome? And then for Tony to casually drive this silly robot into a roadmap meeting to discuss some fundamentally radical mobile ideas, not the least of which is how to maximize the value of our totally custom cross-platform mobile layer — my mind is blown.

I’m not saying every day feels like living in some parallel universe where Sneakers meets Ocean’s Eleven. But some do, and I can’t help but think “Damn! I love working here.”

PS: Did I mention we’re hiring? Programmers, salespeople, and desperately looking for a designer. Know any? Send them our way, please!

When giving the same pitch over and over, you quickly settle into a specific way of delivering a line, and then say it so often it becomes second nature. Most conversations I have with investors or the press really just involve stringing together a series of well-rehearsed snippets that address pretty much any question I could ever be asked. One of those snippets starts with:

“Now, I don’t read many ‘pop business books’ (air quotes), but there’s one I really swear by called the Innovator’s Dilemma.”

That’s been part of my pitch for a long while now. It’s even on tape. So guess how pleased I was to learn who else swears by it? None other than the late great Steve Jobs.

However, never one to pass up an opportunity to disagree with Mr. Jobs, I should mention that I took away a different lesson. Granted, I haven’t read his biography so I’m going off of other reports. But I’ve heard his opinion summarized as:

“Over-focus on profit is the problem, and the solution is to focus on the product.”

Granted, that’s watered down to a nice-sounding but highly ambiguous statement, so I don’t really know what he meant by that in practice (or if he’d have even agreed with that summary). But despite what he may or may not of have thought, I’d say the pursuit of profit isn’t itself the problem. Profit isn’t some happy accident that can only be pursued out of the corner of your eye. Rather, it’s how you pursue that profit that causes the dilemma.

Specifically, if your profit depends on continuously abandoning your core to move up market, you’ll eventually hit the top and be incapable of going back down. This is the inevitable fate of any (successful) organization with a direct salesforce that:

  • Is compensated through commissions, and
  • Sells to leads gathered from outside the core userbase.

Indeed, if your salespeople are encouraged to always go out and get the “next biggest deal” — and are given free reign to get it from anywhere — how else could they possibly accomplish that goal without abandoning the core market? If there aren’t an equal number of people pushing the product down into smaller markets, naturally you’re going to find yourself drawn into inexorably bigger markets. An organization like this can’t help but use their current market position as a stepping stone to move somewhere else, which as the book explains, is a fantastic rocket ride up to the top followed by disruption from below — typically by another rocket using the same strategy, and then another after that. It seems the cycle of life.

Mr. Jobs broke the cycle by (apparently) decoupling product focus from sales. And luckily he’s a genius with the intuitive vision to predict where the money was, so it paid off.

But I think that’s a risky gamble that could have gone the other way. Apple bet it all on black (or brushed aluminum, in this case), and it paid off handsomely. But don’t forget that it didn’t pay off so well a couple decades back when he tried the exact same strategy: Apple was only able to have this stunning rebound because of its previous tragic decline.

So I feel there’s got to be some other way to break the cycle — some way that doesn’t require going “all in” on the gut instincts of a genius at the helm. Some way to build an organization based on repeatable, customer-focused development that can be accomplished by mere mortals instead of an endless game of “double or nothing” played by the gods.

If product isn’t the answer, and sales isn’t the problem, then where else to look?  And that’s where I lay the blame at something surprisingly benign: the lead source.

Nobody talks much about lead sources. “Leads” — the people at which you point your salesforce — are just assumed to come from the same places other companies get them. SEM and SEO to landing pages, going to conferences and gathering business cards, channel partners, affiliate programs, buying contact lists from the many, many people who sell them, etc. And you might argue that all these leads come from such a diverse array of sources that you’re naturally inoculated against myopia. But all those sources have one thing in common: none of those people actually use your product.

So if your salespeople are always talking with people who don’t use your product, and are always incentivized to start with the biggest first, then they can’t help but pull you away from the needs of all the smaller people who already do use your product.

(This is aggravated further by outside sales typically talking with the “decision maker” — a person whose likelihood of actually using the product they’re buying decreases as the company size increases.)

All of this inexorably shifts your customerbase’s center of gravity up market, day after day, such that even if you’re in the most customer-focused organization, you can’t help but realize “our customers are getting bigger, that’s where our resources should go”.  This inevitably de-prioritizes the initial customers who got you where you are, in favor of the bigger customers that you’re always trying to get. It’s a vicious cycle; it’s a dilemma.

But what if you could somehow keep your center of gravity stable? What if instead of building new features, you just kept your organization focused on improving the features you already have, for the same people who already use them?  It means you have a lot fewer features.  And require fewer engineers.  And have less to support, all of which is higher quality.  Wouldn’t it be great if you could do this, and still achieve your growth and profit goals?

There are some obvious ways to try. One way is to just not take on larger customers — maintain a laser focus in a particular customer segment, always resisting the urge to move upmarket. That’s one way. But I wouldn’t recommend it — in any market, upmarket is where the money’s at. The margins are thicker, the opportunities bigger, the names sexier, etc. Any company that has no interest in going up market is one that intends to be overrun (or at best, acquired) by someone who does.

Another obvious way to do it is to have two teams: one focused on moving up, and another on moving down, such that you always balance out your growth. And that might work, if they’re very carefully balanced.  But that seems impractical to manage, so again, I wouldn’t recommend it.

A third option, and the one I would recommend, is to focus your sales effort on people who already use the product.  This way you avoid shifting the center of balance and create an organization focused on increasing engagement amongst existing users. This approach addresses the core deficiency of the lead source itself: the fact that new leads don’t use the product.

Now you could argue “Of course they don’t use the product; if they did then sales wouldn’t need to talk with them.” If the only way to use your product is to buy it, then that’s quite right! But as we know, that needn’t be the case. The internet is full of services that offer huge value at absolutely no cost. Services that have millions of “users” who aren’t yet “customers”. People who already use the product, even if they haven’t yet bought it.

What I’m describing of course is the classic “freemium” model: give away basic functionality for free such that some users will decide to upgrade. This isn’t terribly new.

But what is new is applying the freemium model in a space where the “deal size” is big enough to enable a sales team to make postive-ROI sales (where the cost of the sale is exceeded by its revenue). This isn’t Farmville — no salesperson is going to earn a commission by convincing you to buy a purple cow. And this isn’t a consumer product that encourages you to upgrade to a $10/mo plan. This is an enterprise product, with customers having hundreds or thousands or more employees. And using the existing users within an organization to serve as leads into converting the organization overall.

Ultimately, the primary purpose of sales is to drive up market. And it’s a slow, steady march taking on new customer segments as you firm up support in existing segments.  But this process is only destabilizing if doing so distracts from the core userbase. If the sales leads are instead drawn from the core userbase, however, then the only way to increase leads (and thus increase sales) is to also grow the core userbase from which the leads are drawn.  So long as your leads some from your active userbase, then you simply can’t lose touch with it.  This makes the entire organization — from the most senior salesperson selling the largest deal, to the most junior support person talking with individual freemium users — play for the same team, aligned toward the same goals.

In a sense, the whole company is spinning up the same flywheel.  It doesn’t matter who pushes, where, or how hard: the bottom-up adoption curve allows everyone to contribute to top-line sales success, no matter where they are in the organization.

This is how you solve the innovators dilemma, without sacrificing the move up market, and without losing touch with the core.

At the very least, this is the strategy that Expensify is using, and it seems to be working pretty well for us.

Note: If you’re interested, consider joining our “Salesforce of the Future!

Years ago Witold and I joked that performance is a problem we’d “love to have”.  It means that you have so many people using and liking the thing you’ve made that it’s starting to slow down.  After all, an iPhone has enough horsepower to power most websites: it really takes a lot of work to overload an actual business-class server anymore.  If you’re experiencing genuine slowdowns, it’s a sign that things are on the right path.  It’s a problem you should love to have.

However, it’s still a problem.  In our case, things aren’t quite as snappy as we’d like.  We’ve increased from 3 to 5 datacenters, vastly increased hardware, and the users keep coming.  So we’re embarking on a much more deliberate optimization campaign than we’ve ever done (or had need to do) in the past.  And that’s great because optimization it’s fun!  It’s full of all sorts of “classic” engineering problems — phrases like “Big O” get tossed around with nary a chuckle.

But like most fun things, at its heart lurks a deep evil.  Here’s what I advised our team, and I thought I’d share it with you as a public awareness campaign highlighting a universal problem.

Premature optimization is the root of all evil. I mean that in the most literal and expansive way possible. Resist this devil with all your might. Here are some tips:

1) DON’T OPTIMIZE IF YOU DON’T KNOW IF IT’S SLOW.

I repeat: don’t make something faster if you don’t actually know how fast it is. It’s possible — in fact, highly probable — that it’s actually adequately fast as is. I’d estimate that 80% of optimizations have absolutely no beneficial effect, and actually make code slower and less maintainable. Don’t be “that guy” who spends all day optimizing something that doesn’t need it, while ignoring the enormously huge low-hanging fruit all around.

2) BENCHMARK BEFORE OPTIMIZING.

Optimization is a field where you can spend an unlimited amount of energy accomplishing precisely nothing of value (or even less). The best protection against this is measure its real-world performance before starting, as this is the only effective way to prioritize areas to optimize. The best measure is that which is experienced by the end user.

3) BENCHMARK AGAIN AFTER OPTIMIZING.

If you don’t know that your optimization worked, it’s safest to assume it didn’t — just like the vast majority of optimizations. If it didn’t, then revert the change. It doesn’t matter how long you spent building some fancy caching layer or tweaking settings in ways that “I’m sure” are better. Don’t trust your gut, trust the numbers. If the numbers say you’re wrong, you’re wrong.

Note: Optimizing is not the same as refactoring, though often they go hand in hand. If you’re refactoring code to make it cleaner and simpler, then it doesn’t matter if it goes faster, so no need to revert a cleanup if it has no speed improvement.

4) FOCUS ON ABSOLUTE TIMES.

It means nothing to say that something is 50% faster if it was already fast enough to start. Don’t even think about problems measured in “miliseconds per X” until all of the “seconds per X” problems are already handled.

5) DO THE MOST IMPORTANT OPTIMIZATION FIRST.

Not the one you just found, or the one that’s been nagging you, or the one that lets you use that really awesome algorithm. This is the absolute hardest of all: when you find something new, add it to the list, but always start with the optimization at the top of the list. If the thing at the top of the list hasn’t already been benchmarked, benchmark it. If after benchmarking it you find that it’s actually not as important as something else on the list, log your benchmark results, then put it back on the list at a lower priority.

6) SHOW LOYALTY TO THE USER, NOT TO A LAYER.

Don’t optimize something merely because it’s the slowest in a particular layer; always do whatever increases end-user performance first. Trace the issue and benchmark through all layers before deciding how to speed it up. Leave no layer unturned.

7) CHANGING USER EXPECTATIONS IS THE BEST OPTIMIZATION OF ALL.

Remember, the goal is to make the user satisfied. One way is to actually live up to the user’s expectations. Another is to change their expectations by adjusting the flow in such a fashion that they just don’t expect as much. Some blocking operation really slow? Make it asynchronous such that the user doesn’t care how long it takes.

8 ) BROADCAST BIG PLANS BEFORE YOU DO THEM.

Before building out some really crazy ambitious awesome thing, email to the team explaining what you’re going to do. *Sell* your change, based on the benchmarks. Be proud of your plans; if you feel hesitant it’s probably a sign that you don’t really know what you’re doing or why — and thus probably shouldn’t.

I’m serious, premature optimization is what sinks ships. It’s the tarpit of any engineering organization; it’s where clean and simple architectures go to die. Resist the devil. Be strong.

After a quick halftime break, let’s resume the second half of the series. As mentioned in the past, this is the fourth in a six-part series elaborating on a presentation I gave at the AlwaysOn OnMobile 2011 conference titled “Disrupting the Enterprise”. I suggest reading from the start (or watching the video) and then continuing on below.

Recap: The Three Conditions Underpinning Sales (N+1).0

So there are three interesting conditions at work:

  1. The “Consumerization of IT” empowers employees to promote products up the chain in an enterprise
  2. “Word of Mouth” has become a “Winner Takes All” phenomoneon where early dominance of the global conversation becomes self-reinforcing
  3. There was a one-time “Cascade of App Stores” that gave a substantial and lasting advantage to first movers

The upshot of all of this is I feel there is an enormous opportunity to reach into previously inaccessible parts of the market using a sales strategy that I call Sales… 3.0? 4.0? Let’s just say 10.0 to get ahead of the curve. The very modestly named “Sales 10.0” strategy conists of three principles:

Principle #1: The Bottom Up Adoption Curve

Many industries share a common chart: a very wide base of customers at the “bottom” of the market, narrowing down to a very pointy tip of customers at the “top”. What “bottom vs top” actually means and how it’s quantified depends on the market. But if you’re reading this blog, odds are you’re targeting the “bottom” of the market while some other big company has a stranglehold on the “top”.

At some point, the big company at the top will decide it wants to capture some of the action down at the bottom. It’ll do this by instructing its massive salesforce to start going after smaller deals — probably by adjusting their commission incentives to make smaller deals more attractive than they’d normally be (or by hiring a new sales force devoted to just this). If they’re really serious, they’ll come out with some new product targeted squarely at the small business space.

But don’t worry, because odds are no matter what they try, it’s not going to work. The product and skills needed to operate in and maximize the value of the top of the market just don’t translate down market. Small businesses aren’t small versions of big businesses, they’re an entirely different beast. Any company optimized to hunt whales just isn’t suited to trap squirrels.

This is where the “bottom up adoption curve” comes into play.

In the top-down sale, you typically start talking with senior management — nobody really experiences the product until they’ve already signed off on it. But the bottom-up sale reverses the process, giving a trial of the product straight to the rank-and-file employees, before senior management even hears of it. So while a top-down salesperson would fight tooth and nail to get a limited trial authorized by senior management, the bottom-up product just walks in and starts a trial on day one. Top-down requires some high-level introduction to start a conversation with a new customer, while bottom-up can start with anybody, anywhere in the company — the lower the better. While the top-down company builds a wide range of complex features that appeal to management, the bottom-up company builds the few core features that the actual users of the product love.

The end result is the bottom up adoption curve reaches out directly to the innovators in every company, empowers them to initiate a limited trial without the need for anybody’s permission, and then champion the results internally — essentially giving you an “inside man” pulling for you in every sales lead.

So it’s “bottom up” because you start with the users first, and percolate up to senior management only after the trial has already successfully completed (and thus, there’s no reason to say no). And its an “adoption curve” because it takes a graduated “innovators first” strategy where those who come before learn and train the people who come after (as opposed to a top-down sale where all users are signed up at the same time). It allows your product to be pulled into organizations by the people who need it most, and then sold to all internal stakeholders by someone intimately familiar with the local conditions — all without you ever picking up the phone.

So it’s a system that definitely works in the small business space. It’s very hard to design a product to accomodate it, and it’s very hard to get all the incentives to line up. But when you do, it takes off under its own steam, with each new user expanding your salesforce — and thanking you for it. Everybody wins.

But it’s also “bottom up” in another sense: with this technique, you start with the bottom of the market, and gradually work your way “up” to the top.

Granted, this is the only thing that will work at the very bottom of the market. The deals are so small, and there’s just so damn many of them, you absolutely need to have something like this to survive. The most important feature you ever build is the one that finds the next customer, automatically, while you’re asleep.

And to be fair, if you were only going to sell to the top of the market, you wouldn’t bother with this. It’s really tricky stuff, and it’s so much easier and more effective to just go out and get a sales force (assuming the cost of sale is substantially less than the revneue it brings).

But if you *do* start out at the bottom, and if you *have* already gone through the trouble to make this work… why not use it upmarket as well? After all, there’s nothing about this process that doesn’t work in large companies as well as small. Sure, big companies have bigger requirements. And you might need to get more clever about how exactly you support your internal champions — giving them the tools they need to start a trial without anybody noticing, and promote your product up the food chain in a non-disruptive fashion. But maybe it’ll work there too?

The bottom up adoption curve is a strategy for not merely taking over companies, but taking over markets. And as we’ll see next week, holding onto them forever when you get them.

Thanks for reading, keep an eye out here to read more next Friday!

Previous: A Cascade of App Stores (3/6)

This is the third in a six-part series elaborating on a presentation I gave at the AlwaysOn OnMobile 2011 conference titled “Disrupting the Enterprise”. I suggest reading the first (or watching the video) and then continuing on below.

Condition #3: A Cascade of App Stores

This third condition is done; it was a one-time wave that will likely never be repeated. I’m referring to the overnight rise of a series of web and app stores, and the cascading effect of new stores inhereting the rank of the old, creating a sort of “meta rank” where apps on top of one tend to dominate the rest.

It all started with the iPhone. (You might argue it started with the BlackBerry or even Sidekick, but those stores never really caught on like it did for iPhone.) It seemed like overnight a million apps appeared, vying to appear at the very top of a seemingly infinite list of applications in each category. Furthermore, because your rank was largely a function of your install rate (and your install rate was largely a function of your rank), this created a feedback loop where the people at the top tended to stay at the top and increase their lead over time: it created a strategic high ground with incredible staying power.

Quick on the heels of iPhone was Android. To a degree, the apps at the top of the iPhone App Store were the first ported to Android, and re-established their dominance in the Android Marketplace. (The difficulty of porting to a new platform allowed a bit of discrepancy to appear, but the iPhone ports came in with an advantage over original Android apps.) And then after Android came the Amazon, Verizon, and Windows Mobile app stores — each reinforcing this hierarchy to a greater or lesser degree, and each opening a brief window of opportunity that has since irreparably closed.

(As an aside, the conventional wisdom — so far as I can tell — is to just buy your way up to the top of the app store using TapJoy and its brethren, each time hoping that some of your rank sticks. This does seem to work a bit. But it also tends to flood your data with low-quality leads, such that the more you employ this strategy, the less actual awareness you have about whether any of the signups are worth having. Furthermore, it seems the quality of the installs “at the top” aren’t as good as the quality somewhere in the middle: people who scroll down a couple pages to find you seem more loyal and genuine than those that simply install whatever app appears at the top of the list. But that’s a different topic.)

The upshot is in rapid succession, the mobile app stores established a murky order that tends to slosh around a bit, but generally settle back where it started. I speak here from experience: we missed this wave, and thus our app has a very low rank on each store — and there’s very little we can do about it except fight hard each and every step. But as luck would have it, we were given a second chance.

Right after we launched, Salesforce held a fortuitous contest to create the best expense reporting app, listing the result in the Salesforce AppExchange. We did really well, and earned our place amongst the illustrious “Force 40” — the top 40 Salesforce apps. Right around then, Intuit saw the meteoric rise of the iPhone and Android app stores and thought “I wonder if we can do the same with QuickBooks?” So they came out with the Intuit App Center. And naturally, they approached us to be early adopters, primarily due to our high rank in the AppExchange. This good fortunue repeated with the launch of the Google Apps Marketplace, which obviously couldn’t launch without the top Salesforce AppExchange and Intuit App Center apps (including us). This process repeated a couple times more, and now Expensify appears at the top of all the major web app stores, much to our delight.

But all that is done. Sure, new app stores open up every day — for both mobile and web. But all the major players have already made their moves, and their not going to make them again. That wave has washed ashore, and though we can scramble along the beach for a new position, those that were washed far in have a large, enduring lead over those who weren’t.

Why you should care: If you have an app with high rank, celebrate. If you don’t, prepare for a very long, hard slog to the top. It’s not impossible — and there are snakeoil salesmen touting every dirty trick to accelerate it — but ultimately the deck is stacked against you for the forseeable future.

Tune in next week to continue the series and read about how these three conditions have created a new opportunity for selling into the enterprise in a faster, lower-cost, and higher-quality way than ever before. See you then!

Previous: Word Of Mouth is Winner Takes All (2/6)
Next: The Bottom Up Adoption Curve (4/6)