In 2015, 26% of global security decision makers consider privacy as a competitive differentiator for their organization.* But what does that even mean? And how would an organization achieve this?
Last week I was out in Las Vegas for Privacy. Security. Risk. and moderated a panel on this topic. Panelists included Michael McCullough (CPO, VP, Enterprise Information Management and Privacy, Macy's), Nathan Taylor (Partner, Morrison & Foerster), and Jamie May (VP of Operations, AllClear ID). Two things were clear:
The ability and desire to use privacy as a competitive differentiator heavily depends on the nature of the business. For example, a cloud provider would approach this differently vs a company that sells gasoline.
Treating privacy as a competitive differentiator vs marketing/selling with it are separate concepts. Some organizations may choose to embrace both. Treating privacy as a competitive differentiator has more to do with corporate culture, privacy practices, and your privacy team. The notion of responsible information management came up several times during the panel session. There is also risk involved with marketing/selling with privacy as a competitive differentiator; if you make a promise, you must be able to fulfill it.
I’ve read a lot recently about the emerging danger of increasingly powerful artificial intelligence. Are there dangers? Of course, but I don’t think we have to worry about machines suddenly deciding it’s in their best interest to end humanity. Here’s why:
The debate first assumes that machines develop a “self-interest” that’s distinct from their programming. Again, leaving aside all the research that demonstrates that the relationship in humans between self-interest, rationality, and intelligence is weak, at best, let’s assume that machines do “learn”:
the need to protect “themselves”;
acts that can protect them from humans;
the ability to discern the impacts of taking those acts; and
Customers increasingly use web self-service as a first point of contact with a company. In fact, last year, web self-service was the most commonly used communication channel for customer service, exceeding phone use for the first time ever.
Companies are not only investing in customer-facing knowledge. They are also using knowledge management solutions to add order and easy access to content for customer-facing personnel - specifically for customer service agents. Our data shows that 62% of technology decision-makers say that they have implemented or are expanding their implementation, and 21% plan to implement their knowledge implementation in the next 12 months.
Knowledge delivered to the customer or the customer-facing employee at the right time in the customer engagement process is critical to a successful interaction. When done correctly, deeper knowledge can be used to personalize an interaction, increase customer satisfaction, reduce call handle time, lead to operational efficiencies, increase customer engagement, and ultimately drive conversion and revenue.
These words, taken from the Hippocratic oath, are ones that I think application development and delivery professionals should consider carefully as we watch the latest example of "Software eating the world" gone wrong. In this case the software algorithms in the "defeat device" that Bosch created for VW defeated emissions testing for millions of diesel cars. Now, 7 years later, VW is setting aside $7.3 billion to remediate the result. But this is just the latest example of developer complicity in creating algorithms of questionable quality. Consider:
Facebook's manipulation of users' news feeds. In 2014 Facebook revealed that it had manipulated the news feeds of over half a million randomly selected users to change the number of positive and negative posts they saw. It was part of a psychological study to examine how emotions can be spread on social media.
If you follow me on Twitter or if you attended WRC at the beautiful Cavalieri hotel in Rome you’ll know that I had the privilege to moderate a panel of distinguished retailers to discuss the subject of discounting, specifically selling for less than the planned margin.
One of the event’s sponsors JDA had earlier presented data from a survey of retail leaders showing that their top foiur risk concerns included : increasing competitive threats (41%); margin erosion and cost reduction (39%); data security threats (25%), and attracting and retaining customers (24%).
Our panel, hosted by Congress sponsor and price optimisation software vendor Revionics, tackled the margin erosion issue asking: ‘How do we kick the discounting habit?’. The panellists, ranging across wholesale, fashion and apparel and general merchandise sectors, established a consensus view that discounting for its own sake, without a clear strategic goal and tactical execution, could be more damaging than beneficial to the bottom line – as was also arguably seen more recently with some of the more negative sentiment generated around Amazon Prime Day, as well as Black Friday.
This past summer, we at Forrester continued to explore new and innovative methodologies. One of my highlights was visiting the IIeX conference in Atlanta back in June. And although I was impressed by the variety of new (qualitative) methodologies, it’s rarely a matter of choosing one or the other. The recent GRIT report by GreenBook shows, for example, that many market research online community (MROC) vendors dropped a few places in terms of innovation, but I agree with Andrew Leary from Ipsos SMX that these online communities will continue to play a relevant (and innovative!) role thanks to their flexibility and variability when it comes to size, duration, integration, and scale.
I recently researched the MROC space, interviewing all the major players to understand their capabilities and how they support organizations. I found that there are a number of ways that MROCs aid customer insights professionals, including:
Creating a better understanding of consumers’ drivers. MROCs allow us to ask consumers in an open-ended way to describe their experiences across the purchase journey, anywhere from the point they learn about or research the company to when they follow up for customer support. In turn, these findings can have an impact at any level of the organization. These insights become even more valuable for ongoing communities.
Stop reading now if you don't care about the machinations, architectures, and human reality of software. This post is for software philosophers and architects.
Dries Buytaert, the founder and core committer in chief of open source Drupal (according to Built With, the second most popular content management system software among the top million web sites) posted thoughtfully on keeping his open source software always in a shippable state. He writes this after a 3-year delay in releasing Drupal 8:
"We [will] create a feature branch for each major feature and only core committers can commit to feature branches. . . . Once we believe a feature branch to be in a shippable state, and it has received sufficient testing, we merge the feature branch into the main branch. A merge like this wouldn't require detailed code review."
This is sensible and now standard practice: Develop new features as decoupled components so committers and software managers can add them to the application without breaking it. That keeps the application always in a shippable state.
But the future of software is more than decoupled components. It also requires highly decoupled runtimes. That's called a microservices architecture: decoupled components available over the Internet as decoupled services. Think of it as a software component exposed as a microservice -- a microservice component.
A microservice to place an order is decoupled from a microservice to alert you that your shoes have shipped. A microservice to display an image sized to your phone or computer is decoupled from a microservice to paint the page.
My report “Develop Your Sales Enablement Charter Or Run Into A Perfect Storm” for Forrester clients, and the associated blog for all, has prompted many inquiries — from business decision-makers in B2B marketing or sales management; from technology decision-makers; and, of course, from the sales enablement vendors themselves. Some have questioned my sense of urgency — “Will things come to a head in sales enablement so quickly?” Well, here is an email that I received from Forrester’s own VP of sales operations that echoes most every sentiment I’m hearing from the sales enablement buying community:
I get contacted multiple times per week with vendors who have technology around streamlining and/or improving some part of the B2B sales process. I (and my team) have taken a number of these calls, and there certainly is some interesting technology out there, however it feels like there is a huge market inefficiency going on that is manifesting itself in two different ways:
There are many vendors that are attacking a small piece of the B2B selling process — i.e., forecasting, or gamification, or content distribution, etc. Because of this, each of these vendors [is] somewhat of a niche player, and it becomes harder to justify the ROI of any specific player. In addition, you have to go through a separate sales cycle with each one, with a separate procurement process, and if we do decide to purchase, completely separate integrations that likely leverage the same [scarce] Forrester tech management resources.
I recently completed preparing a presentation for the Forrester Digital Business Forum in Chicago this fall. The session I’m delivering is on delivering mobile app quality, and through my research, I’ve learned that security is an important part of app quality. My colleagues Michael Facemire and Tyler Shields recently published a report on The Future Of Mobile Security Development and that, plus some experiences I had working with a development team in a previous position, started me thinking about what it takes to make a developer that understands how to code apps securely. The report I listed above covers the security topic well, and makes some recommendations on how the security aspect of app development is likely to change, but beyond security capabilities and tools, how do you ‘create’ the type of developer that understands exactly what to do to build security into their apps?
I know trial and error works, but that’s expensive. Tools exist that can validate security aspects of an application, even tools that enforce security on apps, especially mobile apps, but those are last mile solutions – what do you do to help developers implement solid security into their apps in advance of those tools? If you have insights into this topic, can you reach out to me and let me know? I think this would be an interesting report to write.
CRM purchasing is undergoing a sea change. I see that companies are no longer purchase heavyweight, end-to-end CRM solutions that have had the reputation of being complex, expensive and hard to implement - even if they have great industry specific capabilities. They itend to mpede user productivity with a bloated set of capabilities that many users can't leverage. A number of dynamics driving this change in purchasing behavior:
CRM purchases are moving to the cloud. Companies are replacing legacy CRM with SaaS solutions at a higher rate than before. Cloud CRM has gained traction, as it provides lower upfront costs, better flexibility, and faster time-to-value compared with traditional on-premises applications. It also shifts the burden of software maintenance to the vendor.
Cloud CRM extends the life of legacy CRM. Modernizing legacy CRM to support omnichannel customer journeys is a critical priority. Companies are using cloud CRM to complement and extend on-premises implementations. Cloud CRM provides the systems of engagement while legacy CRM provides business process support and data management capabilities.