Blog

  • 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?

  • A Startup’s Product Roadmap

    Product roadmaps are a tricky thing in startups. As a startup, one of the most important aspects of the business is the ability to move fast and make decisions quickly based on new information. With a detailed roadmap, especially one shared with key customers, the ability to change direction can be greatly diminished.

    Here are a few thoughts on product roadmaps:

    • Consider outlining the public-facing plans in minimal detail for flexibility
    • Maintain an internal-only roadmap with more information and specifics
    • Incorporate feedback from sales, marketing, services, support, engineering, customers, and partners
    • Capture internal ideas in a simple Google Sheet with separate tabs for each constituency
    • Provide an idea exchange for customers to submit requests (e.g. tools like GetSatisfaction)
    • Constantly revisit the roadmap and question how the pieces fit together

    Product roadmaps are an important part of any tech company. In startups, roadmaps are especially sensitive and should be dynamic whenever possible.

    What else? What are some more thoughts on product roadmaps in a startup?

  • Regularly Engaging with Business Leaders Outside the Startup Community

    By way of the Atlanta Tech Village, I have the opportunity to engage with a number of business leaders on a regular basis. Common questions like “what’s the hottest startup in the Village?” are oft repeated and I enjoy sharing stories of Yik Yak and SalesLoft. Only, we don’t have a great strategy for proactively reaching out and helping keep the startup community more top-of-mind.

    Here are a few ideas for regularly engaging business leaders outside the startup community:

    • Holiday Showcase – Once a year get together in December where we invite a few hundred people to meet with a couple dozen startups
    • Tech Village Talks – Speaking at local Rotary and business groups about the Village helps spread the story to new people and repeat the message to those that have already heard it
    • Coffees / Lunches / Meetings – One-on-one time is the most impactful but difficult to scale
    • Private In-the-Know-Only Monthly Newsletter – We have a great weekly newsletter for our community but we don’t have one geared towards business leaders that want to stay apprised of what’s happening the startup community (e.g. startups that are doing well, recent deals, opportunities to invest, etc)
    • Quarterly Startup Lunch – Potentially an intimate group of business leaders that get to hear presentations from four heavily-screened startups in the community as a way to engage and provide introductions

    One of the key ideas is that we need more proactive efforts to get business leaders involved with a corresponding rhythm. While this takes time and effort, I’m confident it’ll pay dividends over time by making the startup community more accessible and sharing ways that business leaders can help.

    What else? What are some more ideas on how to engage business leaders on a regular basis with the startup community?

  • Think IPO Roadshow When Raising a Venture Round

    Companies that go public on exchanges like the New York Stock Exchange and NASDAQ have a ritual late in the process called an IPO road show. Investopedia defines a road show as the following:

    A presentation by an issuer of securities to potential buyers. Road shows refer to when the management of a company that is issuing securities or doing an initial public offering (IPO) travels around the country to give presentations to analysts, fund managers and potential investors.

    Imagine spending six months documenting and auditing every aspect of the business, distributing the information to thousands of investors, and then setting up a two week sprint to present the pitch at dozens of meetings. Assuming demand is strong, the company goes public and throws a huge party. Finally, life continues on as a newly public company.

    For entrepreneurs raising a venture round, treating it like an IPO with a corresponding road show is a good strategy. Extensive preparation followed by an intense period of pitching is the best approach to create a competitive deal environment (much like what investment bankers do when helping sell a company). Raising money is difficult, but with strong business fundamentals and fundraising process, readily achievable.

    What else? What are some more thoughts on entrepreneurs treating the venture fundraising process like an IPO road show?

  • Before Raising an Angel Round

    Lately, it feels like a number of entrepreneurs I know that are in the low six figures recurring revenue range are contemplating raising money either through an angel round or a micro VC round. Each one has already raised a friends and family round, is near product-market fit or already has it, and has a low burn rate. Now, there’s a desire to grow faster, and raising an angel round is a common next thought.

    Here are a few questions to think through before raising an angel round:

    • How close is the product to initial product-market fit? How do you know?
    • How repeatable is the customer acquisition process? When will you feel confident that it’s repeatable?
    • What does the spreadsheet math say about growing without more outside capital vs raising an angel round (e.g. growth rates, co-founder dilution, etc)?
    • What are the expectations for ongoing investor involvement (e.g. hands-on, passive, non-existent, etc.)?
    • What milestones will be achieved with the new money?

    Entrepreneurs would do well to think through these topics before setting out to raise an angel round. While raising an angel round isn’t as involved as raising a venture round, it still takes significant time and effort.

    What else? What are some other questions to think through before raising an angel round?