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

I agree DW. Like coaching recreational hockey in town. Kid's age range from 6 to 12. Some are like newborn fawns just learning to walk others are motoring like momma. Got to have something in the program that appeals to all of them, just not at the same time:)

Can't please them all. Some like stories and background, motivation and history. Others, mostly the managerial types, only care about the bottom line - they just want an executive summary with the bottom-line up-front.

You'll just have to imagine which audience you want to read your review and write accordingly. I like to imagine that I'm writing for a technical audience that is savvy enough to skip the parts they don't care about, and facilitate that with proper chapter headings/subheadings. I imagine that they care about the methodology, as that influences the result, as well as the results themselves. I imagine they also would want that with a side of opinion and interpretation. I don't write targeting a general "high-school" audience as some newspapers would, as I feel that to be too restrictive, even though it may improve accessibility. There are plenty of spaces where marketing PR material is spewed out verbatim - that has been minced and shaped for general consumption and I (personally) feel we don't need any more of that.

If concerned, perhaps stratify your review for an overview up-front (an executive summary) and detailed blog-post click-throughs for those who want more meat.

But yes, the process is perhaps not all that interesting - but it can also depend on how you present it. Some of the best talks out there talk about the process from the perspective of reflecting on their learnings and making it humourous. It's probably no fun to go through each iteration procedurally without having a "point" to convey about why you even mentioned it.

I suppose in the case you were talking about - perhaps you should have known more about your audience before you assembled it, had the chance to practice it with your superiors for their input prior to the event and kept some of the detail in reserve slides to answer questions from the audience if they were actually interested. Presentations and videos may be similar - you're there to convey information, but you have to be engaging and entertaining for it to work. This is part of why I usually don't do video. Written reviews, however, may be more relaxed in their requirements.

- Gough

I would be careful to lump Project posts and Road Tests into the same type of content with the same intended audience.

In a Road Test, I actually want all of the mundane details about how the testing went. (I could, however, do without how the thing is packaged or what color the shipping label was.) Because I'm interested in seeing from the reviewer's perspective why they did what they did and seeing the results, as context to why they are saying what they said.

However, I think Road Test is a special case, and as such, it should be treated as so.

Now, when it comes to Projects, I want to be careful to differentiate between in-progress updates and a final presentation. Because in-progress updates are just that: here is everything that is going on. I'm sure that I, like some people, use it as a form of a notebook. The nice thing about this kind of media is that you, as a reader, can choose to follow along or not.

That said, as a final "here is my project," I totally agree. Think from the perspective of: "if I was reading about this project, what would I need to know about?" and NOT, here is every detailed decision that I painstakingly made. (by the way, if you note the progress of the project as a separate media type, then you don't need to do this!)

The problem is the vast majority of "unboxing" content is not necessary. Unless something is packed extrodinarly good or exceptionally bad, you do not need to see how a thing was put into a box!

But, because so many people record this step as part of their review process, they feel the need to include it.

Most of the time, it is unnecessary. Which has the unfortunate result that I (and I suspect others) skip it.

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.

This was several (or more) years ago, actually my boss was absolutely correct and the team appreciated the honesty. This was a manager we really trusted, he had almost zero turnover in his staff. The entire staff was very experienced and we did the presentation every 2 weeks. There were influences that caused the presentation to go off track a bit, but a little coaching put it right back on track. After that feedback, we all stepped up our game and actually joked about it every 2 weeks.  

To do good presentations you have to know your audience and you have to know what message you want them to hear.

Even if you do not know your audience, you can still focus on the message you want to deliver.

You also need to understand that not everyone will understand the message, but you usually do not have control over who will see it.

there are many aspects. I went to a company funded (expensive!) training on how to write, prepare, run presentations.
The kind of training where they give you a (not easy) topic to present. Then film you when you present to a critical audience, then review your performance based on the film.
Whenever I use the learnings in the same company, I get flack.

Learning: do not put details in your presentation. It's not a document to record details. It's a story. Focus on the story.

My manager: you do a great job overall, always beyond expectations. Except your presentations and slides. They are awful.

<shrug emoji here>

It depends upon the briefing.

On some I had issues with too much detail, but on others it was for too little.

That takes us back to understanding your audience.

I don't get briefings. That's the kind of company I work for. I have to do my own briefing.
(edit: not that they don't care. It's a skill I have to have)