By Tom Gersic
As senior director for Cloud Services at Salesforce, I was asked to form a strategy for my organization’s Research & Development. As the name implies, Cloud Services is the services arm of Salesforce — consultants, frontline support personnel, and the like. We provide our customers with prescriptive advice, best practices, and even onsite experts, so that they can achieve business value from Salesforce faster.
It has been an interesting effort to define how to shape R&D within the overall strategy of our organization — in this case, to offer always-on expertise from the people who know Salesforce best, data-driven insights from our unique view into the cloud, and design-led innovation to help our customers fully realize their vision and create experiences customers love.
With this as the first in a series of posts, I’ll highlight what we’ve learned over the years at Salesforce from our clients and our own teams. Each post will explore both business and technical initiatives that can help you build out your own plans to transform into a more innovative, competitive organization. In this first post, I will focus on the importance of research-driven human-centered design in R&D process.
A Unique Problem
I’ve spent most of my time at Salesforce helping our biggest and most strategic customers transform their own businesses for the better by enhancing the way people work and opening doorways to new business opportunities. But turning that lens internally within Cloud Services was a new challenge. After talking to senior executives across the company, I realized that what we needed was a process by which to grow and scale our ability to consistently help our customers innovate. Our mission became one of transformation — designing and developing intellectual property to better enable our teams to be successful in the field, which would accelerate the growth and customer impact of Cloud Services.
R&D is not just about Development.
The first thing I noticed when I began talking to people about R&D strategy is that the picture that comes to mind most frequently for most people is the D of R&D, as it were — development. Coding and architecture. This illustrates a challenge that I’ve seen in many organizations: Too many large companies try to innovate with software by focusing only on development. They put the cart in front of the horse, and completely forget about the other letter — the R — Research.
A design-led team needs to be research-driven, using qualitative and quantitative methodologies to drive rapid innovation. To me, research means taking the human-centered design expertise of our Experience Design team and interviewing the people who may some day work with whatever it is we’re developing. If our customers aren’t involved in the process before we start developing, then we’ve already missed the boat. We start with user research, iterate our design and development efforts based on customer feedback, and ultimately bring to market the things that those customers have had a part in building through that feedback.
It’s all about the users.
When we talk about research with customers, we don’t just talk with business and IT leaders. Decision makers are important to the sales process, but design needs to account most critically for end users. Many business and IT groups ignore user research, believing that a focus on business and technical requirements is all that is needed to build successful software.
When working with our customers on development projects, the initial reaction we often get when we ask for time with end users is, “that’s not needed for this project,” or “that’s just too costly.” After all, those users are busy with their day jobs, and if the end user is a top sales rep, bringing that person out of the field and into an office to meet with consultants means lost revenue.
From field technicians to sales reps to managers to executives, we are all end users. We all have an opinion on the tools we use every day. We know a good app when we see one, and we certainly know how to complain at great length about a bad app that we’re forced to use. It’s not a given anymore that people will use the tools they’ve been given by their employers. Even if employees must use them, they won’t necessarily use them effectively.
When we take the time to talk with end users and integrate their feedback into the R&D process, we are ultimately far more successful. We get not only their initial feedback about what they need and how they work, but also their buy in and support in rolling it out when it’s ready to launch. Those users champion an app or process they had a hand in to their colleagues and friends in a way that managers, trainers, and consultants can’t.
User Research in Perspective
Several years ago I worked closely with a large manufacturer of heavy industrial machinery — agricultural tractors, mining equipment, and the like. The team there initially asked us to build an app for tablets to be used by service technicians. The iPad had just been launched by Apple, and many companies were excited about the possibilities afforded by these new devices.
Many of our clients expect that we’ll begin our projects with them by “collecting requirements.” Some even just hand us a list of requirements that they’ve already collected, and are surprised that we need more information. I’ve been told more than once, “You guys are the experts and you’ve done this before. Stop asking questions and just tell us what to do.”
With this company, we asked to start the project by having members of our team do ride-alongs with their field technicians. This was no small ask, to be sure. Their technicians mostly worked for a network of partner companies in remote locations and were completely disconnected from the internet for days on end. What we learned: These technicians had to climb over large earth-moving equipment, complete checklists, and take pictures of problems they found. They needed two hands available at all times, so had to be able to put any devices in their pockets quickly. They needed a phone app, not a tablet app, which would be useless to the end users.
Another company we worked with was looking for a mobile tool to help with selling beverages in remote locations across Latin America as a part of a rollout of a more consultative sales process. During the course of that project, we learned that expensive, flashy mobile devices were a real liability because they could make a person a target for theft or kidnapping. We needed the app to work well on cheap hardware that could be hidden easily and would be less likely to interest thieves.
How to transform
User Research is imperative to a human-centered design processes, and it’s imperative to any successful R&D initiative, but it’s not the only thing to consider. We also had to consider how to adapt our methodology, how to incorporate a global team, and what KPIs to track for our customers and ourselves.
What have your experiences been with creating innovation in the enterprise? Have you seen success? What would you like to hear more about? Let me know on Twitter at @tomgersic.