Why We Present

The hidden returns of preparing a formal presentation

Marshall McLuhan famously said decades ago that the medium is the message.[1] I found that true again in coaching the Data4Good team through a recent presentation. What struck me was not what we delivered to the audience, which was good. It was what the process of preparing to present delivered to us.

I have given a lot of presentations over the years and coached a lot of people through theirs. What I keep relearning is that the returns are not limited to the day you give it. Most of the value accrues before you step in front of the room.

Here are six things I observed from watching the team prepare.

1.  A Hard Deadline Forces Things Done

There’s a management truism I’ve always believed: work expands to fill the time available, and important-but-not-urgent work never gets done without a forcing function. A presentation deadline is one of the best I know.[2]

In preparing for this one, the deadline moved things off the backlog that had been sitting there for weeks. Code got deployed to staging. Repositories got organized. Pages went live. Multiple items were explicitly deferred until after the presentation, which tells you exactly where all the urgency was going. The presentation did not just showcase the work. It got the work done.

2.  Preparation Is a Quality Review in Disguise

You don’t really know what you’ve built until you try to explain it to someone else. I’ve seen this enough times that it no longer surprises me, but it still impresses me.

In rehearsal the team caught things they had not noticed from the inside. Demos that were missing some features. Web pages that were not up-to-date. Technical details that made sense to the builders but would land as noise for a practitioner audience. I found myself asking on nearly every slide: what is the one sentence a listener should take away? That question sounds like presentation coaching. It is. But it is also a product question. If you cannot answer it for a slide, you probably cannot answer it for the feature.

Rehearsals feel like preparation for the presentation. They are actually a quality review of the work.

3.  Real Audiences Build Real Skills

We gave every team member a speaking role, each presenting their own section. The intent was deliberate: everyone having a speaking role is representative of how we work in our team.

For students and early-career volunteers, the difference between presenting in a seminar and presenting to a professional audience is higher stakes. A working group of experienced practitioners is not an audience of peers. They have opinions, real-world experience, and they ask hard questions. You do not build that skill by preparing to present. You build it by presenting.

4.  Each Deck Builds the Library

Presentations are not one-and-done deliverables. They are assets. I have been saying this to the team for a while, and I think it has proven true to us anew.

Each new deck links back to prior ones. Slides get borrowed, refined, and reused. The diagrams, the who-we-are framing, the product overviews accumulate into what I think of as a slide library: a growing inventory of well-crafted explanations, demos, and frameworks that any team member can pull from. The work of one presentation makes the next one cheaper to build and better to deliver. This mirrors our building blocks approach to systems that I wrote about earlier.[3]

5.  Outsiders See What Insiders Miss

When preparing to present one product we are working on, we ran into a problem. The pitch we had been using did not land with our host. As we pressed on why, we realized the framing was too narrow. It described one application of the tool but missed what the tool actually does at a more general level.

We got there by having to explain the product to people who were not in the room when it was built. Outsiders ask the questions insiders miss. The team came away with a clearer understanding of their own work than they had going in.

6.  The Audience Becomes an Advisory Board

A small volunteer team rarely has a formal advisory board, a product council, or a user research budget. What it does have, every time it presents to a group of experienced practitioners, is a room full of people with ideas and opinions.

We designed the Q&A and brainstorming sections specifically to surface that feedback, priming the audience with a question before opening the floor, not to plant an answer but to plant a direction. In one session we got more input on our product direction than from months of internal discussion. A formal presentation, structured well, is a feedback mechanism. The audience does not know it is serving as an advisory board. But it is.

The Preparation Is the Message

McLuhan’s insight was that the form of communication shapes meaning as much as the content. The same is true here. The act of preparing a formal presentation shapes the team, the work, and the thinking, independent of how the presentation itself goes. The deadline, the rehearsal, the library-building, the product insight, the feedback loop: all of it happens before anyone enters the room.

If your team is doing good things and not presenting them formally, you are leaving most of the returns on the table.

Have you found this in your own team? I'd be curious to hear.

Full disclosure: I used Claude to help draft this post, drawing from team meeting transcripts and my own notes. I provided the outline and edited the final copy. Another collaborative use of AI.

The postings on this site are my own and don’t necessarily represent positions, strategies or opinions of any of the organizations with which I am associated.

---

[1] Marshall McLuhan, “Understanding Media: The Extensions of Man,” Kindle Edition, 2013, 1964, https://www.amazon.com/Understanding-Media-Extensions-Marshall-McLuhan-ebook/dp/B00DIEZI7U/

[2] Christopher Cox has written about this in "The Deadline Effect: How to Work Like It's the Last Minute—Before the Last Minute", Kindle, 2022, https://www.amazon.com/Deadline-Effect-Work-Minute-Before-Minute-ebook/dp/B08LDVGYDD/

[3] “The Lego Approach,”  Dec. 10, 2025, https://eghapp.blogspot.com/2025/12/building-blocks-lego-approach.html

Click Bloat

A 50-year-old principle from Bell Labs, and what your iPhone keeps getting wrong

At one of his seminars, I heard Brian Kernighan of Bell Labs fame say, that the purpose of computing is the conservation of typing.[1] I took that to heart during my development days, and it shapes how I think about technology to this day.

Which makes what I’m seeing now all the more frustrating. We’ve moved from keyboards to touchscreens, from typing to clicking, but the principle should have traveled with us. Conservation of typing should have become conservation of clicks. Instead, with every new iOS release, it seems to take more clicks to do what used to take fewer. I’ve started calling it click bloat: the quiet accumulation of extra steps that creeps into our devices with each update, usually unannounced and rarely acknowledged.

Let me give you three examples from my own recent experience.

Reading email on my iPad.

In the old layout, a simple < icon let me back out of a message in one click. Now there’s a three-part icon. You click to open it. You click the X, not the <, to close the email. Two clicks instead of one. Is there a setting to restore the old layout? I looked. There isn’t. Classic click bloat.

Picking up the NYT puzzle mid-game.

I usually start the daily crossword on my iPhone and finish it on my iPad, or vice versa. The app syncs well enough, at least it looks that way. Here’s my five-click adventure to simply resume where I left off: open the game board (1), select “Resume” (2), only to find a blank board, none of my answers in sight. So, I close the game (3), reopen it (4), and select “Resume” again (5). This time, mercifully, the words have synced. Five clicks to get back to where I already was. I suppose I should be grateful it didn’t ask me to upgrade my account!

Hiding options as a method of promoting new ones.

I explored this one at length in my last post, and it still bothers me. Here’s the pattern: a new release arrives, and somewhere in the shuffle, a button you’ve clicked a thousand times has quietly moved, or vanished entirely, to make visual room for something the designers want you to notice. Your muscle memory is now wrong. You go hunting. You feel, briefly, like a confused newcomer on your own device. The feature isn’t gone, of course. It’s just been demoted, tucked behind an extra click or two. Which means, yes, more click bloat, dressed up as innovation.

I genuinely understand the pressure to ship new features with most releases. But adding features while quietly inflating the click count on things people already knew how to do isn’t progress, it’s a trade-off the user never agreed to. Are the UX designers even tracking this? Are they measuring click counts against previous versions? Somewhere along the way, the user got left out of that conversation.

Kernighan’s principle was elegant precisely because it was measurable. How many keystrokes did this save? We should be asking the same question about every new release: how many clicks did this add, let alone save? If the answer is more than zero, someone owes the user an explanation. Click Bloat is real, and it’s time we started calling it out by name.

So what can you do about it?

Start by leaving feedback: most apps have a built-in mechanism for it, usually tucked somewhere in Settings. If the bloat is coming from your device’s OS, find your way to Apple’s or Google’s feedback channels. And if the culprit is an Amazon app? Well, good luck. I mean that sincerely. Navigating their customer feedback labyrinth may itself be the finest example of Click Bloat you’ll ever encounter.

And then there’s the brave new world of AI assistants. Try telling ChatGPT that you’d like to pass some feedback along to the development team. It won’t. Instead, you’ll click the thumbs down icon (intuitive, right?) and then manually copy and paste the relevant portions of your conversation into a feedback form. In 2026, that’s how you reach the people building the future. The irony writes itself.

But try anyway, all of it, because the only way UX designers hear that this matters is if enough of us say so, loudly and repeatedly.

---

[1]The quote is commonly attributed to Bell Labs folklore, possibly originating with Rob Pike. It echoes Richard Hamming’s earlier remark that “the purpose of computing is insight, not numbers,” documented in Numerical Methods for Scientists and Engineers (1962).

Full disclosure: I used Claude to help draft this post, drawing from my notes. I edited the final copy you are reading. Another collaborative use of AI.

The postings on this site are my own and don't necessarily represent positions, strategies or opinions of any of the organizations with which I am associated.