A High-tech Entrepreneur’s Guide to Surviving Technical Due Diligence
Posted by rbpasker on August 28, 2007
The purpose of technical due diligence is to investigate the technical aspects of an investment opportunity. But tech diligence is done infrequently enough that few people get really good at it, and in the absence of being good at it, its worthwhile to have some guidelines. This survival guide just that: a guide. But a thorough reading should get you in the right mood, and if you prepare well, you’ll have a much better shot at “wowing” your audience. You’ll know you’ve done a solid job if the person you met with offers to invest himself or wants to join your advisory board!
There are typically two different kinds of companies I come across: true high-technology companies that have a unique technology that can be applied across many different markets, such as Tervela and Mocana; and vertical companies which use (often novel) technology to deliver their product, such Mint, a new personal finance site, and MedCommons, which makes it possible for individuals to take control of their healthcare records. I’m only going to cover technology product companies in this post, but many of the same lessons will apply.
Some people who conduct technical diligence sessions (or any diligence, for that matter) see themselves as gatekeepers, wherein every company starts out as a “NO!” until proven otherwise. But I prefer the “all students start with an ‘A'” method, which means that my job is to help them get through the process as successfully as possible, just like when interviewing a job candidate. Indeed, treat the diligence session like a job interview or an oral exam, with the except that your company and technology are as much under review as is team.
Set aside a day or two to prepare for your first technical diligence meeting. You’ll be doing research, gathering materials, preparing illustrative slides, and, perhaps most importantly, getting yourself mentally prepared. If you’ve ever taken an oral exam or made a thesis defense, the technical diligence process should be a snap.
Know your audience – Find out who is conducting the technical diligence and what that person’s background is, including work history and technical background. Typically a VC firm will try to find someone who knows your business, technology and ecosystem (e.g., SAP or MSFT) well enough to do a good evaluation, but that’s not always possible. Sometimes the VC will get someone who built or used the current generation of the product you’re building. And if your product is in a narrow technical area (security, embedded systems, etc.) or in a an area that is highly regulated, the person doing the diligence will hopefully have that experience as well. In any event, be prepared to give your audience some education on the intricacies of your domain.
Bring your “A Game” – Amazingly enough, some companies don’t send their technology leadership to a technical diligence meeting! I’ve had non-technical CEOs come alone, put up the architecture slide from his VC pitch, and proceed to echo the party techno-speak and provide shallow or uninformed answers. Always send your CTO, VP Eng, Chief Architect, etc., to the meeting, so you don’t waste time.
Provide documents in advance – If you will be referring to documents (patents, whitepapers, etc.) or drawings during the meeting, provide them beforehand, but don’t worry if they’re not reviewed in advance. I prefer to have the documents before the meeting so I can brush up on the domain. Having to photocopy, email, locate, or thumb-drive documents can be a distraction and slow down the meeting.
Introduction: Company and Product
Remember, this is a technical diligence meeting, so don’t give a investor pitch. But you’ll still want to cover a few non-technical areas in the introduction.
Company – This is where you get to tell your “garage” story. Keep it short, but a good human interest story is key to drawing your audience in. Include the genesis and evolution of your product, too. This is where you also review the company status: headcount, previous and proposed funding, existing investors and advisors, etc.
Problem – In an investor pitch, you would explain the business problem you’re solving, but in a tech pitch, you’ll also have to describe your customer’s technical problems, such as scalability, latency, volume, complexity, etc.
Your solution – This is where you have to be very specific about what your product does. If your product is a DBMS, for example, say, “we’re building a new kind of DBMS,” rather than “our product fundamentally changes enterprise corporate data management.” You don’t want to get into a game of 20 questions while your audience tries to figure out if “enterprise corporate data management” means ETL, BI, integration, or something else entirely.
Business model – Describe how your product will be marketed and get sold (direct sales, OEM, VAR, etc), and how your company will get revenue (licenses, support, consulting, etc.) If you are in the commercial open source space, now would be a good time to talk about licenses.
You have a lot of freedom here to describe your product, but there are a number of areas which you have to address:
Technology – This will be the longest part of the discussion, and should be done top-down, starting with an overall architecture slide, and going through every piece of your technology. If applicable, also describe the technology from a historical perspective, including previous failed attempts to solve the problem, and the overall industry environment that now make the problem solvable (e.g., increased processor speed, new algorithms, or availability of wireless spectrum).
Underlying Infrastructure – Explain all your underlying technology choices, including programming languages, databases, app servers, and other tools and technologies that are part of your solution.
Defensibility – describe the state of the intellectual property (IP), including patents, trade secrets, prior art, and the legal status of the IP ownership, rights, or licenses. You can also demonstrate defensibility by showing how hard it is to solve the problem using some objective measure like complexity theory, amount of code, exclusive resources, etc.
Compatibility, Migration, and Standards – since no product is an island, you’ll have to go through how your product fits into the larger picture from a compatibility standpoint (intranet, extranet, internet), how customers are going to migrate to your solution, and what standards your product will support or require. If you’re dependent on the work in standard bodies or if you are going to promulgate standards around the product, then describe that here, too.
Competition – Not only will you have to talk about competitive products and competitive companies vying for the same dollars, but you’ll also have to address build-versus-buy, and the biggest competitor of all: inertia.
Customers that have something “good enough” present a huge obstacle to the adoption of new products, so you’ll have to explain how your customers solve the problem today, and of course, what (technical or business) impetus will drive adoption of your product.
Team and Staffing –Demonstrate the technical team’s credibility and capability. A “dream team” usually has a successful track record of building a similar product for a similar customer base, but not every company can make that boast. One “dream team” example is Michael Stonebreaker, who has successfully launched any number of new companies related to his research and scholarship in the database space, including RTI/Ingres, Illustra, and Streambase. Try to show as best as you can that your team has (yes, I know its cliché) “been there, done that” in your product area.
You’ll need a slide with the technical team org chart showing 6-quarters of hiring projections across all technical areas, including development, QA, product management, support, operations, etc. Each box on the org chart should show that person’s expertise (“java developer for streaming server”, “Windows developer for desktop client”), rather than generic “engineer” titles. You’re trying to show that you’ve actually though through your hiring choices, so avoid the temptation to use the headcount spreadsheet from your financial presentation.
If you are doing any outsourcing or relying on an open source community to compete the project, you should have a slide for that too.
Roadmap – Provide upto a year’s product history, plus the next 6-quarters of future product milestones. Tie the product roadmap to the company’s business and funding milestones, and to your hiring plan. This last point is key to showing your audience that the management team is working in sync.
External dependencies – Almost every product relies in some fashion on other products, such as databases, app servers, etc. But some products or companies are dependent on products, consulting, or manufacturing that are not “commercial off-the-shelf” (COTS). You’ll need to describe any non-COTS dependencies, what the risks and alternatives are, and the state of the relationship with your suppliers.
Product Development Process – I like to get a sense of what kind of development environment will be in place because it is well correlated with product quality. The process discussion should include “methodologies” such as waterfall, scrum, XP, etc., but also the product management process, development processes/tools, bug tracking, testing, etc.
Consulting, Support, and Training – although these are primarily business issues, if your product has special requirements in these areas, you’ll need to cover them, too.
Do’s and Don’ts During The Meeting
Don’t Derail the Conversation – Non-technical people at these meetings should be introduced and say good-bye, and leave the discussions to the technical team. Having someone bring up extraneous points in a meeting so they can “add value” doesn’t.
Don’t argue politics – If you feel really strongly about something, express it, but don’t get lured into a debate for or against any hot-button issues (open source v. Microsoft, Java v. Ruby, Spring v. J2EE, etc.) Its still your company and product and you get to choose whatever technologies will make it work, but you may still have to defend your choices. Do so with grace and respect.
Don’t Snow – “You can fool some of the people some of the time…”, but you will hurt your credibility with anyone who doesn’t buy your story. I give higher marks to people who are up front about what they don’t know versus those who blunder through a poorly thought out answer.
Assume your Audience is Intelligent but Uninformed – This was the best writing advice I ever got from a college professor, and it works just as well in presentations. Inform, don’t educate, unless asked, otherwise you might come across as condescending.
Spark Discussion – Don’t expect to stand up and make a long-winded presentation, then finish with a Q&A slide. Invite discussion, have interesting and important digressions, go into detail, and ask your audience members question,and solicit their opinions.
Use Pictures and Diagrams – Slides are an aid to your discussion, not your lecture notes, so weigh heavily towards pictures and diagrams, rather than endless bullets. Don’t use any type face under 30 points.
Draw on the Board – I always take the chair closest to the whiteboard because I’m always drawing and illustrating. You should, too.
Make a List of Open Issues – Email the answers the next day.
ABC: Always Be Closing – This “sales” advice comes from The David Mamet play “Glengary Glen Ross.” Don’t wait for the last slide or the good-bye handshake to close the deal. Every thing you say and do should purposefully move you closer to a successful conclusion.
When the meeting is over and everyone is standing up shaking hands, make sure you ask appropriate closing questions, like “Did we answer all your questions?” and “What do you think of our product?” Personally, I prefer to make a rallying statement (“I hope we can count on your support.”) versus a question (“So, can I count on your support?”), but that’s a style thing.
After you leave the meeting, research and answer any open questions via email. A thank-you note is nice, but don’t ask questions about when they the feedback meeting is, and can they please tell you the status of the decision-making process. Those are questions for the VC, and the diligence guy is rarely in a position to provide the answers.
By now, you should have a good idea of how to conduct a successful meeting. Ultimately, the product and technology should carry the day, but being prepared, demonstrating credibility, and showing that you’re an integral part of the overall management team will get you many extra well-deserved points.