Thou shalt only use Internet Explorer. Gone are the days of the “one official browser” corporate IT standard. At least that’s the principle I operate under. I’ve vowed not to purchase or select a product, application or SaaS service that restricts itself to Internet Explorer, or any other single web browser.
The world of web browsers is just simply too diverse for most organizations to truly operate under a one web browser only policy, which has traditionally been Internet Explorer in most IT shops.
Users demand choice. Users have very strong preferences. Whether it’s Firefox, Chrome, Safari, Opera, Internet Explorer or whatever… many (most?) end users want to use the web browser of their choosing, not the browser dictated by the company or by IT.
Web access from multiple devices. If I’m on my phone, my laptop, my computer, it doesn’t matter – I want to get to all applications, sites, etc. from whatever device is in use when the need occurs.That means it could be an iPad or iPhone one moment, a Windows 7 device another, or a MacBook at another time.
More and more users aren’t running Windows (or don’t want to.) What about Linux or Mac users? Why should they have to use a remote desktop, run a virtual Windows machine locally, or use or borrow another Windows computer to access an application or site that only supports IE?
Why don’t all vendors products support the most commonly used web browsers?
Supporting multiple browsers means adding code specific to browsers, supporting multiple versions of each browser, dealing with the myriad of browser idiosyncrasies, exponential testing variations, and ultimately added cost to create and support products. Having designed and built commercial web based software products, I know it’s hard and complex. While I sympathize with vendors, users don’t. If they prefer to use Chrome, Safari or Firefox, well… they expect your site, application or service to support their browser of choice.
It used to be acceptable for a product to start out only supporting a single browser, most often IE, and then add support for additional browsers further down the product roadmap. Not any more. Users expect products to at least support IE, Firefox and Safari, on Windows (IE), Mac and Linux platforms with product version 1.0. Chrome also has a loyal following.
My recommendation is bite the bullet and design for multi-browser support right up front. It’s much easier to do as you incrementally add features, versus retrofitting an entire product 2, 3 or more years down the road. And you won’t be facing the negative cost-benefit dilemma of retrofitting multi-browser support vs. adding features needed to make sales or customers happy. By the time you get to that point, you’ll be so proficient at cross-browser support, you’ll be rockin-and-rollin at creating new features that also work across browsers.
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.
Continued from a previous blog post…The Digital Age Will Save Us… Uh HuhIf 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 HurtI 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 CustomersWhat’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 FasterShifting 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.
If you create products (or run a business that does), it’s your professional and personal goal to create something everyone wants so badly that products fly off the shelves like Nintendo Wii’s at Christmas (and most of the year, actually).
There are countless examples of this kind of demand, including the Wii, XBox’s, iPhone, Tickle Me Elmo, and Cabbage Patch Kids to name just a few. Now we’re seeing the online equivalent of customers banging down the virtual doors of our servers and networks to get at products. Rockies world series tickets and Apple’s MobileMe service are examples where servers cratered over the demand by users within a very short time window.
A very recent example is the public-beta of Windows 7, the successor to the much maligned Windows Vista. Microsoft had to shut down their download servers and regroup on Friday as too many requests were coming over the gun walls, causing a bad experience for everyone trying to get new bits.
As a product creator I haven’t (yet) been fortunate to have that kind of success for a product. (But you gotta believe you’ve got that in ya 🙂 ).
Limited Supply Can Be A Good Thing
In the recent Blackberry Storm SmartPhone product launch, much was made about the Storm being the device to knock the iPhone off the top of the leader board. While the Storm certainly didn’t do that, it was a very successful product launch. It’s no doubt by anyone there would be high demand for the Storm, but Verizon stores had limited supplies of them on hand the day of the product launch. The store I visited at 6am on a Friday morning only had an allotment of 30 Blackberry Storms. All stores only had a limited few phones, and before I left with mine in hand, other Verizon stores were calling the into the store I was in looking for more phones. The warehouse was out by days end.
Certainly Verizon and Blackberry anticipated high demand upon launch of the Storm. But did they purposefully limit the number of units available on day one to help keep demand for the Storm high and in the buying market’s mind? Or were they just being prudent and protecting themselves on the backside from an over supply if the product’s acceptance didn’t live up to the pre-launch hype. The only recent product I’m pretty certain has been purposefully kept in short supply is the Wii. There’s been a shortage of Wii’s (at least a perceived shortage) virtually since the gaming console came out.
It’s A Manufacturing Problem
Then there’s the “RAM factory burned down in Japan” or “manufacturing can’t keep up” situation. Now that’s something no product manager wants to have happen. The customers are there but the product can’t get to the customer due to manufacturing.
There’s a flip side to this dilemma too. At a training course (I think it was a Florida Power and Light Quality course, but I’m not sure) we played something called the “beer game”. No, it wasn’t a drinking game like you’re thinking. It was to show how decisions in the supply chain can run afoul. You come out with the hottest new beer on college campus’ but no one anticipated that outrageous demand you’re seeing. Beer isn’t like CDs, you can’t just stamp out more… it takes time to cook. Long story short, folks in the supply chain start over ordering attempting to raise their position in the queue, and fill demand for beer money that’s been left on the table, and then… demand suddenly drops off, that beer’s not in vogue anymore. Suddenly everyone’s cancelling orders and sitting on more product than they know what to do with. It was a very enlightening scenario, which emphasized the need for systemic thinking.
Note: I always tell clients and friends I coach about blogging and social media to keep it short, three paragraphs or so. With that in mind, I’ll break this up in to more than one post.
To be continued…
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 hasreal customers telling their story about how they use StillSecure Safe Access tosecure their network.
I think this is a really innovative idea and one we'll see more of. Companieswill have to be careful that it doesn't become a slick commercial (those areokay too, just not labeled as case studies.) I think you could go with a videothat 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 tosee more of these.
Here's the Safe Access customer case study:
Just because many of us are in the tech industry doesn't mean we shouldproceed oblivious to the impact green product design is having on allindustries, including ours. Software delivered through SaaS and virtualizationare two of the more well recognized ways we as technology professionals, productcreators and technology consumers see "green" happening in our industry.Virtualization and SaaS both help reduce the carbon footprint through power andcooling reduction of hosted and virtualized software. Downloadable and hostedsoftware and documentation also reduce the paper, printing, transportation andother eco-unfriendly costs of creating and delivering products.
But the decisions we make in the creation and consumption of technologyproducts impacts our planet's carbon footprint in many other profound and farreaching ways beyond just (and I am in no way minimizing these) saving sometrees or conserving energy costs. Product designers are very often unaware ofhow decisions made early and throughout the product lifecycle can impact thecarbon footprint of the products we create. Certain paints may requirespecial ingredients having a higher carbon footprint manufacturing cost.Software the requires a large number of high speed, energy consuming diskspindles running 24×7 which could be better optimized for peak or infrequentusage. Computer hardware and accessories may have a high environmental impactbecause of their poor recyclability or the products they displace. Even how weorganize or operate our businesses can have a smaller or higher carbon footprintbecause of travel and energy costs.
A new breed of entrepreneurs, called environmental entrepreneurs, haveemerged focusing on creating greener products, services and businesses. I'mfortunate 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 theSustainable Minds team launched a series of information services for productdesigners supported by companion decision support software created by thecompany. Here's how Terry describes their offerings:
“These are the first of our information services which deliver newknowledge, processes and strategies for a life cycle-based approach to productdesign, and are the counterpart to our decision support software. Thiscombination is key for design organizations looking to innovate or differentiatethrough delivering more sustainable products or design services.Product designprofessionals can acquire new green skills, increasing their value on the joband having greater impact in organizations. Manufacturers can access new marketswith innovative, environmentally superior products that meet customer needs, andincrease brand value by credibly marketing ‘greenness’. Our aim is to cover theexceptionally broad topic of sustainable design with experts from diverse areaswho drill down to specifics that practitioners will findilluminating.”
I like and believe in the pragmatic approach Sustainable Minds is taking tohelp advise and education product designers, and support the design process withdata and tools. Terry likes to say, "The bottom line is, there is no suchthing as a green product – all products use materials and energy, and createwaste." See what I mean about Terry's pragmatic approach? To help designersthroughout the entire process, the company created Okala, a lifecycle assessmenttool for creating more ecologically sustainable products. She has also assembledsome of the leading experts in creating sustainable products who arecontribution to the Ask the Okala Expertsblog.
I believe we as product creators and designers should be responsible foreducating ourselves about designing more sustainable products. Terry talked atPARC prior to launching Sustainable Minds and thisvideo gives you some good basic information about sustainable design. The Ask the Okala Expertsblog is a blog you can also follow to hear from thought leaders in the space. Iappreciate your checking this information out and sharing it with other friendswho might benefit from this information. I'm learning right from Terry and theSustainable Minds team right along with you.
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 tobe able to give a demo without scheduling an SE or the demo system? Want a goodscenario-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 arecorded demo. It's that easy and it works.
I've helped create Flash demos (see thisexample) using voice overs for the presentation, and also recorded lessformal demos, using products like Camtasia Studio and aPC headset microphone (See this Xobniexample). They work very effectively and sales people love 'em. Send thecustomer 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 oftechnical glitches. After using the recorded demo, follow up with an onsite orweb demo to answer specific questions not covered in the standard demo… butonly when necessary. A recorded demo is probably all that's needed in manysituations. And giving a customer login credentials isn't the equivalent of arecorded demo. They are just as likely to have problems or struggle finding whatthey are looking for, so I'd recommend not giving customers their own demologin.
I can't say enough how effective and useful recorded demos can be. They canalso significantly shortening the sales cycle, and free up SEs to handle morecomplex or specific customer issues, rather than presenting general productdemos in every customer situation. They are definitely easy to create so I'dlook into it if you don't already have a recorded demo.
Use a self contained demo. If anything can go wrong in ademo, it will — so, if you are going to give a live demo, leave as little tochance as possible. The less outside factors you have to rely on, the better. Doyou 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 thecustomer's proxy, firewall, or VPN connections through their network. If allelse fails, have a demo slide deck you can use in case you can't connect, theserver's down, your laptop decides to croak, something's messed up on the demosystem, or things aren't going well and you need to retrench.
"Boy Scout" Rule of Demos – Be prepared. Bring your ownprojector. Invest in one of the compact projectors you can take on the plane. Ican't tell you how many times I've walked into a customer's conference room onlyto find some ancient projector that's the size of a trombone case, has reallybad faded color, or one that my laptop just won't sync up with correctly. Nowyou spend all your time and focus acting the part of the high school AV guytrying 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 haveto 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 onethat's going to cause issues getting the meeting started. Switch to a differentservice if you do have issues until you find one you like and worksreliably.
Lastly, carry what I call my "Swiss army knife cable kit". I have two verysmall portable hard drive travel cases I carry in my backpack that have justabout every cable and connector combination you can think of in it. It's lightweight, doesn't take much room, and now I'm prepared for just about anythingshort of using a flashlight to do a shadow puppet demo. (Oops. Better add a flashlight.) Just make sure you takeall your equipment and cables with you when you pack up and leave.
How do you get to Carnegie Hall? Practice, practice, practice. Samefor demos. Make the demo the smoothest and easiest part of yourcustomer meetings by knowing the demo cold. Know what works, and where there arepitfalls or dead ends. Know your product front to back. Anticipate how you'llanswer questions, whether it's worth the time to traverse to the place in theproduct that answers the question or if you'll just tell them verbally. And mostimportantly, be at your best by literally talking through your demo frombeginning to end, working through the rough patches where you stumbleyour words, repeat yourself or forget those salient value points you want tomake sure come across.
There's a reason why there are mirrors in hotel rooms and its not only foradjusting your tie or fixing your hair. Stand up when you give a demo so youhave better command of the room and visibility of your audience (and visaversa.) And practice standing up, just like you will when giving your demo inperson. Instead of watching reruns of Myth Busters in your hotel room, practiceyour demo for the upcoming customer meeting.
Don't bag dive. Have you ever seen a situation like thishappen? "Hello Customer. Thanks for having us in. Okay, I think the best thingto do is start off by showing you our product…" That's called bagdiving. Demos and product literature are the security blanket of selling. When unsure or uncomfortable, people love to bag dive, missing all the upfront dialogue to set the stage for the meeting. I don't want to waste aprospects time until I know how I can laser in on helping them, and I nowknow to communicate that to the customer. Before you start anything else, set the context andobjective of the meeting, reconfirm needs and problems, understand who's in theaudience and why, etc. (I talk about this a lot more in my other two posts aboutdemos.) 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 quicklyderail 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 toofake, you are just creating another obstacle the audience must work through toget 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 demosI've been in where I cringed because the demo system had embarrassing orquestionable data in it, causing a "note to self" to fix the demo data rightafter the meeting. Software developers are famous for taking license by usingquestionable or unprofessional looking data in their test systems. They're justhaving fun and don't think that anyone outside their team would ever see thedemo data. Invariably someday they are asked to show software that's underdevelopment, or the test data spills over into the demo data. Again, if it canhappen, it probably will.
A demo account called "moron customer" probably isn't going to show you oryour product in a positive or professional light. Even an account called"developer account" (unless your product is a development tool) might scream tothe customer "this software isn't baked yet, it's still under development". Youdon't want the demo data detracting from the real purpose you are showing apotential customer your product.
Scripts that feed in data or reset data nightly can be a blessing and acurse. Some products need ongoing data pumped into them to show how the productworks (take a security monitoring system for example.) Scripts also help bringthe demo system back to a known state every night, taking out any changessomeone might have made while giving a demo. You often also have to use scriptsto change dates in the data (so it stays relevant). But as always seems tohappen, scripts break, they don't run, or something gets whacked when the demosystem is upgraded. Put your demo system under change control, so everyone knowswhen it's unavailable, and what changes are being made. Test the demo systemafter every upgrade — It is a production system, not a develop box. And loginto the demo system right before every demo to make sure everything's up andrunning. Double check the expected data's in the system. No sense in taking anychances.
Stop selling when the customer is sold. You can undo a lotof really hard work by over selling in a demo. If you had the customer atthe login screen, then stop demoing and close the sale. We all know you'rereally proud of the latest doodad feature that was just added to the product butthat 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 questionsyou've identified, and wrap things up. It'll save you from a lot of bruisedshins, 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 reallyowns the demo system, but a bunch of people work on it. I've come tothe conclusion that whoever is creating the messaging, value points and demoscript 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 oneperson should own it. Support may come many other technical resources but makesure you have a clear owner. And that person or group is also responsible fortraining the rest of the organization on giving demos.
One last point about the demo system. Your product release cycle needs toinclude the creation and updating of demo data, to appropriately demonstrate newcapabilities, and it needs to include upgrading the demo system software andscripts. It should be scheduled as part of the product release process, justlike collateral, training, and PR.
The best demo may be the one you never give. Believe it ornot 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, customerreferences are very strong, the match of customer needs and your capabilitiesare spot on, an employee from a previous company that used your product acts asa testimonial, product reviews or analysts reports speak volumes about thegreatness of your product… those are all good cases where you may not need todemo your product. So keep that in mind. You can seriously shorten thesales cycle when you can make the case for the customer to buy your productwithout having to do a product demo.
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.
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!
I was talking with a friend and fellow musician JasonMendelson last week and the topic of software delivery came up during ourconversation. Jason knows that I have a lot of experience leading product teamsto bring software products to market. I’ve learned a ton about shipping productsand if there’s a mistake you could make, well, I’ve probably made it at one timeor another, and sometimes more than once.
When it comes to shipping software, delivering software releases on time isone of those seemingly elusive concepts that most everyone desires butfrequently don’t achieve. (I actually believe delivering on time is a learnedbehavior, but that’s for another blog post.) Quality can also be an elusivegoal, especially for startups who may not have a lot of experience workingtogether as a team, or are under huge pressures to deliver releases. Dialing inon the winning customer experience and product feature mix is another passion ofmine that’s vital to creating great products. I could blab on about all thesesubjects 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 aproduct development effort, sometimes for the very first time. Frequently they’vecome up through the developer ranks with a lot great experience that sets themup for new opportunities leading product development efforts. I always try to helpthem understand a key lesson I’ve learned; while I love software developers and theinnovative work they do, I trust most what QA software testers tell me about thequality and completeness of a software release. I’ve advised more than onedevelopment 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 lookingout for your best interest.
Software developers, engineers, artists, or whatever job title you chose tocall them, are a loveable, creative, quirky, smart bunch of people who have totry and envision how best to build software that embodies the vision and needsof the business. They are a great group of people and I love hanging around themand being part of the team. Sometimes product developers get great directionand it seems more often than not a lot is left up to their interpretation whencreating a new product. Hopefully someone is giving them great input about thetarget user personas, product requirements, user interface design and help withkey decisions about the product architecture and which options help the businessmost achieve its goals.
But inevitably, releasing software products can become a grind. What’s afterthis release? Another release. And after that, another release, etc., etc. It’shard work and developers are frequently in a situation where they have to be asproductive as possible, inevitably making decisions that could make or break theproduct’s quality, feature set and success in the market. Developers have a lotof competing needs to balance and are often asked to make decisions without thetime or input that might help make that decision the best one. That’s where thedevelopment leader, manager and/or product manager comes in, btw, making surethe development team grasps the impact of various options and decisions, andalso that business leaders understand consequences of certain demands whichcould 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 rightthings done to create great products.
It’s also why asking a developer questions like; Is it done? Is ittested? 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 shipto a customer? I could think of a million questions that while I’ve askeddevelopers, I know I may not have gotten a completely accurate picture based ontheir answer. In many ways developers are too close to the problem, head deepinto creating the solution we need. One developer is likely only working on oneportion of the software release, and more work is required to integrate and getall the elements of the full release working together. That’s why everyone knowsthat to get quality software you shouldn’t rely just on developersthemselves testing their own code. That’s also why I trust developers, but Itrust QA engineers more when it comes to understanding the true state of asoftware release.
QA guys (guys and gals) tend to think very differently. Their job isn’t tocreate stuff, it’s to break it — anyway they can. Because if they don’t find aproblem, that means a customer will. And some people just have a real knack forit. The best are also very detail oriented, don’t assume anything and watch tomake sure nothing gets by them. The best QA engineers are also very good abouttracking results, creating thorough test plans which get a lot of scrutiny byeveryone including the developers, automate testing, and understand the value ofmetrics and how this can raise the learning and skill of the entire team atreleasing quality software on time.
QA engineers are also the first point in the process where someone isactually trying to use the software. Functional testing doesn’t always drivethis out, but scenario or use case based testing can make a really bigdifference. Using your own products in your lab or by your IT staff can also bea great way to get real usage feedback, in addition to customer experiencetesting of course. Testers also have great suggestions about the product. Theycatch nonsensical error messages, product inconsistencies, or encounter areas ofthe product that are hard to use. Most importantly, QA engineers know they arethe last in line to judge the release, and take their responsibility veryseriously when it comes time to say whether they think the release is ready ornot. QA engineers aren’t just critiques, they want to ship the product too. Theyjust don’t want to be embarrassed, taking it personally when bugs or qualityissues escape the testing process and are found by customers.
I also believe the effectiveness of any QA team or department is a directreflection on their leadership, including the visibility, importance and voicegiven them in the product development process. One of the things I’ve learned todo as a development manager, VP engineering or CTO is to hold my own weeklymeetings with the QA team. Development managers are welcome if they like too.This is our time to talk about release testing, QA processes, metrics, testplans, lab needs, improvements, suggestions, issues escalated from support, and– most importantly — give QA a voice directly to the top of the organizationto say whatever needs to be said, good news or bad.
I hope this explains some of my learnings around the philosophy, lovedevelopers, and trust QA. The fact of the matter is that I love them bothfor what they bring to product development, and I trust them both too. But Irely on their skills, experiences and judgment differently, and at differenttimes, bringing the best strengths of both to release great software products.