Remember Harvard Graphics?

I saw this clever post yesterday, titled Computer Science Courses That Don't Exist But Should, and one suggested course in particular really stood out:

CSCI 3300: Classical Software Studies

Discuss and dissect historically significant products, including VisiCalc, AppleWorks, Robot Odyssey, Zork, and MacPaint. Emphases are on user interface and creativity fostered by hardware limitations.

While I am not nearly geeky enough to know all of those old products, (the only one I recognize is VisiCalc, and I never even used that), it made me think back on my introduction to software and workplace technology more generally.Pretty slick UI, right?

And the one 'classic' piece of workplace tech that I remember most fondly, for reasons I will share in a second, is Harvard Graphics, the first general use charting and data visualization tool to gain acceptance in the office. In the late 80s and maybe a little into the early 90s, Harvard Graphics was the go-to tool for creating at that time were really amazing bar, pie, line, and other types of charts that today we would just laugh at for their simplicity. But pretty soon Microsoft Office took over the office, and Harcard Graphics pretty quickly fell out of fashion.

But I loved my time with Harvard Graphics. Back in the day, when the first colorful stacked bar chart of regional sales broken out for the last 4 quarters emerged from the plotter, (look that one up, kids), and I marched it in to the CFO's office, suddenly I was looked at not like the 22-year-old kid who knew nothing, but as the 22-year-old kid who created something cool.

After getting a glimpse of what the HG program could do, the CFO started setting me off to make more and different kinds of graphical representations of our financials that would be used in exec meetings, sent out to the regional presidents, and often tacked up on the wall in the CEO's office. No one would ever tack a boring looking income statement on their wall, but a 3-D multi-colored bar chart of gross profit margin by product segment? That was high art to some of these guys, and I was the only person in the office, (probably because I could not add much value anywhere else), that was able at that time to produce these charts.

That simple little program, and the rest of the office's reluctance to embrace anything new or seemingly complicated, helped me cement a reputation as someone clever, useful, and for being what then passed for technically savvy - which make no mistake helped out your career as much back in those days as it does today.

Harvard Graphics got me at least two raises I am pretty sure.

Ok, the walk down memory lane is over. Have a great weekend and think about this little tale the next time some new and scary and complicated technology shows up in the office.

It just might be the one that gets your work tacked up on the CEO's wall. 

Users don't know what they want - but they know something

How much, or little, should product designers and developers interact with potential users and customers of the products the designers and engineers are creating?

It seems like a simple question, but if you think about it some and recall some of the famous perspectives on customer input into product development you find that the answers to this question tend to land on one of two extremes.

On the one side, you have the Steve Jobs/Henry Ford take on customer needs and wants. Jobs more or less thought customers had no idea what they really wanted, and he (and Apple), had to create that want by building amazing products that met that need (that the users didn't know they had). Ford is famously quoted as saying that if he had asked customers what they wanted they would have replied 'faster horses', instead of reliable and affordable automobiles.Ford

The other extreme, and one seen traditionally in lots of workplace kinds of technologies, is for developers and designers to build just exactly what customers request. This approach is mostly an outgrowth and evolution of internal IT shop's tendency to build custom applications based on a list of documented requirements from the end users. If the feature was in the requirements doc, it made it into the product. If not, then the capability didn't get built in the delivered product. And the IT response to downstream complaints was always, 'Well, it wasn't in the requirements.' 

So what is the best, or most effective middle ground between Jobs/Ford (customers don't know anything) and the traditional IT (customers HAVE TO know exactly what they want) approaches?

Maybe the best approach is summed up in this recent piece from the O'Reilly Radar site, 7 User Research Myths and Mistakes:

The most common reason people give for not talking to users is that “users don’t know what they want.” While that’s sometimes true, it’s not a good reason for not talking to them. It’s just a good reason for not asking them to tell you exactly what they want.

Instead, ask people about their problems. Ask them to tell you stories about how they use other products and how they make buying decisions. Ask them when they use specific products. Is it on the train? In the car? At their desks? At work? Ask them about their lives.

Users might not be great at telling you what new product they’re definitely going to use, but they’re great at telling you about themselves, and that is a very good thing for you to understand if you’re making a product for them.

That seems right to me - describing that sweet spot or middle ground between not giving a rip about what users think and the other extreme of expecting the users to tell you exactly what you should build for them.

Keep this in mind the next time you sit down with some HR tech solution provider salesperson. How much do they ask you and your team about the problems you need to address? How much do they seem interested in what makes your organization work (and unique)?

And how much do they like to talk about exactly what their product does?

You are the user. You might not know everything. But you sure know something.

Diversity, testing, and how bugs often go unnoticed

Recently I was talking to a friend who told me that he was in the market for a new car. My friend, who has been a loyal driver of a particular brand of vehicle for many years, for argument's sake let's call it Lexura (not the actual brand, but since I don't want to get hassled by any PR folks, I am making up this brand). When I asked him if he was considering the latest Lexura luxury model, a brand new one for 2015 that has generated significant buzz and some really stellar initial reviews, my friend surprised me by saying 'No', that he had soured on the Lexura brand.

When I asked why the conversation went more or less as follows:

Him: 'I like Lexura, I really do. But the last two Lexura's I owned have had the exact same problem. When it is raining, and I have the windshield wipers on, the water comes right inside the driver's window. I am always getting wet.'

Me: 'Why would you have the window open if it is raining so much that you have to have the wipers on? That seems a little odd. Most people you know, close the windows when it's raining.

Him: 'Well, usually I do. But sometimes I am smoking. And I like to keep the window open when I am smoking in the car. And then if it is raining the water comes right in off the wipers.'

A sort of odd story, and immediately after hearing the 'when I am smoking in the rain the wipers get me wet' take from my friend I starting thinking about software, (and really any other kind of product), that is developed, tested (significantly), and then is released into the wide, strange, and harsh world of customers and users.

My friend should not, on paper anyway, be driving in the rain, wipers on, driver's side window rolled down, getting wet. It does not really make much sense to most of us. It's raining. Roll up the window, dummy.

But if you are a smoker, then it is pretty common that when you are smoking and driving that you want/need the window down, at least part of the way. I guess even smokers don't really want to be trapped in a small, enclosed area with their own second hand smoke. So they open the window. And most of the time it works out just fine. Unless it's raining and your Lexura has the bad habit of directing water off of the windshield wipers right into the open window and in your face.

So let's spin this back to technology and testing and think about how/why 'bugs' like the Lexura spitting water back through the driver's window (let's just assume that it is actually, a bug for now), can make it past the testers and developers and engineers and make it into the world. Could it be, perhaps, that no one on the Lexura design/dev team was a smoker? That driving in the rain with the wipers on and window open was never actually tested, as it would have never occurred to the non-smokers at Lexura that this was actually a thing that would be important to some customers? That this possible lack of 'diversity' in the makeup of the Lexura team led to a bug that was only likely to be experienced by customers whose specific issues were not adequately represented at Lexura?

This is kind of a odd story, as I mentioned above, but I think there is something important here nonetheless.

First, it is almost impossible in the design, development, and testing processes of software, hardware, or products of any sort to test everything, every potential use case that is possible. It just cant' be done. Bugs will results, often from customers using the product in a way the builders never considered or even could have reasonably imagined.

And second, 'diversity', at least the way we usually think about it, is often a very incomplete way to frame the noble notion of ensuring all important and representative voices are heard. Because every time you think you have incorporated ideas and points of view from all the necessary constituencies, one new one you never thought about raises a hand, and wants to be heard.

Even smokers who drive in the rain with the windows open.

Have a great week.

The consumer is the enterprise

On the list of SMB-approved services is Box.  Box, at it's simplest is a cloud-based file storage service, (but has grown tremendously to become a serious player in the enterprise collaboration space), provides a flexible, simple, and eminently useful solution for storing, sharing, and collaborating on documents and files.

Box is led by CEO Aaron Levie who recently shared some interesting comments and observations about the changes in how enterprise software is being developed, purchased, and deployed at an event in London, (documented here on the Cytalk.com site), and are worth noting for both software providers and software customers as well.

I recommend reading the entire piece, but below I've pulled out below what I think is the most important, (and maybe seems like it's obvious but it really isn't), observation about how cloud deployed enterprise solutions differ from their legacy and traditional IT-dependent forebears, and what that means for both software solution providers and the modern HR organization using (or looking to begin using), cloud-based enterprise technologies:

The shift to cloud and mobile changes the way software is bought and deployed. “This shift means the onus more than ever is on the vendor. If we don’t stay competitive, if we don’t build whatever that that next thing is the user wants to do and build it in as simple a way as they expect from the consumer tools they are using, then we will get swapped out.”

By making it simple for users to deploy solutions, companies like Box need to be aware that they’re also making it easy for customers to replace them with something new. “You will either get swapped out because IT will swap you out or just because people will stop using you because they’re using a consumer solution, And because it’s SaaS, they’re only paying for what they use — and you stop getting paid”. Levie sees these forces as a Darwinian engine driving software evolution.

Any enterprise software vendor that doesn’t actually think they’re in the consumer business really doesn’t understand where the future is going.” It’s a future that he believes will carry on changing the industry. “That use-centric approach will see a very different set of vendors playing in the space. Existing vendors will have to change rapidly or become irrelevant to the world of the future.”

It seems like we've been talking about the idea of the consumerization of enterprise technology for quite some time now, but up until fairly recently the dialog and the emphasis has been around product design, user interfaces, and the shift towards mobile and tablet applications and solutions. There has been much less focus on the processes by which enterprise solutions are evaluated, acquired, implemented, and, as Levie is talking about, replaced by other solutions.

Levie's take is really interesting and hopefully a signal that in the near future enterprises (and the actual people in these enterprises), will wield more power, influence, and have more impact on how the solutions they use every day are built and leveraged. Slick interfaces and an iPhone app are great, but until enterprise solutions are forced to engage and delight the actual users in the enterprise or risk a quick replacement, then the tools we use are work will always seem less attractive than what we use in our personal lives.

Have a great week everyone!

What if there was a Yelp for HR Software?

I'm a little late on this since some of the big tech news sites like TechCrunch and CIO.com covered this back in February, but over the weekend I finally got around to checking out a site called G2Crowd, and the simplest way to describe it is as a 'Yelp for Enterprise Software.'

By now we are all familiar and possibly reliant on the crowdsourced reviews and ratings paradigm popularized by sites like Yelp for restaurants and bars, TripAdvisor for travel destinations, and certainly Amazon.com for books, music, heck just about everything. There continues to be tremendous popularity and value for sites to gather, interpret, and categorized real live customer experiences with products and services for just about anything that can be purchased. But while consumers and users love these sites, as they generally provide neutral, unbiased, and sometimes massive amounts of information about the quality and value of a product/service, many suppliers have come to fear and loathe these sites, as one or two poor reviews can sometimes cause serious damage to a business' reputation and sales.

HR Software Comparison

But for whatever reason despite there existing a 'Yelp' equivalent for seemingly just about everything, there really isn't a large, successful manifestation of the crowdsourced review and ratings site for Enterprise Software. That is the gap that G@Crowd is trying to fill, providing a platform and frameworks for enterprise customers and users of technologies like CRM, ERP, Accounting, and yes HR Technology as well, to enter product reviews and ratings just as people do for the local BBQ joint on Yelp.

The process to create a software product review on G2Crowd is familiar to anyone who has used Yelp or TripAdvisor, but with one important difference - G2Crowd requires the reviewer to log in with their LinkedIn credentials, which serves a few important ends. One, (with limited exceptions), reviewers identities are not anonymous; two, G2Crowd 'knows' based on the LinkedIn profile, at what company and in what role the reviewer was working in at the time of the review; and three, G2Works can police phony reviews left by people working for or against any of the software companies themselves.

The idea is simple really, a set of unbiased ratings and reviews of enterprise software solutions like Salesforce, SAP, Oracle, etc., that can be aggregated, (over time, and if enough scale is achieved), produce a valuable and previously unavailable resource for organizations that are evaluating software for themselves. In addition to the individual product reviews, G2Crowd has started to create, based on the review data, their own version of the 'analyst grid', positioning competing firms in a given market segment in comparison to each other, the most famous of which is the Gartner Magic Quadrant. But rather than a Magic Quadrant that represents, in the end, the opinions of one or a few analysts, the G2Crowd grid would reflect the collective experience and opinion of potentially thousands of users. In theory not necessarily a 'better' way to compare vendors, but certainly a different one, and one that if G2Crowd can continue to keep the reviews clean, would potentially be more important, (and accessible), than what the traditional analyst firms create.

Will G2Crowd catch on with enough users and customers to generate the kind of scale it needs to be a truly valuable resource to the enterprise software buyer?

Hard to say. It is a new site, and there seems to be some decent traction and volume on the CRM market. If you spend some time checking out the HR software reviews you will see they are a little thin.

But how about this? How about if everyone who reads this blog and is a current user of one of the big HR software solutions heads over to G2Crowd this week and drops a product review?

That might be a way to get this kind of endeavor a little more attention for the HR market, and perhaps also show how all of you as users of these solutions really do have the power to influence the market.

What do you think - would a site like G2Crowd be helpful to you and your organization?