menu burger
post img blur
Build to Sell: How Paul Heard Prepares Startups for Billion-Dollar Acquisitions
scroll img
Back to Perspectives & Insights

Build to Sell: How Paul Heard Prepares Startups for Billion-Dollar Acquisitions

Share

icon linkedin icon twitter

Paul Heard has spent decades transforming companies worth billions and orchestrating M&A transactions totaling more than $10 billion. He reduced churn at Mimecast by implementing customer success functions, delivered HP’s separation into two companies in 9 months, and reimagined business processes at Zuora to enable scalability. He innovated financial services products at DaimlerChrysler to create a $1 billion loan business and managed operations across Mars Inc., Micro Focus, and numerous other enterprises. Now, through Oxonian Technology Partners, Paul leans on that experience to advise early-stage software as a service (SaaS) founders on translating technical vision into sustainable revenue. 

In that work, Paul often sees the same patterns: Technical founders build sophisticated products with impressive capabilities, but often struggle to articulate how purchasing companies will derive value. That lies in contrast to enterprise executives who start with the problem and its revenue impact, then work backwards to solutions. Paul’s insights, drawn from manufacturing floors to boardrooms, reveal how founders can build companies that scale profitably and sell strategically. He recently shared his wisdom with us on a range of topics, including what and how to automate, avoiding technical debt, and why founders must learn to delegate early.

Solve problems, not features

In Paul’s experience, technical founders need to reconsider where they allocate their attention.

“Many founders focus on the product and the capabilities, and less on the problem,” Paul said. “It’s really important that you understand exactly which problem you are addressing and how that problem itself is impacting revenue or benefit for the company.”

The distinction matters because enterprise buyers don’t buy technology for its sophistication; they buy solutions to problems that cost them money or prevent them from making money.

“I’ve had founders present features and functions and amazing capabilities to me, but they have no idea how the purchasing company will actually find value from using it,” Paul said. 

This gap separates technical founders from enterprise executives. Executives begin every evaluation with a clear understanding of the business problem: How much does this problem cost us? How much could we gain by solving it? Only then do they assess potential solutions. 

“To get off the ground and get revenue, the only thing that matters is product features, the ability to get customers and to make those customers happy,” Paul said.

Automate repeatability, not risk

Paul’s framework for deciding what to automate comes from a simple two-part test: Risk and repeatability. Both criteria must align before automation makes sense.

“You would not want to find a role that is extremely high risk being automated in initial phases,” Paul said. “Equally, if the role has no repeatability, it makes it extremely difficult to automate.”

The examples Paul uses illustrate the extremes. Customer escalations sit in the high-risk category. “If the customer is already escalating, then you do not want to make a mistake. You want the best foot forward,” he said. Password resets, in contrast, offer high repeatability with minimal risk. “Definitely should automate,” Paul said.

Where founders should invest early differs from where they typically focus their automation efforts. Paul encourages startups to automate customer communication as quickly as possible.

“A startup needs to get visible. It needs to build a brand presence. It needs to get feedback from the customers,” Paul said. “The ability to automate that interaction gives you a much larger user base, more insights, and a better tuning of the product.”

Where founders over-invest surprises many: Automating the product itself. “They really try to make the product extremely slick and sophisticated. And sometimes the customer actually wants to understand what’s going on,” Paul said. “You can over-automate so the customer thinks it’s just a black box. A black box is hard to understand and feel comfortable with.”

The solution requires breaking that black box apart. “The customer, perhaps, has some activities to do, but certainly they’re understanding what is happening with AI, can interact with it, and feel that they understand how the artificial intelligence is making decisions and taking actions,” Paul said.

Simplify first, then automate

Paul’s formative experience with automation came not from the boardroom or consulting work, but from working hands-on with production.

“I got my training building automation and production lines. And it was very, very obvious there where you’re trying to build a robot to manage production, that the first step is simplification,” Paul said. “If you try to copy what humans were doing, it gets horrendously complicated and expensive.”

That principle applies directly to how founders should think about artificial intelligence (AI) and automation. The instinct is to examine existing processes and ask how AI can automate them. Paul argues that’s backward.

“If you’re looking at how AI should do something, don’t just think about how AI can automate what’s there. You have to make the effort. You have to simplify prior to thinking what AI can do,” Paul said. “That, I think, is the fundamental way that you enable AI success over time. Where something’s excessively complicated, don’t try to automate it until you can work it through enough that you understand how to simplify it.”

Paul’s success with Zuora demonstrates this approach. “When I reimplemented the quote-to-cash process at Zuora, we spent all the time simplifying the business process before implementing the new system,” Paul said. “What we found was that there were just historic methods of operating which required human intervention, decision-making, and collation of information prior to the next step. That just wasn’t easy to automate and scale.”

The team had to eliminate those intervention points before automation became possible. “We had to go back and simplify those steps out of the process, standardize our billing approach so that it was easier to automate,” Paul said. “And then we significantly improved the productivity of the entire quote-to-cash business team.”

Technical debt that makes companies untouchable

When Paul evaluates startups for acquisition readiness, he focuses on two areas that determine whether a company becomes an attractive target or gets passed over entirely.

“One is the architecture of the product itself. You need to be able to see an architecture that is scalable, and easy to maintain and grow,” Paul said. “If the design of the product itself hasn’t really been thought through, it can block your ability to be purchased because most purchasers are looking for a significant increase in scale when they acquire a company.”

The second area involves business processes. “If you look at your ability to quote, invoice, bill, and operate the back end of your organization, you need to have repeatable and simplified processes,” Paul said. “They don’t need to be highly automated. I think acquirers may move you into their own systems landscape, and they have tools already. But you need to have a good understanding of how that process works, and it is simple enough that they can be quickly moved into new systems.”

Usage-based billing represents one concrete example. “Fully automating that collections process was key to enabling scalability in billings,” Paul said. “It previously was not a completely automated process to know how much we’re going to charge, how much they have used. To build that usage capture process in a way that enabled it to be fully automated.”

Beyond technical and operational readiness, contractual commitments can kill deals entirely. “If you have a 10-year contract with a licensed product that the purchaser doesn’t want to use, that’s 10 years of wasted expenditure that you’re going to have to spend, or you’re going to have to buy yourself out of that at a significant cost,” Paul said. “Those kinds of commitments that you cannot undo will significantly reduce the price, if not break the deal completely.”

For carve-outs, the question becomes whether a company can operate independently. “Can a company operate in the future without all of the systems and processes that the former owners had?” Paul said. “You may have to invest in some solutions so that they’re in a standalone mode, and it’s much more straightforward to carve them out than they’re part of this big integrated landscape.”

Delegate early or hold the company back

Another challenge Paul sees consistently among technical founders centers on control.

“Many founders are reluctant to let go of everything in the company. They work crazy hours, and yet they’re holding their company back,” Paul said. “They’re being ineffective because they cannot focus on so many different things.”

The solution requires founders to identify people with complementary skillsets who they can trust with major responsibilities. “You often see founders less experienced at hiring and managing large teams, hiring people that are very much like themselves. And that’s a big risk because you all think the same. You’ll make the same mistakes,” Paul said. “You have to hire strong strategic partners in your organization to feel comfortable delegating to them, and help them take over that responsibility.”

Infrastructure represents one of the earliest and most critical areas where founders need to let go. “Founders should be focusing on the customer and their product and how to go to market,” Paul said. “Putting their time and investment into building their own infrastructure is probably the wrong thing.”

The answer isn’t to skip infrastructure investment entirely, however. “Bring in an IT manager, somebody to help you own and manage that,” Paul said. “You want somebody that’s really partnering with the business teams and producing solutions that are probably one step ahead.”

That final point matters because founders tend to over-invest when they do bring in infrastructure support. “If you’re a $10 million revenue company, you don’t need a $20 billion solution. You need a solution that maybe can handle $100 million,” Paul said. “You just invest enough to keep you going for the next few years. That is the most sensible way of going forward, where you’re taking incremental steps and building up the capabilities of the systems to operate the company, but not going crazy and investing in a massive Salesforce system when really all you need is a simple CRM solution.”

Listen to customers, not just your vision

Paul traces one of his most successful innovations back to a single customer conversation. At DaimlerChrysler, the team was trying to sell to the Port of Los Angeles.

“They had a business model, and they had ideas. And we spent time listening, understanding, and then creating a solution that would enable their success,” Paul said. That customer-driven approach led to a financial services product that created a $1 billion loan business.

The success shaped how Paul advises founders. “An important lesson there is that founders don’t fixate on ‘This was my idea and I’m going to make it happen,'” he said. “They need to be flexible, and listen and engage strongly with their customers, because they may be a little bit off in their targeting. By listening to the customer, they can find a product that’s going to make $1 billion in revenue instead of a product that maybe can only make $20 million in revenue.”

That flexibility becomes even more critical as startups introduce new solutions. “I’d actually focus on being good at supporting customers through change,” Paul said. “They’re bringing an innovative new solution to the customer. The customer is going to go through a change cycle to embrace it and make it successful.”

Maintaining that customer focus requires operational discipline as companies scale. Paul recommends establishing regular review cadences across different aspects of the business. “Every month, you look at your accounts, you look at the financials. Every quarter, you look at your customer profiles, your fit, your churn,” he said. “You’ve got to build a cadence around aspects of your business so that it’s not 9 months down the road and you suddenly never thought about competitors because you got so distracted.”

post img blur
Build to Sell: How Paul Heard Prepares Startups for Billion-Dollar Acquisitions
scroll img

Paul Heard has spent decades transforming companies worth billions and orchestrating M&A transactions totaling more than $10 billion. He reduced churn at Mimecast by implementing customer success functions, delivered HP’s separation into two companies in 9 months, and reimagined business processes at Zuora to enable scalability. He innovated financial services products at DaimlerChrysler to create a $1 billion loan business and managed operations across Mars Inc., Micro Focus, and numerous other enterprises. Now, through Oxonian Technology Partners, Paul leans on that experience to advise early-stage software as a service (SaaS) founders on translating technical vision into sustainable revenue. 

In that work, Paul often sees the same patterns: Technical founders build sophisticated products with impressive capabilities, but often struggle to articulate how purchasing companies will derive value. That lies in contrast to enterprise executives who start with the problem and its revenue impact, then work backwards to solutions. Paul’s insights, drawn from manufacturing floors to boardrooms, reveal how founders can build companies that scale profitably and sell strategically. He recently shared his wisdom with us on a range of topics, including what and how to automate, avoiding technical debt, and why founders must learn to delegate early.

Solve problems, not features

In Paul’s experience, technical founders need to reconsider where they allocate their attention.

“Many founders focus on the product and the capabilities, and less on the problem,” Paul said. “It’s really important that you understand exactly which problem you are addressing and how that problem itself is impacting revenue or benefit for the company.”

The distinction matters because enterprise buyers don’t buy technology for its sophistication; they buy solutions to problems that cost them money or prevent them from making money.

“I’ve had founders present features and functions and amazing capabilities to me, but they have no idea how the purchasing company will actually find value from using it,” Paul said. 

This gap separates technical founders from enterprise executives. Executives begin every evaluation with a clear understanding of the business problem: How much does this problem cost us? How much could we gain by solving it? Only then do they assess potential solutions. 

“To get off the ground and get revenue, the only thing that matters is product features, the ability to get customers and to make those customers happy,” Paul said.

Automate repeatability, not risk

Paul’s framework for deciding what to automate comes from a simple two-part test: Risk and repeatability. Both criteria must align before automation makes sense.

“You would not want to find a role that is extremely high risk being automated in initial phases,” Paul said. “Equally, if the role has no repeatability, it makes it extremely difficult to automate.”

The examples Paul uses illustrate the extremes. Customer escalations sit in the high-risk category. “If the customer is already escalating, then you do not want to make a mistake. You want the best foot forward,” he said. Password resets, in contrast, offer high repeatability with minimal risk. “Definitely should automate,” Paul said.

Where founders should invest early differs from where they typically focus their automation efforts. Paul encourages startups to automate customer communication as quickly as possible.

“A startup needs to get visible. It needs to build a brand presence. It needs to get feedback from the customers,” Paul said. “The ability to automate that interaction gives you a much larger user base, more insights, and a better tuning of the product.”

Where founders over-invest surprises many: Automating the product itself. “They really try to make the product extremely slick and sophisticated. And sometimes the customer actually wants to understand what’s going on,” Paul said. “You can over-automate so the customer thinks it’s just a black box. A black box is hard to understand and feel comfortable with.”

The solution requires breaking that black box apart. “The customer, perhaps, has some activities to do, but certainly they’re understanding what is happening with AI, can interact with it, and feel that they understand how the artificial intelligence is making decisions and taking actions,” Paul said.

Simplify first, then automate

Paul’s formative experience with automation came not from the boardroom or consulting work, but from working hands-on with production.

“I got my training building automation and production lines. And it was very, very obvious there where you’re trying to build a robot to manage production, that the first step is simplification,” Paul said. “If you try to copy what humans were doing, it gets horrendously complicated and expensive.”

That principle applies directly to how founders should think about artificial intelligence (AI) and automation. The instinct is to examine existing processes and ask how AI can automate them. Paul argues that’s backward.

“If you’re looking at how AI should do something, don’t just think about how AI can automate what’s there. You have to make the effort. You have to simplify prior to thinking what AI can do,” Paul said. “That, I think, is the fundamental way that you enable AI success over time. Where something’s excessively complicated, don’t try to automate it until you can work it through enough that you understand how to simplify it.”

Paul’s success with Zuora demonstrates this approach. “When I reimplemented the quote-to-cash process at Zuora, we spent all the time simplifying the business process before implementing the new system,” Paul said. “What we found was that there were just historic methods of operating which required human intervention, decision-making, and collation of information prior to the next step. That just wasn’t easy to automate and scale.”

The team had to eliminate those intervention points before automation became possible. “We had to go back and simplify those steps out of the process, standardize our billing approach so that it was easier to automate,” Paul said. “And then we significantly improved the productivity of the entire quote-to-cash business team.”

Technical debt that makes companies untouchable

When Paul evaluates startups for acquisition readiness, he focuses on two areas that determine whether a company becomes an attractive target or gets passed over entirely.

“One is the architecture of the product itself. You need to be able to see an architecture that is scalable, and easy to maintain and grow,” Paul said. “If the design of the product itself hasn’t really been thought through, it can block your ability to be purchased because most purchasers are looking for a significant increase in scale when they acquire a company.”

The second area involves business processes. “If you look at your ability to quote, invoice, bill, and operate the back end of your organization, you need to have repeatable and simplified processes,” Paul said. “They don’t need to be highly automated. I think acquirers may move you into their own systems landscape, and they have tools already. But you need to have a good understanding of how that process works, and it is simple enough that they can be quickly moved into new systems.”

Usage-based billing represents one concrete example. “Fully automating that collections process was key to enabling scalability in billings,” Paul said. “It previously was not a completely automated process to know how much we’re going to charge, how much they have used. To build that usage capture process in a way that enabled it to be fully automated.”

Beyond technical and operational readiness, contractual commitments can kill deals entirely. “If you have a 10-year contract with a licensed product that the purchaser doesn’t want to use, that’s 10 years of wasted expenditure that you’re going to have to spend, or you’re going to have to buy yourself out of that at a significant cost,” Paul said. “Those kinds of commitments that you cannot undo will significantly reduce the price, if not break the deal completely.”

For carve-outs, the question becomes whether a company can operate independently. “Can a company operate in the future without all of the systems and processes that the former owners had?” Paul said. “You may have to invest in some solutions so that they’re in a standalone mode, and it’s much more straightforward to carve them out than they’re part of this big integrated landscape.”

Delegate early or hold the company back

Another challenge Paul sees consistently among technical founders centers on control.

“Many founders are reluctant to let go of everything in the company. They work crazy hours, and yet they’re holding their company back,” Paul said. “They’re being ineffective because they cannot focus on so many different things.”

The solution requires founders to identify people with complementary skillsets who they can trust with major responsibilities. “You often see founders less experienced at hiring and managing large teams, hiring people that are very much like themselves. And that’s a big risk because you all think the same. You’ll make the same mistakes,” Paul said. “You have to hire strong strategic partners in your organization to feel comfortable delegating to them, and help them take over that responsibility.”

Infrastructure represents one of the earliest and most critical areas where founders need to let go. “Founders should be focusing on the customer and their product and how to go to market,” Paul said. “Putting their time and investment into building their own infrastructure is probably the wrong thing.”

The answer isn’t to skip infrastructure investment entirely, however. “Bring in an IT manager, somebody to help you own and manage that,” Paul said. “You want somebody that’s really partnering with the business teams and producing solutions that are probably one step ahead.”

That final point matters because founders tend to over-invest when they do bring in infrastructure support. “If you’re a $10 million revenue company, you don’t need a $20 billion solution. You need a solution that maybe can handle $100 million,” Paul said. “You just invest enough to keep you going for the next few years. That is the most sensible way of going forward, where you’re taking incremental steps and building up the capabilities of the systems to operate the company, but not going crazy and investing in a massive Salesforce system when really all you need is a simple CRM solution.”

Listen to customers, not just your vision

Paul traces one of his most successful innovations back to a single customer conversation. At DaimlerChrysler, the team was trying to sell to the Port of Los Angeles.

“They had a business model, and they had ideas. And we spent time listening, understanding, and then creating a solution that would enable their success,” Paul said. That customer-driven approach led to a financial services product that created a $1 billion loan business.

The success shaped how Paul advises founders. “An important lesson there is that founders don’t fixate on ‘This was my idea and I’m going to make it happen,'” he said. “They need to be flexible, and listen and engage strongly with their customers, because they may be a little bit off in their targeting. By listening to the customer, they can find a product that’s going to make $1 billion in revenue instead of a product that maybe can only make $20 million in revenue.”

That flexibility becomes even more critical as startups introduce new solutions. “I’d actually focus on being good at supporting customers through change,” Paul said. “They’re bringing an innovative new solution to the customer. The customer is going to go through a change cycle to embrace it and make it successful.”

Maintaining that customer focus requires operational discipline as companies scale. Paul recommends establishing regular review cadences across different aspects of the business. “Every month, you look at your accounts, you look at the financials. Every quarter, you look at your customer profiles, your fit, your churn,” he said. “You’ve got to build a cadence around aspects of your business so that it’s not 9 months down the road and you suddenly never thought about competitors because you got so distracted.”