Esquire Theme by Matthew Buchanan
Social icons by Tim van Damme



Stop Saying “Only”: Harvard MBAs Are Good Founders



There has been a lot of commentary recently stating that MBAs, and Harvard MBAs specifically, aren’t very good startup founders.

Only 12 of the 39 companies had any MBAs within their co-founding teams…only three had at least one co-founder who went to HBS.” – Dan Primack of Fortune

“I would bet a large amount of money that the overwhelming majority of us would not look favorably on a company started by one of you” - Chamath Palihapitiya on Harvard MBAs



What to Look for in a Cofounder – an Evolving Personal Framework

(This post was adopted from my original post on the "Founders’ Dilemmas" 2013 class blog, an HBS elective course taught by Prof. Noam Wasserman).  

Most of the HBS students take the “Founders’ Dilemmas” class with the hope to find the “magic formula” to answer the question of “what to look for in a cofounder.” Unfortunately, even a class with “Founders” in its title does not seems to have the magic bullet answer: we analyze cases and experiences of past founding teams with the hope of using pattern recognition skills to guide us through future founding events, and that appears to be the best approach available. However, others’ experiences can only go so far – knowing who you are, how you function, and analyzing your previous experiences might be even more important. 

I have (fortunately?) had the experience of working on my own startup with a cofounder while at HBS for about a year before the founding team split happened. Having previously worked in VC, I had some exposures to capital structure and founder issues through indirect observations and anecdotes. Being a first-time founder, I tried to rely on the “rules of thumbs” I picked up as a VC, but most of the time I had to rely on my instincts. Coming out of and reflecting on my first founding experience, I started to construct a “cofounder framework” that I hope to help me form better judgments around cofounder selection next time around:

  1. On the same page regarding expectations and goals in life as well as the venture. This ranges from the practical question of “how long are you willing to go/can you last without a salary?” to “why are you doing this?” and “do you want to build A company?” vs. “are you interested in solving this very specific problem (and just this problem)?”. In my opinion, this is the single most important element that can contribute to a founding team success (or cause failure). If cofounders are not aligned on these issues, they will run into problems when times get tough – one wants to persevere while the other one might mentally give up much quicker.
  2. Complimentary skill sets so that the team is “uniquely positioned” to tackle the space/solve the problem. Using the investor lenses, I would love to see a team slide in the deck highlighting all the right functional and industry experiences that the founding team collectively possess to have an “unfair advantage” to tackle the problem this startup is trying to solve. Why should I have a lower standard when I switch roles from investor to founder? In the world of startups you are always raising against time, but I believe this is one of those decisions that you can’t rush into. Be patient and find the best people you can possibly convince to partner with – optimizing on your founding team is one of the best investments you can make to increase your startup’s chance of success. 
  3. Personality fit. Starting a company is hard, and you will be working ALL THE TIME with your cofounder – you most likely will spend more time with him/her than with your significant other. If you don’t respect each other and can’t enjoy hanging out and working together for long periods of time, then it’s probably a bad decision to team up. This quality is hard to observe at first, but you can test the compatibility by working together over a “test period” on small projects before fully committing yourself. 

I expect this framework to continuously evolve and develop as I incorporate more personal experiences and observations, but hopefully it will help me increase the chance of success in my next venture by avoiding major “founder issues”.



Lessons Learned from Working with an Outsourced Development Team

(This post was also published on the “Launching Tech Ventures” 2013 class blog, an HBS elective course taught by Jeff Bussgang)

When I initially started working on my first startup, FirstCrush (a personalized ecommerce wine subscription service), we had a team of two non-technical founders. We got far enough to conduct an MVP test on campus by putting together a WordPress site with PayPal integration so we could test people’s true willingness to pay, but we needed a real beta site that was polished enough to convey the trustworthiness of the service to test with the general population. We also needed a few key features to test our hypotheses around engagement and customers’ willingness to provide ratings of the wines they receive. 

After speaking with a few development shops that utilized a blended payment scheme of cash plus equity, we decided to go with Shop A in NYC. Although they seemed young and relatively less experienced compared to a few other options, they were much more affordable, were willing to do an all-equity deal (we did not have much cash so we thought this was the smart way to go – align incentives!), and seemed very enthusiastic about our project. They also pitched themselves as ex-entrepreneurs (which were true) so that they have more “value-add” beyond development resources. 

We signed an agreement with the mutual understanding that it will be an all-equity deal, vested in tranches, with the last tranche fully-vested when the V1 site is officially complete. We tried to scope out what the definition of V1 is in a few bullet points and quickly went to work. Fast forward, we did get our V1 delivered and my experience working with the development team was generally positive. I learned a lot both as a first-time founder working with an outsourced team and as a first-time product manager, and here are some of the important learning:

  • Scope out EVERYTHING. All the details on the pages and how they flow – do not ignore even a tiny little button. When we first started communicating, we had the expectation that the V1 would be done by May 1st. We did not launch our beta site until the last week of June. Why the delay? The scope of our V1 kept expanding as we continued with the PSD design process and the actual development phase, because we ignored how the “little things” on the site would flow during the wireframing phase. Our QA process was prolonged because we inadequately used QA to get my product input into the build, which should’ve been done in step 1.
  • Example: I was testing out a Facebook share button on the page and realized that we never designed the landing page for those who clicked on the shared link on Facebook. I would then sketch out the new landing page and file that into Pivotal Tracker as a new feature request, but this should’ve been thought through in the initial PRD process, not during QA.
Clearly define your project and don’t assume that something should be common sense/unspoken rule. Thisis especially true when it comes to working with an outsourced team and you’re under a project-based agreement. This is a hard thing for people who’ve never built web-based products before, because you just don’t know how much details is too much, and what might come back to bite you. If it’s not clearly defined in the contract, you have no way to get it done. 
  • Example:The first day the site went public to our mailing list, I got a call from an angel investor whom I met a few days ago. He claimed that the sign up page was not working, and it turned out that he was using IE as his browser. Yes I know Chrome is cool, but the reality is the majority of the Corporate America still uses IE. I immediately called our developer about the issue, and he pushed back saying “well making it render on IE is very involved, and we usually don’t do that for a V1 site…” – what? You would assume that “of course things need to work with IE and Firefox as well as with Chrome!” but yes you’d better spell it out in the agreement. 
Don’t overly rely on the “equity” component to incentivize your outsourced team to act as founders/owners. Part of my oversight on #1 and #2 was partially a result of me trusting the development team as part of “us” because they were getting paid with our equity – if we don’t succeed, the equity is worth nothing, so the reasoning goes that we are completely aligned and I can trust their judgment to help me manage the development process to the best they could. This is true to certain degree but the incentive only goes so far. At the end of the day, if they’re a development shop/consultancy, they have multiple projects in the pipeline. Their bigger objective is to close one project so they can move onto the next.  
  • Example: The development team kept emphasizing the fact that they couldn’t start coding until they have the final PSDs from our designer. I did not understand why until one time when I camped out at our developer’s apartment to give him real-time product directions during QA. I was watching him code this color box on our homepage, and I realized that we might have to change its size if we want to alter the length of the text wrapped in it. However, that element was not coded in CSS to preserve flexibility, but instead it was done using the PSD image element, which meant that we would need a new PSD file to change the size of that box. Given that they know we did not have a full-time designer on staff, that should’ve not been the way they built the page. 

Sometimes using an outsourced development team can help you speed up your project because you can make parallel progress in your product and sales/business development while you recruit full-time engineer talent. However, be mindful about how your outsourced team is incentivized and carefully manage your and their expectations. 



Doing Business Development with Big Companies as a (Lean) Startup

(This post was also published on the "Launching Tech Ventures" 2013 class blog, an HBS elective course taught by Jeff Bussgang)

The prevailing “lean startup methodology” popularized by Eric Ries over the past few years has greatly impacted how companies and products are built in the early stage. In the early days of a startup’s lifecycle, “proof of concept” and “product market fit” can often be achieved with a minimum viable product (“MVP”) that contains only the critical features required to prove key business hypotheses. However, to fuel the next level of growth, startups usually want to explore partnerships with large, established players in the ecosystem to 1) build out additional distribution/marketing channels (e.g. Square’s partnership with Starbucks, Fab’s partnership with Facebook), or 2) obtain access to critical technology, data, or IP (e.g. Simulmedia’s data partnership deals with TiVo, GetGlue’s partnerships with various media companies). 

These two realities often clash against each other, as large companies are generally neither willing nor able to work with smaller startups for the following reasons (and this is why Time Warner Investments, where I used to work as a VC, focused on investing in Series B or later-stage startups because they are more likely to successfully establish partnerships with the operating divisions):

  1. “Immature/half-baked” product. This is most relevant to those startups that are still in the “beta” phase or are just transitioning out of their MVPs. Fortune 500 companies are used to a “perfect” product built over a 24-month waterfall cycle, not a constantly-evolving product with ten releases every other day. 
  2. Lack of business or engineering resources to handle the deal. As the strategic VC arm of a large media company, we frequently connect our divisions (e.g. HBO, Turner, Warner Bros., Time Inc.) with those startups that we thought would provide interesting operating partnership potentials. Many times the feedback would be: “Yea they’re doing some interesting things, but they don’t have the resources to meet our (sometimes long) list of requirements.” on both business and technology fronts. 
  3. Unequal/one-sided value claiming. Naturally, large companies have more resources and much more to offer (on the surface). Without creative thinking and structuring, the relationship could easily be seen as one-sided as if the startup is claiming all the value created in the deal. 
  4. Reputation risk. Large companies take on significant reputation risks when inking a partnership deal with a less-established startup. In addition to the product risk discussed in #1 (e.g. reputation damaged by the startup’s crappy product), the mere risk of associating its established household name with a no-name startup that might go under tomorrow is scary for many. 

Given the above challenges, how should startups fight this uphill battle and secure the next strategic partnership to accelerate growth? Here are a few ideas:

  1. Share your product vision/high-level product roadmap with potential partners (without disclosing sensitive, proprietary information). Even though the current version of your product might be “minimal,” potential partners will get more comfortable if they can better understand your product roadmap and timeline for feature releases. 
  2. Show resource dedication without over-promising (and under-delivering). If a partnership is truly strategic and potentially transformational to your startup’s growth trajectory, don’t be afraid to commit resources and make it work. However, be mindful about over-committing – if you’re not yet at the stage where you have enough resources to make it work, focus on your core business.
  3. Be creative to structure mutually-beneficial deals.  To make your large corporate partners feel like they are getting something equally valuable out of a deal, focus on things a startup is uniquely positioned to bring to the table – e.g. PR benefits of “being innovative, cutting-edge,” exposure to a tech-savvy or younger demographic that they otherwise could not reach, etc. 
  4. Leverage “adults” of your startup to minimize reputational risks. Get your investors, Board, and Advisors to work! Having your brand-name VC investors to introduce you to large companies that their partners might be a Board member of brings instant credibility.  Introductions from industry veterans who sit on your Advisory Board serve similar functions. 

Ideas or thoughts? Would love to hear your perspective. 



Why Are Apple’s App Store Policies Killing Its Mobile Ecosystem

Fresh out of the Thanksgiving holiday shopping spree, a few interesting reports came out digging into the Black Friday-Cyber Monday ecommerce shopping performance. According to IBM, mobile engagement continued to soar, making up 24% of the traffic and 16% of the sales., a design-focused ecommerce startup, has been seeing very interesting mobile stats on sales and the dominance of the iOS platform - revenue from its mobile apps reached 25% of total sales just 30 weeks post-app launch (95% of which came from iPhone & iPad), and mobile apps generated over 1/3 of its Black Friday-Cyber Monday sales. This phenomena is not hard to undersand - people are simply spending more time with their phones than with their computers

The continued rise of smartphone led to an appreciation for a “mobile first web second" strategy - in order to deliver the "right" mobile experience, you have to start building your product with the mobile UX/UI in mind (vs. building a website and then repurpose the web experience to mobile). As a result, countless startups focused all their resources and energy to build a killer iOS app (why iOS first? because it continues to dominate Android on engagement and monetization) only to realize there are some serious flaws in this approach.  

Some of the issues around building a “mobile first/mobile only” product can be attributed to the unique properties of a mobile device (e.g. smaller screen translates into a constant battle between usability and monetization, small/ineffective ad units, etc.), but a few of the key problems can be traced back to how Apple runs its App Store. 


  • Discovery/Distribution - One of the key differences between the web and mobile is that there is no SEO/SEM in the App Store, a key tool for organic traffic and paid marketing for driving visitors to your websites. Yes, you can “kind of” buy pay-per-installs through ad networks such as Tapjoy and Flurry, but Apple continues to crack down the whole pay-per-install model with its latest App Store rule change. The sheer volume of apps in App Store plus its notoriously random “Featured Apps” system makes it extremely hard for an app to gain any organic visibility. In short, no one has cracked the app distribution nut and Apple is not helping. 
  • App Approval Process & Cumulative Reviews -  In a web environment you can iterate much more cheaply and faster than you can do so on mobile. For one, it costs much less to build a “minimum viable website” to test key hypotheses than to develop a fully-functional native app. Apple’s app approval process has improved over the years in terms of speed and transparency, but it is still a barrier for fast iteration and testing (wait time running up to to three weeks). Furthermore, the fact that all Ratings & Reviews of an app is carried over across versions means that the first version “can’t suck.” The only way to avoid “getting on the app store stage before you’re ready” (to avoid bad reviews) nd test your app with users is through Apple’s Ad Hoc distribution (but you’re limited to 100 beta testers) or third-party hacks such as TestFlight
  • Apple’s 30% Cut - Apple charges 30% revenue share on gross revenue generated through apps (in-app purchase AND ad revenue). 30% off the top is great profit for Apple in the short-term, but if no one can build a real mobile business in the iOS ecosystem given the high customer acquisition costs (see “Discovery/Distribution” above) and the hefty 30% payment to Apple (and we haven’t taken into account credit card payment processing, taxes, etc.), Apple might have a problem in the long run.   

So what can you (and Apple do) beyond reconsidering the above policies?

  • (You) Build Web Presence to Drive Mobile Download - Instead of “mobile first web second,” maybe the alternative strategy is “mobile product web marketing” - leveraging traditional SEO/SEM and the web’s larger screen to do more effective,  targeted marketing and a simpler on-boarding process. You do the “selling/convincing” on your homepage, walk the user through a sign-up process to create an account, then bring the user to the App Store to download the app. An example: I found out about Lift through an article and arrived at its homepage, which did exactly the above. I would’ve never thought of looking for the Lift app in the App Store otherwise. Instagram also leveraged its web presence (via shared Instagram photo landing pages) to drive awareness and downloads.   
  • (Apple) Native “Share An App” Function and Referral API - The major benefit of Apple’s “closed” App Store ecosystem is that the user experience is much more unified across all apps. Contrary to the web environment, there’s no easy way to create a mobile viral loop among iOS devices to facilitate sharing an app with friends. One thing Apple should consider is to build in a native “Share An App” function that sits within each iOS app, so a user can easily spread the word with contacts who have iOS devices. To push this thought further, Apple could develop a referral credit API (e.g. invite a friend and get $10 credit when the friend installs/purchases) to further help facilitate native viral loops within the iOS environment.   

Apple’s iOS ecosystem is currently enjoying the mindshare of developers, and developers need a thriving ecosystem that can help them build a business. It’s a fine balance to strike between maintaining the integrity of the user experience and optimizing on monetization, but Apple should start spending more time to help developers make a plausible business case by investing in “mobile first on iOS.”

(p.s. I know some people will suggest “Why not just build a good mobile web app using HTML5?” Unfortunately, as Mark Zukerberg (and many others) realized, “‘good enough’ wasn’t good enough" and its benefits of delivering consistent cross-platform experience and development weren’t enough to outweight the downsides - much slower and less stable. Plus, consumers just LOVE apps and their app icons.)



So, How Exactly Do You Find A Tech Cofounder/CTO/Coder??

There have been countless posts and discussions around the topic of “If I don’t know how to code/am not technical, how do I launch my website/startup?”, and I know many of my classmates/non-technical friends (myself included) have encountered this challenge. I wasn’t going to pile on top of great posts that were already written (such as here, herehere, and here), but an in-depth discussion in class the other day prompted me to share a summary of insights and actionable suggestions that I thought would be valuable to others.  

Last Tuesday, instead of the usual case discussion, we had an interesting group of guest panelists (Brandon Liu, Anna Palmer, Jim Psota, and Hugo Van Vuuren) in our Online Economy class to discuss the very topic of “Hiring Tech Talent” (translation: How do I find a tech cofounder/coder???), and the discussion kicked off with a glance of the infamous tumblog MBA Seeks Code Monkey. Because of the right mix of technical and non-technical panelists and their understanding of their audience (HBS students), I thought the discussions were even more relevant and actionable to business/non-technical people in general. 

The biggest takeaway, surprisingly, is that finding a (tech) cofounder is VERY similar to dating (a panelist plugged OkCupid’s blog as a resource with nuggets of wisdom that are as applicable to dating as to startups/cofounder relationships). 

Below is a summary of tidbits from the discussion that resonated most with me:

How to attract/find tech talent: 

  • Present yourself as resources, and know how to frame your skill set as an MBA (see more below)
  • Develop personal relationships 
  • Be a magnet - attract, not attack (especially at networking events)
  • Get yourself a few technical advisors
  • Plug yourself into the UX/UI/design community - they would know good technical people whom they’ve worked with
  • Have a conversation on what they (engineers) are looking for, and how you can contribute - “What matters to you?”

How to identify top tech talent:

  • Best programmers work on side projects - they keep themselves abreast of the latest technical trends and learn from these side projects
  • Leverage your technical advisors to help vet candidates and ask the right questions
  • Best quality to look for (in the context of startups) - smart, tenacious, cultural fit, and can just “figure things out” 

Sources for top tech talent that you can realistically attract:

  • Develop undergraduate students (especially at the inflection point - when they are about to graduate) - they are looking for “personal growth” (you can’t compete on cash/equity comp with Google/Facebook anyways) 
  • Poach top talent who are working at good tech companies - especially when startups get acquired and/or they are at the end of their vesting period
  • Talented folks who do NOT live in prime cities/startup hubs - e.g. SF/Silicon Valley, NYC, Boston

What technical people value in a potential non-technical cofounder:

  • Tenacity, not getting stalled by not having a tech cofounder - e.g. testing hypotheses and validating the concept via MVP/customer feedbacks
  • Charisma
  • Network - leverage your network to recruit respected advisors, and offer your tech team the opportunity to work with these advisors
  • Leadership - have a vision and lead by example
  • Understanding in distribution/sales - how to get USERS (not a task engineers want to spend time thinking about)
  • Time is the most valuable thing in startups - skill in managing “time” and keeping people accountable

Tech product management/how to manage working relationships with your tech team:

  • Frequent, weekly communications
  • No surprises, small milestones
  • Take “time” and chop it up - e.g. set short-term, medium-term, long-term goals; 2-week product development “sprints”

How to get technically fluent:

  • Understand components of technical architecture - e.g. Web development stacks
  • Focus on means to get to understand code, not necessarily learning how to code - only spend time learning how to code if you enjoy it
  • Ask questions - don’t pretend you understand everything
  • Sit next to your tech team and observe how they work

There’s no “one silver bullet” and it takes time to find the right technical cofounder/team, but you can start building relationships and technical fluency now. 



(from Jason Goldberg,

My co-founder, Bradford, and I decided from the beginning that we’d never make a single decision about what goes on the website based on how much money we’ll make on a particular product. Instead, we ask, Will it make customers smile? Excite them? Make them tell their friends about it? The biggest realization I’ve had is that if you really want to build a successful business, it’s not about how much money you’re making. It’s emotional. For us, it’s how do we make our customers smile? Every single decision we make comes down to that.



a collection of random coffee meetings scattered across NYC this summer. (Taken with Instagram)

a collection of random coffee meetings scattered across NYC this summer. (Taken with Instagram)



Wine pros @morganwharris @davisanderson3 opening 1993 bottle @ericbatscha found in storage. W/ @leitihsu @ericahsu  (Taken with Instagram)

Wine pros @morganwharris @davisanderson3 opening 1993 bottle @ericbatscha found in storage. W/ @leitihsu @ericahsu (Taken with Instagram)



Cake with @winemeapp & other @DreamItVentures logos #DreamItNYC12 demo day (Taken with Instagram at Time Life)

Cake with @winemeapp & other @DreamItVentures logos #DreamItNYC12 demo day (Taken with Instagram at Time Life)