The Other Productivity App I Love

Posted on January 31, 2016February 4, 2016 by rogteran

Let’s get something straight: I love Slack. Slack was, without a doubt, the most transformative productivity software I started using in 2015. Slack has quickly become the heart of so many organizations, pumping a constant stream of internal communication and coordination. But a successful organization also needs arms and legs to swiftly get work done in real time. Enter Quip, the mobile-native collaborative word processor I can’t live without.

That Magical Moment

For years I struggled to get any work done in an airplane. I’m 6’3’’, so typing on my laptop during a flight is nearly impossible (when I do, I look like a baby T-Rex). Even though I always traveled with a smartphone and a tablet, I was never able to get much work done on them because mobile productivity applications remained largely ensnared in an antiquated, single-mode paradigm: either entirely offline (Microsoft Office) or completely online (Google Docs).

A trusted friend recommended I try Quip. According to him, Quip “bridged the online and offline worlds,” creating the continuous availability I was desperately seeking. I decided to give it a shot.

When I first opened the app on my iPhone, I experienced a familiar interface resembling that of my email inbox. The top drawer displayed a “What is Quip?” message conveniently waiting for me to tap it. This action swept open an instructional manual on how to use the product. Thumb-on-screen, I dragged the page down ever so slightly until I saw the “Just start typing” sentence on the screen. Huh? I tapped the screen…

My heart stops. A cursor starts flickering on the screen while the keyboard magically slides up. My brain’s been tricked: Although the content looks and feels immutable, the page is actually editable! I feel I have just taken a plunge into my smartphone screen. In a world where I am flooded with new products every day, very few ever manage to trigger a powerful physiological reaction of both surprise and delight. Could this really be an enterprise product?

A Whole New World

Enterprise software is changing for the better—namely, by applying consumer software best practices. Under the hood, a core technology shift and a concurrent demographic shift drive the consumerization of productivity software.

Although mobile phones have been around since the 1970s, the mobile era of computing really began in 2007 with the advent of the iPhone. By pocket-sizing a computer with Internet access, we could now be connected all day, everywhere we went. From an enterprise perspective, doing work would no longer be confined by the physicality of sitting in front of a PC. According to tech strategist Ben Thompson, “By virtue of being, well, mobile, smartphones extend computing to every aspect of our daily lives.”

This monumental shift still remains an underrated technology trend. In Mary Meeker’s latest Internet Trends report, there are 5.2 billion mobile phone users, 2.1 billion of which are smartphone subscribers. To put it in perspective, there are roughly 1.5 billion PCs. Yeah, welcome to the mobile era. Moreover, replacement cycles for mobile devices are more than twice as fast than PCs. As Benedict Evans pronounced in his blog, “The smartphone itself is close to a universal product for humanity—the first the tech industry has ever had.”

Accelerating the impact of the mobile era is the demographic shift in the workplace. According to Meeker, over the last five years, millennials have overtaken baby boomers and gen-X’ers as the predominant generation represented in the workforce. Millennials, a plurality of which are doing freelance gigs, expect a ton of flexibility in the workplace. Furthermore, work and communication habits entrenched in the previous generations are less so with millennials: indeed 34% of millennials prefer to collaborate online and, more importantly, 45% of millennials use their personal smartphones for work purposes.

This is critical because it couples together the purchaser of productivity software with the end user. Not too long ago, users rarely had any input with regard to which PC they would use in the workplace—it was mainly a cost-based decision made by someone else at the firm. But the ubiquitous nature of smartphones have blurred the lines between our professional and personal lives. As such, we are willing to engage with productivity-related products at home or on the go. That said, if it’s going to sit next to our Instagram, Uber, or Spotify apps, it better be just as good.

Engaging with Quip

Although the productivity software space is pretty crowded, Quip stands out from other word processors on three fronts: collaboration, continuity, and design.

1/ Collaboration

According to Greylock’s John Lilly, “In Quip, documents are central, of course, but so are people.” I couldn’t agree more.

Microsoft Office forces users to work in a stepwise fashion, in which document iterations must be done sequentially in order to avoid conflicting versions. Documents must then be saved and attached to our emails—or worse, printed out—for the collaboration to actually begin. This workflow has become so habitual that we don’t really realize how much time we’re wasting on simply loading the dock prior to actually collaborating.

Google Docs took a step in the right direction by allowing real-time collaboration among multiple users. Google Docs, however, is a relic of the web-based, PC-centered world. In the mobile era, messaging is the “killer app” and Quip takes full advantage of this by layering a chatroom beneath each shared document. Just swipe right on the document and a unique message thread is uncovered.

Quip has gone a step further by transforming real-time collaboration into a more social experience. Simple touches such as including a user profile picture next to each collaborator or confirming that a message was read by somebody else makes the overall experience feel more human. As Lilly denotes, “When you lower friction to participate and communicate — just like our mobile phones have done in the rest of our lives — interactions get richer, documents get better, and cycle times get shorter. It’s magic that way.”

mobilequip — Collaborating with Quip is both convenient and social.

On the document itself, watching a colleague’s words magically appear on my screen still takes my breath away. Part of that is the novelty of seeing it happen on my smartphone, which I find more personal than a PC, but much of the magic’s staying power has to do with the incredibly fast performance. That’s the result of some powerful engineering going on behind the scenes.

On mobile devices, latency is high and memory is limited, so updating an entire document on the fly becomes a computationally intensive task. But according to co-founder Bret Taylor, each document in Quip isn’t really a “document” in the traditional sense; every single sentence or spreadsheet cell is its own “atomic unit” instead. Rather than reloading the entire content of a document, only the actual snippet of bytes being changed will be synced on everybody’s page. Quip’s asynchronous architecture results in a super fast and smooth collaborative experience across every device.

2/ Seamless Crossover

“Mobile is about being omnipresent,” is how Ben Thompson characterizes the nature of today’s predominant software epoch. Using our smartphones and tablets, we can now get connected to the Internet almost everywhere we go. The problem, however, is that connectivity quality remains inconsistent and wireless access points remain fragmented. Quip accepts this reality but refuses to pass that pain point on to the end user—a reflection of its human-centered approach to productivity software.

While existing word processors implicitly require users to make a binary online-offline choice upfront, Quip enables users to seamlessly work in either state. Any progress made online is automatically available offline and vice versa. When teams are working on time-sensitive documents in multiple locations with varying levels of connectivity, automatically syncing your progress on the fly without needing to mark something offline is exceptionally important. With Quip, I can now do work comfortably when traveling—before, during, and right after a flight—without ever missing a beat.

Similarly, Quip is optimized to work across multiple devices with varying screen sizes. A team could easily be comprised of a remote worker on a tablet, a traveling colleague on a smartphone, and yet another team member working from a desktop. Traditional word processors are clunky on mobile devices since the legacy architecture is essentially stuffed into a smaller screen size. But mobile devices are fundamentally different computers than their predecessors, not just smaller, keyboard-less laptops. Accordingly, Quip has natively built the frontend for each device, rendering a beautiful and flawless UI throughout.

quip-app — Quip has a seamless look and feel across device and Internet connectivity.

3/ Design

The consumerization of productivity software requires enterprise products to be differentiated on a design level. And although my strategy professors at Columbia would disagree, I strongly believe that building a durable competitive advantage in enterprise software requires deep design competencies.

According to John Maeda’s Design in Tech report, “Designing for mobile brought new design and engineering constraints compared with the desktop.” Quip’s elegant handling of limited computing constraints and unreliable network connections highlight the team’s design dexterity.

On a more visible level, the product’s design is simple and intuitive, creating a natural experience. I love how documents on Quip don’t look like physical 8 x 11 pieces of paper, inadvertently (or not?) creating the illusion that the words, numbers, and images on the screen are fixed. After 15+ years of MS Office/Google Doc conditioning, Quip’s invisible document design still manages to elicit a physiological response of surprise and delight. Font formatting is enveloped into five different themes, which can be viewed as a limiting factor, but I find this simplification to be congruous with an overarching mobile-everywhere approach.

“It’s hard to believe that emailing Microsoft Word documents back and forth with ‘track changes’ remains the primary collaboration workflow for many people,” Edmond Lau, a top engineer at Quip, writes. In Quip, changes are tracked on the messaging thread, keeping the document’s content area clean and easy to read. On the messaging thread, edits are displayed in a Github-like fashion: words with a green highlight were just added while those with a red highlight and a strikethrough were just removed. Lastly, adopting a Slack best-practice, Quip sends a push notification to a specific team member by activating the mentions feature with the ‘@’ symbol.

Looking Ahead

Quip’s future is bright, but competitive challenges abound. Although direct competitors with a scale advantage—namely, Microsoft and Google—will continue to pump tons of cash to update their legacy productivity suite, the bigger challenge may come from Slack. Like Quip, Slack is well designed and built for the mobile era. Furthermore, Slack’s bread-and-butter product is dynamic organizational communication, so Quip needs to be mindful with how it enhances and expands its collaborative chat application. Impinging on Slack’s home turf could inadvertently put Quip on a defensive position.

Although both Slack and Quip service the essential business functions of a similar customer segment, the value proposition of their core products are complementary in nature. Slack’s core product (communication for organizational coordination) coupled with the unprecedented growth of its ecosystem have quickly transformed the company into a true enterprise platform. As a platform, the synergies with Quip—both on a business case and a product case—could be massive.

In the more immediate future, Quip should think about entering the university market. Business schools in particular would be a great market to test because of the intense team collaboration that goes on everyday. For this to work, upgrading Quip’s spreadsheet core functionality is key—we need those keyboard shortcuts! Convincing power-users of the Microsoft Office suite to jump ship necessitates near identical functionality on the dominant platform (ie, the desktop app) to reduce the friction of crossing over.

Similarly, another missing element is a presentation processor. Powerpoint is a dinosaur of the PC era, so Quip may understandably view a presentation as completely unnecessary and anachronistic in the mobile era. But such a tactical decision could be loaded with strategic implications given the end market Quip is servicing. A little bit of handholding from Quip to bridge the gap from desktop computers to mobile devices could accelerate the product in crossing the chasm.

As Quip continues to grow and innovate, I’m excited to see how the company shapes the consumerization of productivity apps for the enterprise. And in case you’ve been wondering: Yeah, I wrote this on Quip.

Uber, Uncategorized

An Uber Story

Posted on January 18, 2016January 18, 2016 by rogteran

During my most recent visit to San Francisco, my wife and I jumped on an Uber after eating at Chubby Noodle (you must get the Korean pork tacos!). The driver overheard us speak in Spanish and asked us where we were from. We told him we lived in New York but both grew up in El Salvador. Excitedly, he exclaimed that he too was from El Salvador.

Our driver’s name was Manuel. He had moved to the United States in the late 1980s to escape El Salvador’s violent civil war. He then worked as a truck driver for more than 20 years. He took a big hit in 2007 when he couldn’t afford his home anymore and defaulted on his mortgage. In 2014, he was laid off from his trucking job and had been struggling to make ends meet. After searching for a new trucking job for 6 months, a buddy of his told him to try working as an Uber driver.

Manuel applied to Uber back in September 2015. After a couple of interviews and background checks, Manuel finally became an Uber driver on December 31st, 2015. His first night on the job was New Year’s, and he was quite happy with how much he had made that first night. He had done more than 60 rides in the first few days and said his overall experience was quite good mainly because he found passengers to be very friendly.

Manuel was driving a brand new Toyota Camry. He proudly proclaimed that the car was his. This didn’t compute: hadn’t he been out of a job for all of 2015? It turns out that Uber was helping Manuel lease the car. Under Uber’s Xchange Leasing program, Manuel could lease the Toyota for three years with a relatively low termination fee and unlimited mileage. I don’t know how Uber’s car payments compare to other financing options, but I liked that through the Xchange program car payments are automatically deducted from the driver’s weekly earnings. This imposes financial discipline and ultimately helps somebody like Manuel – a subprime borrower – to rebuild his credit.

(While the leasing program has been around since 2013, I was admittedly unaware of this since most Ubers in NYC operate directly under fleet partners, abstracting ownership and leasing issues away from the drivers.)

It may not be the American dream, but I found Manuel’s story a powerful and refreshing reminder of how Uber is helping generate a positive impact for many drivers.

competitive advantage, eharmony, marketplaces

Analyzing eHarmony’s Competitive Advantage

Posted on September 24, 2015September 25, 2015 by rogteran

Although Columbia Business School often gets pigeonholed as a finance school, it’s really a top-notch program to learn about strategy. My professors in various subjects – from marketing to tech investing – have pushed my classmates and me to think deeply about competitive advantage. Indeed, this semester I am taking a course called Economics of Strategic Behavior, which provides a focused approach to business strategy and demystifies competitive advantage.

Every business school student is introduced to Michael Porter’s five forces, the most prevalent framework to analyze the structure of an industry. These forces are: 1) barriers to entry, 2) existing industry rivalry, 3) threat of substitutes, 4) bargaining power of suppliers, and 5) bargaining power of buyers.

What I like about my “Economics of Strategic Behavior” class is that it builds on Porter’s framework by prioritizing the five forces. My professors opine that barrier to entry is, by far, the most important force when analyzing the competitive dynamics of an industry. Competitive advantage therefore stems from the ability of companies to create moats around their industry in such a way that they deter potential entrants from capturing any value. The outcome is an out-sized return on capital for long periods of time.

Competitive advantage can be derived from unique capabilities or unique positioning. It’s the latter, however, that provides a more durable and sustainable advantage. These positional advantages can be distilled as:

Demand advantages in the form of customer captivity and network effects
Supply advantages in the form of patents and unique technologies
Economies of scale when high fixed costs are spread out to generate low avg. costs
Information or regulatory advantages

When an industry incumbent has a pronounced advantage, it’s incredibly difficult for an entrant to gain traction or turn a profit.

During this week’s class, we analyzed eHarmony, the leading online dating site to find Mr. or Mrs. Right. Although the eHarmony case was written in 2008, the company still maintains a leadership position in the relationship-seeking segment, which speaks volumes of its competitive advantage: in fact, about 2% of marriages in the US are due to eHarmony!

As an online marketplace, eHarmony developed a demand advantage that stemmed from targeting, attracting and maintaining a quality pool of singles seeking a serious relationship. One of the toughest things about online marketplaces is that they are devilishly difficult to initialize because of the proverbial chicken-and-egg problem: when there is nobody on the other side of the platform, then there is no real value proposition for an initial user.

To get over this hump, a founder’s credentials, experience and networks can served as the spark of trust essential to seed an online marketplace. As a practicing psychologist, eHarmony’s founder, Dr. Neil Warren, had developed a reputation as an expert after writing several books on the subject of love and marriage, making numerous speeches at conferences, and appearing on national TV and radio programs. By tapping into the psyche of conservative and faith-based communities, eHarmony was able to get over 100,000 quality registrations in just a matter of weeks.

eharmony_founder — Dr. Neil Warren, eHarmony’s founder and relationship expert.

With initial liquidity in the marketplace, eHarmony managed to build several levers that effectively captured customers. Leveraging Dr. Warren’s credibility, eHarmony built a matching algorithm for prospective customers. At the time, no other online dating site provided anything remotely close to effectively match highly compatible people. The algorithm served as a powerful hook to incent users to fill out the 250 question Relationship Questionnaire.

The Relationship Questionnaire was instrumental on two fronts: first, it generated an important filter that weeded out casual daters, thus ensuring the quality of the marketplace by increasing the signal-to-noise ratio; second, the significant upfront investment – in time and effort – to complete the questionnaire lowered the relative cost of the subscription. After users’ personality profiles were fed to the algorithm, users could see but not communicate with their matches – an incredibly effective teaser for non-paying members to purchase a subscription. As a result, eHarmony’s conversion ratio was 3x higher than that of its competitors.

To sustain its customer captivity, eHarmony imposed several measures of control that initially seemed counterintuitive to me. First, eHarmony rejected the membership request of roughly 20% of users who were willing to pay. This additional filter ensured that the quality of paid users was very high, enhancing the value proposition for existing and potential members looking for a serious relationship. Second, unlike other online dating sites, eHarmony deliberately limited the number of matches available to its customers.

Given eHarmony’s target customer, it actually made sense to artificially restrict the set of choices because it reduced the level of competition among users, implicitly increasing their expected payoff. Limiting the number of matches also created an illusion of scarcity. This illusion induced users to pay up since they were not-so-subtly reminded that there were only a couple of fish left in the sea. More powerfully, by controlling and limiting the number of matches, eHarmony mitigated user skewness, the phenomenon in which a few of the “hottest” members command a disproportionate interest and hits throughout the platform. Many dating sites suffer from this, which would often lead to way too many men trying to connect with only a couple of women, consequently producing a poor user experience on both sides. Nearly 60% of eHarmony’s members were women, though, indicating that its user base was well balanced and of high quality.

As eHarmony gained greater control over the serious relationship-seeking customer segment, the company exerted positive network effects. Both sides of the marketplace – men and women – benefited from each additional high quality member of the opposite sex. This virtuous cycle is inherently defensible and difficult to break for competitors looking to gain market share. While eHarmony’s network effects were a function of its high quality and expensive-to-acquire membership base, the network effects also enhanced and reinforced its customer captivity. Accordingly, eHarmony charged a 10% premium relative to Chemistry, its closest competitor.

Strategically, one of the most important decisions eHarmony made was to choose the right niche within the online dating industry. After targeting this niche, eHarmony tailored its product and services in such a way that it efficiently captured the hearts and minds of those souls looking to find “true love.” Online marketplaces are hard to build, but if done right, they can become incredibly successful businesses given their network effects-based competitive advantage.

Latin America, marketplaces, Startups

Launching a Hypothesis-Driven Startup

Posted on September 12, 2015September 12, 2015 by rogteran

There’s nothing like the second year of an MBA program. Although I’m taking a full 15 credit course load, I had a ton of leeway in choosing my schedule and decided to stack all my classes on Mondays and Tuesdays. With a “5-day weekend”, I plan to dedicate quite a bit of time in honing a business idea my Dad and I have been tinkering with.

As a quick recap, I learned to code this summer and for my final project I built a prototype of an online marketplace. It’s by no means a finished product, but it is a product that I can demo to prospective customers. With my 5-day weekend, I decided to fly down to Panama – the initial target market – where I attended a tradeshow. In just a few days, I’ve gained a lot of insight into both the market and the customer.

Panama is a strategically located and business friendly country, making it an ideal market to launch a Latam startup.

There are a lot of ways to define a startup, but the best definition I’ve found is the one proposed by entrepreneurship guru Steve Blank: “A startup is an organization formed to search for a repeatable and scalable business model.” In essence, a startup is a set of well-formulated – and therefore testable – hypotheses that the entrepreneur must either validate or debunk. With every customer insight, the entrepreneur then tweaks the business model to reflect and ultimately solve the real needs of the market. It’s an iterative process, but constantly adjusting to arrive at product-market fit is how you build a scalable business without investing huge amounts of capital upfront.

During the few days here, I spoke with a lot of people in the “vertical” my Dad and I are targeting. Three interviews with domain experts where incredibly insightful. I had a set of 10 questions that I felt would lead to a lot of insight. Although I never went through all 10, I was able to touch upon key elements that will help refine the marketplace going forward. In particular, I gained deep insight into the following:

Customer discovery: buying and selling in this market is prohibitively expensive and incredibly inefficient. I now have estimates of how much it costs to the prospective seller using the current solutions, and even how much it costs – in time and money – when a sale is unsuccessful.

The customer development cycle espoused by Steve Blank.

Market size and market dynamic: talking with several experts, I was able to triangulate an estimate of how many potential customers exist and what the total gross merchandise value of the marketplace could be. I also learned much more about what drives sales cycle and sales channels in this industry. Most importantly, even though this is a relatively small market, I believe there are enough players to create initial liquidity in the marketplace.

Competitive landscape: I was able to piece together a pretty comprehensive map of online players and their limited solutions, as well as more traditional brokers and dealers. There are a lot of relatively small players, which leads me to believe that the supply side of the market is very fragmented. A verticalized marketplace could very well add a lot of value, not just by reducing search costs but also my reducing transaction costs.

I also learned that a key challenge of building this business in Panama will be changing the mindset of potential customers that transacting online is a viable and much better option than existing solutions. Nonetheless, the heat and vibrancy throughout Panama was intoxicating, and I am convinced that this is an optimal market to launch a Latin American startup.

Fintech, Latin America, Startups

Latam Startup Series: Nubank

Posted on August 29, 2015August 29, 2015 by rogteran

I have been captivated by the idea that businesses infused with technology at their core and espousing a culture of continuous learning can unleash Latin America’s productivity and true potential. The aim of my Latam Startup Series is to identify those companies in the region that are radically changing the competitive landscape of their respective industries by introducing fresh perspectives and new solutions to pressing problems. My ultimate hope is that by highlighting some of these innovative companies, we can break down the no se puede (“it can’t be done”) mindset so prevalent in Latin America – to me, the biggest roadblock to generating a cycle of positive change in the region.

Over the last three weeks, I went through the unfortunate experience of closing my bank accounts in Costa Rica (where I previously lived/worked for two years). Yes, you read that correctly – it took me three weeks to close my accounts. Bottlenecks included locked accounts (so I couldn’t pay off my credit card), filling out multiple forms (some could be handwritten, some needed to be typed), unanswered emails, dropped calls, more forms, more unanswered emails…you get the point.

This isn’t an isolated event: I had a similar experience with a different bank from another Latin American country last year. From a customer perspective, banks seriously suck in Latin America (including the multinational ones). They are incredibly bureaucratic built on top of legacy infrastructure that is slow and barely secure. Yet, despite their terrible services, they make tons of money.

That’s why I am excited about Nubank, a relatively new Brazilian financial services company. What’s unique about Nubank is that the company is completely digital – in other words, no physical bank branches. This translates into a significantly lower cost structure, thus allowing the company to provide customers with better services at much more competitive prices. Nubank currently offers a Platinum MasterCard credit card that customers can manage through an intuitive iPhone or Android app. With more than 200,000 people applying for the digital credit card, this Latam startup seems to be on a path to huge success.

Brazil, of course, has unique dynamics that make Nubank a compelling investment. First, Brazil is a huge market: the country boasts a population of 200M. Second, Internet penetration is abnormally high due to the +90M smartphones currently in use. Third, Brazil has really high interests rates: the benchmark (Selic) rate is about 14% compared to ~3% in Mexico and ~5% in Colombia. Lastly, despite a tepid macroeconomy, credit card transactions have been on a tear, growing over 13% from 2013 to 2014.

Add to this market opportunity a capable and visionary leader – founder and CEO David Velez – and it’s no wonder that Nubank represents Sequoia Capital‘s first venture investment in Latin America. In fact, Nubank raised a $30M Series B a few months ago to take on Brazil’s biggest banks.

While trying to find investment opportunities on behalf of Sequoia, David Velez decided to roll-up his sleeves and build the opportunities himself. A badass.

Although replicating what Nubank is doing in other Latin American countries would be challenging due to different regulatory hurdles and market dynamics, I think Velez’s calculating approach – identifying and then tackling a broken industry by building a tech-savvy business – provides a powerful roadmap for other Latin American entrepreneurs.

marketplaces, Rails, Ruby

Building an Online Marketplace MVP

Posted on August 16, 2015August 17, 2015 by rogteran

I’ve officially “graduated” from General Assembly‘s web development immersive. What an incredible journey it’s been – from learning the basics of a loop to building full-blown web applications.

For my final project I decided to work on a business idea my Dad and I have been thinking about for the better part of this year. The company is an online marketplace. I won’t go into more details at the moment since we are still in “stealth” mode, but over the next year at Columbia, I plan to dedicate a substantial amount of time building out the business.

Needless to say, I’m stoked that I’ve been able to build a “minimum viable product” (MVP) for the business – in other words, I have a prototype of the marketplace which I can use to validate whether it’s something potential users would consider paying for. I coded non-stop for about 2 weeks to get the application running. And while it’s a fairly basic platform, much of the core functionality is there. Education aside, I’ve spent less than $100 to get this up and running.

I built this application using a very “English-like” programming language called Ruby and a popular app-building framework called Rails. As a programming noob, Ruby on Rails is pretty remarkable since you’ll have the basics of an application up in a matter of minutes. This allowed me to focus more on the unique aspects of my application instead of the basic plumbing. Rails is fairly opinionated and stresses “convention over configuration”, but if you stick the to Rails Way of doing things, building an application becomes a lot less daunting.

ruby_rails — Ruby on Rails makes building web apps much easier – and much more fun.

As I built the application, I faced three big challenges:

1) Database manipulation: I built the application using a relational database called PostgreSQL. Personally, I struggled to figure out how to link my users to listed items and any possible orders. This was further complicated by the two-sided nature of a marketplace. Users could be categorized as either “sellers” or “buyers”, and their orders broken down into “sales” or “purchases”. Conceptually, this is not difficult to grasp; correctly connecting the associations, however, was tough to get right.

2) Payments: These days, getting payment processing on your application is fairly straight-forward thanks to application programming interfaces (APIs) such as PayPal or Stripe. APIs sound fancy, but they are nothing more than instructions for applications to talk to each other. In my case, rather than build out a payment processing platform from scratch, I incorporated a couple lines of code from Stripe, and voila – I can now process transactions! Although incorporating APIs is much easier – and arguably more secure – than building something as complex as a payment platform, placing the code in the right place and grabbing the right objects resulted trickier than what I initially anticipated.

Stripe allows users of my platform to make purchases. Their sensitive information never touches my database. — Stripe allows users of my platform to make purchases. Customers’ sensitive information never touches my database.

3) Design: For this application, I incorporated a styling framework called Bootstrap. The framework injects some basic styling into the application, but what I particularly like about Bootstrap is that it takes a lot less work to get the app to be “mobile-responsive”. That said, re-formatting the entire application to make it look professional is very time-consuming and tedious. I wanted my application to look simple and professional, which is easier said than done when you don’t have a design background.

I love the fact that I’ve been able to build something (actually, several things) this summer. Skipping a summer internship and learning to code instead has been one of the best decisions I’ve ever made. Programming has pushed me to my intellectual limits and humbled me so much. Programming has also taught me to think about things from very different angles, and challenged me to leverage my teammates in unexpected ways. Most powerfully, programming has opened my mind and afforded me the confidence to tackle difficult problems by using software in productive and creative ways. As I get ready to go back to b-school, I look forward to present the marketplace to potential customers, further flesh out the MVP, and eventually build a real technology business in Latin America.

collaboration, Github, software development

There’s No “I” in Software Development

Posted on July 27, 2015July 27, 2015 by rogteran

Business schools often proclaim fostering teamwork by assigning tons of group projects. Yet, it’s at General Assembly – the three-month programming bootcamp I’m currently enrolled in – where I’ve been immersed in the most intense team environment of my career. Without a doubt, the depth of collaboration has been the biggest surprise of my summer in software development.

General Assembly boasts three immersive tracks: user experience (UX) design, product management, and web development (the one I’m taking). These tracks reflect three of the main functions inside of many early-stage Internet firms today. The role of the developer is pretty obvious: to build a product using code. UX designers, on the other hand, focus on shaping the experience of a user when interacting with the product. As our lives become cluttered with applications, excellent design is quickly becoming paramount to capture and retain our limited attention. Finally, product managers liaise between UX designers and developers, and validate customers desires for a specific product. I think of product managers as “mini-CEOs” of a product.

The cross-immersive project allows UX, product management, and programming students to work together. — The cross-immersive project at GA allows UX design, product management, and programming students to work together.

The climax of General Assembly is a “cross-immersive” project during weeks 9 and 10 where 2-3 programming students are paired up with a product management student and a UX design student. I was a bit apprehensive at first because I had no idea what kind of project our product manager would assign us to, but I was pleasantly surprised that instead of diving into a predetermined idea we had a day-long brainstorming session to figure out what we should build. To me, the key criteria to decide on a project centered on 1) finding a reasonably cool idea and 2) making sure that the project was within scope (in terms of time and ability to execute given our rather limited skill-set). We decided on a web app to create and join pick-up soccer games in and around New York City.

As a business school student, I found it both refreshing and challenging to collaborate with a product manager. It was refreshing because we could finally talk about “customer validation” or “monetization strategies” which are part of my daily b-school vocabulary. At the same time, I constantly had to stop myself in team discussions regarding the direction we should take because as a junior programmer my role in the team is completely different. Instead of focusing on the merits of the idea and how we should proceed, I homed in on understanding the requirements, features, and time horizon of the project. Hard as it may be, I think learning to follow is a crucial leadership ability that more business students need to practice.

On the first few days, I also found myself pushing back – more than my programmer teammates – on many of the features thrown at us by the designer and the product manager because I could foresee that they would take way more time than originally estimated. This reinforced my notion that serious product managers should take the time to learn how to code – at least enough to understand the time, effort, and pain it can take to create something as simple as, say, a login page.

This cross-immersive project was also the first time my fellow coders and I really used Git and Github. It’s taken me a few months to really understand how these two tools really work together, so explaining it fully requires a standalone blogpost. But at the most basic level, Git and Github allow for “version control” of the code in a big project. In production settings, programmers will work on a “clone” of the master codebase, making changes to the code on their own computers. If the workflow is coordinated well, then no two programmers should be working on the same files. Parallel workflow would then allow each programmer to essentially save their work and “push” it into the cloud (Github) without producing a problem. At this point, all the files that have been changed are merged back into the master codebase and process then repeats itself.

Basic flow of version control using Git and Github

At first, the process of pulling, saving, pushing, and merging felt arduous and we maybe completed a cycle per day. This, however, proved to be a huge mistake because there were just too many changes to keep track of and each person’s work spilled into the files of another teammate, creating merge conflicts at the end of the day. By day three, we were communicating much more explicitly – telling each other exactly what were going to work on – and after 30 minutes or so, we’d all stop and integrate our files on Github.

Building software requires teams to be truly synced up, both on a developer-to-non-developer level as well as on a developer-to-developer level. Failing to do so only leads to deployment delays, conflicting code, and an overall crappy product at the end of the day.

Meet Octocat, Github's cute mascot. Makes you think Github is a friendly tool, but given the steep learning curve, it's anything but. — Meet Octocat, Github’s cute mascot. Makes you think Github is a friendly tool, but given the steep learning curve, it’s anything but.

backend, javascript, Node

Building My First App With Node

Posted on July 4, 2015July 4, 2015 by rogteran

I’ve made it through the end of the first half of my programming intensive course at General Assembly. Just barely.

After a 3-week frontend introduction, we shifted gears to the backend. To do so, we downloaded something called Node.js. We also installed a bunch of “modules” onto Node to do specific things.

Traversing from the frontend to the backend of software development

I’m going to level with you: during my first week of learning about Node, I was completely lost. Like “I-have-no-effing-clue-what’s-going” lost. And it was particularly frustrating because I spent countless hours after class trying to understand what exactly Node was. I read a bunch of “intro” tutorials, watched at least 10 videos on YouTube, and even bought a few books on the basics of Node. Despite all my effort, I still couldn’t explain Node to my wife.

The tutorials, videos, and books presumed some basic knowledge of server-side applications. But I had no foundation to connect so many new concepts and terms. It reminded me of a recent passage by Tim Urban on his blog “Wait, but Why?“:

I’ve heard people compare knowledge of a topic to a tree. If you don’t fully get it, it’s like a tree in your head with no trunk—and without a trunk, when you learn something new about the topic—a new branch or leaf of the tree—there’s nothing for it to hang onto, so it just falls away. By clearing out fog all the way to the bottom, I build a tree trunk in my head, and from then on, all new information can hold on, which makes that topic forever more interesting and productive to learn about. And what I usually find is that so many of the topics I’ve pegged as “boring” in my head are actually just foggy to me.

So I set out to build a “tree trunk” and stick all these branches of knowledge together. I started at the most basic level by asking simple questions such as: “What’s a server?” Of course, I kind of knew what a server was, but “kind of” was not good enough. I needed to understand how things worked at a more fundamental level. Admittedly, I was embarrassed at first to google these things or ask my instructors these questions during review sessions. Once I got over my fear of sounding ignorant, I started getting a much clearer and deeper picture of how the Internet and our computers work.

So, what is Node?

Node is a platform that extracts JavaScript out of its natural habitat – the browser (ie. Chrome or Firefox) – and provides a non-browser environment that JavaScript can run on. Through Node, we can access databases, listen to network traffic, and receive/respond to http requests – all with JavaScript. By embedding Google’s really fast and really awesome JavaScript engine onto our computers, Node allows us to build scalable network applications using solely the web’s lingua franca.

Since JavaScript is the only language I have been exposed to thus far, I initially failed to grasp the magnitude of Node’s impact. Before Node, a JavaScript programmer would have been confined to the frontend or would have had to learn a server-side language such as PHP, Python, or Ruby on Rails in order to connect to the backend and create a full-blown application. Thanks to Node, frontend developers can now work in the backend as well, and that’s pretty sweet since there’s now language consistency across the technology stack. More importantly, because of JavaScript’s asynchronous nature, we can write code that is non-blocking. In other words, a chunk of code doesn’t have to wait around for previous chunks of code to finish before it can start executing. Two or more chunks of code can run in parallel. The result: blazingly fast web applications.

An illustration of how Node's event loop enables non-blocking code — An illustration of how Node’s event loop enables non-blocking code

Using Node, I could create a chat server, an ad server, or a real-time data app. Indeed, using Node I was able to create my first application: a simple Wiki on startups. As a user, you can sign up and log in (I’ve encrypted passwords) as well as create, edit, and delete posts. Node is pretty low-level, so I also used a number of modules (such as Express and EJS) to build the server. Lastly, I hooked up to a Mongo database to store and retrieve information related to users and any posts on startups created.

I tried to go for a minimalist style that should make it intuitive to navigate. Due to the time constraint, I wasn’t able to build out all the functionality I wanted, but I’m still happy that I was able to build this Wiki over the course of a weekend. As simple as this application may be, the feeling of creating something from scratch is second to none.

Airbnb, marketplaces

Assessing Airbnb’s Billion Dollar Round

Posted on June 23, 2015May 16, 2016 by rogteran

Airbnb is the premier online marketplace for short-term rentals. The Wall Street Journal reported that the company is raising a $1B round on a $24B valuation – approximately 26x this year’s projected revenue. That would make Airbnb more valuable than Marriott International, which is valued at ~$21B. How can we make sense of this seemingly crazy valuation?

Here’s how I think about it:

Timing: Smartphone penetration and social media growth have enabled consumers to grant each other temporary access to their under-utilized physical assets by removing key friction points to asset owners and potential users. In other words, these key Internet trends have unleashed the “sharing economy.”

Market Size: Airbnb is competing in a massive market. Nobody knows exactly how big this market is. Beyond vacation rentals (an $85B market), Airbnb has enabled people living in cities to rent out spare rooms or entire apartments, creating a market that didn’t even exist seven years ago. Going forward, Airbnb will eat into parts of the hotel industry as well as other low-utilization-to-asset-value sectors. I estimate Airbnb’s total addressable market to be between $500B-$600B. It’s incredible to think that not-too-long ago Airbnb’s founders thought the total market was under $20B.

Business Model: I love online marketplaces because the economics are amazing. Marketplaces often command +60% gross margins and +20% operating margins. Moreover, as an online marketplace, Airbnb is asset-light and does not hold any spare-room inventory. Unlike hotels such as Marriott or Hilton, Airbnb is unconstrained by real estate and can add thousands of rooms in a matter of weeks rather than months or years. Airbnb’s +1M listings are more than Marriott’s 700K rooms. On a per room basis, the valuation starts to look more reasonable.

Competitive Advantage: Airbnb has created a very defensible company by building a global – and somewhat fanatical – community through its trusted service. Online verification techniques, a $1M host guarantee, and a secure payment platform have all helped build trust throughout its customer base. Airbnb also creates a continuous stamp of approval since each additional review is another valuable datapoint that fosters further trust among members. This, in turn, generates powerful “network effects.” What’s particularly unique about Airbnb’s network effects is that supply and demand are often one and the same, creating overlapping network effects. Guests are often hosts, and vice versa. From a competitor standpoint, this dynamic is incredibly difficult to break and even more difficult to replicate.

Team: Lastly, Airbnb’s founding team is just so tenacious and creative. This may be less important when we are talking about billion-dollar companies than those at the seed or Series A level, but it inspires confidence going forward (they still have much to execute). This blog by Fred Wilson about Airbnb’s founders designing cereal boxes and then selling them to keep their business afloat back in 2008 sums up their abilities quite nicely.

I put together a short investment recommendation on Airbnb last month. The deck highlights and expounds upon some of the points I’ve mentioned above. I definitely think Airbnb is a phenomenal company, and if it maintains its growth trajectory, it could very well be worth ~$24B – in fact, $24B is what I thought Airbnb was worth in my upside scenario. But that doesn’t mean I’d invest in Airbnb this late in the game. Separating a great company from a great investment is arguably one of the most valuable lessons I’ve learned at Columbia so far.

In case you’re interested, I’ve shared the deck below. Please note the context has slightly changed over the last few months, but I think the main takeaways still stand.

front end, programming

Humbled by Code

Posted on June 13, 2015June 29, 2015 by rogteran

A few weeks ago, I started a 3-month intensive full-stack programming course at General Assembly. Full-stack is simply a fancy way of saying I’m learning web development and design (the “front end”) as well as server, application, and database programming (the “back end”).

I thought the first few weeks would be pretty straight forward. It’s been anything but. My mind has been stretched in many ways: first, by learning a lot of vocabulary and new syntax; second, by applying object-oriented and functional “paradigms” that string together disparate actions into a coherent body; and third, by thinking in a very explicit, step-by-step way so that the machine I’m working on can interpret my instructions. I’m amazed how tough this is for me, even though I’m writing very basic code.

So far, I’ve been exposed to primarily front end languages: JavaScript, jQuery, HTML, and CSS. Hard-core programmers don’t even consider HTML or CSS as code, but it looks like code to me when I’m writing it. I didn’t really know what either was before I started this course, but it’s pretty simple: HTML is used to “structure” a web page, while CSS allows a developer to “style” the page. Neither is particularly difficult to grasp, but manipulating pages and making them look good is both a skill and an art.

JavaScript, on the other hand, is a programming language. Many people confuse JavaScript with Java, but aside from sharing a similar name, they are pretty different. JavaScript is the language that powers the web: it enables webpages to have functionality. If a user clicks on something on your webpage, what happens? That’s JavaScript.

It’s been fun learning JavaScript as well as jQuery – a library that simplifies writing JavaScript. JavaScript is considered one of the “lighter” programming languages to learn – and doesn’t carry the gravitas of learning something like C++ or Java – but it’s deceivingly simple. From what experienced programmers tell me, JavaScript has its quirks, but these quirks – when wielded properly – can produce powerful programs. In fact, according to a recent Bloomberg article on code, JavaScript is the world’s most-used computer language. Here’s what basic JavaScript looks like:

Simple JavaScript to create a sliding menu bar

I struggle quite a bit when using JavaScript to manipulate the CSS and HTML of a page. Nonetheless, I’m astounded that in three weeks I’ve managed to write several programs, including:

A stopwatch
A calculator
A To-Do list
A game called ‘Snake’
A game of ‘Tic Tac Toe’

I won’t post these programs since I’ve received plenty of help from my instructors, peers, and online material. The code I wrote is also plain awful and riddled with bugs, so I don’t feel comfortable sharing these just yet. But as I continue to get better with programming, I look forward to sharing some of my projects on here.

Back to coding.

	Mariangela Ramirez D… on An Uber Story
	Latam Startup Series… on Latam Startup Series: Nub…
	Building My First Ap… on Humbled by Code
	Assessing Airbnb… on Assessing Airbnb’s Billi…
	Assessing Airbnb… on Christmas in May: Internet…

Roger Teran