Companies should not consumer’s social content without opt-in

It’s a great article that explores a number of pertinent topics with regards to consumer generated content (photos, tweets, etc.) on social media and how companies may leverage that content for their own marketing campaigns.

I do think the article misses two key points, however.

First, a 37-year-old mom of a 4-year-old daughter should know better. But the problem is that the general public is extremely naive. They think what they post online is private, or reserved for only a select few. Even worse, many people have no concept that what they post online, even for a few moments, can come back and haunt them for years. Use this rule of thumb: don’t post anything online that you wouldn’t want your dear old grandma to see. But in the example in the article, this post pasts that test. So then what’s the problem? The problem is that she didn’t want Crocs to use the photo. In a moment, I’ll get to why Crocs screwed up royally… But first, if you don’t want strangers seeing photos of your kids, stop posting them online! Stop talking about your child’s hissy fit or medical problems too… when they are old, their classmates will use these things as bullying opportunities. In this case, the mom even hashtagged the brand term. That sort of says, “hey brand, come and get my photo!”

Crocs broke a core marketing principal when they did not seek her permission to use the photo. Seeking permission is so easy. It’s a great opportunity to engage a fan, thank them, possibly reward them, encourage them to continue sharing, and so on… However, this didn’t happen, nor did they get the mom’s permission. Yet somehow the picture showed up on their site.

There are exceptions of course… In my opinion if you pull a social feed, moderated but unmodified, and post it on your site, that’s fine… The content is easily attributed back to the social source and no one for a minute thinks those users are participating in a marketing campaign without their permission.

It’s very easy for brands to go from good to evil, and not seeking permission can be the pathway. But to prevent it from happening, users should think carefully about what they share online, and even how they tag it.

Miserable employees

One of my roles as head of marketing at a large employer is dealing with the ramifications of unhappy, miserable employees that insist on staying in their jobs and complaining instead of quitting or resigning. It’s the job of management to make sure employees don’t hit this stage of the workplace happiness timeline. Employees who are underperforming or have the wrong attitudes should be counseled and remediated; and if improvement doesn’t occur, the company should separate (fire the employees). Or, the employee should just simply quit. You should not be a in prolonged state of misery because this means that most likely the employee is not positively contributing ROI to the business, not optimally serving the customers or stakeholders, and is unproductive. What a huge liability? Yet, in large workplaces, this seems to persist… and time and time again I find my self dealing with negative employee reviews on The common thread is that these employees are junior and they compare themselves to others. They also lack maturity and experience… but management let’s them coast right along.

Here’s my advice if you are unhappy at work:

Don’t measure yourself through the eyes of others around you. Measure yourself by looking in the mirror and saying, “I can do better, I can achieve more, I can be great.” Then, stop gazing and go out and do it.

In other words. Quit your job now. Otherwise, shut the f* up and work to better yourself, what you do and your contributions.

Steve Jobs said, “Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is

By many reports, Steve wasn’t necessarily beloved by his employees… but Steve loved his job. And many people around them did so too… which is why Apple has achieved so much.

Should I purchase domain names proactively?

This past week, The Donald made headlines when it was uncovered that his company owned thousands of domain names that are simply being parked in what it deems as a defensive move.

Says Trump’s son, Eric, “For a company like ours, it’s incredibly important to protect ourselves, and it’s incredibly important to own our intellectual property.”

Here’s why this doesn’t make financial sense, and why it also a futile effort:

Yahoo lists some of the domains owned:


It typically costs anywhere from a few dollars to about $15 to keep each domain per year. Let’s say it’s $10. And let’s say they have 50,000 domains. That means they are paying $500,000 a year to park these domains. Chump change for a billion-dollar corporation, right? Well, after 20 years, that’s $10 million. Not to mention the lost return on capital the $500,000 would generate on a annualized basis.

The Trump organization is probably also (over)paying an agency to manage these domains on their behalf… perhaps another $50,000 – $100,000 per year.

When asked, I have never recommended purchasing domain names to thwart potential slander. And I’m asked this same question at each company I work. The reason is pretty simple, you just cannot purchase all the combinations of potentially scandalous domain names. In fact, there are 36 to 245th power which is basically a 2 with 381 zeroes following it. That’s a lot more than a google, and a lot of $10 bills each year. For example, here are five domain names I could purchase that they haven’t yet:


See my point?

Not only is this a waste of money, it’s a waste of time.

Proponents of this futile activity will claim “it’s worth it if we even thwart one attack!” But you won’t. If you know search engine optimization, you don’t even need Trump in the name of your website to talk about the organization. I’m talking about them now, and if I had good content and SEO, then I won’t need a Trump-specific domain name to spread my word.

And, let’s say you are slandered, if another person is using your trademark and/or slandering you, there’s a really good chance you can shut them down through the legal system – and it’s typically not a big company fighting you, but an individual that lacks sufficient legal resources to counter attack.

So save some time and a lot of money and stop buying domains you don’t need.

ClickZ Live Toronto – Session update and discount code

Use Dan's Discount Code for ClickZ Live Toronto 2015

Use Dan’s Discount Code for ClickZ Live Toronto 2015

In an effort to beat the heat this summer (I live in the sub-tropics and it’s hot, I mean like step out in the sun and fry an egg type of hot). So, what better way to take a break from the heat and head north of Tampa. Way north… How about Toronto?

I can’t think of a better way to spend a few days in Toronto then with the good people of ClickZ Live. I contend that ClickZ continues to put on the best conferences around for digital marketers and search marketing.

If you’d like a 25% off code, use this one:

Dan Soschin ClickZ Live Toronto.

Advancing with Social Analytics: Measuring Social Marketing

Everyone knows the implied value of social marketing, but how do you identify your true ROI and provide reports to others? All material covered in this session will be using free tools and not premium social media platforms. So yes, you CAN try this at home! You’ll laugh, you’ll cry, but most importantly you’ll learn how to use Google Analytics, Excel dashboards and Microsoft Word case studies to measure and report on the value of your social media campaigns.

Hope to see you there!

How to redo a corporate website in 12 weeks

UMA's new homepage

UMA’s new home page.

Website relaunch projects don’t have to take a year (or more). In fact, when executed properly by skilled teams, you can rapidly deploy (or redeploy) a new website. Here’s how I recently relaunched the website for my school, Ultimate Medical Academy:

  • PREP PHASE (12 weeks prior to project start; or launch minus 24 weeks)
    My web team (consisting of two employees) tested out some concepts for the new website by piloting the technology and styles on smaller projects ahead of time. We knew we wanted to push the envelope quite a bit with the school’s site, but we didn’t want the site to be the first time we tried all the new bells and whistles. Like any good web team, we have and actively manage a project backlog or road map that goes out about a year. This helps us understand what’s ahead and manage our time effectively. It also enables us to pilot some new techniques ahead of time. So, beginning about six months earlier, we had two very small websites to build for other projects at UMA. In each of those builds, we tried a few new things. Some worked, while other ideas didn’t pan out as we had expected. These sites served as a proving ground for new ideas.


  • RESEARCH PHASE (week 1)
    First, we formed a steering committee that included the following members of the marketing team: web manager, web developer, copywriter, brand director, creative manager, search marketer, and me (the VP). That’s it. This group would make all the decisions, with the VP (me), holding veto power and general oversight of scope. The web manager would be the project manager and oversee development and the day-to-day project plan. Next, we asked each member of the steering committee to spend a couple hours looking at and documenting sites they felt were “great.” It didn’t matter what your definition of great was; just that you came back the next day with a good list and could present it to the team. More on that in a moment. The other task we completed early on in the first week was to discuss the results of a brand perception study we had completed months earlier which helped us understand what our customers really wanted out of their experiences. During this phase we met pretty much daily to discuss all the features and aspects we wanted to include in the site. We reviewed everyone’s wish list, sample sites from their research, competitor sites, and so on. The end results was a ranked list of features into a couple of buckets: things our site must do at the launch, and things we wanted the site to do eventually. While we knew that a success project needed to have some elasticity to accommodate unforeseen needs along the way, it was also important that we minimize scope creep to hit the 12 week goal. At this point in the project we did not worry about “how” to do something, just whether we wanted to do it. Later, during the development process, we would tackle how to address items that were excessive in development time and light on ROI. The goal was to come out of the week with a solid list of features. Additionally, during the first week (and carrying into the 2nd week), we identified every major department at our school (about 10) and met with each stakeholder group’s leadership for about 60-90 minutes. During these meetings we explained the project’s goals, set expectations, and solicited feedback/input into the site. The questions we asked were fairly basic:

    • Does the current site meet your needs?
    • Do you use the current site? If no, why not?
    • What would you want out of a new site?
    • What other sites do you like and why?
    • Who can we work with on your team to help update your section’s content/copy?


  • DEVELOPMENT & DESIGN (weeks 2-12)
    Now the sprint begins. We kicked off three separate initiatives at once because we knew that if we ran the three parts of the project in serial order, we wouldn’t hit the 12 week goal.

    • Our copywriter began rewriting what would become nearly 200 pages of copy
    • Our designer began mocking up the different templates for various site sections
    • Our developers started work on the templates and sandbox config by having the three teams work in concert, we had to communicate daily to ensure pieces fit together, especially with how copy was to be produced. For example, our copywriter had to work with the other two teams on headlines to ensure there was enough space for various copy elements incorporated into the template designs.The designer had to work closely with the developers to ensure that his designs could be easily reproduced in the code.As the VP of marketing, I had to ensure that project requests outside of the web reboot were minimized in order for the teams to be able to focus primarily on the website project. We set aside 20% of our week (about one day) for other projects, but ultimately were able to reduce that a bit further. We did have to supplement our 12-week schedule with a few late evenings a couple weekends, but nothing too dramatic. We wanted to use the extra time mid-project rather than wait until the end and scramble. This gave us a much more predictable finish date, as we did our “long hours” mid-project and then glided in. Though, I don’t want to underscore how close of a finish it was. But more on that later.


  • COMPLIANCE & REVIEW (weeks 4-12)
    The majority of public-facing content marketing produces is reviewed by an independent team to ensure that what we are saying is legal and compliant with a score of very specific regulatory requirements governing advertising and communications within the post-secondary education space. This means that everything we write needs to be reviewed. To ensure the compliance team was up to the task, our steering committee met with their team early on to set expectations. We shared the site concept to generate excitement and provide context. We also checked in regularly and developed a good system for sharing feedback, collaborating and obtaining sign-off efficiently. The web developers used draft copy for development, with little formatting or editing, as much of the content would have to be replaced. In other areas, they simply used lorem ipsum types of placeholders, since we knew the copy was going to change during the review. I also reviewed all the copy to ensure the messaging was consistent with my objectives for the new site. This meant that I had to provide a very fast turnaround on the nearly 200 pages of copy; so scheduling the requisite amount of time and attention to this project was key.


    Early on in the project, the steering committee met almost daily. As week three approached, meetings were scaled back to 2-3 times per week. The meetings were used to:

    • Review progress
    • Allow team members to ask questions about features/specs
    • Address issues in real-time
    • Make on the spot decisions
    • Discuss new findings and limitations
    • Review features and scope to reevaluate the two buckets (must have and nice to have)… ultimately, a few items that were found to be heavy in development time and low on ROI were pushed from must to nice. At this point, we began keeping a list of post-launch features that would go into weekly “agile sprints” where we would release new features over time.It was important to understand that we wanted to launch a core website in 12 weeks, not a site that had 100% of everything everyone wanted. So, working with the web manager, we discussed whether certain features could wait, and adjusted the project scope as necessary.


  • LAUNCH PREP (weeks 9-12)
    To set expectations, the actual launch window I provided the school’s leadership was much broader than our target. This would allow me to squeeze a few more weeks of work if needed. So, when communicating out to the organization, I provided a month-long window, with emphasis on the end of the month. However, internally, we were managing to the early-to-mid part of the month.Additionally, I began speaking with members of the leadership team about the site, and even provided “sneak peaks” to a select few individuals, mainly the senior leadership team at the Academy. It was important that I provide them a brief overview of the site so they knew what to expect. I also wanted some feedback, to ensure we were not missing anything critical on the site. During these meetings and demos (about 3-4 took place), we also gauged feedback and excitement to understand where we might want to focus a little extra last minute effort.Since we had planned so well, and sought early input from each department, we found that the site delivered on everyone’s expectations (often exceeding it when it came to look and feel). A couple minor items came out of the demos and the team quickly adjusted what was necessary without losing too much steam.


  • QA / TESTING (weeks 10-11)
    While testing was on-going throughout the project, we expanded the testing efforts around week 10 by bringing in a couple of additional team members for a few hours to help test on various devices (tablet, iOS, Android, IE, Chrome, etc…) This helped us find as many issues as possible in the shortest amount of time. Issues were funneled directly back to the development team and tracked accordingly. The copywriter reviewed all copy once again; and I personally tested a wide variety of devices and stepped through the majority of the site.


  • GO/NO-GO (week 11)
    With about one week remaining in our sprint, we had a go/no-go meeting with the steering committee to understand what was still remaining on the project list and why so we could work through those last roadblocks efficiently.


  • THE LAUNCH (week 12)
    I opted for a soft launch on a Wednesday. This meant that we would coordinate with the information technology team that controls the DNS settings and make the switch in the afternoon after one final go/no-go call between myself and the web manager. Once the switch of the DNS was made, the QA team did another full walk through of the site across their devices and platforms. This revealed a few last minute items that needed to be addressed. Believe it or not, our old site was not heavily used by staff or students (mainly only prospective students), primarily because it was simple and didn’t include a lot of information. So we knew we could do a launch without communicating it widely to everyone at the academy. And, those few extra days of being live and testing; and collecting feedback from the few people that new the site was live, would be extremely valuable. The good news is that there were no major issues. That following Monday, we did the full launch which included an email to all staff, an announcement to our students through the online student portal, posters throughout the building, and information on the staff intranet. We also created a scavenger hunt, with five questions… Staff had to find the URLs for specific items, such as “what page features a picture of an employee dressed as a Rubik’s Cube?” Anyone who answered the questions correctly got a souvenir school pennant and was entered into a raffle for a school sweatshirt. This contest, along with the email announcement helped drive awareness about the site and all the new features.


So what worked and what didn’t?

Overall, the prep and collaboration really proved to be the cornerstone of our success. I cannot underscore how important these processes were. It was equally important to have full buy-in from senior leadership and to protect the team from competing priorities/projects.

Of course the team would have liked more time. That would have yielded minimal differences though. Of course more time would allow for more scope, but we’re releasing new features weekly. It was important to launch a new site quickly with a solid foundation, and then focus on additional features. So more time would not necessarily have yielded a higher quality site – just more features. It may have reduced stress a bit, or eliminated a few of the extra days we spent across a couple late nights and weekends. But I have a feeling we would have used those late nights and weekends even if we had more time.

I owe the success of this project to the steering team (especially John Klingler, the project manager for this endeavor.) It was a lean team, that continues to meet to this day looking at new features and specs to make the site even better. They did the hard work and were successful; I’ll bask in the moment of accomplishing a great feat and then jump into the next project “business as usual.”