3 ms·
When pitching a new product, I detailed the observations, product hypotheses, experimental design, results and conclusion in that order. The discussion focused
by prawks 14y ago
When pitching a new product, I detailed the observations, product hypotheses, experimental design, results and conclusion in that order. The discussion focused mainly on the experimental design and the biases in the results and the implications for the conclusion.
I've had trouble putting into words how different mis-communications of mine have occurred, and this sums it up rather nicely. I think many developers I know do this: we're so excited about all of the sound reasoning we placed around our conclusions and the processes that got us there that the actual conclusion is an afterthought tacked onto the end (oddly enough, the conclusion of the communication).
But that's not why you're telling someone something. You're telling them so that they take away what you put all of that work into arriving at, not how you did it (unless they want details later, of course).
- ttunguz 14y agoYep, exactly. This was my mistake.
- ZoFreX 14y agoSome similar advice I heard recently (I think possibly in another HN discussion thread) was to not be scared of "spoilers" when communicating. I have a tendency to try to make my presentations a nice linear development, like a story, which naturally dissuades you from revealing the "ending" before you reach it. However, it's a lot easier to keep people's attention if they know where your story is heading, it gives them the answer to the ever-present implicit question: why do I care?
- ChuckMcM 14y agoThis is the part the I had to break myself. I have always enjoyed telling stories, and they work great in a causal setting but they are not useful (except as illustration) in some contexts. I did a power point once which was essentially the inverted pyramid in a deck, the first slide was the conclusion, the next two where the problem statement and the conclusion, the next 5 were the problem statement, some constraints on the shape of the solution and the conclusion. Down to about a 22 point presentation on the problem, the constraints, the different paths tried, the lessons learned and fed back into the process, and then the solution. It was a bit gimmicky but some folks really liked it as they felt they always knew what I was getting at.
- groby_b 14y agoIt's fascinating to me that our profession is so hung up on the format of the scientific paper. A presentation rarely is that. Instead, you're telling a story. And part of _any_ good story is a "hook", something that reels the audience in at the first sentence and has them (hopefully) wanting more. My recommendation to _anybody_ giving presentations is, look at storytelling practices. Make it a fun experience, not a dry list of fact, or a chain of evidence. Reserve that for the actual paper ;)