We spend a lot of time (rightly) on the capabilities of our products – identifying valuable problems and compelling solutions.  This focus is ideal for addressing the needs of our users.  But what if people abandon our products before trying them?  First impressions matter – both for buyers and users.

SXSW BizSpark Accelerator

Microsoft sponsored the BizSpark Accelerator at SXSW this year, where several startups competed by giving a 2 minute presentation of their products / companies.  The panel of judges emceed by Guy Kawasaki and Brad King.  The contestents were the top 20 from 200 submissions.

First Impressions

I was lucky to attend part of the event, focusing on the eight finalists in the Innovative Web Technologies area.  I recorded the presentations, but the camera shakes so badly in my hand that watching them is like trying to listen to a lecture while riding a rollercoaster.

Two minutes is barely enough time to make a first impression.  Each presenter had 15 minutes of Q&A with the panel, where they could get into more details and provide feedback to the entrepreneurs.  First impressions, however, are made by the very first thing you say.  Here’s the first sentance from each of the presenting finalists:

• klout.net – Hi everyone, I’m Joe.  At klout, we measure influence across the social web.
• OtherInbox - Thanks everybody, my name is Josh Baer, and I’m here to tell you about OtherInbox, which helps you save your real inbox for real people.
• Piryx - The idea is that you want to wake up, create an account, run for public office, and change the world. [Note - I lost the first sentance when recording, but this is the first substantive sentance]
• Ribbit.com – My name is David Lee, I am the director of strategy and business development for Ribbit Corporation. Ribbit is a cloud service for enabling communications innovation, bringing together the internet, voice, and data.
• Ringlight - I’m here to talk to you about my company, Ringlight.  My name is Brandon Wiley, I’ve been working in peer-to-peer for a decade, from the first peer-to-peer application, freenet, to the most popular peer-to-peer application in the world, bittorrent.
• Thrive - My name is Avi Karnani from Thrive.  I’m going to show you a new feature we’re about to launch called behavioral budgeting.
• YouData - Let’s talk about internet advertising.  [something garbled as the speaker had trouble speaking clearly into the microphone]
• Zoomorama - Hello, my name is Franklin, and I’m president of Zoomorama.  Zoomorama comes from panorama, the wide open space, and indeed zooming is not just about details, it is mostly about space. [Note that in parallel with the speaker, the display was showing some compelling image zooming technologies]

Every one of these presenters made a first impression.  klout, OtherInbox, and Zoomorama (and maybe Piryx) tell you what their products do in the opening sentance.  Ringlight and YouData both set the tone by identifying an existing space.  Thrive lets us know that whatever it is, we haven’t heard of it before, and Ribbit shared a lot of jargon words.

Elevator Pitch

When I was in presales, I learned how to craft an elevator pitch.  What I had not heard of before this year’s conference was the one-floor/two-floor pitch. 

An elevator pitch is a presentation of what your product (or company) does, that is short enough to be delivered while conveniently riding on an elevator with the really important person you want to hear your pitch.  It is a powerful image, used to remind us that people will usually give us a brief opportunity to get their attention.  To get more time, we have to earn additional attention.

The one-floor elevator pitch is a variation of the elevator pitch, but imagine your audience gets off the elevator after one floor.  You really only have time to get out a sentance or two – just like the above quotes.  

Which of the eight presenters, after giving the quotes above, would get invited to follow their listener down the hall, and which would have to stay on the elevator?

I saw the full presentations, and one of the presenters is a client, so I won’t share an opinion.  Would love to hear yours.

As a product manager, what would you have wanted the presenter to say for the one-floor elevator pitch?

Having trouble working through complex concepts?  Struggling to get a “simple” message across?  As human beings, we are all pre-wired to absorb visual communication.  You should take advantage of that to give yourself an edge when it comes to communicating.

Thinking in Pictures

Guy Kawasaki did an interview last week with Dan Roam, author of The Back of the Napkin: Solving Problems and Selling Ideas with Pictures.  There are eleven good questions with detailed answers, so it is definitely worth a read.

Whenever we hear a pitch or evaluate an idea, we go back to first principles and try and understand why something might work.  If we believe the explanation of why something might work, we’re much more open to the possibility that it will work.  Here’s part of Dan’s answer to Guy’s question about how and why using visuals to communicate can be effective.

Recent breakthroughs in vision science have indicated that there are multiple “vision pathways” along which the signals from our eyes travel into and through our brains. Each pathway keys off different visual cues in the environment–one pathway looking to identify the objects around us, another understanding where they are, another determining how many there are, another watching for changes over time, etc. This process takes place in parallel, breaking the entire visual world down into discrete elements that we initially process independently, and then only later “see” in our mind’s eye as a whole.

Dan Roam, interviewed by Guy Kawasaki

The basic idea is that we can perceive solutions to abstract and complex problems visually.  Visualization becomes a compelling vehicle for communication too.

Visceral Examples

Instead of writing a long string of words to describe the power of communicating visually, we’ll give you a couple examples.

One of Guy’s ventures is a company called Alltop, the goal of which is to find the valuable search results and present them to you.  Alltop is acknowledging a weakness in the search results created by algorithms – whatever the ranking mechanism, it is imperfect.  Alltop’s goal is to eliminate the pain of wading through useless search results to find the “nuggets” of useful results.  Does that explain the idea sufficiently?  What if you looked at this picture, from Guy’s recent blog article, showing a drawing by Dan of the concept described in this paragraph.

There’s a company called Slydial that allows you to make calls directly to someone’s voicemail.  A few minutes of poking around their website will give you an idea of what they do.  If you also read the FAQ and watch the videos, you can infer how it works too.  Or you can just look at the following drawing:

[click for larger version] * Note – depending on your age, the weird boxes are either obviously reel-to-reel recorders, or they are apparently happy robots that are excited to record your message for you.

Instead of calling someone in hopes of leaving them a message (because you don’t want to talk to them), you call Slydial, tell them the number you want to reach, and record a message.  Slydial then calls the voicemail of the person and replays your message directly into their voicemail.  In some cases, the person’s cell phone will even show a “missed call” from your number.

Whiteboards Rock

I’ve been heard to utter the phrase “I can’t think without a whiteboard.”  Whiteboards make for great visualization tools.  In my presentation at ProductCamp Austin, after a quick sojurn through my meager slide deck, we switched to the whiteboard.  With me at the whiteboard, the entire room was able to create an example Ishikawa diagram, first exploring an example problem with a concept map, and then building the associated ishikawa diagram.  The combination of collaborative teaching and visual expression and learning was very effective.

There’s an entire industry, now, built around electronic whiteboards.  Ten years ago, I was at a client using a copyboard – a whiteboard that would rotate the screen (like those old cloth-reel towels in restrooms) and a scanner built into the side of the whiteboard would copy what you had drawn, printing out a black and white copy of your diagram on thermal paper (the kind that used to be in fax machines, and that curls up after printing).  Five years ago, I was able to use an electronic whiteboard that detected the location of (and color of) the markers you were using.  It would detect when you were pressing down to write, triangulate the position of the pen, and create a digital copy on your connected computer.  Now those devices can be used interactively too – you can use a projector, pointed at the whiteboard, share the drawing real-time with remote viewers, and probably any number of other uses.

This matters, because you want a way to capture and share the drawings you create.  If you manage your information and communication well, it’s like slingbox + tivo for whiteboards.  View them any time, anywhere.  If you’re a product manager or business analyst, this gives you an easy way to embed drawings and diagrams within the traditional requirements artifacts.  Electronic copies of the drawings can be incorporated where they are needed most – leveraging context and providing clarity for your readers.  They dramatically help you when writing for an audience that does not have the context you have when creating the document.

Data Visualization

This is yet another incredibly valuable area of study – visual presentation of data.  Networks, connections, values, trends, everything can be visualized.  Check out this article from Smashing Magazine if you want to open pandora’s box into the current cutting edge(s) of data visualization.  If you’re a data-geek or a visualization-geek, my apologies.  This article will suck you into a black hole of great visualization ideas from which you may never recover.

Requirements Visualization

The only reason for documenting requirements is to communicate those requirements.  You can do it with text, or you can do it with analytically-saturated text, combined with gripping and clarifying visuals.  Make sure you have the following visualization techniques in your communication toolbox.

• Structured Requirements (or including interaction design) – this simple approach (and diagram) puts everything into perspective, from business goals to detailed specifications and to test plans and implementation.
• 
• Ishikawa Diagrams – demonstrate the cause-and-effect relationships that articulate why something is important to your stakeholders.
• 
• Class Diagrams – an explicit and expressive way to describe the business domain, providing context for your requirements.
• 
• Process Flows – there are many ways to do describe processes, from simple flow charts and sequence diagrams to BPMN process models (24-article tutorial & free visio template).
• and and
• Use Case Diagrams – no, not the UML use case diagrams, they are next to useless.  These are simple sketches that make a complex use case crystal clear.
• 
• State Transition Charts – show how objects can change their state over time (an order is placed, then paid, then filled or cancelled)
• 

What are your favorites (and why)?

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 http://tynerblain.com/scott.sehlhorst/ – 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.

Effective communication of requirements requires more than documentation and broadcasting. Effective communication requires interaction and collaboration. Alistair Cockburn addresses this in his analysis of project successes and modes of communication.

Alistair’s Article

Alistair analysed three dozen projects over the course of two decades. He was trying to find common approaches and processes that would correlate with or predicate software project success. What he found instead was that people and communication had more of an influence over the success of a project than process. This may be the source of the “people trump process” quote.

Hat tip to Jeremy Miller, The Shade Tree Developer, for the reference, as part of his excellent article describing the ideal software team.
In his article, he presents a diagram of different forms of communication and their effectiveness. We’ve redrawn Alistair’s diagram here.

The most effective communication is person-to-person, face-to-face, as with two people at the whiteboard. As we remove the characteristics of two people at the whiteboard, we see a drop in communication effectiveness. The characteristics that get lost are:

• Physical proximity. I am at a loss to explain why, but being physically close to the other person affects the communication. Whether it is three-dimensionality, timing, smell, or small visual cues, physical proximity matters.
• Multiple modalities. People communicate through gestures as well as words, often making a point by gesturing, raising an eyebrow or pointing while speaking.
• Vocal inflection and timing. By speeding up, slowing down, pausing, or changing tones, the speaker emphasizes the importance of a sentence, or perhaps its surprise value.
• Real-time question-and-answer. Questions reveal the ambiguity in the speaker’s explanation, or the way in which the explanation misses the listener’s background. The timing of the questions sets up a pattern of communication between the parties.

Characterizing people as non-linear, first-order components in software development, Alistair Cockburn

Visualizing The Analysis

When you look at the characteristics Alistair identifies, and overlay them on the diagram, you see the following:

The forms of communication can be clustered into two groups, one clearly more effective than the other. Within each group, there are more distinctions.

• Physical Presence vs. Artifacts. Collaborating in front of a whiteboard or on the phone is more effective than an email exchange. While eMail and instant messaging allow for near real-time interaction, they lack the cues that come from physical interaction. Our brains are wired for listening and looking as the means to communicate. You can absorb information and express ideas through artifacts, but it is less efficient. Artifacts that you create lack the instinctive elements of nuance in communication. Active listening skills are refinements of what we’re already wired to do – and they make physical communication more effecient than when you write something down.
• Interaction vs. Broadcasting. Strikingly distinctive is the difference between interaction and broadcasting. It is the difference between a community and an audience. Intuitively, you know that “throw it over the wall” is bad. Alistair’s research validates this. Determining the correctness of requirements requires interaction. You can use use cases to verify requirement correctness – but doing it without interaction is less effective.

Conclusion

Product requirements management requires communication. Different teams use different processes, and all processes involve communication. Effective communication must be interactive, not broadcast. Physical communication is more effective than communication with artifacts.

Artifacts serve a purpose – providing context, continuity, and a record of what has gone before. They are important for those goals, but relying on them as a communication vehicle in the absence of interaction will reduce the effectiveness of your team.

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.

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.

Forecasting

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?”

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

Summary

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

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:

• Part 1 – Purpose
• Part 2 – Research
• Part 3 – Planning and Execution
• Part 4 – Iteration and Execution
• Part 5 – Completion
• Part 6 – Postmortem

Conclusion

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!

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…

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

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.

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.

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,...



]]> http://tynerblain.com/blog/2006/04/03/targeted-communication-three-tips/feed/ 0 http://tynerblain.com/blog/2006/02/16/top-ten-tips-for-giving-a-better-presentation/ http://tynerblain.com/blog/2006/02/16/top-ten-tips-for-giving-a-better-presentation/#comments Thu, 16 Feb 2006 14:14:28 +0000 Scott Sehlhorst http://tynerblain.com/blog/2006/02/16/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.



]]> http://tynerblain.com/blog/2006/02/16/top-ten-tips-for-giving-a-better-presentation/feed/ 0 http://tynerblain.com/blog/2006/02/15/jargon-gone-amuck/ http://tynerblain.com/blog/2006/02/15/jargon-gone-amuck/#comments Wed, 15 Feb 2006 11:57:49 +0000 Scott Sehlhorst http://tynerblain.com/blog/2006/02/15/jargon-gone-amuck/

This video showing the abuse of jargon (2 minutes) is absolutely hysterical, and should be watched for humor alone. However, it also drives the point home about the effects of using jargon when writing requirements.

When we write a PRD or SRS if we use the jargon of one domain, this is what we will sound like to everyone who isn’t in on it.

To avoid this mistake start with Writing requirements unambiguously.



]]> http://tynerblain.com/blog/2006/02/15/jargon-gone-amuck/feed/ 1 http://tynerblain.com/blog/2006/01/23/top-five-presentation-tips/ http://tynerblain.com/blog/2006/01/23/top-five-presentation-tips/#comments Mon, 23 Jan 2006 19:26:02 +0000 Scott Sehlhorst http://tynerblain.com/blog/2006/01/23/top-five-presentation-tips/

From Start to End has a great post, Some tips on presentations. Very little we can add here – check it out.

Our top five presentation tips (our first four picks are from the list behind the link)

1. Know your audience. A key preparation – you have to have a goal for a presentation. Are you convincing, educating or inspiring people? What do those people care about (and what do they already know?)? Also – do you actually know the people in the audience?
2. Revise and rewrite. Editing is the best thing ever. When we first put ideas down, it’s generally from our point of view. Validate that the content is targeted at the audience.
3. Minimize the text on the slide. Eyecharts distract from the presenter. People read ahead – the slide content should provide cues for you to speak, and for your audience to remember. If we need a bunch of text to support our point, we include it in a handout.
4. One idea per slide. Focus!
5. Include supporting slides. We’re already simplifying the content we present to maximize the impact of the ideas, which means that there is more content somewhere, but we haven’t shown it. Often someone in the audience (generally interested person, micro-manager, dude-trying-to-look-smart) will ask drill down questions – “Where did you get that data?” “Isn’t that diagram overly simplified?”. Adding those supporting slides (created in previous presentations, or prior to revision) after a blank slide (with the title “End of presentation”) to the deck. Don’t plan on showing these slides, just have them at the ready.

The best advice I know about preparing content for a presentation: Plan the formal part of the presentation to share 2/3 of what you want to tell the audience. Draw that last third out through engaging conversation and informal asides during the formal presentation.



]]> http://tynerblain.com/blog/2006/01/23/top-five-presentation-tips/feed/ 2 http://tynerblain.com/blog/2006/01/17/brainstorming-making-something-out-of-everything/ http://tynerblain.com/blog/2006/01/17/brainstorming-making-something-out-of-everything/#comments Wed, 18 Jan 2006 04:20:47 +0000 Scott Sehlhorst http://tynerblain.com/blog/2006/01/17/brainstorming-making-something-out-of-everything/

Previously, we talked about brainstorming as one of the best elicitation techniques for gathering requirements. Here are some details about how to facilitate a general brainstorming session with a group of people in 5 easy steps (and then another 5 easy steps).

Seven to ten people is a good number to pull together in a brainstorming session. With creative and vocal people, a smaller number can work.

Five Steps to making brainstorming effective

1. Set the ground rules. Let people know that this is a brainstorming session, which means that all ideas are valuable. They may be bad ideas, but they can lead to good ideas. The most important thing to make sure people don’t do is criticize any ideas. People need to feel no fear – this is a creative release and they need to feel secure that any ideas they throw out are for the good of the cause. I have run brainstorming sessions where people have felt inhibited by their managers who might think an idea is stupid. Unless we know that this won’t be the case, we should exclude managers from the sessions, and try and fill the room with peers.
2. Set a time limit. There have been studies that show that creative thought is more effective when there’s a time limit. Creating Passionate Users has a post titled Creativity on Speed, where this idea is pursued in interesting ways, including creativity deathmatches. Makes for a nice segue. Set a 20 minute time limit on the session – long enough to get some juices flowing, but short enough that people won’t feel like it’s a waste of time.
3. Define a starting point. We don’t want people coming up with ideas for space elevators or edible plates – we need some focus. Since we’re eliciting requirements for a specific product, we have a context. Identify the high level goals of the business for this project, and write them on the whiteboard (or flip-chart paper taped to the wall) before the meeting. People will read this during the setup and subconciously start thinking of ideas. A statement like “Acme Bricks and Mortar needs a website to sell directly to customers online.”
4. Shout out and write. This is the fun part. Everyone in the room shares ideas as they come to them. Write them all down. Don’t editorialize the ideas. Some ideas will be requirements like “Make the borders of the page look like bricks” and others will be ideas like “90% of our sales is to existing customers.” Write it all down. If the group is too raucus, get a second person writing down ideas. Sometimes we end up with a room of people who aren’t comfortable, or aren’t interested in getting started. Start throwing out some ideas – say them out loud and write them down at the same time. If we don’t have strong relationships with the participants, this could easily backfire – we could cool off the room we’re trying to heat it up. An alternative is to start asking questions – “what do people care about when buying mortar online” or “what else do people buy when they buy bricks?” Think about some starter questions before the meeting. Don’t try and cram all the ideas together into nice organized lists – just write them wherever is convenient, this isn’t the time for structure. Prioritize quantity over quality at this point.
5. Pick the best requirements. The most important requirements are determined by the group, as described in the next 5 steps.

Five steps to picking the best requirements

1. Flag the requirements that should be considered (all of the requirements, but none of the thought-fragments, goals or general ideas) with a star or a colored post it note. If we’ve done this right, we will have several sheets of flip-chart paper or whiteboards covered in requirements, ideas, words and fragments (maybe even pictures). Tape the flip-chart paper on the walls if that’s where the ideas are written.
2. Count the requirements. We’re going to create three evenly sized priority buckets and place the requirements in the buckets (1,2,3). Each person will rate every requirement as a 1,2 or 3 (1 being most important). Give each person a stack of post it notes and a marker, and have them make out a fixed number of 1,2, and 3 post-its (evenly divided, with the remainder as 2s). It’s important that people be forced to divide the scoring evenly so that they don’t make every requirement a 1.
3. Everyone prioritizes the requirements. Have everyone physically get up, mill about, and stick their post-it-note priorities on all of the requirements. The scoring is somewhat subjective and individual. Provide a guidance about how ideas should be rated (value, feasibility, alignment with strategy), but ultimately each person will make a judgement call, and that’s ok.
4. Tally the scores. Add up all the scores, and pick the requirements with the highest priority (lowest totals). Throw all the scores in a spreadsheet – and look at a quick X-Y graph. It’s the weirdest thing – there always seems to be a cluster of scores for “important requirements” and then the rest of the requirements sort of taper off. There’s probably a mathematical reason for it, but someone smarter than I will have to explain it to us. The requirements in the top-cluster (probably between 1/4 and 1/3 of the ones we just scored) are the “first cut” requirements.
5. Make a list of the first cut requirements. We’re not done, however. There is usually at least one really good idea that didn’t fall in the top cluster because the “group” didn’t all agree that it was important. Give everyone in the room a chance to nominate one of the leftover requirements into the first cut group. Let them make a case for it. If we see something that we suspect is valuable, ask questions about it. Pull these ideas into the list.
We don’t have a spec. Yet.Brainstorming isn’t the key to writing a requirements document. There’s a reason that design by committee and group think make us cringe – because nothing great comes (solely) of it. A brainstorming session gets us a starting point when we are faced with customers who “don’t know what they want.” Even people who don’t know what they want generally have a good idea about what they don’t want. It’s easy to be a critic. Use this first cut list of requirements as a starting point. Review the list in individual interviews. Understand the ROI of these ideas, validate their strategic alignment with the stakeholders. Having a concrete set of requirements is the easiest way to get someone to say “We don’t need that, what we need is this!”Use the results of the brainstorming session to seed the cloud of ideas in one-on-one interviews. Don’t just spell-check them and hand them over to the dev team for implementation.- – -20060131: I just found this great link to some other brainstorming techniques at Never Work Alone -> Brainstorming 101. Check them out



]]> http://tynerblain.com/blog/2006/01/17/brainstorming-making-something-out-of-everything/feed/ 5 http://tynerblain.com/blog/2005/12/11/when-%e2%80%98no%e2%80%99-means-%e2%80%98yes%e2%80%99/ http://tynerblain.com/blog/2005/12/11/when-%e2%80%98no%e2%80%99-means-%e2%80%98yes%e2%80%99/#comments Sun, 11 Dec 2005 09:58:54 +0000 Scott Sehlhorst http://tynerblain.com/blog/2005/12/11/when-%e2%80%98no%e2%80%99-means-%e2%80%98yes%e2%80%99/

At our dinner table, we sometimes play the desert island game – if you could take one food, or one book, or one person on a desert island, what or who would it be? If I had to manage requirements with only one skill, it would be communication.

Without good communication skills, you won’t understand what the stakeholders want. And you won’t structure and describe the requirements in a way that the developers will implement what you intend.

For a given project, there are three sets of requirements – the requirements you are given, the requirements you document, and the requirements that are interpreted by the delivery team.

Each group of people is speaking a different language – stakeholders may talk about scenarios, and developers may talk about features or widgets. A recent post on from The Straight Dope reminded me that this can happen at the most basic level. Charles Darwin did a study to determine if head nodding (for yes) and shaking (for no) was a universal behavioral pattern among humans. He found this to be generally, but not universally true.

Ten years ago, I was presenting some statistical techniques in Oyama, Japan, for incorporating feedback into a manufacturing process, and the members of my audience would nod their heads and say “yes” during portions of my presentation. I just assumed it was a verbal attend (a pull-behavior validation of comprehension of a message). It was later explained to me that culturally, in that context, when the audience members were saying “yes”, it wasn’t “I understand you”, it was “I [physically] hear you.”

Three years ago, I spent a few weeks in Malaysia, training a group of about 30 new developers from different regions of India. They were learning some advanced AI, search, and configuration technologies. They were all very bright and they were learning concepts that involved approaching programming and representation in ways that were very different than they had done before. It was a critical time for me to know when someone was “getting it”, and when I needed to find a better presentation technique – if they didn’t grasp something, I wasn’t doing my job. One day, when introducing some complex topics, I noticed a few heads in the room shaking back and forth. My first reaction was that people weren’t grasping the concepts, but all the other cues indicated that people were in fact understanding the topics. After the presentation, I asked one of the developers about it, and he explained to me that this head shaking was in fact acknowledgement that the concepts were being absorbed.

So, “yes” didn’t mean anything, and “no” meant “yes.”



]]> http://tynerblain.com/blog/2005/12/11/when-%e2%80%98no%e2%80%99-means-%e2%80%98yes%e2%80%99/feed/ 2 http://tynerblain.com/blog/2005/12/08/it%e2%80%99s-not-business-it%e2%80%99s-just-personal/ http://tynerblain.com/blog/2005/12/08/it%e2%80%99s-not-business-it%e2%80%99s-just-personal/#comments Thu, 08 Dec 2005 09:41:00 +0000 Scott Sehlhorst http://tynerblain.com/blog/2005/12/08/it%e2%80%99s-not-business-it%e2%80%99s-just-personal/

Having the best powerpoint presentation (thanks to Presentation Zen and Beyond Bullets, this is possible) is not sufficient to persuade. We have to craft personal messages. We have to be interactive, and adapt our presentations as we present – maybe even discard them entirely, and craft the key points of our messages into a conversation lead by the people to whom we are presenting.

Susan Cramm writes about it in an article for CIO magazine.  We review Guy Kawasaki’s advice in Top ten tips for giving a better presentation.
Susan tells a great story – she has a relationship of trust and established credibility with a client. Together, they delivered a presentation to her client’s boss – and Susan gave the presentation. She didn’t have any prep time, an established relationship, or previous contact with her client’s boss. She didn’t gather intel about the boss’ hot buttons, goals, or objectives. She was walking into a mine field – give it a read and find out if she stepped on one.

Sometimes we can avoid the landmines, and sometimes we have no choice but to cross the mine field. Maybe we’ll get an opportunity to demostrate credibility to our one-person audience before we hear that deaded clicking sound when we take our first wrong step. Susan tells the story of hearing that sound on the first slide of her deck.

The way to get out of these high-risk situations is to prevent them. At a minimum, find out what’s important to the people we’re trying to convince. If Susan had asked her client what’s important to her boss, she could have presented her compelling arguments in that context.

It can be hard, but we need to step back and ask – why is this important to them, not why it is important to us – and then present accordingly. With a map of the mine field, we may be able to get to the other side.

No matter how prepared we are, when our audience starts telling us where the mines are – don’t ignore their advice. Don’t keep following a carefully crafted script. Let the conversation go where it wants to go, or it will end up going nowhere.

Persuasion is personal, no matter how much it looks like business.



]]> http://tynerblain.com/blog/2005/12/08/it%e2%80%99s-not-business-it%e2%80%99s-just-personal/feed/ 2