Exit Readiness: Product

Your product is the lifeblood of your company, so it makes sense that it would be one of the main points of attention during an exit process. All product-related factors influence buyer confidence and enterprise value: your product roadmap, quality, scalability, and security. These are exacerbated if a strategic buyer is in the mix. Beyond the usual strategies, some practical diligence tips can make or break an exit process.  

The most important tip of all? Be fully transparent throughout the product and technology diligence process. Every organization has soft spots, but if you try to cover them up (or “perfume the pig,” as I like to say), it will hurt your credibility and potentially jeopardize the deal and/or your role in the post-transaction organization. Ideally, you would begin to address any of the known challenges mentioned later in this blog well ahead of your exit, so that your organization can benefit from the improvements; however, in the case that issues arise during the process, remember that honesty is the best, no, the only policy. 

General Considerations 

Throughout my career, I’ve seen product teams run into some other common challenges during diligence. I recommend getting ahead of these obstacles early on to set your team up for success: 

• Product Management Workflow: You need to be able to describe your product management approach in detail. The acquirer will want to understand it from idea to discovery to UX design to software implementation to user feedback. If you’re using one of the major thought leaders (e.g. Marty Cagan) or process frameworks (Pragmatic Institute, Jobs-To-Be-Done) to drive your approach, be sure to share that. If you’re using application tooling (e.g. Pendo) to determine feature uptake and effectiveness, be sure to describe. You should also characterize your approach to UX/User research and user interface. 

• Product Management Discovery: It will be important for you to characterize your product discovery discipline from proof of value to usability, to development feasibility, to business model fit. Discovery is critical to mitigating the risk associated with a new offering or significant enhancement. Acquirers understand that software engineering is an expensive resource; we need to get the “what” right much of the time or we’re wasting that resource.  

• Product Management Prioritization: One of the most difficult and critically important responsibilities of the Product Management function is facilitating tradeoffs and prioritization. If you’re using one or a combination of methodologies (RICE, Kano, Value vs. Effort, Weighted Scoring, Eisenhower) to inform your prioritization decisions, be sure to share this with the acquirer. An inability to prioritize causes “peanut buttering”/spreading the organization too thin and results in suboptimal execution across all functions. 

• Development Productivity and Measurement: The software engineering function is often the largest or second largest operating expense; the acquirer will be interested in both the effectiveness and efficiency of your engineering organization. Ideally, you will be using tooling to measure engineering productivity and effectiveness (e.g. Jellyfish, DX, Pluralsight). If not, effectiveness is typically associated with roadmap fidelity and efficiency, with R&D as a % of revenue. 

• Technical debt: Most successful growth companies have it. Be prepared to characterize it and describe your plan for addressing it. Whether it’s as simple as a backlog of relatively low-severity bugs that have built up over time or a more significant and expensive challenge like a major modernization effort, be prepared to describe the problem and, most importantly, the path to a solution. Some acquirers will want to do a code review and/or ask for your software to be run through an automated code-hygiene tool. Be prepared to show your bug backlog and historical arrival rates and fix rates. 

• Cloud Costs: These costs have a direct impact on gross margins. If you’re not already using a consultant and or appropriate tooling (e.g. VMware/CloudHealth, CloudZero) to optimize cloud costs, you should have a plan to do so. 

• Business Continuity/Disaster Recovery: Depending on the nature of your business, this may be more or less important. Be prepared to characterize today’s approach and how you’re thinking about evolving it with the growth of the business. 

• Software Development Process and Tool Chain: You will be asked to describe this in detail. If you know you currently have gaps (e.g. lack of automated testing, security testing, appropriate management of infrastructure-as-code, etc.), have a plan to address them. 

• Intellectual Property: All acquirers will be interested in patents as potential competitive moats, but they will be equally interested in your reliance on Open-Source Software (OSS). You need to make sure that you aren’t using GPL or Copy Left licenses in your code. If you’re not already scanning for this, there are myriad tools (e.g. Black Duck, White Source) that can help you do so. 

• People: As you would expect, acquirers are typically concerned about attrition and single points of failure in engineering organizations. It’s helpful to be able to point to employee engagement survey results and robust knowledge sharing programs to keep attrition low and dependency on any one individual equally low. 

Beyond these general points, there are three key areas of consideration for product exit readiness: 1) product strategic planning and roadmap management, 2) scalability and technology, and 3) intellectual property, security, and policies. 

Product Strategic Planning and Roadmap 

A strong product roadmap signals to potential buyers or investors both that the company as a whole is headed in the right direction and that you understand the ways your product needs to evolve to continue serving customers in the long term. 

 The following graphic represents one process by which you can create business-aligned product goals to drive your roadmap: 

Scalability & Technology 

The investment thesis of your acquirer is based in the belief that you will either continue your impressive growth or grow even more aggressively post-transaction. Be prepared to demonstrate that your software platform and supporting infrastructure is positioned to support that growth. 

Buyers often scrutinize scalability readiness. Prepare to demonstrate how your platform supports growth, and address areas like cloud cost optimization and business continuity plans (more on that later). 

Intellectual Property, Security, & Policies 

If you’re already SOC-2 Type 2 or ISO27000 compliant, then you should be fine for diligence. If you’re not, be prepared to characterize your overall approach to security. 

Obviously, this is a topic that goes well beyond Product and Technology and there are plenty of compliance frameworks and consultants available to build you a program. That said, application security is becoming a critical part of software diligence efforts. If you’re not already using scanning tools (e.g. Veracode, Snyk) as a part of your software development lifecycle, describe your plan to do so. “Shifting left” for application security is part of the modern development process. You need to demonstrate that you understand this and have a plan to get there.

Beyond basic IP protections, acquirers will delve into your use of open-source software. Ensure compliance with licensing requirements and consider regular code scans with tools like Black Duck to avoid hidden risks. 

Product and technology readiness are pivotal to successful exits. Transparency, robust planning, and proactive diligence preparation not only boost buyer confidence but also position your company for long-term growth. To further prepare your Product team for a transaction, download our Exit Readiness Checklist.