Blog

  • B2B Tech Incubator Entrance Requirements

    Over the past couple years I’ve had the chance to talk with several entrepreneurs that are interested in setting up a tech incubator. At the Atlanta Tech Village, we don’t call it an incubator because there’s no equity component. One of the tech incubator discussion topics was around entrance requirements, especially in a B2B context, with a goal of more transparency for applicants.

    Here are a few ideas around entrance requirements for a seed-stage B2B tech incubator:

    • Aligned Core Values – Entrepreneurs, employees, investors, and everyone else that’s deeply involved need to have aligned core values.
    • 10 Paying Customers – Nothing happens until something is sold, and signing up paying customers, even if the revenue is small, is incredibly valuable.
    • 3 Reference Customers – Customers that are raving fans, and happy to act as a reference, are critically important.
    • Pain-Killer (not vitamin) – While this can be subjective early on, once customers are using the product, it becomes clear if it’s a must-have vs a nice-to-have.
    • Clear Path to Scale – Every startup starts small, but the goal is for it to get large, very large, which necessitates a huge addressable market,

    Similar to investor requirements, a seed-stage B2B tech incubator would have its own requirements. Regardless, an incubator would do well to publish what it looks for in resident startups and establish guidelines.

    What else? What are some other possible entrance requirements for a seed-stage B2B tech incubator?

  • VC Managing Partner Economics – Round 2

    After yesterday’s post on Venture Firm Managing Partner Economics, I received a number of good comments and thoughts. Parker Conrad, founder/CEO of Zenefits, offered up that the economics for a VC change dramatically when managing multiple funds simultaneously. So true.

    Here’s how the economics might look with multiple funds under management:

    • Fund 1, with $100 million of capital, performs well (3x cash on cash), and Managing Partners make an average $2 million per year over seven years (most is back-loaded)
    • Fund 2, with $150 million of capital, closes four years into Fund 1 (able to raise it quickly because of progress to date), performs well, and Managing Partners make roughly $3 million per year over seven years, but the first three years overlap with Fund 1, so during those years, the Managing Partners make $5 million per year
    • Fund 3, with $200 million of capital, closes four years into Fund 2 (able to raise it quickly because of progress to date), performs well, and Managing Partners make roughly $4 million per year over seven years, but the first three years overlap with Fund 2, so during those years the Managing Partners make $7 million per year

    Of course, this is all theoretical and is presented in a manner that makes the venture model look smooth and consistent (it isn’t). More complexities to the model include the fact that most venture firms don’t do well (see the Kaufman Report’s PDF – h/t @jalex2003), some have a hurdle rate before the VCs earn a piece of the profits (e.g. a hurdle rate of 8% requires the investors to get that return first – h/t @stephenfleming), and VCs have to invest their own money into the fund (e.g. invest 1-2% of the fund’s capital such that it takes several years of management fees just to get back to breakeven – h/t @lance). The venture business, and corresponding economics, are more complicated than expected.

    What else? What are some more thoughts on the economics of the venture business?

  • Venture Firm Managing Partner Economics

    Recently I was talking with an entrepreneur about his goals and aspirations. He offered up something I don’t hear too often: once he sells his company he wants to become a venture capitalist. We dug into it more, especially the economics, and analyzed how it might work out.

    Here’s an example scenario of a venture firm with a $100 million fund and three managing partners:

    • 2% management fee and 20% carry (profits) such that the firm has $2 million/year to operate for the first 5-7 years and then a much smaller amount after that
    • $400,000/year salary for each partner and another $800,000/year for associates, office space, legal, accounting, etc.
    • Fund goal to produce 3x cash on cash in seven years, so invest $100 million and generate $300 million from those investments net of management fees (say $10 million)
    • Each partner gets 6% carry with the remaining 2% going to associates, venture partners, advisors, etc.
    • With $300 million from exits, less the initial capital invested ($100 million), the firm gets 20% of the remaining $200 million, which is $40 million. The partners would then each earn $12 million (6% out of the 20%).

    So, assuming the fund does well and everyone is happy, the VC earns $12 million over seven years plus a couple million more in salary. The money starts to get much larger when the VCs raise subsequent funds that are larger in size and/or land a once-in-a-generation investment like Google or Facebook.

    The economics of a managing partner at a venture firm are straightforward, if not well understood by people outside the industry. As for the entrepreneur in the conversation, he’d make for a great VC.

    What else? What are some other thoughts on the economics of a partner at a venture firm?

  • 50 $5k Bets or 5 $50k Bets

    Recently I was talking to a successful entrepreneur that wants to start doing some angel investing. As part of this initiative, he wanted to initially invest roughly $125,000 per year for two years ($250k total). He said he was looking at a variety of strategies and debating between two approaches:

    • 50 $5k Bets – Invest $5,000 in 25 startups per year with the idea that it’s incredibly hard to pick the winners, so having a diversified portfolio increases the chances of finding a couple that do well, and then doubling down on the winners. With so many investments, at such a modest amount, there wouldn’t be much time to give individual attention, but in a short amount of time it’d be clear which ones are doing well, and which ones aren’t.
    • 5 $50k Bets – Invest $50,000 in 2-3 startups per year with the idea that he’d pick ones where he can add value based on the industry, domain expertise, and/or connections. The portfolio wouldn’t be diverse, but he’d have a larger stake in a few select companies and hopefully add value beyond just the money.

    After hearing these two strategies, I asked him how much he was reserving for follow-on rounds to participate pro-rata (if any) and his general follow-on strategy. His response was that he’s planning on the same $125,000 per year for follow-on rounds, so likely 1-2x the initial investments, depending on how many make it and actually raise more money. Now, this differs from one recommendation I’ve heard to save 3x the initial angel investment for follow-on rounds but it’s still in the ballpark, especially if he’s not very selective.

    Regardless of what he chooses to do, what’s important is that he’s working on a strategy and getting into the arena.

    What else? What are your thoughts on the two strategies and which one do you like better?

  • Technical Review in a Company Acquisition

    As part of the Pardot acquisition a few years ago, there was an extensive technical review during the due diligence. As you would expect, the idea was to evaluate the technical underpinnings of the product and to try and assess if it was well made and will continue to perform as the company grows. Only, a technical review by a third-party is incredibly difficult as languages, frameworks, deployment strategies, etc. are all different and nuanced.

    Here are a few areas of technical review in a company acquisition:

    • Code Walkthrough – Much time was spent walking two senior engineering managers through how the code was organized and styled. Here, the goal wasn’t to evaluate every line of code, but rather to see that it was maintainable and that we were thoughtful in our approach.
    • Architecture – After the code walkthrough, the next step was to draw out the architecture of the product and explain how all the modules interfaced with each other. With a standard Model-View-Controller approach, the basics are usually straightforward.
    • Data Storage – With so much information being stored across so many different customers, data storage and retrieval was a big deal. Of particular note were the areas where data was growing the fastest as well as our strategy for keeping up with the growth.
    • Deployment – When a software engineer makes a change, what happens before customers get to see or use that change. How much human intervention is required? Is it automated? What tests have to pass? Where does the code go?
    • Hosting – With a complicated web-based application, the number of servers and services can be quite large. An acquirer wants to understand how manageable the hosting configuration is and how hosting costs grow as the customer base grows (hopefully there are some economies of scale in the hosting costs as revenue grows).

    Note that nowhere during the process was there a consideration for how well our product could integrate with their product or if our product was written in the same language and/or style as their product. For acquisitions whereby the product is going to continue on as a standalone application, the goal is make sure that it’s well made and will continue to perform as the business grows. Technical reviews, in my limited experience, are much easier than expected.

    What else? What are some other thoughts on technical reviews in a company acquisition?

  • Legacy Code Base Challenges

    Continuing with yesterday’s post 90 Days of GitHub Commits, jumping back into software engineering has really driven home to me why it’s so hard for successful software companies to keep up with new upstarts. Once a product is working, and the startup starts scaling, all the engineering efforts are focused on keeping up with growth, not with the latest technologies. And, over time, as the code gets deeper and broader, it becomes even more difficult to modernize things.

    Here are a few thoughts on legacy code base challenges:

    • Think of the products you use on a regular basis. Now, think about their user interfaces, especially the ones that are the most legacy (e.g. payroll, CRM, etc.). The older the application, the more antiquated the interface due to a large customer base and the tremendous difficulty updating it.
    • Newer technologies often make software engineering faster, more scalable, and more maintainable (when used correctly), which gives an edge to startups using the latest technologies.
    • Complicated customer use cases for a limited audience can be even more challenging for legacy products as the market no longer demands the functionality, yet it still has to be maintained because certain customers use it (watch out for frankenstein products).
    • Entire markets of new products to mobile-enable legacy products have emerged (e.g. Catavolt) showing that legacy software companies have serious difficulties staying up-to-date

    A common question I hear from people outside the software world when talking about a startup idea is “can’t Google/Facebook/Microsoft just update their product to include this functionality?” Yes, it’s technically possible, but there are so many competing priorities and legacy challenges that it won’t ever get done. And, that’s one reason why startups can start with a niche and grow into a formidable competitor.

    What else? What are some more thoughts on challenges with legacy code bases?

  • 90 Days of GitHub Commits

    As part of my 2015 Year of Code plan, I made a small goal to commit code daily for 90 days straight to get back into things and learn as much as I can. My last run at serious software development was in 2008, so it’s been many years since I’ve done it on a regular basis. Now, I feel proficient and productive again.

    Here are a few takeaways after writing code for 90 days straight:

    • GitHub – Git, and GitHub in the cloud, make version control easy and integrated. Before, we had hosted a version of Subversion in-house and it worked, but wasn’t nearly as seamless. Add in pull requests, code reviews, tight issue tracking with code commits, and things are much better.
    • AWS – Amazon Web Services is insanely powerful. Between OpsWorks, RDS, ElastiCache, EC2, and more, AWS completely changes how software is managed and scaled in the cloud. I now understand why AWS is a $5 billion a year business for Amazon.
    • Continuous Deployment – Running automated tests and deploying code to production was historically a tedious process. Now, as soon as code is committed, tests automatically run and code is pushed to the appropriate servers, without human intervention.
    • Special Purpose Conversion Languages – One major trend that wasn’t around before is writing code in one language to produce code in another language, specifically CoffeeScript for JavaScript, HAML for HTML, and SCSS for CSS. Clearly, smart people weren’t happy with some of the tedious aspects of popular languages and markup formats, so the solution was to write code in a more understandable way to produce other code. I like it and it works well.
    • jQuery – Writing JavaScript (through CoffeeScript) and plugging in pre-built components has never been easier. The eco-system and available modules make putting together interactive front-ends enjoyable.

    Overall, software engineering has made solid progress. Now, things are more maintainable, distributed, and productive compared to several years ago. I’m a fan of the innovation and can better appreciate how the new tools and systems have decreased the time to market for talented teams.

    What else? What are some other new trends in software engineering compared to several years ago?

  • Ideas for Angel Investor Groups in the Startup Community

    Recently I met with one of the angel investor groups in town to catch up on the startup community and the Atlanta Tech Village. One of the questions posed was “how can we become more top-of-mind for entrepreneurs in the community?” Easy, I said, the best form of marketing is education. Meaning, go out and help educate entrepreneurs, which in turn will result in more mindshare and more deal flow.

    Here are a few ideas for angel investor groups in the startup community:

    • Develop a program to help entrepreneurs learn the basics of building a business (e.g. run an event every Wednesday night for eight weeks like the Kauffman FastTrac program)
    • Start a monthly breakfast series that’s open to the public for entrepreneurs to learn about the fundraising process as well as ask questions (e.g. the BCVP Entrepreneurs’ Breakfast program)
    • Provide clear expectations around the desired types of investments, stage of business, level of traction, etc. so that entrepreneurs can quickly ascertain if they are a good fit
    • Host an investor summit once a year where CEOs of portfolio companies present updates on their businesses and invite a small group of entrepreneurs to attend along with the members

    Angel investor groups are an important part of the startup ecosystem. Groups that help educate entrepreneurs through events and mentorship will also see the best investment opportunities.

    What else? What are some other ideas for angel investor groups in the startup community?

  • Product and Company Name Should be the Same

    Back when we started Pardot in 2007, we didn’t know any better and decided that our product needed a separate name from our company. After tons of brainstorming we finally arrived at a name that we liked and was available: Prospect Insight. Since Pardot didn’t mean anything to anyone, we felt that our product name needed to be more descriptive, hence the name. Also, being a little nerdy, we liked that Prospect Insight could be abbreviated PI, hence lots of jokes about pi (3.14159…).

    After several years of trying to build brand equity in both the company Pardot and the product Prospect Insight, all our customers would call up and ask for help with Pardot, not Prospect Insight. Customers didn’t care what we called the product as everything was simply Pardot. Instead of trying to fight it, we embraced it and rebranded our product as Pardot. That is, the company and the product were one and the same. To this day, you can go to prospectinsight.com as well as pi.pardot.com and see remnants of a disconnected product name and company name.

    For startups, the product and company name should be one and the same.

    What else? What are some more thoughts on keeping the company and product name consistent?

  • Product or Sales Startup CEO

    Earlier today I was talking with a startup executive that’s worked for several successful CEOs. Towards the end of the conversation I asked how he would characterize the CEOs and their styles. Easy, he said, there are the product CEOs and the sales CEOs.

    Here’s a simple generalization of the product and sales CEO in a startup:

    • Product CEOs – They love the thrill of inventing new things and new ways to help customers while generally spending most of their time with the R&D team. Often, they have an engineering or analytical degree.
    • Sales CEOs – They love the thrill of closing a new customer and figuring out how to win more deals while generally spending most of their time with the sales team (see the SaaStr post on Hyperaggressiveness). Often, they were a sales executive before becoming a startup CEO.

    The next time you meet with a startup CEO, see if you can figure out if they’re generally product focused or sales focused. Most fall into one of these two buckets.

    What else? What are some more thoughts on product or sales focused startup CEOs?