Investment Due Diligence Checklist for Product Managers | by Martin Michalik | Oct, 2022

Gone are the times when the sketch on a napkin from your lunch was enough to secure your company Series A funding. In the current economy, investors are way more carefully evaluating where they will invest their capital.

If you manage to catch their attention, sooner or later in the process your whole company is going to undergo a due diligence. If you’re a software product company, your product and it’s development will receive a lot of attention. Attention that can be completely new and overwhelming to any product leader.

During spring 2022, we went through the exactly such evaluation and we successfully secured $40 million in growth capital. And because there’s very little information online about what you can expect from such a process, I’ve decided to share our experience. In this article, I write about what inputs were required from us during the very detailed product evaluation, my suggested outline, and my recommendations and best practices for each part.

Even if your organization is not searching for an investment at the moment, having a clear understanding of the areas described in this article (or even better, having them documented) is — in my opinion — absolutely necessary for any existing or aspiring product leader.

Let’s dig in.

Goal: In under 30 minutes showcase your product’s unique value proposition, key capabilities, and flow to people who likely haven’t seen it before. And who will likely get access to the demo environment later for deeper exploration.

Proposed outline: Start actually outside of your product and prepare 2–3 intro slides. Explain the demo settings and what are the main topics that you’re going to cover. And then dive straight into your demo environment.

My recommendations: Go slow and avoid frantic clicking around. Use a cursor highlighter. Describe what you’re doing, highlight the main value points, and don’t be afraid to pause and summarize the last few steps. Remember that this is likely the first time your audience sees the product in greater detail. And don’t forget to record it — it can come in handy later.

Goal: Demonstrate how do you think about the future of your product. Showcase that you have plan lasting longer than next 6 months. Provide confidence in your product’s longevity and great future.

This is the most important part of the due-diligence process that can be delivered by you as a product leader.

This is where you have to be confident and shine. Do not underestimate this part under any circumstances.

Suggested outline:

• Product roadmap inputs — What has influence over your product roadmap? What are the inputs and qualifiers?
• North Star metric — What is the single metric that best captures the core value that your product delivers to your customers?
• Long-term vision & differentiation— What is your plan to win the long game? How do you plan to stand out in the crowded market? What is your strategy? What is your unique value proposition in the long term?
• Product core values/pillars — What are the core principles your product stands on?
• Roadmap outlook — A visual overview of your roadmap. This really depends on you and how do you work with your roadmap. Do you have a feature based roadmap? Theme or OKR based? Now, next, later? Showcase it here. In all cases, it is important to put things into time perspective. And you can be sure, that this slide is where all stakeholders will pay attention the most.

• Details on the product initiatives — While itemized timelines are great for visualization and putting things into (not only time) perspective, they tell only half of the story. That’s why I recommend to dedicate several slides for additional explanation of the items from your roadmap. It doesn’t have to be exhaustive explanation, but don’t leave too much room for misinterpretations.

My recommendation:

Pay extra attention to this portion of the due-diligence and tell your product story — where you’re coming from, what you want to achieve, how you plan to get there and what is essential for your success. If you don’t know how to structure your pitch, I recommend this article from Andy Raskin.

Goal: Showcase the maturity of your product development organization by explaining the steps an individual product improvement goes through from the idea to the release.

Additional comments: This is the second most important part of the product due diligence as it shows how healthy your product development is. Do not underestimate this part. Moreover, very likely you’ll need to combine your inputs with those from your peers on the Engineering side of your product organization to provide a holistic view.

Suggested outline:

• Product requirements approach — How, when, and where do you collect product requirements? Is there any methodology in place? Any specialized software? How do you analyze the requirements and share them with the rest of your organization? How are the requirements transformed into development tasks?

• Product organization — How does the structure of the product organization look like? What are the roles and how do they cooperate? How many people are fulfilling these roles?

• Product development process — How are product requirements transformed into the final product? What is the lifecycle of an individual product objective? What are the stages? When do different roles participate in the process? What methodology/approach is applied? What is the product team’s way of working? How do you manage product backlogs? How do you manage product maintenance?

• End-to-end practices & Quality management — How do you approach product releases? What does your CI & QA pipeline look like? How do you approach QA in your product organization? What is your (automated) test coverage? What is the level of automation in the whole process?
• Defects & Customer Escalation approach — What is your issue/incident escalation and resolution process? How do you categorize and approach the resolution of product issues?

My recommendations: Each organization has a different approach to their software development, yet they have many things in common, so the devil is in the detail — focus on what makes you stand out, what are you doing differently, and what have you learned that works for you. You don’t need to explain what Scrum is. You don’t need to showcase your JIRA project structure. Try to use visualizations whenever possible (after-all one picture is worth a thousand words) instead of lengthy texts.

Goal: Provide a quick functionality overview of your product. Often times can be joined with the architectural overview (Engineering due diligence).

Proposed outline: One slide visual of your product’s overall logical structure (functionality areas). Then highlight your top 3–5 most important features.

My recommendations: Keep it simple. You don’t need to go into much detail, but provide links where people can find more information if needed. Make it work on 5 slides or less.

Goal: Showcase that you can holistically look at your product and its development organization, that you understand where it can be improved and what gives you an advantage in the market.

Suggested outline: Don’t try to squeeze everything into one slide as some templates suggest or you’ll create an unreadable mess. Instead have one slide for Strengths, one for Weaknesses, etc. Separate the two SWOTs into two files, don’t mix them together.

My recommendations: For each category pick only the top 3 items. That’s more than enough. Then for each item provide additional context rather than having them as a list of ambiguous bullet points.

Goal: Showcase maturity of understanding your user base by explaining who are the main users and what are their motivations to use your product.

Suggested outline: Keep it simple. Briefly introduce on a few slides the main personas, their categories, and representation in your product. Then ideally combine this with your individual personas “overview” into one package.

My recommendations: A nice visual representation of your key personas goes a long way. Focus on their goals, motivations, and frustrations rather than on their demographic information.

Goal: Again, showcase your maturity of understanding your user and base by presenting their journeys with key value moments (= moments when they realize value).

Suggested outline: This part is heavily influenced by whether and how you have your journey captured. In our case, it was one slide with the visual of the journey and two slides with explanations of our key value moments.

My recommendations: The content of this part depends on how you have your user journey captured — do you want to present multiple journeys for different personas or combine them into one? My suggestion is to with simplicity over accuracy (detail), but not at the cost of creating nonsense.

Goal: Showcase the maturity of your product design approach by explaining the role of the design & research team in your organization.

Suggested outline: Again, keep it simple. Showcase your Design & Research team organization, their main roles, and responsibilities. Explain how you approach User Testing and Research and highlight some of the research projects. You should fit within 10 slides.

My recommendations: You would be surprised but many organizations don’t consider product design and research as important. This is your unique opportunity to show that your product organization is mature and data-driven.

That’s it. That’s what worked for us and helped us to secure the capital. However, remember that in your case the required information might be different as each investor and their approach to the due-diligence process is different. Always tailor your presentations to their requirements.

Nonetheless, it is important to keep in mind during the whole due-diligence process that you have usually only one shot to make a good impression. Don’t waste it! Even though it seems like a lot of work to prepare everything, make it count. Invest in nice visuals. Get professional help with the slides, if you need one. It will pay off.

And even if you’re currently not raising growth capital, it is good to have the aforementioned information documented somewhere in your organization. They’re not only a great on-boarding resource and they’re sometimes required for various certifications (such as ISO), but also their preparation will force you to think about your product organization’s strengths and weaknesses.

Finally, let me know in the comments if I missed something important — something that was required from you or something that made an impression. Let’s share the knowledge!