When publishing blog or Road Test report, do you know your audience ?

Interesting topic!

Some stuff is very esoteric, and I might only write it for anyone who happens to google for that specific problem, i.e. not for a wide audience.

However I'm most comfortable writing (and reading) at a white-paper sort of level, which assumes some knowledge, but not a lot, but does assume the reader has a real particular problem, and I'm going to address a way to solve it, in enough detail for the reader to positively move forward. I hate it when a blog/document assumes too much knowledge, but also on the other hand it's annoying reading stuff that teaches people to suck eggs. I also hate traditional "short blogs" that often paid PR firms write... useless snippets of information, heavily weighted toward an org, or sensationalized. It doesn't feel honest, and audiences will know that they are being fed a big fat advert by someone who possibly doesn't have any real interest in the subject.

To convey information to readers, when done right I think it's possible to place enough bit of info and hyperlinks/images so that it's not dumbed-down and yet newcomers and experts both are provided with ways to dig deeper, and at the end, if it were me, I'd want the reader to feel they have the knowledge to move forward to solving their problem.
There's no shame in writing simple-to-read stuff, that's not the same as dumbing down.

As Jan says, you can't please everyone. At one workplace, we would always ignore the single worst score from presentations, because there's always going to be an outlier grumpy person hehe (or even a competitor who will deliberately score you low). Similarly, there will always be a few outlier people whose technical problems unfortunately might not be well addressed in your blog/review.

For sure sometimes one needs to write at an academic paper level, to get through some topics to solve particular problems. Some technical stuff is complex, there's no doubt. But people also like rules of thumb and diagrams to get them through problems too, without needing complexity always.
It should be noted, not everyone is familiar with reading academic papers, they can often seem alien, so again it depends on the audience. So personally I would try to avoid that format unless absolutely essential.

Another idea is to write a "For further information" type comment, for those who want to read more, or to organize content so that people can easily skip stuff without becoming lost. I really wish there was an inset-type style in blog posts, for mentioning either important key stuff, or for informational content. Some people write stuff in a box or intro that provides a kind of abstract for instance. It would be good if there was a style/format for such stuff in the editor.

Deciding which approach to select does need some thought of the audience, and their problems and their experience. Not possible to always get it right.

Regarding the points you mention, it's personal taste, I personally don't show all iterations of a project in blog posts. If there's a problem finding content, I might mention it very briefly (i.e. a sentence), but will provide the resources/links so that the reader doesn't go through what I did. In one RoadTest, there was a bug, and none of the reviewers shared the solution (even though they had found it). It was disappointing.

For presentations in front of customers, I would _always_ want to know my audience (ideally down to the name and job title of every single person), and personalize the content to suit them.
It's disrespectful to present something generic or irrelevant, when they have made the time to listen, and I had every opportunity to talk to whoever knows them (e.g. account people, or whoever is responsible for that region etc) if I make the effort, so it's the least I can do. (Some may ask what do you do when it's not you who has prepared the presentation! - good question, and there are ways to tackle this).

Part of presentations would include predicting what the customer could benefit from knowing for their future, even if it isn't an immediate need. In other words, customers love hearing about trends from an outside perspective.
Customers are human too : ) and many will be just as passionate about technology as the manufacturers of products, so if you recognize that, then you can really connect by talking about the challenges or subtle features etc., since they will get a kick out of it too.

Another point is that you should just keep watching, are they yawning etc : ) and if so then it's a huge sign to change the pace, or react by skipping irrelevant material in the slides. Also, get feedback regularly throughout the presentation : ) it shouldn't be one-way. It can be good to let them know what's going on inside their cool products they are planning to buy or have bought. No-one wants to feel the product they bought is a black box or a lemon. It's awesome when they feel just as proud owning and using the product, as the developers feel creating it (and it works the other way too, i.e. don't forget to give the developers feedback about how their product/features are viewed and used, since you're a link between them and the customer.

Interesting topic!

Some stuff is very esoteric, and I might only write it for anyone who happens to google for that specific problem, i.e. not for a wide audience.

However I'm most comfortable writing (and reading) at a white-paper sort of level, which assumes some knowledge, but not a lot, but does assume the reader has a real particular problem, and I'm going to address a way to solve it, in enough detail for the reader to positively move forward. I hate it when a blog/document assumes too much knowledge, but also on the other hand it's annoying reading stuff that teaches people to suck eggs. I also hate traditional "short blogs" that often paid PR firms write... useless snippets of information, heavily weighted toward an org, or sensationalized. It doesn't feel honest, and audiences will know that they are being fed a big fat advert by someone who possibly doesn't have any real interest in the subject.

To convey information to readers, when done right I think it's possible to place enough bit of info and hyperlinks/images so that it's not dumbed-down and yet newcomers and experts both are provided with ways to dig deeper, and at the end, if it were me, I'd want the reader to feel they have the knowledge to move forward to solving their problem.
There's no shame in writing simple-to-read stuff, that's not the same as dumbing down.

As Jan says, you can't please everyone. At one workplace, we would always ignore the single worst score from presentations, because there's always going to be an outlier grumpy person hehe (or even a competitor who will deliberately score you low). Similarly, there will always be a few outlier people whose technical problems unfortunately might not be well addressed in your blog/review.

For sure sometimes one needs to write at an academic paper level, to get through some topics to solve particular problems. Some technical stuff is complex, there's no doubt. But people also like rules of thumb and diagrams to get them through problems too, without needing complexity always.
It should be noted, not everyone is familiar with reading academic papers, they can often seem alien, so again it depends on the audience. So personally I would try to avoid that format unless absolutely essential.

Another idea is to write a "For further information" type comment, for those who want to read more, or to organize content so that people can easily skip stuff without becoming lost. I really wish there was an inset-type style in blog posts, for mentioning either important key stuff, or for informational content. Some people write stuff in a box or intro that provides a kind of abstract for instance. It would be good if there was a style/format for such stuff in the editor.

Deciding which approach to select does need some thought of the audience, and their problems and their experience. Not possible to always get it right.

Regarding the points you mention, it's personal taste, I personally don't show all iterations of a project in blog posts. If there's a problem finding content, I might mention it very briefly (i.e. a sentence), but will provide the resources/links so that the reader doesn't go through what I did. In one RoadTest, there was a bug, and none of the reviewers shared the solution (even though they had found it). It was disappointing.

For presentations in front of customers, I would _always_ want to know my audience (ideally down to the name and job title of every single person), and personalize the content to suit them.
It's disrespectful to present something generic or irrelevant, when they have made the time to listen, and I had every opportunity to talk to whoever knows them (e.g. account people, or whoever is responsible for that region etc) if I make the effort, so it's the least I can do. (Some may ask what do you do when it's not you who has prepared the presentation! - good question, and there are ways to tackle this).

Part of presentations would include predicting what the customer could benefit from knowing for their future, even if it isn't an immediate need. In other words, customers love hearing about trends from an outside perspective.
Customers are human too : ) and many will be just as passionate about technology as the manufacturers of products, so if you recognize that, then you can really connect by talking about the challenges or subtle features etc., since they will get a kick out of it too.

Another point is that you should just keep watching, are they yawning etc : ) and if so then it's a huge sign to change the pace, or react by skipping irrelevant material in the slides. Also, get feedback regularly throughout the presentation : ) it shouldn't be one-way. It can be good to let them know what's going on inside their cool products they are planning to buy or have bought. No-one wants to feel the product they bought is a black box or a lemon. It's awesome when they feel just as proud owning and using the product, as the developers feel creating it (and it works the other way too, i.e. don't forget to give the developers feedback about how their product/features are viewed and used, since you're a link between them and the customer.