Can the team actually deliver the roadmap?

When you’re acquiring a tech-driven company, the roadmap almost always looks good: ambitious features, clear milestones and a story that makes sense on paper. But the real diligence question isn’t whether the roadmap is compelling.

It’s whether the team can actually deliver it.

Start with the delivery record

The standard playbook is a good starting point. Look at historical delivery. Review code commits. Separate features from fixes to understand the real cadence. Pay attention to who shipped what, because that’s where key-person risk quietly shows up.

That tells you what’s been delivered before. To understand how future delivery will really feel, look beyond the code and spend time with the team.

Ask the team what they’re building — and why

• What are you working on?
• Why is it important to the company?
• Why is it important to the customer?
• How is it better than what they do today?
• Where does it fit in the bigger picture?

Individually, the answers matter less than their consistency.

When a team is aligned internally and aligned with its customer, people tell the same story in different words. The priorities make sense. The trade-offs are clear. The work connects to outcomes.

Alignment reduces wasted effort

Those teams can move faster, not because they write more code, but because they waste less time: fewer false starts, fewer rewrites and fewer features that need to be “repositioned” after launch.

Misalignment, on the other hand, rarely shows up as a single red flag. It shows up as friction, slow iteration and features that technically ship but never quite land.

So yes, look at the repository. But also listen closely to the team.

Execution risk isn’t just in the codebase. It’s in how clearly and consistently the team understands what it’s building and why.