The Converging Network

Generations Of Communications and How They Influence Business and Products

Part 1: One of the reasons I enjoy creating software is that I'm fascinated by researching and understanding users of the technology we create. I sometimes refer to myself as a software anthropologist. That's part of why I also enjoy user interface design. So, enough about me... lets get on to the topic.

Over time, I've noticed how the form of communications we use is generational. By that I mean as time marches on, we create new ways of communicating and that tends to be the form users of that generation stick with. Some make the transition to the next generation, some have a foot in both camps, and others stick with what they've been comfortable with.

When I first started my career, business people communicated very differently than they do today. Besides the phone, communication was written, either through memos or reports, or personal letters between friends and family. There were no cell phones yet, and desktop computers were just beginning to make their way onto desktops. Yes, I'm really dating myself here.

But how I communicated was a bit different, a hybrid actually. I was a computer science student in college and had a side business writing medical software for the Apple II. I was exploring online bulletin boards and using word processing software (that's what we called it back then) to create my content, but few were doing this when I started creating software at the bank where I worked. Very soon after that, I was setting up my first LANs and starting to deploy email servers and email clients, something else that was also very new to the PCs in businesses where I worked.

So, with that as a starting point, I noticed that I was different from those around me in the bank and in the IT department. Everyone lived by pen, paper or a typewriter, while I was always on a computer. And over time I observed how our communication patterns tend to change with new generation of users and stay the same for others.

Here's how I break down the generations of communications and how users of that generation create and consume content.

Non-computer - short hand, dictation, pen and typewriter. I collapse all of these forms together because they don't involve the use of a computer, matter of fact they largely predate computers. Content was handwritten or created verbally and either written down in shorthand or recorded into a Dictaphone type device, and then transferred via typewriter into written form. This is the generation my parents and grandparents grew up in. My grandmother was well known at the local hospital for her typing speed and accuracy at deciphering and spelling medical jargon dictated by doctors. That couldn't have been easy. Other than the use of the phone, all of our communications were written. (You could go back in history and talk about typeset, printing press and when everything was handwritten, but I'm not going there in this blog post.)

Word processing. When I officially joined the workforce (after college), word processing was making it's way through businesses. This was the Wang word processor era, specialized hardware and software just for word processing. I was using PC software for word processing, like ScreenWriter II (Apple II), MacWrite (Mac), WordPerfect, WordStar and eventually Microsoft Word (PC). I really only saw the tail end of dedicated word processor generation, as it was pretty short-lived from my experience. I recall on the first development project I worked how many people created content by writing it on yellow pads, and then the word processing pool (formerly typewriter operators) transferred it to typed pages. This was an odd period for me because I was using my own word processing software to create content and either printing it on my own printer or handing it over to the word processing pool to retype. (Go figure.) As computers moved onto the desktop, thanks largely to VisiCalc and Lotus 123, word processing shifted to the desktop as well. Understand that ultimately what we're talking about here is content that's only consumed once it's printed. Creation of content is still written but it's being translated to the computer rather than being created at the computer.

Email. I'm largely of the email generation. I remember setting up one of the first LAN-based email servers in EDS where I worked. The email software was InterMail and it ran on the Mac (and I believe later became part of ccMail.) Most in the email generation send, receive and consume content via email while they are at their computer. They do it themselves. (This probably sounds like no big deal to you because that's likely how you work and communicate.) An interesting side effect is that non-computer and word processing generations typically didn't fully make the transition to email. I remember countless managers and executives who had their assistants print out their email for them, write comments and responses on the printed page for their assistants to type up and reply back to the sender. That seems as uncomfortable to me as having someone act as a mediator between myself and a caller on the phone, but for those of the written communication generation, computers, mice, keyboards and email programs seem just as foreign or strange.

Instant Messaging (IM). A relatively collapsed generation are IM users. I say collapsed in that IM tends to be an extension of email users, not really a generation in and of itself. It doesn't replace email, but gives instant communications to individuals and groups. The audience of people who you IM is usually pretty small, such as co-workers in your immediate workgroup, some family members and friends. Except for a relatively few users on the extreme, I don't see this as a way an entire generation changed their communication patterns, giving up email in place of IM.

Texting. My kids are of the texting generation. They rarely use email (mostly to communicate with me) and they don't use email to communicate amongst their friends and social groups. They text, and they text a lot. They see email as something Dad does, but not them, though they use email for other purposes such as their school email account where information is delivered to them via email. Both my kids and I are hybrids, but at different extremes. I text, but use much more email while my kids' generation text and use a little bit of email. We're at that crossover point in this transition from email to texting in a variety of forms as we'll see in  a moment. People like myself who have adopted texting will better communicate with the next generation and may transition there themselves (I hope I do), and those who haven't will still require their audience cross back and forth between their preferred method and previous generation's methods.

Twitter and social networking. Clearly social media, with the exception of blogging, is designed around the same types of short messages we've seen from the texting generation. But it's different in  that social networking can reach one person (such as with a direct tweet or wall-to-wall message) and also go out to many within our social networks, both close friends and family or more distant observers. An interesting aspect of social media is how it has quickly crossed multiple generations. While mySpace was primarily a youth and music oriented community, Facebook is used by a much broader spectrum of age groups. Twitter is rapidly making its way into businesses as a new medium for reaching their audiences, but we're still largely in that early adoption phase.

One of the things I haven't addressed yet is mobile communications, i.e. cell phones. Clearly mobile technologies have enabled options like texting, while twitter, IM and email communications can be performed with and without cell phones. I won't go into mobile communications any deeper here as I think I could write a very similar blog post about how mobile communications has shifted from one land line phone per home to wide spread use of mobile phones and to a lesser degree SmartPhones.

Okay, that's the breakdown. In Part 2 of this blog post I'll discuss how thinking about communications in this generational context is important and how it influences our products, IT systems and methods of reaching customers and communities.

Product Bistro: A Product Manager’s Dream and Nightmare (cont’d)

Continued from a previous blog post…

The Digital Age Will Save Us… Uh Huh

If you haven’t noticed our world of software is changing right from under us. We rarely receive CDs or DVDs when you buy software. All the Microsoft products I use in my business all come direct via the web, downloading an installer or the ISO image of the DVD to my computer. We buy and download our music through Amazon and iTunes. Now customers have much greater access to products, and we have instant delivery of online services and software products to our customers. 

Fall 2008 at the Microsoft developer’s conference, Microsoft announced Windows Azure, their strategy for bringing applications and infrastructure services into the cloud. It’s a bold step but nothing short of bold will do to be able to compete against the lead created by Google and Amazon. We’re entering an age where computing power, storage and network bandwidth are services we can spin up or wind down as needed. That’s a product manager’s digital dream, right? Well, it’s never that easy.

Yes there are automated processes for provisioning services and bringing new servers online, and they work, but not always in peak situations. There’s always more to it than standing up a dozen or more servers and “bring them online”. Databases, load balancers, firewalls, application software, backup/recovery, bandwidth, failover schemes… it all plays into the equation.

Microsoft was down for nearly a full day reconfiguring their service to be able to handle the huge demand for the Windows 7 beta. We don’t yet think of Microsoft as hosting thousands of computers like a Google or Amazon EC2 and S3 (Amazon’s hosting and storage services). But Microsoft runs a huge infrastructure that delivers MSN Messenger, MSN email, MSNBC site content, Windows Update service (all those patches you keep receiving), automated anti-virus updates for OneCare…. see there’s a lot. So, Microsoft’s no newb at the online services hosting game and it still took them a day to get back on their feet delivering Windows 7 downloads on the Internet.

It’s Not A Successful Launch Unless The Order System Gets Hurt

I see a trend happening. It’s obviously not intentional but it may become one of the criteria for any mind blowing, gang buster style product launch. The trend: crashing the servers.

Apple’s iPhone 3G was plagued with enormous problems which revealed a single point of failure in their online and SmartPhone strategy – the iTunes service. Yes, that nice little program you have on your Mac or PC to play songs, sync up you iPod and iPhone, and buy digital songs and movies. Behind your desktop app are the iTunes service which not only provide the online store for buying digital content, it also is crucial to provisioning iPhones and delivering software upgrades. Apple unwisely chose to bring out a new iTunes and iPhone software upgrades, and convert the .MAC service to MobileMe… all within a few days of each other. Busted. When demand peaked, the iTunes servers couldn’t handle the demands and customers were impacted on all fronts.

Verizon’s Blackberry Storm was plagued with similar issues when their ordering system overloaded during the first day of product launch. Call me silly but I’m pretty sure they knew the demand was coming following several very public product launch date delays, tons of attention from online on technology sites and blogs (like mine) and Verizon’s own billboards plastered around town more than a month before launch. (A consequence of moving the launch date once too often.)

Don’t Do It To Yourself… or Your Customers

What’s the second most under appreciated component of any piece of software? Answer: The installer. And what’s the number one under appreciated component of any software product? Answer: The upgrade.

My mom used to say that you don’t get to go to kindergarten until you can remember three things. (I forget what the other two things she says are, but I digress.) My adage is a product team doesn’t really know how to ship a successful software product until they can reliably do software upgrades successfully at least three times consecutively. (And not just minor upgrades.)

Apple is notorious for really bad upgrades, the consequences of which are bricked iPhone, wiped out data and pissed off customers. It’s not happened with just one software release, but occurs time and again. I’ve personally had two iPods blanked from Apple’s software updates, one of them was totally DOA and not recoverable without sending it to Apple. The most recent episode smacked down my buddy Alan’s iPhone, wiping it and causing him to wait while fix was tested and posted. That one experience moved him from being an iPhone advocate to an iPhone protagonist.

In IT shops software upgrades might be something we do once or twice a year. They are well planned (or should be) and timed, and include a recovery strategy should something go afoul. But that’s become much different for consumers and PCs in small and medium businesses. An upgrade or patch to Windows or Mac OS X could happen at any time, resulting in our PCs being reboot overnight or creating a capability problem you didn’t have the day before.

Upgrades are crucial to a positive customer experience. Their importance is drastically increasing. In my opinion, we’re not far from the day where every company needs to learn to do upgrades flawlessly or they get to go away.

The Fundamentals & Learning Faster

Shifting to the age of Software-as-a-Service (SaaS), online hosting, services on demand, and digitally delivered products are launch and delivery strategies we all are likely to consider and use at sometime. It opens up new possibilities, gives us access to new customers and markets, and drastically decreases the time to reach customers before, during and after the sale. It also means we need to be smart about learning from our experiences and the experiences of others in market.

Jumping onto some new technology often means we forget or ignore the fundamentals. Who’s the customer, what really are their needs, what will create a satisfying experience for them, positioning, messaging, the 5 P’s, etc. If anything technology accelerates and shortens the window between a buying a experience and a satisfying product experience. That means we have to learn faster, plan better and be prepared for more contingencies. We have to be open and transparent with our customers because they see the magnitude of product issues we experience and the age of whitewashing problems through some fancy PR campaign of CEO slight of hand are gone. Ask Jet Blue’s former CEO who is Passenger Bill Of Rights won over unhappy customers who sat in the plane grounded for hours.

Transparency. Something I’ll talk about at another time.

Power IT Down Day + Call To Action To Create Greener Products

Yesterday I recorded a podcast about Power IT Down Day. I'll be posting the podcast to my Network World Converging On Microsoft Podcast first part of next week. Power IT Down Day is an initiative set up by Citrix, HP and Intel, to get everyone to fully power down their desktop and laptop computers, and associated monitor, printers, powered speakers, etc. during the off work hours on August 27th. I say fully power down because even hitting the power button on monitors and laptops, for example, doesn't mean they aren't sucking up juice through their standby modes and transformers. Better yet, power it all down, by hitting the power switch on the power strip plugged into the wall.

The idea behind Power IT Down Day is to help all of us be aware, and also to try and start some behavior changes, to save electricity consumed by our individual computers while we're not working at our desks.  According to my podcast guest Tom Simmons, area Vice President Federal at Citrix, many are projecting we could see electric power costs soar in the future similarly to how gas prices skyrocketed this summer. California already suffers rolling brown outs and a lack of power for data centers. The seemingly unlimited low cost power we take for granted today, like the low cost gasoline of the past, could become a scarce and expensive resource in the future.

I'll save some of the specifics behind the program for the coming podcast, but until then please visit http://www.hp.com/go/poweritdown and sign up for the program. Based on the estimated power savings from powered down PCs at participating companies, Citrix, HP and Intel will donate an approximated savings amount the Red Cross. (Personally I wish they were donating the money to help us build more wind farms, or create hydrogen powered cars and fueling stations in the U.S.) I think this is a great program and I hope you'll participate.

Power IT Down Day is a socially conscious conservation effort: Help users, through their company's participation, understand the impact of needlessly leaving computers running during off work hours. That's good stuff, and well worth doing. I hope we change some habits and conserve power as a result. I've already started changing some of my power munching habits just after hearing about the program. But, I think we should tackle something closer to the heart of the problem: designing greener products.

Do monitors, printers, computer motherboards and power supplies, etc., really need to operate in standby mode where they continue to consume power? What's it save us, 10, 5, 3 or 1 seconds to start up our devices faster? Are we that pressed for time or that lazy? Why can't laptop power supplies (bricks) have a built in sensor that determines when laptop batteries no longer need charging, and then fully turn off the transformer? I'm sure those are just a few of the obvious examples and there are many more that could save even more energy.

I have the same beliefs about network security. Educating users only marginally helps the problem. The real issue is designing products that are fundamentally more secure or can automatically configure themselves securely rather than relying on end users to deem what programs should/shouldn't talk through a personal firewall, for example. Same with conserving energy. Fix the problem of creating greener products.

I call on product designers to design products than consume less or no energy, including periods when they might experience light or almost no use, rather than relying on end users to know and act to conserve energy. If you need help understanding how product design decisions impact the "greenness" of a product, and want to know how to design greener products, check out a company called Sustainable Minds (I'm an advisor to this company), their Okala methodology and their green product design industry expert blog. Help us all by starting at the source, creating greener products from the get-go.

And remember to sign up for Power IT Down Day, and most importantly, turn off all that computer equipment when you leave work on August 27th, and every day for that matter.

Product Bistro: YouTube Your Customer Case Studies

Alan has a post over on his blog showing a customer case study using YouTube. What a great idea. Who wants to read another boring marketing document. This has real customers telling their story about how they use StillSecure Safe Access to secure their network.

I think this is a really innovative idea and one we'll see more of. Companies will have to be careful that it doesn't become a slick commercial (those are okay too, just not labeled as case studies.) I think you could go with a video that has even less polish than the StillSecure video case study.

Kudos to Jayson, Sonya and the team who came up with this idea. I'd like to see more of these.

Here's the Safe Access customer case study:

Product Bistro: Learning To Create Sustainable Products

Just because many of us are in the tech industry doesn't mean we should proceed oblivious to the impact green product design is having on all industries, including ours. Software delivered through SaaS and virtualization are two of the more well recognized ways we as technology professionals, product creators and technology consumers see "green" happening in our industry. Virtualization and SaaS both help reduce the carbon footprint through power and cooling reduction of hosted and virtualized software. Downloadable and hosted software and documentation also reduce the paper, printing, transportation and other eco-unfriendly costs of creating and delivering products.

But the decisions we make in the creation and consumption of technology products impacts our planet's carbon footprint in many other profound and far reaching ways beyond just (and I am in no way minimizing these) saving some trees or conserving energy costs. Product designers are very often unaware of how decisions made early and throughout the product lifecycle can impact the carbon footprint of the products we create. Certain paints may require special ingredients having a higher carbon footprint manufacturing cost. Software the requires a large number of high speed, energy consuming disk spindles running 24x7 which could be better optimized for peak or infrequent usage. Computer hardware and accessories may have a high environmental impact because of their poor recyclability or the products they displace. Even how we organize or operate our businesses can have a smaller or higher carbon footprint because of travel and energy costs.

A new breed of entrepreneurs, called environmental entrepreneurs, have emerged focusing on creating greener products, services and businesses. I'm fortunate to be an advisor to one of the leading environmental entrepreneurs, Terry Swack, and her third (I believe it's third) "green" company, Sustainable Minds. Terry and the Sustainable Minds team launched a series of information services for product designers supported by companion decision support software created by the company. Here's how Terry describes their offerings:

“These are the first of our information services which deliver new knowledge, processes and strategies for a life cycle-based approach to product design, and are the counterpart to our decision support software. This combination is key for design organizations looking to innovate or differentiate through delivering more sustainable products or design services. Product design professionals can acquire new green skills, increasing their value on the job and having greater impact in organizations. Manufacturers can access new markets with innovative, environmentally superior products that meet customer needs, and increase brand value by credibly marketing ‘greenness’. Our aim is to cover the exceptionally broad topic of sustainable design with experts from diverse areas who drill down to specifics that practitioners will find illuminating.”

I like and believe in the pragmatic approach Sustainable Minds is taking to help advise and education product designers, and support the design process with data and tools. Terry likes to say, "The bottom line is, there is no such thing as a green product – all products use materials and energy, and create waste." See what I mean about Terry's pragmatic approach? To help designers throughout the entire process, the company created Okala, a lifecycle assessment tool for creating more ecologically sustainable products. She has also assembled some of the leading experts in creating sustainable products who are contribution to the Ask the Okala Experts blog.

I believe we as product creators and designers should be responsible for educating ourselves about designing more sustainable products. Terry talked at PARC prior to launching Sustainable Minds and this video gives you some good basic information about sustainable design. The Ask the Okala Experts blog is a blog you can also follow to hear from thought leaders in the space. I appreciate your checking this information out and sharing it with other friends who might benefit from this information. I'm learning right from Terry and the Sustainable Minds team right along with you.

Product Bistro: Demo Secrets From The School Of Hard Knocks

I thought I'd share some more product demo lessons learned as a follow up to my other two posts Product Bistro: Mitchell's Rules of Demos and Product Bistro: Demo In 5 Clicks Or Less. Doing demos well isn't easy and there's a lot that goes into doing product demos properly. I hope sharing these ideas help you in your quest to help customers.

Use recorded demos. Want to avoid the demo gremlins? Want to be able to give a demo without scheduling an SE or the demo system? Want a good scenario-based demo rather than a trip down the product functionality bunny trail? Want good demo data for your demo? Want all your sales people to give the same, consistent demo, emphasizing the proper messaging and value points? Use a recorded demo. It's that easy and it works.

I've helped create Flash demos (see this example) using voice overs for the presentation, and also recorded less formal demos, using products like Camtasia Studio and a PC headset microphone (See this Xobni example). They work very effectively and sales people love 'em. Send the customer a link and they've got a demo. No SE, no scheduling, no bad demos (if the recorded demo is appropriately done), and much, much less risk of technical glitches. After using the recorded demo, follow up with an onsite or web demo to answer specific questions not covered in the standard demo... but only when necessary. A recorded demo is probably all that's needed in many situations. And giving a customer login credentials isn't the equivalent of a recorded demo. They are just as likely to have problems or struggle finding what they are looking for, so I'd recommend not giving customers their own demo login.

I can't say enough how effective and useful recorded demos can be. They can also significantly shortening the sales cycle, and free up SEs to handle more complex or specific customer issues, rather than presenting general product demos in every customer situation. They are definitely easy to create so I'd look into it if you don't already have a recorded demo.

Use a self contained demo. If anything can go wrong in a demo, it will -- so, if you are going to give a live demo, leave as little to chance as possible. The less outside factors you have to rely on, the better. Do you need to use the customer's Internet connection? Then bring your own cables (two, one for backup) and a broadband wireless card in case you fight with the customer's proxy, firewall, or VPN connections through their network. If all else fails, have a demo slide deck you can use in case you can't connect, the server's down, your laptop decides to croak, something's messed up on the demo system, or things aren't going well and you need to retrench.

"Boy Scout" Rule of Demos - Be prepared. Bring your own projector. Invest in one of the compact projectors you can take on the plane. I can't tell you how many times I've walked into a customer's conference room only to find some ancient projector that's the size of a trombone case, has really bad faded color, or one that my laptop just won't sync up with correctly. Now you spend all your time and focus acting the part of the high school AV guy trying to make some projector work, when you should be focusing on other things. Plus, everyone else in the room is distracted instead of listen to what you have to say. 

If you are using a web conferencing service to deliver your demo, use your's, not the service the customer sets up. If you are presenting or giving a demo, you set it up. And make sure you use a reliable conferencing service, not one that's going to cause issues getting the meeting started. Switch to a different service if you do have issues until you find one you like and works reliably.

Lastly, carry what I call my "Swiss army knife cable kit". I have two very small portable hard drive travel cases I carry in my backpack that have just about every cable and connector combination you can think of in it. It's light weight, doesn't take much room, and now I'm prepared for just about anything short of using a flashlight to do a shadow puppet demo. (Oops. Better add a flashlight.) Just make sure you take all your equipment and cables with you when you pack up and leave.

How do you get to Carnegie Hall? Practice, practice, practice. Same for demos. Make the demo the smoothest and easiest part of your customer meetings by knowing the demo cold. Know what works, and where there are pitfalls or dead ends. Know your product front to back. Anticipate how you'll answer questions, whether it's worth the time to traverse to the place in the product that answers the question or if you'll just tell them verbally. And most importantly, be at your best by literally talking through your demo from beginning to end, working through the rough patches where you stumble your words, repeat yourself or forget those salient value points you want to make sure come across.

There's a reason why there are mirrors in hotel rooms and its not only for adjusting your tie or fixing your hair. Stand up when you give a demo so you have better command of the room and visibility of your audience (and visa versa.) And practice standing up, just like you will when giving your demo in person. Instead of watching reruns of Myth Busters in your hotel room, practice your demo for the upcoming customer meeting.

Don't bag dive. Have you ever seen a situation like this happen? "Hello Customer. Thanks for having us in. Okay, I think the best thing to do is start off by showing you our product..." That's called bag diving. Demos and product literature are the security blanket of selling. When unsure or uncomfortable, people love to bag dive, missing all the up front dialogue to set the stage for the meeting. I don't want to waste a prospects time until I know how I can laser in on helping them, and I now know to communicate that to the customer.  Before you start anything else, set the context and objective of the meeting, reconfirm needs and problems, understand who's in the audience and why, etc. (I talk about this a lot more in my other two posts about demos.) So don't go for the security blanket and bag dive right into the demo. Set yourself up for success and leave the bag diving to the competition.

The importance of good demo data. Bad demo data can quickly derail a great customer meeting, making you and your product look embarrassing. If the data isn't relevant to the scenarios your talking through, or is too fake, you are just creating another obstacle the audience must work through to get to that place where they "get" how you solve their problem.

Use data that's presentable to the customer. I can't tell you how many demos I've been in where I cringed because the demo system had embarrassing or questionable data in it, causing a "note to self" to fix the demo data right after the meeting. Software developers are famous for taking license by using questionable or unprofessional looking data in their test systems. They're just having fun and don't think that anyone outside their team would ever see the demo data. Invariably someday they are asked to show software that's under development, or the test data spills over into the demo data. Again, if it can happen, it probably will.

A demo account called "moron customer" probably isn't going to show you or your product in a positive or professional light. Even an account called "developer account" (unless your product is a development tool) might scream to the customer "this software isn't baked yet, it's still under development". You don't want the demo data detracting from the real purpose you are showing a potential customer your product.

Scripts that feed in data or reset data nightly can be a blessing and a curse. Some products need ongoing data pumped into them to show how the product works (take a security monitoring system for example.) Scripts also help bring the demo system back to a known state every night, taking out any changes someone might have made while giving a demo. You often also have to use scripts to change dates in the data (so it stays relevant). But as always seems to happen, scripts break, they don't run, or something gets whacked when the demo system is upgraded. Put your demo system under change control, so everyone knows when it's unavailable, and what changes are being made. Test the demo system after every upgrade -- It is a production system, not a develop box. And log into the demo system right before every demo to make sure everything's up and running. Double check the expected data's in the system. No sense in taking any chances.

Stop selling when the customer is sold. You can undo a lot of really hard work by over selling in a demo. If you had the customer at the login screen, then stop demoing and close the sale. We all know you're really proud of the latest doodad feature that was just added to the product but that doesn't mean everyone's got to see it. Look for the "you had me at hello" signal from the customer, make sure you've covered all the needs and questions you've identified, and wrap things up. It'll save you from a lot of bruised shins, and your sales person's commission check will thank you for it.

Who owns the demo system? Ah, just who owns the demo system? The SEs? The SE manager? Marketing? Development? IT? Far too often nobody really owns the demo system, but a bunch of people work on it. I've come to the conclusion that whoever is creating the messaging, value points and demo script for product demos owns the demo system. This might be a product manager, someone in marketing, or a variety of other roles. But the bottom line is one person should own it. Support may come many other technical resources but make sure you have a clear owner. And that person or group is also responsible for training the rest of the organization on giving demos.

One last point about the demo system. Your product release cycle needs to include the creation and updating of demo data, to appropriately demonstrate new capabilities, and it needs to include upgrading the demo system software and scripts. It should be scheduled as part of the product release process, just like collateral, training, and PR.

The best demo may be the one you never give. Believe it or not but you don't necessarily need to give a demo in order to sell your product. I've seen it happen many times. The customer has a serious enough need, customer references are very strong, the match of customer needs and your capabilities are spot on, an employee from a previous company that used your product acts as a testimonial, product reviews or analysts reports speak volumes about the greatness of your product... those are all good cases where you may not need to demo your product. So keep that in mind. You can seriously shorten the sales cycle when you can make the case for the customer to buy your product without having to do a product demo.

Product Bistro: Demos, Demos, Demos

I enjoyed a really great session yesterday with a few of the teams at TechStars in Boulder. The room was filled with two things; passionate entrepreneurs, and people looking to help each other. Four companies presented in rapid succession their 10 minute investment pitches with some time for Q&A.

Part of those pitches were product demos in various forms, so naturally I had to chime in about my experiences demoing products. To help folks out, I said I'd post links to two of my previous posts about demos.

• Product Bistro: Mitchell's Rules of Demos
• Product Bistro: Demo In 5 Clicks Or Less

One other thought I'd pass along is that old saying, "How do you get to Carnegie Hall? Practice, practice, practice." There's nothing like knowing your story better than anyone else and being able to tell it at the drop of a hat, and tell it well. Being on top of your game comes through in spades to your audience. Then you can deliver your best presentation and deal with the questions and other things that might come up.

Best wishes to everyone at TechStars and keep practicing those pitches!

Product Bistro: Love Developers, and Trust QA

I was talking with a friend and fellow musician Jason Mendelson last week and the topic of software delivery came up during our conversation. Jason knows that I have a lot of experience leading product teams to bring software products to market. I've learned a ton about shipping products and if there's a mistake you could make, well, I've probably made it at one time or another, and sometimes more than once.

When it comes to shipping software, delivering software releases on time is one of those seemingly elusive concepts that most everyone desires but frequently don't achieve. (I actually believe delivering on time is a learned behavior, but that's for another blog post.) Quality can also be an elusive goal, especially for startups who may not have a lot of experience working together as a team, or are under huge pressures to deliver releases. Dialing in on the winning customer experience and product feature mix is another passion of mine that's vital to creating great products. I could blab on about all these subjects but a philosophy of mine about creating software caught Jason's ear; "Love developers, and trust QA".

These days I'm frequently a coach or mentor to someone who is leading a product development effort, sometimes for the very first time. Frequently they've come up through the developer ranks with a lot great experience that sets them up for new opportunities leading product development efforts. I always try to help them understand a key lesson I've learned; while I love software developers and the innovative work they do, I trust most what QA software testers tell me about the quality and completeness of a software release. I've advised more than one development manager that even though you may not always like what QA has to say (you may even dread hearing it), you need to hear it straight -- they're looking out for your best interest.

Software developers, engineers, artists, or whatever job title you chose to call them, are a loveable, creative, quirky, smart bunch of people who have to try and envision how best to build software that embodies the vision and needs of the business. They are a great group of people and I love hanging around them and being part of the team. Sometimes product developers get great direction and it seems more often than not a lot is left up to their interpretation when creating a new product. Hopefully someone is giving them great input about the target user personas, product requirements, user interface design and help with key decisions about the product architecture and which options help the business most achieve its goals.

But inevitably, releasing software products can become a grind. What's after this release? Another release. And after that, another release, etc., etc. It's hard work and developers are frequently in a situation where they have to be as productive as possible, inevitably making decisions that could make or break the product's quality, feature set and success in the market. Developers have a lot of competing needs to balance and are often asked to make decisions without the time or input that might help make that decision the best one. That's where the development leader, manager and/or product manager comes in, btw, making sure the development team grasps the impact of various options and decisions, and also that business leaders understand consequences of certain demands which could impact the product or the business. But that's why I love developers -- with all these things to consider, the best plow through and get the right things done to create great products.

It's also why asking a developer questions like; Is it done? Is it tested? Does it work? Is the quality better? Did we find all the problems? Is this going to satisfy what our customers asked from us? Is it ready to ship to a customer? I could think of a million questions that while I've asked developers, I know I may not have gotten a completely accurate picture based on their answer. In many ways developers are too close to the problem, head deep into creating the solution we need. One developer is likely only working on one portion of the software release, and more work is required to integrate and get all the elements of the full release working together. That's why everyone knows that to get quality software you shouldn't rely just on developers themselves testing their own code. That's also why I trust developers, but I trust QA engineers more when it comes to understanding the true state of a software release.

QA guys (guys and gals) tend to think very differently. Their job isn't to create stuff, it's to break it -- anyway they can. Because if they don't find a problem, that means a customer will. And some people just have a real knack for it. The best are also very detail oriented, don't assume anything and watch to make sure nothing gets by them. The best QA engineers are also very good about tracking results, creating thorough test plans which get a lot of scrutiny by everyone including the developers, automate testing, and understand the value of metrics and how this can raise the learning and skill of the entire team at releasing quality software on time.

QA engineers are also the first point in the process where someone is actually trying to use the software. Functional testing doesn't always drive this out, but scenario or use case based testing can make a really big difference. Using your own products in your lab or by your IT staff can also be a great way to get real usage feedback, in addition to customer experience testing of course. Testers also have great suggestions about the product. They catch nonsensical error messages, product inconsistencies, or encounter areas of the product that are hard to use. Most importantly, QA engineers know they are the last in line to judge the release, and take their responsibility very seriously when it comes time to say whether they think the release is ready or not. QA engineers aren't just critiques, they want to ship the product too. They just don't want to be embarrassed, taking it personally when bugs or quality issues escape the testing process and are found by customers.

I also believe the effectiveness of any QA team or department is a direct reflection on their leadership, including the visibility, importance and voice given them in the product development process. One of the things I've learned to do as a development manager, VP engineering or CTO is to hold my own weekly meetings with the QA team. Development managers are welcome if they like too. This is our time to talk about release testing, QA processes, metrics, test plans, lab needs, improvements, suggestions, issues escalated from support, and -- most importantly -- give QA a voice directly to the top of the organization to say whatever needs to be said, good news or bad.

I hope this explains some of my learnings around the philosophy, love developers, and trust QA. The fact of the matter is that I love them both for what they bring to product development, and I trust them both too. But I rely on their skills, experiences and judgment differently, and at different times, bringing the best strengths of both to release great software products.

Breathing Your Own Exhaust

One thing that happens to everyone at one time or another is when you become so engrossed in your own world view, you start to believe everyone else thinks the way you do, or if they don't, your spin will fool them. Doesn't matter whether you're big like Cisco and Microsoft, or the latest startup on the block with a new mouse trap. You hear phrases like "he believes too much of his own press" (I'm sure that's been said about me more than once, lol) or "they've been breathing their own exhaust too long."  I blogged about what could be one such case of this, Microsoft's self makeover to be perceived as "open source friendly". Another example is Microsoft claiming it supports Linux in Hyper-V, but only if it's Novell's SUSE Linux.

I'm a big believer in ideas like enrollment, passion and engagement, and to achieve these you have to believe in what you, your product and your company are doing. Doesn't matter if you are the press spokesperson or the person answering the customer service phone -- everyone else can pretty easily tell if you are enrolled in what you are doing, or it's more a matter of your going through the motions.

But that same passion and engagement can also create a blindness, especially in entrepreneurial environment where passion, ideas and commitment runs high. It's easy to build a wall around yourself or your company, focusing just on what's happening inside your product, the product development efforts, or even the geographical market area where you are physically located. My very good friend Alan Shimel used to frequently tell me "you need to get out of Boulder more often", not because Boulder isn't a good town (check out Brad Feld's blog post about Twenty-Five Square Miles Surround By Reality), but to really understand the industry, competition, customers and the market.

I recently blogged about (tangentially as it relates to partnering) the bubble effect that can happen in a startup company. It is very easy to become so engrossed in what you are doing, crafting your marketing messages, building the product, training the sales force in the ways you want them to sell, that you forget there are other people out there. Companies may claim to already do what you do, cover the same supposed differentiators, or have already beat you to the punch but you just don't know it yet. I call this inward looking focus, "staring at your own bellybuttons."

There are many things I've found helpful to me to try and avoid this. In a leadership role you probably have more opportunity to take advantage of these but I believe in any of our roles you can find a way, or even ask to participate in these kinds of activities. Here are a few ideas.

1. Never turn down an opportunity to talk to a customer. Doesn't matter if they are a sales prospect, an unhappy customer who wants to scream at you, or one that's nicely tucked in and happy. If you have a chance to talk with or meet with a customer, always, always do it.

2. Support your company's trade shows and marketing events. I learn more about the industry at many of the trade shows I attend than I probably do by reading about companies and the industry online. Even if you aren't one of the marketing dudes or dudets who normally cover these events, ask to go and help out. Stop by everyone's booth, introduce yourself, listen to their pitch, ask questions and learn. It's so invaluable.

3. Be well read. Read everything you can get your hands on. I get between 30 and 60 Google alerts each day. That's in addition to all the email and blog reading I do. I don't read them all, just the ones that really catch my interest, are newsworthy, are something new, or are on a topic I follow. Read blogs, news sites and portals.

4. Inject what you've learned.  Share it in meetings, on calls, in product discussions, in planning discussions, with customers, etc. Bring that information to everyone. Forward relevant info (but don't spam) to others in your company. Add your comments/insights up front so they know whether the article is worth the read or the value is in your insights.

5. Talk to every company, not just the ones you like. Go talk to your competitors. You might find out they could actually be your partner. Or, they may still be your competitor. But go meet them. As Alan also told me many times, "stay close to your friends, and even closer to your enemies."

These ideas are pretty basic and simple, and while they might not shake up the world, they could redefine how you view your own business.

Zero Day Threat & My First Book Jacket Quote

I'm a big believer in serendipity, karma and helping people whenever I can. A lot of people have been very gracious to me throughout my career, and I'm always looking for ways to pay it forward. That's one of the reasons I coach entrepreneurs and enjoy starting new companies so much.

Back in 2001-2003 I started getting much more involved in the external aspects of the CTO role, working with press and analysts, writing byline articles, speaking, etc. Though I had been in a few press interviews (my first quote was in the London Financial Times in 1986 while helping with some story background), I was a huge neophyte when it came to doing media work. I received some extremely valuable coaching from Sonya Caprio at StillSecure along the way and now am pretty comfortable doing just about any media, writing and speaking work.

Early during that learning process, USAToday reporter Byron Acohido got a hold of me while researching stories about various computer security threats posed to the average computer user. This was back in the Code Red and Melissa virus days. While I'm no security researcher guru by any stretch, I've been working and creating security and networking products since the early '90s, so I was able to help Byron on background, tutoring him on the various kinds of threats, how they worked and what the current and emerging threats were around the corner. Though I didn't expect any quotes from those conversations, Byron was kind enough to quote me in 4 or 5 USAToday stories.

When I talk to press I always offer to help on background, specifically noting I have no expectations for quotes. Part of my job of course is pitching media about my companies and products when that's the topic, but I also believe in helping people outside of my own agenda. I do this with no expectations of any payback or reciprocal quid pro quo to me. If you help people, even if they don't return the favor directly, someone else down the line might return the favor to you. And even if the favor is never returned, that's okay.

Helping people with the expectation of something in return isn't helping, it's trading. You don't help people with a payment expected in return. You do it because it's something you want to do. Good karma, serendipity, etc. will take care of everything else. Trading has an expectation of something in return, helping doesn't. I'm not naive enough to believe that everyone has this philosophy -- many don't. Even with some, everything has strings attached, but that's not me. As long as people don't take advantage of that goodwill I'm happy to help, and if they do, it says a lot more about them and than me. I just have my own philosophy about helping others.

After my media work became more focused on the business market and Byron expanded his sources to researchers much more talented than me, we talked less frequently but still kept in touch via emails. Bryon is good about emailing his network whenever he writes a new piece, is looking for feedback or is seeking out knowledge in new areas..

A year or so ago, Byron sent out an email about a new book he and USAToday reporter Jon Swartz (who I've also done interviews with) were working on. Bryon has a background in investigative reporting, having won a Pulitzer Prize for beat reporting about his investigative reporting of Boeing 737 tail rudder problems and related government foul ups. Jon has also been nominated in the same Pulitzer Prize category.

I checked out Byron's and Jon's site they'd set up about the book, Zero Day Threat. Byron sent me an early look at some sections of the book, which I blogged about in a post last year.  Later Alan Shimel and I had Byron on the SSAATY podcast to talk about the book they were writing. Later, Bryon also offered my some sage advice to me about setting up my Converging Network LLC company and doing additional media work after leaving StillSecure.

Zero Day Threat is a fresh, unique look at how actions by financial, credit, technology companies and "the bad guys" not only put everyone at risk for identify theft, but result in a large number of identity theft victims because they fall in the margin of acceptable risk. Companies are playing lose with our identities because it's an acceptable level of risk to them, not us. The book is available in books stores April 1, and has already started shipping through Amazon.

This week I received a copy of Zero Day Threat in the mail from Byron. I'm very to pleased to have my first book jacket quote on Byron's and Jon's book (see below). And I also appear in the acknowledgments, along with a very nice hand written note from Bryon inside the front cover of the book I received. The quote came from something I wote on my blog back when I reviewed some early parts of the book.

I definitely never expected or even thought I'd receiving such acknowledgments, and I'm totally honored and flattered Bryon, Jon and their editors chose to acknowledge my small contributions. I also owe a dept of gratitude to Sonya, who helped me be in a position to contribute to Byron and Jon.

What this experience says to me isn't that "doing something good will get you quoted", but that you don't always know the impact you have when helping someone else. My few conversations with Byron must have been much more valuable to him that I ever realized. The satisfaction I'm feeling is more about playing some small part in helping Byron and Jon be able to write their book. The quote is gravy, and really something I take as a thank you from them both.

You never know the impact you have on people. Sometimes you learn about it later, such as in this case, but most of the time you don't. That tidbit, coaching, idea, compliment, comment in passing or something you didn't even realize, may have had a very significant impact.

Whether my philosophy about helping others has zero, a little or a huge impact on readers, I'll likely never know. Maybe it won't have an impact on anyone. Whatever the result, I hope you received some enjoyment from reading about my experiences with Bryon and Jon.

Here's my quote that appears on the Zero Day Threat book jacket:

"Rushing in to profit from online commerce and banking, financial institutions knowingly put our personal information and identities at risk -- the digital-age equivalent of tobacco companies making sure cigarettes have highly addictive properties." - Mitchell Ashley, security consultant, The Converging Network

Please check out their new book and the blog at their site. I hope they are both wildly successful.