Preventing the same discussion from taking place again and again and again does help keep the lights on though, and putting things in writing helps with that.
As does having the original reasoning for why things were done the way they were three years ago, when there's a new feature request and nobody is left of the original team.
OP mentioned he's in a business owner role. He's probably talking to customers often, possibly scoping projects or features.
In these cases, having notes will prevent scope creep and will be necessary to have customers accept the work. Customers will forget what was discussed and what was agreed to. They will want to add that "one last thing" just when you're expecting to close the project.
Even in different roles (or internally), I think many would benefit from writing down meeting notes because it anchors the discussion and creates shared understanding. Voice only will cause many to forget specifics or move the goal.
I don't think OP is in favor of writing a book for every meeting. Having notes / documentation will make you more effective. It will also lower the frequency of you and the other party having different expectations. It's a good habit to have for these reasons and the many others outlined in this thread.
When I was a consultant/analyst, we had a few otherwise wonderful clients who were also masters of expanding the scope of projects if you let them. This, more than anything else, taught me the value of clearly documenting deliverables and milestones. That's not to say we couldn't make adjustments if needed but doing so needed to be done as a formal mutually agreed-to process.
Sorry no - I work on enterprise websites for a very big brand and the process is a key part of the product - liaising with European developers creative agencies in the UK / US and the brand and ourselves is a key part.
Unfortunately a lot of the big name consultancies and agencies are terrible at written communications and quite often farm out work to what appears to be interns with poor writing skills and very little knowledge of the web.
I got sent a scrappy unformatted PDF yesterday that if I had delivered that when I worked for British Telecom would have got my appraisal marked as needs improvement (the first step to a PIP)
> For most companies, the process is not the product.
Where do you think the product comes from? A bunch of people randomly doing whatever they want? The process absolutely impacts the product. Does SCM keep the lights on? It's the same thing, except for code.