Category Archives: Presentation

Preparing presentations, judging the audience, giving presentations, public speaking, etc

Brilliant Presentation on Identity 2.0

Dick Hardt at OSCON 2005

The material in the presentation is off-topic, but the presentation is so good that you just have to watch it. I found this when researching about openID (mine is – check out myOpenID to set up yours). Consider the open ID thing to be a tangent you might be interested in pursuing today, and will be interested in pursuing soon.

Regardless, you should watch this presentation. The delivery will knock your socks off. The topic is interesting, or perhaps not interesting at all – but delivered so well that you’ll be interested.

This is your third link to it. Last chance.

Project Dashboard Icons

turn signal traffic light

We create project dashboards all the time to show status, or to give upper management an update. Dashboards and scorecards are great for giving us a “quick view” into the health of a project – they give us a way to drill down. Many of us use the colors red / yellow / green, with a stoplight metaphor. The problem is that some of us are colorblind. Johanna Rothman gives us a GREAT tip. We give you a set of icons / images.

Dashboards and Scorecards

Without going into detail about the differences between the two, they have a common mission: a scannable view of the status of a project. Scannable often means images or colors too, at least in the dashboards we’ve seen (and made in the past). The traffic light is a common metaphor – green is good, yellow is ok but might be going bad, red is bad.

Then someone adds blue. Or orange for “bad, but not end of the world bad.” Sort of like “extra high priority” features.

Rothman On Traffic Lights

Some may use the traffic light model–red, yellow, and green–to denote the project’s state. This model shows today’s state, but it’s hard to see where the project is headed. I haven’t found the traffic light useful, due to the static nature of the assessment and the limit of three levels to denote project state. And unlike traffic lights that automatically change, projects don’t change unless the project manager and the team act to change them. Projects tend to continue in the direction the team is heading.

Sunny Skies or Storms?, Johanna Rothman

We agree, traffic lights are lame. And thanks to Johanna, we now have a much better metaphor.

Weather Reports

This is definitely Johanna’s idea – we’re not stealing it, we’re redistributing it. It goes in the “wish we’d thought of that” bucket. We’ll try and add a little value, though.

In short – weather reports work as a better metaphor both for (current) status, and forecasting. They also allow for more than 3 statuses without breaking the metaphor. Johanna throws up an example with six.

Six may be too many. Suddenly, your audience is tasked with mapping a fairly nuanced break-out against a common metaphor. We think four would be more effective.

weather forecast

We created these using free icons from Ganato, who asked only that they not be downloadable, except from them. Get them there if you want to use them, or search for others. Johanna also points us to a page with a zillion icons, all hot-linked from their respective owners. Don’t take them without permission – but definitely go there for inspiration if you want your own.

The goal is to have a natural and obvious progression of status.

Explaining The Meaning

We could propose definitions for each icon – in terms of what it represents for the project – but we won’t. At some level, the icons need to stand on their own, or they aren’t good icons. If your team needs an explanation, make sure you include it in the scorecard as a legend.


Another thing to keep in mind – the senior manager you’re communicating with has to juggle a lot of information about a lot of projects. And when you have problems, the questions they should ask are “when will it get better?” and “what can I do to help?”

weather forecast

This quick and simple presentation shows where the project was, is, and will be. It presents both position and velocity.


Thanks Johanna! Stealing this idea. We (all) owe you one.

Building the Case for Requirements Management Tools

Movie Projector

Marcus Ting-A-Kee has assembled a great presentation on the value to his company of requirements management tools. In addition to creating the presentation and sharing it with all of us, he shares the process of creating the presentation in several articles.

The Final Product

Marcus made his presentation available to us via his esnip account (v 1.2 is the one I reviewed). Even if you aren’t interested in the genesis of the presentation, you should get it and read it. And if you don’t care about pitching for requirements management tools, you want to get the presentation anyway – it is a fantastic real-world example of many of the Beyond Bullets and Presentation Zen techniques.

Marcus’ effective use of imagery is the reason we have images with our articles. So effective on his site that we couldn’t pass them up here. I’ve been learning from him ever since – and in the presentation – even more and better use. Images supplant text, instead of just augmenting it.

The Approach

Marcus does it exactly right – he develops an understanding of his audience, including their goals, needs, and backgrounds. Then he designs a presentation to show how their goals are addressed, in a language that is consistent with their backgrounds – he adapts to the context of the listener. Awesome. Then he iterates and builds out the presentation.

Targeting his communication for his audience makes more of a difference than anything. Funny how few people do it.

The Genesys

Check out Marcus’ work and progress via his articles:


Marcus creates better presentations than we do. Maybe next time we can get him to videotape it – he probably delivers them better too. Thanks for sharing this stuff with us!

Extra Features Cause $245,000 Loss

Internet Explorer dependency graph(complex IE dependency graph)

Robin Lowry has posted a story of a demo gone horribly wrong at The Product Management View. In the story, users end up confused by the myriad of features of the software – resulting in a $5,000 sale instead of a $250,000 sale.

The Quote

In ten minutes, the SE showed all of the specific capabilities the customer had identified. The SE then looked at his watch and noted that he fifty minutes left in the meeting.

He said, “Since we have some additional time, why don’t I show you some of the other capabilities our software offers?”

The Impact

“The users said the software looked too complex – they couldn’t visualize using the tool themselves,” responded the customer champion. “They got confused by all of the various functions and capabilities that were shown during the demo…”


Showing too much in this demo reduced the value of the sale from $250,000 annually to $5,000 annually – a negative conversion of $245,000 per year!

Their Conclusion

The SE (sales engineer) knew what the customer needed, and should have demoed only those features. The other features never should have been demoed. The additional demo contributed to what they call perceived complexity, causing the loss of significant sales.

Our Conclusion

While we agree completely about the demo, we suspect the features should never have been there in the first place.

Having too many features can create a barrier for new users (or potential customers) as this story shows. It also makes the software harder to use, causing reduced satisfaction and user adoption.

From our article, Goldilocks and The Three Products

suck threshold

… we see that too many features leads to unhappy users and reduced value. When the customer gets less value, we get less revenue.

Intro to Requirements Gathering – St. Edward’s University

St Edward's logo

Welcome Dr. Franke’s students in Analysis, Modeling and Design MCIS6310! Thanks again for inviting me to present to your class on requirements gathering and requirements management.

The presentation is available for download. You can get both the slides and the notes pages. The notes pages include additional content and links to articles for further reading on the individual topics.

For the rest of our readers – the presentation for the St. Edward’s class is primarily written for people with little exposure to formal requirements management processes. It does not go into the depth of most of our articles, and instead hopes to present a broad overview of what we do when managing and developing requirements.  The presentation is 34 pages (about 90 minutes speaking time)
If you’ve been reading Tyner Blain for the last few months, there is little new material. If you’re new to Tyner Blain, the presentation is worth a quick read. Although we didn’t record the presentation, the notes-pages will provide some additional context to the slides.

Targeted Communication – Three Tips

cliff notes

Most guides to writing an executive summary miss the key point: The job of the executive summary is to sell, not to describe.

This from Guy Kawasaki’s recent post, The Art of the Executive Summary. Guy’s article is structured towards pitching an idea to a potential investor. We’re going to apply the same rationale to the communication that is key to successful product development – communication from the team, to stakeholders and sponsors.

Two types of communication – tactical and strategic

For this post, we’ll assume that we are part of a team delivering a new software product for our company. We have users, marketing, product management, development, quality, and SMEs (subject matter experts). We are all working together to deliver great software. We communicate with each other as part of executing on our tasks. This is tactical execution.

horse with blinders

James Shore posted Two Kinds of Documentation last month, where he presents an Agile perspective on documentation. The two types of documentation he identifies are ‘get work done’ documentation and ‘enable future work’ documentation. The purpose of these documents (or more precisely, the communication they represent) is to help our team execute either now or in the future. Internal communication is tactical communication.

We also communicate with people outside of our team. We communicate to set expectations with customers, users, and clients.We communicate with sponsors, customers, and others who fund our software development. Without these channels of strategic communication, we won’t have a project, or worse, won’t have a customer when we’re done. External communication is strategic communication.

Tailoring strategic communication

Guy’s quote is very insightful – there is only one reason for presenting to the executive – to get funding. Why? Because the executive has only one reason for listening to us – to decide if we should get funding. All of our strategic communication should focus on one goal. – The goal of our audience.

Here are three tips on providing targeted communication to people external to the team.

    1. It’s the economy, stupid! When President Clinton ran for office the first time, this was one of his slogans. He capitalized on the fact that his opponent was busy talking about what his opponent thought was important. Then Governor Clinton talked about what his audience thought was important. This is the hardest thing to remember, especially when we’re passionate about what we’re creating. We need to run our communication through the “so what” filter. If it isn’t important to our audience, don’t make them listen to it (or read it).
    2. No habla Ingles. Once we identify what our audience cares about, we have to make sure that we can communicate that information in a language that they understand. In one of our earliest posts, Intimate Domains, we talk about how people are so rooted in their areas of expertise that they almost speak different languages. If we can’t modulate our signal to a band-passed frequency*, we might as well be speaking jargon gibberish.
    3. Brevity. Clear. Concise. Contextual.

    [Update 25 Apr 06]

    We have added a post, Targeted Communication – Status Reporting as a detailed example of targeted communication.
    – –

    *If we can’t get the message across in terms our listener understands,...

Top ten tips for giving a better presentation


[Update: At least two people have misinterpreted this post as a commentary on Seilevel’s presentation two days ago. It was not. Sorry for the confusion! Watching their very good presentations reminded me that I need to continually focus on my presentation skills, so I wrote this. As I think back on their presentation, they hit every single item on Guy’s list. I don’t know that they asked for a small room – I think they just had a better than expected turnout for the event. Great job Jerry and Joe, and thanks Seilevel for the event – it really helps increase awareness and will certainly help everyone who was there be better at managing successful products. Scott Sehlhorst]

Top ten tips for giving a better presentation
Guy Kawasaki wrote a great article last month about how to give a great presentation. You should be reading his stuff!

He goes into details about each of his ten eleven tips from his perspective. Here’s a quick summary of those tips with our thoughts.

  1. Have something interesting to say.
  2. Cut the sales pitch.
  3. Focus on entertaining.
  4. Understand the audience.
  5. Overdress.
  6. Don’t denigrate the competition.
  7. Tell stories.
  8. Pre-circulate with the audience.
  9. Speak at the start of an event.
  10. Ask for a small room.
  11. (bonus) Practice and speak all the time.

The most important themes in his post are

  • Be relevant. If we aren’t saying something we passionately believe in, and it isn’t something our audience wants to hear, we shouldn’t speak. Presentations aren’t opportunities to engage in ego stroking, they are opportunities to communicate.
  • Engage with the audience. We should find out what’s important to the audience, and entertain them – not try and broadcast our own “sales message.” We should try and entertain and inform the audience about what they want to know not what we want them to know. Of course there’s a message we want to give, but we should think of it in terms of what they want to hear, and craft it as such. This applies to small presentations, like proposing a project to a management team – which we talked about in our post, It’s not business, it’s just personal.
  • Earn the respect of the audience. Guy points out that the opportunity to speak is a priviledge, and we should treat it as such by not doing a sales pitch, not talking smack about the competition, and by showing respect. Overdressing is a great piece of advice – it is too easy for technical people to dismiss this advice – what we wear is not an indicator of what we can do or know. But human nature trumps correlation. People will perceive casual or sloppy dress as a lack of respect.

Check it out.