I was talking to a prospect this morning who was enthusiastically telling me about his software. It sounded good. Hes a great salesman and I love to dig into software, but what he was telling me wasnt that helpful. Only in rare instances do we need or want to know much about the inner working and hidden mechanisms of the software our clients sell. We use their literature and web pages to describe it and we and the buyers use indirect measurements like revenue and profit to deduce whether the software does what its supposed to do and has market acceptance. The product details are relevant later in the process, often after you have the framework off a deal. But, like everything else in the M&A process, bad news should be disclosed before you have an offer on the table. If you wait for the buyers due diligence youll most likely have to renegotiate the price youve agreed on and the result wont be in your favor. Bad news is in the eye of the beholder, but obvious examples include missing source code and clouded ownership and I wont soon forget the meeting with six buyer representatives when it was announced that the key mid-tier code of a very complex vertical application was written in Pick basic. The meeting was adjourned early.