Why The Boom In Enterprise Tech Will Happen In New York

After more than a year building Writebot, we learned there's no better place to learn how to be lean—and no other city with such an urgent need for simple, usable software.

A year ago at this time, as I was preparing to be thrown out of my Greenpoint loft for Airbnb'ing too much, I began to realize what can happen when you let things get too complicated.

People like to talk about simplicity, the type you associate with Apple products or fine cuisine—luxurious, elegant, unadorned. But there's another kind of simplicity—the back-against-the-wall sort, where you're forced to slash and burn, leaving behind the things you thought you needed to be shoved off to the side of a hallway. In that way, bootstrapping a software product is a lot like getting evicted. Simplicity isn't so much a design choice as a point of survival.

I'm writing the draft of this article in a real-time web app called Writebot: A simple, web-based productivity tool that two friends and I have designed and built, and for the past six months, tested here at FastCo.Labs. It's used at about a dozen publishers, banks, and hedge funds here in New York. It is not the prettiest—the entire visual design is grayscale—and it doesn't integrate with Facebook or Twitter. It's simply a web-based repository that lets you quickly ball up a bunch of raw materials—files, links, notes, chats—into a single page and start a project. It looks like this.

It's almost shameful how long it took us, me and my partners—Ananth Muniyappa and Jon James—to arrive at something this constrained. And much of what I learned designing Writebot last year got poured into FastCo.Labs this spring. This site is about exactly this process—teaching yourself how to think about software. To that end, here's what we learned about simplicity while building Writebot—and why New York is the best (and scariest) place to solve big business problems with software.

Start with a shamefully small part of the problem.

When I drew the first wireframe for Writebot, it was in 15 minutes—after literally thousands of other wireframes and specs of much more ambitious tools. As a journalist and consultant, I had seen first-hand how messy most companies' internal workflows were. With a couple of iOS development books under my belt, I thought I could design a mobile app that would totally streamline the way people managed projects. Ha.

It took almost a year of research, YouTube learning, burning cash, and frying brain cells before I got humble enough to just draw a simple web app that would just save me, and people like me, a precious few minutes. The first drawing looked like this:

The task flow above: Search for news, drag relevant links into a "bucket," and take some notes on what you've collected. Then share that page via a single URL. That's it.

The more I read (and write) the stories of products' early days, the clearer it becomes that even the most complex systems and products begin with something that is almost shamefully reductive. They grow with the people that use them. You can't plan out any of it on paper. The metaphor of a product "road map" is all wrong. It's more like genetics—you don't know exactly how the thing will look, but there are certain core traits you know it will exhibit.

As you get users, they start to ask for things, and you start to find adjacent problems that you could solve. Complexity comes naturally and fast. If the base product is already complex any way, the concept will turn to dust when you start adding features and you’ll be eaten alive by scope creep. Below, we almost immediately had to add tabs to the real-time Notes area because people kept asking for them, even though it wasn’t in our dev pipeline.

Like the Terminator, your product should be built to protect people.

Left to their own devices, computing systems (like the rest of the universe) will grow in complexity. The more time they save us in one way, the more they require in another. Call it the "law of thermodynamics of bitch work." Somehow the more "tools" I had in my toolkit, the less time I felt I had to think and write. For me, Writebot was designed to protect what I value—my creative energy.

The cloud—everything, everywhere!—sounds great until you realize you have duplicate files all over the place and no clue where anything's stored when you need it. There’s stuff archived in Dropbox or Box, versions frozen in email, common docs on the corporate intranet, images, videos, and voice recordings on your phone, and a whole pile of downloads on your desktop. Below, a file bucket exists on every Writebot project.

By 2011, when the idea for Writebot started germinating, news sites like ours had begun to run lots of rich media. But before you see finished articles like this one, the raw materials live scattered across the hard drives of reporters, editors, videographers, photo editors, producers, and developers. Every time you start a big article, you feel like Sisyphus grabbing the boulder: You forage for info, you share things, you brainstorm—and you almost immediately start to lose track of your raw materials.

Someone else probably feels your pain.

When I abstracted out my frustration with journalism, I felt as though I spent half my day digging around my computer to copy and paste things. It sucked, sure, but it wasn’t exactly world hunger. The original Writebot concept was so basic—just a simple way to manage big groups of links—that it was tough to think of use cases outside of, well, myself.

It wasn't until Ananth, who is a former hedge fund analyst and trader, started to consider his own specie of bitch work that we realized other businesses (in the capital markets) were burning time the same way. We thought people in media and finance might be experiencing similar problems. And people in both industries place primacy on speed, so they really, really hate losing time. We started to think of Writebot as a tool that could work for both.

Find the easy way in.

In New York, people generally treat jobs like spouses. If you're going to intercede in someone's work/marriage with a software product, it has to be workflow-agnostic and modular. People need to be able to drop it right in and see if there's an improvement. And if not, rip it out.

Last month we told the pivot story of a Y-Combinator company called AnyPerk, which sells employee benefits packages to other startup companies. Theirs is an ingenious business because they were able to sell to other startups who can change policy quickly. But in New York, where lots of businesses have existed unchanged for decades, there are routines. There are best practices. There is IT policy. There is IE8.

On my trips out to San Francisco, I had met with all sorts of startups building amazing consumer apps. But then I'd go back to my hotel and lose precious ounces of sanity and time to this mundane problem of starting an article. When it came time to improve the process, I just started at the part of the article process that was most unstructured and also most painful—the beginning.

Solve a problem that feels like it’s killing you (or someone you care about).

The start of the writing process made me stressed, anxious, late on deadlines, error-prone, and generally grumpy. It literally cost me income, enough that I took on the opportunity cost of trying to solve it.

You see the same approach in projects like the experimental apartment finder we covered yesterday, built by WSJ reporter and programmer Jeremy Singer-Vine. In Silicon Valley, where things are cheap and space is plentiful, minds wander towards solving inconveniences or using the Internet towards a greater good. A side project in NYC is more like trying to plant a vegetable garden next to a highway—there’s often a shred of desperation.

To stick with the project, you don't just need a core problem that's killing you, but a message of hope about how to solve it. You need to value something that is being threatened by that problem, and your product has to exhibit a hypothesis about how you can protect that thing you value. With Jonathan's app, the theory is that human referral beats algorithms for certain high-value items (like an apartment). The hypothesis behind Writebot is that projects maintain greater momentum when they get going fast.

Even when you make huge pivots like we did—starting with a consumer iOS app and ending up with a real-time web app for enterprises—you'll never feel lost if you are always circling in on the problem. As Gentry Underwood from Mailbox (now, Dropbox) told me last month:

There's this sense that you can take the parts of [your startup] that are working and reapply those parts to a new problem—that you end up having these two degrees of freedom. . . . I think when you have that much freedom, it's really easy to get lost. It's easy to lose your bearings in terms of why you're doing what you're doing. With that goes, I think, a lot of the motivation to suffer through all the hard parts that are inevitable, no matter how close you are to an actual solution. In our case, we pivoted from Orchestra to Mailbox, but we pivoted in a way that it was pretty different in a sense that we never let go of the "why" that we were trying to solve when we started. . . . The problem was always the same consistently throughout. I think that's central to why we were able to finally find product-market fit—because we tried a lot of different stuff, but it was always attached to the same problem. It wasn't like we were truly floating along the way.

Don’t ignore the mess made by the last generation of software tools.

Business used to move at the pace of its systems. You compiled your report, mailed it off, and had a cocktail while waiting for the Chicago office to read it two days later. But work happens so fast, and we all manage so many systems, that the time it takes you to dig around and copy-paste stuff is actually costing money.

Complex businesses like the ones that are mainstays here in New York—banking, media, fashion, consulting—need simplicity more than ever. The tools that were boons a decade ago are sucking the life out of them now. What costs one employee a few wasted minutes scales to enormous waste across an enterprise. You can’t even think about solving this schema of problems unless you acknowledge and work within legacy systems.

Financial institutions love Bloomberg because it's a super-efficient market data tool. But it's just a data feed—it's not efficient at putting together projects. There's chat and email-like functionality, but no content or idea production. In the decades since Bloomberg launched, the reports, models, research, and pivot tables that analysts, traders, and sales people create every day have become scattered across email, chat, intranet, and local hard drives in all sorts of formats—PowerPoint, Word, PDF, email, pivot tables, screenshots.

When it comes time for work groups to manage clients, stuff gets lost, and in a digital cloud-based world, customers don't tolerate that excuse anymore. If the startup-minded kids at Stanford had any idea how neolithic the processes were inside big business today, they wouldn't build dating apps.

[Image: Flickr user Doc Searls]

Add New Comment


  • Pat Morrell

    Preface/context: I'm with a Charlotte-based enterprise tech-innovation shop. My knee-jerk response to this headline was "Ppppssshhhh... this dude's obviously never heard of Charlotte, NC...." 
    Naturally, I read the article to its completion and agree wholeheartedly with the predictive conclusion. The enterprise tech-innovation boom will not come (solely) from traditionally tech-progressive markets i.e. SF.  Problem-solving, neolithic-process-killing, business-centric software products are just as likely -- perhaps more likely -- to emerge from markets like NY, Atlanta, and Charlotte that have roots in traditional, brick-and-mortar, actual-dollars-in-and-actual-dollars-out industries (fin serv, manufacturing, media, etc.).

    Unfortunately, you're all too correct to note that these markets/industries are swimming in outdated software and sloth-like techprocesses. 
    Fortunately, as I imagine you've seen in NY – and as we've witnessed here in Charlotte – these traditional industries do have a long-standing penchant for driving incremental efficiencies and (eventually) solving real-world business problems to generate new revenue.  They're old pros at regularly getting better and making money.
    This historical continual-improvement capacity is not a newly realized phoenix-ian skill. It’s the smart business of incremental improvements. And it lays foundation for these industries to spark an enterprise tech boom because they aren't, and won't be, focused on what's the most progressive, or what's the coolest, or what's the best algorithm to generate pre-tailored content to engender longer time-on-site. They'll be focused on what problems need to be solved to make their business run better and their people more efficient.  And software will now be the vehicle with which they solve that problem.  

    What now enables these traditional businesses to propel upward from this problem-solving foundation is a set of two intermingling cultural technology shifts.
    1) Business leaders now realize they have options.  Traditional business leaders don’t care about cool.  They care about things that make work/life more efficient and solve problems.  They care about reducing inputs and increasing outputs.  Technology
    has always been about solving problems and enabling efficiency, but traditionally it's been seen as a hoop to jump through.  Many of the business leaders we talk to have historically seen software as something "we have to use" as opposed to something "we get to use."  Now that paradigm is shifting.  These same business leaders now understand that "software solves problems" because technology, in general, is no longer intimidating or generationally unattainable.  A major enterprise-tech wall tumbled the minute your 75 year old grandfather-CEO got an iPad. We’ve seen business people internalize this “tech solves problems” concept on an entirely different and more intimate level because they now use progressive technology every single day. They’re starting to realize that any/all worthwhile software application should reduce inputs and increase outputs, and be easy-to-use; that ALL software should make work-life easier, and at the same time drive business efficiencies and revenue.  More to the point, companies
    now know that that they don't always have to go with off-the-shelf products from Big Blue et al.  This is not novel idea for sub-35-year-olds -- "of course software should be user-friendly and solve problems" -- but for a lot of tenured business folks, this is an awakening. And this realization is the linchpin for new ideas getting bankrolled and risks being taken.
    2) Tech innovators want the white picket fence, too.  Progressive programmers and product developers are people too.  Many want a certain quality of life – kids, white picket fence, dog, draft beer for less than $12, etc. -- that they can't afford or enjoy in larger markets like SF and NY.  So they’re dispersing into other markets, seeking opportunities at companies where business leaders have internalized this new-tech-realization. I've seen this on a narrative level as we attract folks from startups and big tech companies to come down to Charlotte and work at Skookum. We’ve seen it happen for our clients, too.  And dozens of other companies see this talent spread take place in markets like Atlanta, Austin, Boulder, and Chicago. As the talent spreads, so too does the potential for traditional companies to begin realizing and implementing their newly conceived options and ideas.

    The challenge often lies in distinguishing and prioritizing business problems, journey-mapping people-centric product concepts, and then developing those products into testable and measurable applications.  

    Pure tech expertise -- the ability to layer rich and cool bells-and-whistle features -- used to be the difference maker between software success and failure.  But the enterprise tech boom will instead rely on holistic product development/testing expertise.

    It all really comes down to an “executive-realization” and a “tech-talent spread.”  So what does this all mean?  A gray-haired CEO at a southern manufacturing company will soon (or has already) say:
    “I actually like to use apps on my iPad.  Why isn’t our ERP system this easy to use?.... (big build-up) Let’s get on this!!” (Cue montage of boardroom applause, papers flying skyward, grown men cheering, charts and graphs showing skyward arrows, people smiling at tablets, factories running cleanly and efficiently, etc.).
    And this scene can – and will – take place in Charlotte, just as easily as it could in New York or Atlanta or Austin.  Or all of the above.

  • seventhman

    I love this statement: "Solve a problem that feels like it’s killing you (or someone you care about)..." People often have this insane idea that innovation has to be complex.. and they're missing out on the basics.  In my own lingo, it's either your business innovate or die trying.  Think of it as free soloing without the safety gear.  When your life is at stake, there's really no room for the slightest mistake.