How I Sold My NYC Condo- Without a Broker

Don’t get me started on real estate brokers, especially in New York city. They’re an affable but utterly contemptible lot who grossly overcharge relative to the service provided. Brokers rely on scarcity of inventory, market fragmentation, and an entrenched lobby to sustain themselves when they are in fact extracting rather than adding value to the market. Try selling without a broker and you’ll probably be boycotted by buyers’ agents, who want to discourage “For Sale By Owner” (FSBO). So most sellers suck it up and pay 6% because they’re afraid not to. It’s a lot like organized crime.

No thanks. I don’t want to pay 6% and I certainly don’t want to contribute to a system which sucks value out of the bottom and gives it to a lazily organized lot of sharply dressed morons.

So I undertook to sell my New York City condo without a broker.

Here’s how I did it:

1) In order to make it easier to sell, I moved out of my residence. No bullshit lining the walls, no pictures, no furniture stained with baby vomit. We cleared out. Now, this isn’t always an option but for us it was a necessity as we have infant twins so cleaning up and leaving the apartment for every showing just wasn’t possible.

2) I hired a stager. In my case, I brought in Jessica and Amanda Salles. These ladies showed up and told me exactly what I needed to do to prepare the condo for sale. Their advice? Refinish the floors, paint, and get it professionally cleaned. Once those steps were complete, they would “furnish” the apartment. A lightly-staged apartment makes it a lot easier for potential buyers to imagine living there. A bed and a sofa give a room a sense scale and size that’s hard for most people to imagine. And a staged apartment photographs exceptionally well. The Salles’ referred me to their vendors – all of whom were excellent and very fairly priced.

2) I got the condo professionally photographed. This made a huge difference. See below..

136915960 120771172

3) I listed the apartment on RealDirect. RealDirect is a site that lets owners pay a flat fee ($395/month) to list a property for sale. RealDirect publishes the listing on the MLS, StreetEasy and all major real estate sites. They do not take a commission (under the plan I chose). But I decided that I would pay the buying broker a commission – 2.5%. I did this because most buyers have a broker and in order to get the foot traffic I needed to yield an offer, a commission was a necessary carrot.

4) I held 3 open houses, all on Saturdays/Sunday. I pushed most of the requests for private showing to the open houses, as I found having to stand around and listen to brokers lie to their clients somewhat tiresome. Total time: 6 hours.

5) I got 4 offers for my apartment. I’d listed it for $1,189,000. One offer was for $1,200,000. Another for 1,150,000. The other two for 1,050,000, but were all cash. Very quickly the higher bidder flaked, despite seeing the apartment three times and his broker assuring me of his good intentions. So I ended up going with the offer for $1,150,000. Total time spent dealing with brokers: ~8 hours.

In all cases the brokers called me up. Each told me how much their client was willing to pay or could be coaxed into paying. And each asked whether the client’s high number would get the deal done. In no case did any broker attempt to meaningfully negotiate on the part of their client. The brokers don’t care – a higher price is better for them. Which is a serious misalignment of interests between the seller and the seller’s broker. As a buyer the biggest reason not to use a broker is negotiating leverage: there’s at least a couple of percentage points discount available to you that would otherwise go to your dumbfuck broker. The second biggest reason is that your broker is probably quietly trying to drive up the price on you. He’s certainly not trying to bring it down.

So net, net, here’s what the deal would have looked like if I’d sold it with a broker:

  • Sale price: $1,150,000
  • 6% Commission: $69,000
  • Net $1,081,000

Here’s what it looked like in reality

  • Sale price: $1,150,000
  • Staging + paint + floors + Real Direct: $9000
  • 2.5% commission to the buyer: $28,750
  • Net $1,112,250

So, I saved myself $31,250. Or about $1953/hour that would otherwise have gone to a broker.

StoryDesk – A Retrospective

The decision to sell a business is an agonizing one. It is particularly so when one has the feeling that there is opportunity left on the table; that the venture hasn’t had an opportunity to run its course; that breakout growth is around the next corner.

This is how I feel about selling StoryDesk.

Having had a bit of time to process my feelings, I offer the following retrospective for your reading enjoyment. I hope you find it useful.

StoryDesk began in early 2011 with the insight that content on a touch-enabled device (iPad) would be experienced, and created, differently than that of a linear medium. The lean-forward experience of a tablet would transform the way stories are experienced. Linear flows would give way to a non-linear storyline; flat images would be replaced by interactive, layered content. This was the idea, anyhow.

With that insight, we searched for a business problem to solve. After hanging out a shingle in the form of a SquareSpace site promising $99 iPad apps, we started getting inbound leads from companies looking to use the iPad as a sales tool.

Ah-hah! This seemed like a reasonable proposition. PowerPoint, the default choice in sales presentation software, had been around for 30 years. Everyone hated it but there weren’t any good alternatives. Businesses use PowerPoint to sell. Could we sell StoryDesk to sales teams looking differentiate their pitch?

We signed a number of customers almost immediately, including an almond farmer in California and a major fashion house in New York city. As an aside, I cold called into the fashion brand and closed them after two meetings. It was very exciting.

Each of these customers wanted a presentation solution, but when we dug deeper, it turned out what they really wanted was an app for presenting their wares and taking an order (like at a trade show).

So we built one. A bad one – because, frankly, no one on our team had much in the way of product sales & ordering.

Within a few months, it became apparent that we’d better go a different route. Each of the clients we pursued wanted a custom integration with their ERP system. And all of the workflows were different. So it was a business I saw as nonstandard, hard to scale, and most importantly, it was totally outside of my comfort zone. Other apps in market offered a similar solution and did a better job at it. I now realize that the custom integrations the clients demanded represented an opportunity to charge for services atop of the SaaS offering. But I was committed to a turnkey offering, for better or worse.

So we killed the catalog product and returned to the initial hypothesis: a sales presentation tool that let a non-technical user upload content to the web and arrange it using an authoring tool we’d built. The content would publish to iPad, appearing within beautifully designed templates. A nonlinear and interactive presentation tool.

This version of the product was also bad. It was clunky and unreliable. But the solution it promised – a way to create interactive content that was many steps beyond PowerPoint – touched on a need. We signed 5-7 customers on this product within the first few months of 2012. We spent the remainder of 2012 trying to refine this version of the product (web to iPad) and get it to a point of stability. It never happened. The core architecture was flawed and the guy we had doing the web portion wasn’t strong enough to deliver what we needed. I was slow to acknowledge and act on this. Our product was crap but I somehow convinced myself it was acceptable. My development team kept telling me they could get the product up to snuff, but they underestimated the time and manpower required. Leads were streaming in. Even Microsoft came knocking – in the form of product managers and patent lawyers poking around the product. This is how I knew we were on to something.

By early 2013 the market for iPad presentation software was heating up. Still, we were having difficulty converting a lot of our leads to customers. Part of this was because the product we had in market wasn’t good enough. But part of it was because there were a lot of “tire kickers” who were intrigued by the offering but felt no urgency to buy.

We continued to improve the web-to-iPad experience but still couldn’t get it right. By April, I’d had enough. In order to get the product to where it needed to be, we needed to rebuild the product from the ground up – making it an end-to-end iPad product. Our iOS guy was very strong, and so it made sense to leverage this capability. I fired the web guy and we went all-in on iPad.

By September 2013 we went live with the new product. It was beautiful. Easy to use, stable, elegant – everything we’d wanted. We were seeing 20-50 signups a day from the app store. Apple promoted it as a best new app. But the product still lacked some of the necessary features to convert trials into sales. Chief among them was an easy way to pay.

Through the end of 2013 we saw our MRR grow from $7000/month to $15,000/month. This owed in part to adding an inside sales guy to close deals. By early 2014 things were really looking up. That said, we still saw a yawning gap between leaded and buyers. No one was in a hurry to buy.

We rounded $20,000 a month in MRR by Q1/2014. We were adding 1-2 customers a month. We added several critical product features like Analytics.

I attempted to raise a round of capital but had no success. Investors didn’t believe that StoryDesk could deliver a venture-scale return. Or they didn’t believe we were in a position of breakout market leadership. Or whatever. I solicited ~80 investors but couldn’t secure a lead. It was baffling. We were in a big space, with an awesome product, and had enjoyed breakout growth over the trailing 6 months.

In April, 2014, my now-wife gave birth to twins. One of our children was born with serious, life-long medical issues and spent a month in the NICU. The stress and exhaustion of this was immense. I didn’t take adequate care of my own physical and mental health.

By May, 2014 things with the business seemed to have plateaued. Our inside sales guy was working hard as ever, and lead flow was decent, but alas we couldn’t seem to catch a break. With burn at $50,000 a month, I had to cut costs. One dev left, and I laid off the sales guy in June. In retrospect, this was probably a mistake but I didn’t really have any good options.

Our existing base of customers – about 30 corporate clients – were mixed in their post-sales adoption. About 1/3 were loyal and continuous users; about 1/3 were occasional but still happy users; and the final 1/3 paid for the product and never used it (but still renewed!).

Product development continued even if sales stalled.

In July, 2014 we released a much sought after feature called Roundtable.

In August, 2014 we released a feature that matched our competitor’s core offering.

But none of this stuff seemed to get the needle to move.

With cash reserves running low I began to fundraise even more aggressively – this time from seed and angel investors. The capital markets still weren’t buying the story. My stress level – coupled with insomnia – contributed to what I now realize was burnout.

With a number of high-profile deals hanging in the balance, I decided to drip-fund the business from my own pocket. After two months of hustling we still couldn’t seem to get anything to close (clients or follow-on investors).

So in mid-November I laid off the team and approached my competitors for a sale.

We still had happy clients using the product; there were ~20-40 people signing up for it daily; inbound sales leads were coming in at a steady clip. Which is particularly frustrating, as it’s evidence of demand. But a trickle of demand won’t support a software business. It needs to gush. I considered continuing to fund the business with my own money but decided against it. Given my obligations, I couldn’t take on that sort of risk.

We got four offers for the business. I took the best one.


I made a number of errors in the rollout of this business. Chief among them was not having a specific, expensive, and broadly understood problem to solve at the outset. I shoehorned an insight into an opportunity. As a result, we wasted too much time and money at the beginning trying to get the product right. I delayed making the necessary product decisions until there was adequate data when instead I should have followed by own instincts. By the time we actually got to the product we wanted, it was too late. And, frankly, it didn’t matter anyhow – because the solution it offered didn’t appeal to a broad enough (big enough) potential market for venture backing. But if we’d had more runway then I suspect I could have flipped it into a “lifestyle” business and grown it slowly over time.

So what are the specific lessons / takeaways from this experience?

1) Clearly identify a critical and expensive problem at the outset and solve for it.

(This is lesson 1-100 with StoryDesk. All of the other lessons are derivative.)

101) Make sure your solution addresses an acute and urgent problem. Anything less and you’ll be stuck in the tepid hell of extended sales cycles.

102) Don’t bet on external funding. Though StoryDesk raised some external funding, I could never quite decide what trajectory we were going to take. Sometimes I thought we’d bootstrap and grow slowly; other times it seemed like raising and growing would make sense. If I’d committed to one vector we’d have been better off. Next time I will bootstrap to profitability and then carefully consider seeking external capital for expansion/growth.

103) As a corollary to #3, focus on cashflow above all. Neglecting this in favor of growth with the hope you’ll raise external financing is a sucker’s bet. Cashflow is predictable; the only thing predictable about venture investors is that they’re fickle and full of shit until they write a check, which they only do a few times a year.

104) Fuck “Lean Startup.” Build, Measure Learn is a truly idiotic strategy. It should be Learn, Build, Sell.

Though I made many mistakes in my execution of StoryDesk, I believe that we did a number of things well. I am immensely proud of the product we built, the team we assembled, the customers we had the opportunity to serve (at some point I’ll write a post about the things we did right), and the investors who supported us. I miss them all, especially the team. Maybe it’s something only founders can understand, but there’s something incredibly satisfying – and addicting – in creating from nothing a business where wonderful, creative people can gather to do good work. It’s further fulfilling to go out into the world and sell our work-product to companies who want it. To me, it’s the most meaningful work I can do. And I’m very much looking forward to getting back to it.

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