Big Data is a Verb (Not a Noun)

Big Data (BD) is not a “thing” (noun). Big Data is a set of actions (verb), orchestrated by people, using specialized tools (software, hardware, algorithms) to organize data streams for the purpose of gaining additional insight. The quantity of data, in unto itself, does not equate to Big Data. The processes used to correlate and draw inferences from (potentially) disparate data streams, ultimately leading to insight, is the soil from which BD thrives.

Nestlé Waters North America, as documented by Marketing Land, demonstrates the power of a creative Big Data strategy.

Antonio Sciuto (CMO @ Nestlé Waters North America): “We listen [to] our consumers on social platforms to understand: conversation topics, share of conversation by social platform, tone, consumer sentiment, roles and consumer engagement rules by media touch-point.

This understanding is enabling us to define the right opportunities to engage consumers with content and the right calls to action by online and offline touch-points. Our whole consumer journey is managed by leveraging… marketing cloud solutions, powered by Salesforce, that allow us to listen, analyze, and engage consumers by automating consumer interactions.

Our mission is to build communities around our brands and content based on the real needs of our audience, offering them a truly personalized omni-channel experience to deepen their engagement with our brands. Success to be measured in market share and loyalty to our brands.”

In 1998 a company was launched with the following mission:

“To organize the world’s information and make it universally accessible and useful.”

With the clarity provided by 17+ years of hindsight, Google’s sublime mission statement not only signals the modern era of Big Data, it provides a succinct, human-readable, and aspirational “true north” when setting expectations for all Data Science, including BD, outcomes.

The following, based on Google’s mission statement, attempts to illustrate a theory of Big Data relativity:

    B = DQE

    B = Big Data Cost (a.k.a. cost to achieve a “useful” and / or “insightful” result)

    D = Number of discrete data streams (a.k.a. “information”)

    Q = Average quantity of information per data stream (a.k.a. “information”)

    E = Effort required to process

Working with the assumption that a “useful” and / or “insightful” result is the objective of any BD exercise, we see that although the quantity of inputs (data streams) impacts the cost, the more significant driver is the level of effort required to achieve a result. From a practical business perspective, the key to implementing a cost effective Big Data strategy is not the quantity of data or the number of streams, but the human and machine effort required to achieve a “useful” or “insightful” result.

If we accept the premise that “Big Data” is a verb, any organization looking to achieve cost effective results from the analysis of their data must consider the following:

  1. Do you have the expertise (a.k.a data scientists), from the beginning, to build an effective strategy?
  2. Do you have the software and hardware tools to accomplish the required level of data ingestion and analysis?
  3. Are your resources (human, software, hardware) capital expenses, or are they elastic (operational expenses)?

Understanding (and appreciating) the linguistic differences between Big Data (verb) and data (noun) will allow individuals and enterprises to more effectively collaborate on strategies which achieve outcomes of insight and value.

About the author:

Tal Golan (@TalGolan) is the Chief Strategy Officer at VERB.

The more you do, the more you can do!

Image of dirty hands with a seedling

Yes. I am highly qualified to build an entire business from the ground up. I know a great deal about the entire business lifecycle (cradle-to-grave).

  • I’ve raised over $9M in venture capital.
  • I’ve sold enterprise hardware & software to organizations around the world.
  • I have been media trained and am a published author.
  • I lecture to MBA students, and I’ve written patents.

However, please do not “miss the forest because of the trees.” My success and accomplishments have been achieved not on the backs of others, but by my belief that teams (as in sports), when properly motivated, have the capacity to exceed even my wildest dreams. I don’t just hire people to make my dreams & visions come true, I ask people to join me on the journey, offering to lift them up on my shoulders. I choose to see people and opportunities as they can be, not (necessarily) as they are today. This type of optimistic thinking allows me to achieve and accomplish much more than most, however, it does set me up, occasionally, for disappointment.

I am an “in-the-weeds,” get your “hands dirty” kind of guy. Just because I know a lot about a lot and have made it my business to ride the leading edge of the “bleeding” edge, does not mean I have forgotten how to create for today.

Things I’ve done, personally, over the last 18 months include:

  1. Architected a state-of-the-art web application.
  2. Built a business, as employee 0, from the ground up.
  3. Established and maintained an accounting system.
  4. Hired and motivated 21 brilliant people [18 engineers, 3 other].
  5. Conceived of, architected, and implemented (with a team) the highest quality, browser-only, transactional video as a services platform you’ve ever seen.
  6. Architected, implemented, deployed, and maintained an entire AWS (cloud) infrastructure.
  7. Lead and motivated a group of people far smarter than me.
  8. Written production-ready code in:
    1. Python
    2. Javascript
    3. PHP
    4. Java
  9. Designed and implemented production-ready relational and non-relational data models
    1. SQL (MySQL & Postgresql)
    2. NoSQL (DynamoDB & MongoDB)

Bottom line…

I am a guy who builds things on the Internet. Period.

The fact that I am able to build effective teams stems from the fact that I am, at heart, an engineer of things (businesses, software, etc.). People follow me because I lead by example. I believe engineers respect me, and follow me, not because I have a PhD (which I don’t) or because I’m some guru (which I’m not), but because they know that I actually know what I’m talking about because I actually write code to solve actual problems. Sales people follow me because I have successfully “sold” to over 700 enterprises. Marketing people follow me because I know how to effectively communicate a message of benefits, not simply features.

My best and brightest years are ahead. There is no way you can beat me, so why not get me to join you? In the words of Lucille Ball…

“If you want something done, ask a busy person to do it. The more you do, the more you can do.”

Designers design. Developers develop. Everyone wins.

Any project / product, whether it be a website, or a mobile application, or a widget, needs to be designed and developed. I realize this is a truism, but bear with me.
The following is my articulation of how I think this process should work:
  1. Product Manager(PM) communicates the vision to the lead designer (translating what was communicated to the PM from ownership/leadership/stakeholders).
  2. PM and designer do a couple of instant iterations, then the PM leaves it to the designer to work his/her magic.
  3. Designer provides 1 (maybe 2) options. (I prefer only seeing the one the designer feels is best, as I’m not really interested in spending my time evaluating the #2 option.)
  4. Sometimes the PM makes suggestions. Sometimes the PM gives the designer brilliant ideas. Sometimes the PM just says “That looks amazing. Let’s use it as it is.”
  5. Designs are handed off to development:
    1. Development’s job is to figure out how long it will take to turn the designs into reality.
    2. It IS NOT development’s job to re-design the designs.
    3. Development is supposed to give a risk assessment and a breakdown of what time the implementation will take.
    4. It is development’s job to make suggestions to the designer(s) that will make the designs easier for end-users and easier for development.
    5. It IS NOT the designer(s) job to tell development how to develop.
    6. It IS NOT development’s job to “pick and choose” what’s to be implemented.
    7. It is development’s job to go through 1 iteration with design, where designer(s) make the final decisions for what everything is going to look like and work like, based on the recommendations from development.
When this process is working properly there is one person (the PM) who makes final decisions in the event of a conflict between design & development. If you have the right people on both sides of the fence, there are no “final decisions” that need to be made, because development is implementing what design designs, based on the limitations articulated by development. The feedback-loop, when dealing with professional adults, is extremely productive. (a.k.a. Agile)

In my experience, this process works amazingly well, provided:

  • The development side does not act as if they are better designers than the people responsible for the design;
  • The designer(s) don’t act as if they are better developers than the developers.

The process breaks down under 3 very obvious circumstances:

  1. Timelines and/or requirements are changed without proper respect for the process.
  2. Development does not implement what has been designed and approved.
  3. Design insists on things that are to complex.