Marketers: Take the Ultimate Survey of All Surveys Ever

In digital marketing, the good old market survey (or, MkSurvey™) remains one of the staples of our business. While surveys can become very useful research assets that add value for you and your customers, they can also be unproductive or a minor nuisance when overdone or improperly conducted. A survey on surveys? Let's do this.

Take the quick 10-question survey yourself, and invite your marketing colleagues (or any peer involved in surveys like these) to join our study group.

Take the survey survey now.

As it turns out, I know a lot of technology marketers. And I hope you share the survey with your friends to make the results even better. By the end of the month, let's get enough response to have a useful study on surveys that answers the question:

Are surveys useful tools for technology marketing, or have they seen better days?

“When in doubt, run a survey.” - Fake Ben Franklin

[Image from wikicommons: {{PD-US}}]

The Reverse Iceberg of Technology Marketing Part 1: Extreme Forces

Marketing in support of any complex technology is an inherently unstable proposition. Competition relentlessly drives innovation, and that need for innovation will drive change in how you position and sell your solution.

As your company evolves and adjusts to market pressures and growing expectations, it is a safe bet that your marketing strategy and message will be revisited early and often. Here’s a simple model for negotiating this level of change. 

I’m sure you’ve seen the “tip of the iceberg” metaphor used to represent how the part you can see above the surface (i.e. your personal appearance, or the company image), is dwarfed by the underlying chunk of ice that carries a lot more weight (examples here).

While this metaphor is fine for many purposes, I’d like to propose a reverse iceberg platform for technology marketing that is inherently unstable. In an environment where you are often only as good as your last release, marketing loses much of the inertia underpinning the business itself. Even well-established brands are subject to being “flipped” out of the market – half of the S&P 500 Index companies are likely to be replaced in the next 10 years, if estimates hold up.

Basic Reverse Iceberg of technology marketing concept. 

Let’s say your marketing message is a cute seal, riding on a fresh chunk of ice, broken off of the permanent shelf it once frolicked upon. If you are that seal, you should not lean your ice sheet too far forward (speculation), nor attempt to inhibit change by leaning too far back (convention).

To survive on this platform, your message must not only be differentiated and fit your brand, it must continuously avoid the two extremes of speculation and convention as it moves forward on the current, to avoid being toppled.

I liked comparing the surface to ice, rather than a surfboard or boat, because it takes into account the “slippery slope” effect of not being able to reverse course if you get too far out of balance. 

How do these extreme forces play out in messaging your technology?

Speculation. This is commonly referred to as “getting ahead of yourself” or “being out over your skis,” and chances are you’ve already seen enough high-profile examples of this in action. It is natural to want to aggressively go to market in response to perceived threats or opportunities, but leaning too far forward can accelerate a problem for a company that cannot meet demand.

For instance, let’s say you are running a massive ad campaign to announce a product launch, without the necessary support on your site or service to handle the increase in traffic. Or, your sales teams are delivering a message – invented in PowerPoint – around product features that are not yet delivered or proven by customers.

  • Problems: High inconsistency of message, high risk of failure, poor customer experience, loss of credibility, inability to capitalize on interest or demand, fast customer churn
  • Solutions: Try evolutionary vs. revolutionary changes, soft launch or graduated release, be more selective about target customers, run advance beta or survey programs, recruit customer or expert validation, track customer value as a success metric, go deeper

Convention. The risk in this conservative approach to messaging is often much harder to detect until it is too late, as it happens over a period of time. Even very large companies can scarcely afford to stand still, as dominant players can suffer the “death of a thousand bites” of nimbler companies that are not only doing specific work better, but targeting messages to specific customer needs more accurately.

Overly conventional marketing focuses on message parity – what industry peers, analysts and competitors are already talking about, rather than expressing a unique point of view and direction. While it is counterproductive to attempt to forge a totally unique message every time, your message does need to demonstrate that you are evolving, thinking, and actively participating in the exchange that drives your market. 

Don’t be jealous about allowing your experts to evangelize innovative ideas, either – if the topics are worth discussing, they are not as proprietary or as permanent as you may think. Remember that if you don’t express market-leading ideas, chances are someone else will.

  • Problems: Becoming irrelevant to the market, slow content production, undifferentiated or boring messaging, teams and customers do not resonate with the message, competition appears to be more advanced
  • Solutions: Commit to a thought leadership perspective, encourage customers and peers to join the conversation, participate in communities, focus on openness, avoid jealousy, go higher

You might say all of the above should be common sense advice, but it is surprisingly easy for companies to fall prey to the extreme forces of speculation and convention, given the competitive nature and high rate of change inherent in marketing technology. Fortunately, these extreme forces have gentler counterparts you can use to keep your messaging in equilibrium: experimentation and evaluation. We will take a look at these balancing forces in a future installment on the reverse iceberg messaging topic.

Guest Post: On-Demand SV Breakfast in the Cloud

Here's a fun complete breakfast I prepared, photographed, ate and then wrote for the community site sponsored by CA, ran Dec. 16, 2015. (See original post at - JE

It’s been a while since Service Virtualization (and this site, for that matter) came out, both as a practice and a technology. Since this site was launched back in 2010, it seems like another trend has occurred: fast food restaurants selling breakfast food 24/7. I don’t know about you, but breakfast is still by far my favorite meal. If everything you want is there, no meal beats breakfast. So why not have a complete breakfast there whenever you want it?

The invention of Service Virtualization in 2007 was huge for resolving dependencies in development and testing, so those teams could move forward without the “complete breakfast” available. At the same time, SV inadvertently resolved some of the primary constraints to serious enterprise adoption of public dev/test cloud environments. We used to describe this phenomenon of constrained components that you can’t simply import as “wires hanging out of your cloud.”

Take any system that you need to have ready for testing, but is not readily available. It could be a heavy mainframe that is too bulky to image as a VM, or a third party service you don’t have the access permission to copy. It would be much easier if you could realistically simulate just the behavior and data you need to run tests with those components.

So SV gave us a lightweight way to eliminate these constraints by replacing them with Virtual Services. This new technology is now a standard practice in large enterprises, with several major vendors offering solutions in the space. SV is proven to “cut the wires” of dependencies in dev/test environments.

That’s great for traditional on-premise environments, but it is especially useful in cloud dev/test scenarios, where dynamic availability – anywhere, anytime — is of the essence. Cloud infrastructure has come a long way in the last few years as well – offering increased capacity and performance at decreasing cost. We're seeing some huge environments running in cloud labs now at every phase of the lifecycle, including CA applications, SAP test regions, Oracle RAC servers, the list goes on. You can even invoke and specify these environments via API with a host of new IaC (Infrastructure as Code) and automated deployment solutions like CA’s Release Automation and CI/CD tools like Jenkins and many others. Containers have also now become a new, happy meal player in this complete SLDC breakfast.

Having the real thing in a 24/7 cloud is great, but who really wants a Coke with breakfast? In many cases, even if you could get the whole production-style application architecture imported, you may not always want the real thing in your dev/test cloud. Production systems may respond and perform unpredictably. If you are developing an application that will talk to production systems, you will likely need to suss out all the boundary conditions in your battery of tests. For instance, what if the mainframe responds in 30 seconds instead of 3 seconds, or .3 seconds? What if my partner’s service returns my form request with an unknown error, or a bunch of SQL hack statements? 

It takes too much work and coordination to try and make every other team’s system respond exactly as you want. But you can easily make a virtual service learn the behavior, and get Test Data Management (TDM) to supply the exact right data, so that you can have it all dynamically provisioned in a cloud environment that does exactly what you want, on-demand. And other teams can get that same level of customization and on-demand environments that are separate so they can work in parallel, without having to become experts in how the whole application infrastructure and network is set up. Better to focus on the aspects of development testing, integration and performance testing that are in the scope of your requirements, and simulate the rest with SV. 

The same concern applies to virtualizing test data. Unless you are getting close to production phases of your SDLC, you shouldn’t have to deal with extracting and loading huge volumes of production data into dev/test environments. When policy demands test data be scrubbed of sensitive info before being loaded, TDM provides another lightweight asset that can provide valid “virtual test data” and be spun up in a public dev/test cloud.

What’s cool is that all of these modern development and test technologies can be loaded into an environment in Skytap, along with all the pre-configured servers, network and domain settings, and management controls needed. Then you can instantly stamp out clones of the exact environments needed to advance development, test and release activities faster than we ever imagined.

Yes, SV and Environments-as-a-Service in cloud infrastructure are great technologies separately, but when pulled together, and given automation, they make up a complete breakfast of dev/test champions that is available 24/7. Don’t just settle for serial, or cereal breakfast just because it is late. Customers won’t wait for it. So why should you?

Go Frack Yourself for Content

I may have a right to call myself a storyteller in business terms. I've written a mountain of blogs, white papers, brochures and ads, as well as producing them in some online, interactive, video or print form. That seldom means a one-man effort.

I've encountered a lot of peers in my time who are brilliant developers, wickedly effective field engineers, or very creative designers, but for some reason they don't seem to think they are able to write or create useful content. Maybe they don't think they are good writers -- or maybe they don't think they have the time -- but get them in front of customers or a team of peers and they sound quite passionate and articulate.

Realize that every time we talk to a customer to offer a solution, or talk to a peer to solve a problem, we're all actually generating great content that could be "fracked" and captured.

If you know me, you know I'm not a huge fan of actual fracking, or the environmental impacts resulting from pumping chemicals into the earth (seen the Gasland documentaries anyone?). But I do think the metaphor applies quite nicely for getting story angles from subject matter experts who are reluctant to make material we can publish and use for content marketing purposes.

Finding time to go into your cave, perhaps sniff a brandy and write a well-worded piece, while managing customers/projects/budgets at the same time seems impossible. To resolve this, an expert might try passing on the task to a writer, but that won't solve the ongoing content crisis if the writer is left to their own devices to figure out what your real conversations are like.

I'm constantly trying to get experts to self-contribute something to the process. More often than not, I have to corner them and "frack" that wisdom out of them. Don't worry, it's not as painful as it sounds. In fact, we're just having the same real-world conversation you would have in a client visit or project meeting. If a writer like me is forced to do this on his own, it may take a while before the content meets your need if there's no spirit of collaboration going on.

Content fracking is not a big-bang one-time event. Like software development, it is far more agile and likely to be effective if you do it on an iterative, ongoing basis. The temptation to say everything perfectly, and cover a 360-degree view of your business is the primary reason why companies fail to publish interesting messages on a regular basis. It's far more plausible and interesting if your messages tell a smaller piece of a bitter story that evolves over time.

So even if you're not a content-oriented professional accustomed to writing, let me encourage you to at least capture your thoughts and conversations. For instance, try keeping a running log of any conversation topics of the day, and categorize them later. Or carry a voice recorder around and articulate what you are working on, or post-mortem the task you just finished. Even if the stories you frack out of yourself aren't ready for prime time and require plenty of wordsmithing down the road, they're a perfect start.

A love letter from Cloud to Service Virtualization

[I originally wrote this one for a Parasoft roundup and Valentine's Day theme on Service Virtualization if you want to see the original post, but it is certainly entertaining enough to share here!]

Dear Service Virtualization,

Hey, I know it’s been a while since we started being “a thing.” When we met, everyone said you were just mocking, and that I wasn’t real enough to make a living, with my head in the clouds. Yet, here we are, a few years later.

Service Virtualization, you complete me.

As a young Dev/Test Cloud, I always wanted to try new things. And what better use for Cloud than experimenting with software for startup companies? I was flexible, I thought I had the capacity to handle anything. I’d stay up all night studying or partying, but sometimes I’d crash. So what if some college kid’s cloud-based photo-sharing site experiment goes down? It wasn’t going to impact anyone’s life.

But when it came to serious business, there was always something missing. What was I going to make of myself? Who could trust their future to me, and develop things that really matter in the cloud? Clearly I didn’t have everything I needed – I was lacking certain critical systems and data, and it was preventing me from maturing. But you came along and together, we changed all that.

One thing I’ve learned is that I don’t always have to handle everything by myself. A dev/test cloud environment is not just a place to store and run VMs for application work—it needs the same clustering, network settings, load balancers, security and domain/IP control as you have in production. I can handle a lot, for sure.

But there are certain items developers and testers need that don’t image so well. Like a secure data source that should be obscured due to HIPAA regulations, or a mainframe system the app needs to talk to, but would be unwieldy to represent in a Cloud like me. That’s when I say Service Virtualization makes every day a great day.more

We’ve come a long way since then, and we’ve handled increasingly serious challenges. Simulating some very complex interaction models between systems, and deploying those into a robust cloud environment of real VMs and virtual services that can be copied, shared and stamped out at will across teams. We work together so well, we can practically finish each other’s sentences.

Hard to believe all this started less than 10 years ago. Here’s to us, Dev/Test Cloud and Service Virtualization standing the test of time. Now let’s go make some history together.

Yours faithfully,


Welcome to the blueFug blog

You know what they say about the cobbler's kids having holes in their shoes. It's hard to work on your own material when you often become busy with work for other customers.

I do have a lot to say here.

Hopefully, my own blueFug blog will have good shoes and keep going steady. Expect to find my latest musings on technology trends, B2B startups, customer and user engagement -- and of course, a little beer-to-beer review and music commentary here. I'll also post a few oldies but goodies from the near and distant past here for your reading enjoyment.

Cheers, and your commentary and feedback on any topic you'd like to see me cover is welcomed.