Investing in Mobile-First Enterprise Companies – 5 Questions to Ask

Let me preface this post by saying I’m an unqualified investor, both according to the SEC and generally accepted indicators: I’ve never made a venture or angel investment in my life. However, in keeping with the spirit of the startup/VC community, I see no reason why this should preclude me from confidently opining on the topic. I’ve operated a mobile-first enterprise company for ~3 years, and I so have a pretty good idea what the roadblocks to growth are. There are a unique set of business challenges that come with building a business on this emerging platform. More than this, though, is a highly dynamic landscape of devices, distribution channels, operating systems, and security standards. Welcome to the Wild West!

I see tons of opportunities for software companies looking to deliver mobile-first solutions to enterprise. For my investor friends looking to back companies in the space, these are some of the questions I’d be asking:

1)   Has the company found a way to acquire customers from within the app store(s)?

Like it or not, app stores are most mobile customers’ (enterprise included) first stop in sourcing mobile software. Optimizing for this is critical to finding prospects who both have the device and are in market for a solution. App Store Optimization can help you get found, sort of, but people need to be looking first. If the customer finds the app, he/she needs a way to try it out easily and cheaply. In-app onboarding is therefore essential to acquiring customers. If a company can’t onboard customers through the app, acquiring customers at scale will be exceedingly difficult.

2)   Can the company acquire and retain customers outside of the app store?

Mastery of traditional marketing methods is critical to driving awareness amongst current and future device owners. Remember, there are still plenty of companies who have not deployed smart phones or tablets to their employees – much less apps. Has the company found a way to reach them at the top of the funnel? And as important, has the company found a way to do it affordably? And after the company has acquired the customers, can it market across channels to drive engagement and ensure retention? Absent these competencies, mobile-first companies will find it hard to reach the addressable market and hold on to the customers it already has.

3)   Is the app easy to deploy, but hard to quit?

Easier said than done. Good mobile-first apps can get the user from zero to hero quickly. Great ones do this, but find some way to deeply integrate the product (technically or behaviorally) with important business functions, making them harder to quit. Look for creative lock-in, network effects, or technical integration. Without something else to keep users coming back, apps risk falling by the wayside.

4)   Does the company have a relationship with its customers outside of the device and/or the Apple paywall?

This is a biggie. I’m seeing a number of “successful” iOS apps with big install bases and solid revenue. But they have no idea who their customers are because 1) there is no registration process and 2) they have no visibility into the e-commerce transaction. Having a hand in at least one of these workflows is necessary if you want to build an enduring relationship with the customer over time and through device replacement cycles. Failing this, the company will struggle with retention and have no real chance to upsell or broaden the product footprint over time.

5)   Does the company have a vision and product framework to support additional features and functionality – and therefore revenue – over time?

This is where the road of bones will be for many mobile first enterprise companies. Put simply, the LTV will be less than the CAC. Viewed from the standpoint of revenue, to generate $100,000,000 in annual recurring revenue the startup needs to have 10,000 customers paying $10,000/year. Or 6600 customers paying $15,000/year. Or 5000 customers paying $20,000/year. These are hard numbers to hit if your app solves a narrow problem retails for $9.95. But these numbers can absolutely be hit if your app solves a narrow problem but is well suited to expand its offering, therefore its revenue, over time. So look for a big vision, but also look for a level of extensibility in the product that already has traction. This can be tricky, given that mobile products tend to have narrow footprints. Product suites on mobile will be trickier than the desktop given the siloed nature of apps.

What have I missed? Feedback is most welcome.

What is a “Mobile-First” App?

There’s a ton of noise around the notion of a mobile-first application. Most people following the space would be hard pressed to define it – preferring instead to apply the pornography rule (“know it when you see it”) to software innovation. I think we can do better. Below you’ll find a framework for mobile-first software. I welcome feedback and I also reserve the right to evolve this post over time.

Mobile-First Apps are:

1)   End-to-End Mobile

A mobile-first experience does not originate on the desktop and then migrate to the app; it begins (the “first” part of “mobile first”) on the app and enables a value-creation event without ever touching the desktop. It’s an end-to-end mobile experience, not a mobile product functioning as an extension of the desktop. Tethering the app to the desktop puts an upper limit on the extensibility of the mobile software. It also delivers a disjointed experience for the end user. Build for mobile or build for desktop; cross-leveraging seems like a good idea but is ultimately dilutive.

2)   Enable Information Immediacy

A major benefit of mobility is immediacy of information, communication, etc. We like iPhones not because they fit into our pocket but because we can access and create information immediately. This same rule applies to mobile-first apps. They must satisfy urgent requirements to either access or create information – preferably both.

3)   Create New Occasions for Computing

Tablets and phones are computers that don’t look or feel like computers. Relative to a laptop, mobile devices are less intrusive props in restaurants, hallways, and tradeshows. Mobile-first software leverages this versatility to create new occasions to compute. The opportunity isn’t in re-inventing a desktop experience – it’s in infusing every day business interactions with software for a more productive, profitable experience.

4)   Constrain Features for Ease-of-Use

Whereas desktop and web experiences are marked by bloated feature sets and everything-in-one (like Office) offerings, mobile-first software celebrates restraint. A smaller screen and a limited number of interactions mean that software needs to be focused on specific, discrete tasks. These constraints result in more disciplined product development. And a narrowly-focused products free from unnecessary distraction and options. In the end, these products are easier to use.

What have I missed?

Field Notes from the Front Lines of Enterprise SaaS

There’s some weird stuff happening within corporate IT buying. It can be a mixed bag for enterprise software startups. Here’s what I’m seeing.

-IT shopping and buying is no longer the exclusive province of IT. Domain-specific buyers are emerging, and they’re not afraid to write a check for software that solves a problem for them. They move forward with and without the participation of IT. So, writ large, the addressable market for software within enterprise has multiplied. This is great news for everyone.

-Free and free trials are great, but you still need a sales effort. Self-adoption + payment is of course the jackpot for SaaS.  But even lightweight products that can be deployed with no-touch need to be “sold.” By this, I mean someone needs to get the user on the phone and work to lever a single happy user into a widespread deployment. Bottoms-up adoption is ideal; more often, though, someone needs to push and make your product a priority for a wider team. Great products are easier to sell than shitty ones, but they don’t just sell themselves. If you doubt this, then have a look at Salesforce’s sales headcount.

-For many businesses, the effort to sell 10 seats is the same as selling 1000. This is  where companies offering easy-to-adopt software sold in increments can run into trouble. XYZ Inc. with $10B in revenue wants to buy your product. But they only want 10 seats—now. Though they quietly suggest that if these 10 users are happy then the whole company might deploy the product.. The time and energy required to sell the 10 seats is substantial. Big companies don’t buy software casually, so expect an IT audit and lengthy procurement process. Therefore, very often these 10 seats are money losers as you try to buy optionality for a larger deployment (which may or may not happen). One way to mitigate against this is by charging an implementation fee or similar pro-serv charge to cover the cost of the sale. But this isn’t always feasible, so in order to not get hosed, you need to make sure your client is a good fit for the product. We’ve all done deals where we suspect our product is an awkward fit for a client, and the client doesn’t know it yet. I strongly suggest walking away from these deals as everyone will be unhappy in the end. Sometimes clients are a good fit, but you’re unsure if they’ll be able to deploy successfully. In this case you need to accommodate for this by training the living daylights out of their team. A closed deal is the beginning of the journey. Training and support are critical to engendering a virtuous cycle of adoption, retention, and referrals. In the offline world, it’s called taking care of your clients.


-Enterprise buyers have an inherent bias against “startups.” No corporate exec wants to rollout software only to have the vendor go out of business 2 months later. So be prepared to answer questions about the solvency of your business and offer references. More than this, though, is considering your corporate and personal brand relative to this audience. While you may find the while “startup” shtick exciting and romantic and you may consider sneakers and hoodie to be acceptable business attire, I can assure you that corporate execs at a big manufacturing company in Michigan find none of this very confidence inspiring. If you’re going to sell to grown ups at grown up prices, then you’d better look and act like a grown up.

The MVP and Technical Debt

The inevitable bi-product of a pivot is technical debt. Each time the product footprint changes, the foundational codebase required to support similarly needs to be retrofitted. Each pivot, and therefore each retrofit, adds a layer of complexity to the codebase. When you are rapidly iterating you don’t have time so rebuild the code base to accommodate each pivot. Until you have validated the pivot, it makes no sense to invest in durable code. Easier said than done. The product needs to work reasonably well for the business model to be validated with sales. But selling an MVP is a pretty tricky tightrope: customers will get frustrated pretty quickly when the realize the product is less than the promise. But this is actually a good thing. If clients believe enough in your product to get pissed off about it, it’s a sign you’re on to something. The best thing you can do, at this point, is to try to pay off the technical debt as soon as possible – building with intention and plans for scale – and then re-release the product. It’s an exercise in sophistry and chance, but it’s also the most efficient way to reach product market fit without letting technical debt force you into actual bankruptcy.

Sales & Product Truth

The only way to determine a product’s viability in the marketplace is to try to sell it to a customer.

Through the din of bullshit, the customer stands tall as an agent of truth.

His/her cash is truly the source of all that is beautiful and virtuous in startup-land. Predictions, assumptions, beliefs, and feedback are all bullshit until you can convince someone to pay for your product. Sales is the only validation that matters.

So how do you sell an early stage product when, ahem, there isn’t much of a product? Don’t you need a completed product before you can sell it?

No. Here are three ways to sell – gathering critical product-market-fit data – without a finished product:

1)  Sell an MVP and a product plan, with payments due on product delivery milestones. You can show customers the early product, let them get value out of it, and then tell them what you’re building. If they like it, ask for a sale that requires them to pay you on delivery of those particular deliverables. Not before. There’s no risk for them and you know that there’s money up around the corner.

2)  Create brochure-ware that presents a product / feature set / price with a way to sign up and pay. But don’t process the cards or take the money. Use this as an opportunity to call up the customer and arrange a pre-sale based on future deliverable. This approach will garner important data about pricing thresholds, traffic sources, and customer priorities. And nothing says intent to buy like hitting the “purchase” button.

3)  Create a finished, working prototype that is a one-off (not a product of the platform) and attempt to sell versions of this. In essence, build the product before you build the platform. Once you’ve sold the product, or a version of it, then reverse engineer success. It’s a lot easier (and faster) to build systems when you know what the end game should be.  No shoe cobbler ever built a shoe factory before he handcrafted a few pairs of shoes to make sure people would pay for them.

Sales is where the most honest discussions happen in any startup. Harness this dynamic to rapidly assess the viability of your business. Doing otherwise can be expensive journey in self-delusion.

(Also, it bears reminding that defrauding your customers or yourself is a really bad idea.)

Selling to Enterprise: A Primer for Consumer Internet Entrepreneurs

There are many wonderful things about creating digital products for consumers, but the business model usually isn’t one of them. Getting consumers to pay for software is tough; they’ve been habituated to believe that it should be free or close to it.

Enterprise, not so much. Businesses spend a ton of money on software. Which is one of the many reasons I now work in enterprise: there’s an honest exchange of money for services. Rather than guessing what consumers want and hoping to get lucky, companies will tell you what they need and then write a check if you can deliver it. They’ve no interest in bullshitting you. As a result, product and business roadmaps can be built around articulated customer demands.

But that doesn’t mean it’s easy. Entrepreneurship in enterprise is not for the faint of heart. Here’s what I wish I knew when we started StoryDesk 2 years ago.

1)   Companies don’t want, and will not pay for, minimum viable products. They want software they can rely on for critical business functions. Early products that you might ship to consumers, buggy and feature incomplete, don’t sail with enterprise. Doesn’t matter if it’s cheap or even free – companies seek reliability and continuity above all. So make sure you build in ample time for testing and QA into your product development timelines. A MVP might be a good way to vet and validate the market, but don’t expect people to pay for it until the product is stable to a fault and feature complete for the solution you are selling.

2)   Sales cycles aren’t long – they’re ridiculously long. In a NTW product in an emerging market, prepare for sales cycles that are 3-6-12 months long. Lowering the barriers to adoption through free trials and self-service adoptions can compress these timelines. But whatever your expectations are for close rates and sales cycles, lower them. That said, once the product has been figured out and you’ve nailed the pitch, things will pick up. That’s what I’m seeing in our business. It’s very exciting.

3)   Content is king. Blog posts, thought leadership, videos, white papers – this is the honey in the fly trap. Devote a big chunk of time to your content marketing effort, as this is by far the best way to attract leads, let potential customers educate themselves, and then have more efficient sales conversations when they’re ready to buy. Done well, content widens the funnel and shortens the sales cycle.

4)   Reduce sales risk for your client. The project leader’s first goal is not to get fired. After all, he/she’s got a minivan, a mortgage, and nice big company benefits package. He/she isn’t going to bet that on a “speculative” software product. No one ever got in trouble for making the safe bet. Your startup is unlikely to be the safe bet (otherwise you wouldn’t be a startup). So, find ways to reduce the risk for your client. A proof-of-concept , a pilot project, a money back guarantee (not recommended, but certainly not uncommon) are all ways to do this. Make the cost of failure (capital or political) low, and talk up the potential upside.

5)   Follow up. Follow up. Follow up. Closing deals is very hard. The only way it happens is if you go after it with tenacity and diligence. Shelve your pride. Business is won by the individual with the greatest capacity for rejection. All those girls who shot you down in high school? Send them a thank you card – they’ve done you a great service.

Good luck!

On Happiness

Are there best practices for happiness in individuals or families? Can a set of rules, a paradigm, a logic be applied uniformly toward achieving a predictably positive outcome? Why, in a nation of great stability and generalized and shared experience, is there such heterogeneity in the human outcomes? In short, why are some people happy and others miserable? What are the ingredients for happiness? And if it’s unique to a person, why is it unique to a person? Shouldn’t there be some basic guidelines that lead to a positive outcome at least 80% of the time? We know that this is certainly the case in the inverse – that if, for example, one is chronically violent it will lead to personal unhappiness. But why is the opposite untrue? Why is that non-violence doesn’t lead to happiness? I understand the rejoinder – that its necessary condition of happiness, necessary but not sufficient in what is a multivariate equation of infinite complexity. What I don’t understand is why this is infinitely complex. Surely we can control for some of the variability given a common set of experiences or circumstances. Or at least the absence of a negative set of experiences or circumstances.


Who has looked at this? I ask not because I am unhappy – alas, I am not. I ask because I find myself surrounded by people who are unhappy, who lack obvious reasons for this condition.