Product Diligence Explainer

We define "tech diligence" as the process of meeting with the technical team, evaluating the quality of their code and build processes and their technical headcount, and determining things like what sort of technological moat they have. Essentially, we want to see if there's any "there", there. And we want to make sure the underlying tech is solid and workable.

Product Diligence focuses on one primary thing: how efficiently and effectively can the team deploy the capital you're about to invest?

Taking on an infusion of capital and being expected to spend it by scaling headcount is all well and good, but if the team doesn't have a strong Product organization in place, there will be a ton of wasted capital while all that newly hired headcount sits around waiting to be told what to do.

We heard a story of a firm that closed a Series B round: $100M raised, mostly to scale the sales and engineering orgs to facilitate the rapid growth they were experiencing. The recruiting team leapt into action and was able to bring in over 35 new headcount—expensive on-shore dev resources—within 60 days. Three months later, more than half of them still didn't know who their direct manager was supposed to be, or what they were supposed to be working on. The product team was playing catch-up for another 2-3 months to get everyone in the right place, working on the right thing. That's not the "cost of doing business." It's failure. There's no reason that 10%-15% of the runway added from this round had to go up in smoke. Not with proper preparation and the right mindset. But that's exactly what happened.

We generally bring Product Diligence in as part of a Technical Diligence engagement, though we've been asked to audit and evaluate Product Orgs at companies, and recommend ways to get them into shape before (or after) closing a fundraising round.

Without giving away too much, we ask questions around the organization's philosophy towards Product:

• What processes do they have in place now?
• How "agile" are they, really?
• What's the state of their Product Roadmap? Is it all in the CEO's head, for example?
• Do they have a plan for scaling the team, rapidly?

We then distill all of that into a report that takes into account where the business is in their lifecycle, what the plans are for the use of proceeds and on what time horizon, and if we think the Product personnel in place can get it done, or if the org might need some help.

For most companies at the level we're brought in for diligence, the answers to a lot of these questions aren't great. That's actually okay. We don't expect a small, dedicated dev team to be absolutely crushing it on the product side of things, out of the box. Sometimes, a company starts outpacing themselves because they're catching early success and they don't have time to hire these roles, and don't know where to start.

Better Diligence helps with developing, coaching, and growing Product Organizations at companies like these, but even without us, asking these questions and getting the team to think about how they're going to approach these problems is invaluable. It can reduce the ramp-up time and dramatically reduce the amount of wasted cycles and burned investment dollars we see when a firm scrambles to put these pieces into place immediately after closing their round.

If you're evaluating making an investment or acquisition in a growth-stage company, you need to be asking these questions about their product org, in addition to the standard technical diligence process. Better Diligence does both, and we'd love to help run diligence for you on your next deal.

And if a deal's already closed, but an organization is struggling to scale their Product team, we have a ton of experience with that, too. Learn more about how we run Product Roadmaps, here, for example.