<!-- Content Here -->

Priorities

Prioritizing is hard when other people's requests fight for your attention. It is stressful. You feel attacked; and when you constantly shift your priorities in response to whoever cries the loudest, you get nothing done and you feel defeated. As hard as it is to prioritize your own time, prioritizing what to improve in a product is even harder. The decisions you make on a product have such a large impact. Living under this stress of competing priorities is the life of a product manager. Here are some tricks that I learned.

1. Create and publish a model for prioritization.
   My prioritization framework looks like this. Being transparent about how you prioritize serves three functions: it sets expectations; it encourages stakeholders to express their requests in terms that you can easily evaluate; and it forces you to adhere to your own rules.

2. Don't elevate the priority of one request. Push everything else down.
   It is easy to fall into a cycle of urgency inflation where each request tries to one-up the others in priority. Hysteria builds and you go into reaction mode as you try to keep up. When I feel like this, I try to visualize calmly but firmly pushing other requests down. You only have so much capacity. The highest priority thing should be whatever you are working on right now. It can't get any higher than that. Everything else will have to wait. It feels empowering to actively push requests down to make room for the one request that cannot be deferred. The alternative is passively accepting every request's own self stated importance. That feels horrible.

3. Group niggling little things into a single item.
   One risk of prioritization is that some of the little things never get done. Individually, these details never get to the top of the stack. But in aggregate, they do matter. User experience is all about the details — sanding down the snags that get in the way of delight. To solve this, I like to group some of these requests together to give them a fighting chance against some of the larger initiatives.

4. Strive for continuous improvement rather than immediate perfection.
   Your application is not perfect today and, no matter what you do, it will not be perfect next month. Rather that succumbing to the pressure of immediate perfection, focus on continuous improvement. One of my favorite articles about product management is "Make it Suck Less." While this sounds like an overly humble goal, software would be a whole lot better if every application was managed on this principle. Besides, if you achieved perfection, your job as a product manager would be over.

5. Take a moment to celebrate your achievements.
   After you launch a new feature, resist the temptation to immediately jump to the next thing. Get closure by reflecting on what you accomplished. This will help in two ways: it will get you off the treadmill for a moment to enjoy your success; and it will allow you to evaluate what efforts have yielded the greatest impact so that you can be even more effective with your prioritization. Personally, I find the best time for this reflection is when reviewing release notes before publication and when preparing for a team retrospective.

These practices work for me in product managing my own time. Hopefully you will find them useful too.

Too Dry Anti-Pattern

I do a lot of code reviews. On average, I probably spend an hour a day looking at diffs. I find this an efficient use of time because I frequently spot bugs that wouldn't be revealed by regular testing. I can also prevent implementations that will create obstacles as we progress through the road map.

One of the anti-patterns that I have started to notice is what I call the "Too DRY Anti-Pattern." For the uninitiated, DRY stands for "Don't Repeat Yourself". It is a primary tenet in one of my favorite books: The Pragmatic Programmer: From Journeyman to Master

. Keeping your code DRY means using methods and functions rather than copying and pasting code and not storing the same information in multiple places. I have written about DRY in terms of content management in this blog before.

The Too DRY anti-pattern starts with the good intention of keeping the code DRY. The developer creates a function or method to avoid having the same code exist in lots of places. However, over time the developer starts to use that function in places that do not quite fit. The function gets more parameters and has increasingly complex internal logic to control its behavior in different cases. Too DRY functions are easy to spot. They have lots of intricate if-then logic that try to address a wide diversity of usage.

A counter-weight to the Too DRY anti-pattern is the Unix philosophy of doing "one thing and doing it well." When you run into a Too DRY function, use the Unix "one thing" philosophy to break it down. Perhaps create smaller functions that do specific elements of the larger Too Dry function and then have different functions that use those building blocks in different ways. Also, repeating code isn't always a bad thing if the code is small and performs a discrete function. For example, if you have some code that creates an object and sets its properties, it is OK to have similar instances of this logic if the properties need to be set to different values.

Like all things, best practices need to be applied thoughtfully rather than as rigid rules. So keep your code DRY, but not at the expense of simplicity.

On Building an API

A few months ago we announced the availability of the Lionbridge onDemand Public API. While there are many translation APIs in the marketplace, I think that ours is the most comprehensive. Most translation APIs offer one level of translation quality (for example, machine translation or crowd translation or professional translation). The onDemand API allows you to select a translation type that meets your needs. This means that you can integrate with one API and give your customers lots of options. We also support many different content types. For example, we can translate videos as well as basic documents. Lastly, we offer different payment options. The end customer can pay themselves or the money can flow through our integration partner. I think these differentiators are responsible for the rapid adoption we are seeing. We already have around ten third party integrations in production or nearing completion.

Personally, this has been a huge learning experience. While I have used many APIs and even helped developed a couple, this is the first time that I designed one from a blank page. The sheer number of approaches, options, and details that you face is enormous. And although the biases formed from personal experience are important, what really matters is the developer audience — not just in the decisions you make but also how you support them.

I hate the term best practice but here are some of the things we got right. I must admit that we didn't always land on all of these practices the first time but when we adopted them, we definitely saw results.

• Learn from others. When first designing the API, I drew inspiration from other APIs that I liked to use. I also found great information from George Reese's The REST API Design Handbook.
  
• Get feedback. When first designing the API, I had the benefit of knowing who the first customers would be. I wrote the initial specification in a Google Doc and invited feedback. The first partners caught some important omissions and had some great ideas too. I also had different developers review the specification before development started.
  
• Be pragmatic about change. An API is a contract. It shouldn't change. However, in the early going there were a few cases where it made sense to change the specification. This was inconvenient and awkward for developers who are starting their integrations. However, it was much less painful than making changes later when the install base is bigger and changes would break working systems. Managing these changes requires a lot of humility (admitting you are not perfect) and effort to rebuild trust. Once the lead integration partner was getting close to being feature complete, however, we did lock down the version of the API and saved our changes for subsequent versions. Since the initial launch of the API to our beta partners, we have launched another version and are now working on a third. We handle versioning with an HTTP header so it is easy for a client application to update the version to get access to the new feature.
  
• Hire your first client. While any early beta customer will need to accept some level of instability, you don't want to risk a partnership with your earliest growing pains. For this reason, we hired a contract PHP programmer to develop and test code samples for working with the API. This external developer had no more access than a true partner developer would have. The experiences of this developer gave tremendous insight. It exposed ambiguity in the documentation where the API implementer interpreted different meaning than an external reader. It revealed cases where the test passed but externally developed code didn't work.
  
• Give client developers a plan of action. Like with most API's the hardest part of working with the onDemand API is authentication. For this reason, we recommend a development sequence that starts with the easiest API: List Services. We also wrote up a quick tutorial with a code sample to help. For our beta developers, we created a project plan template that developers could follow. It contained tasks for integrating with the various features and rough time estimates. I was surprised to learn how much the developers liked this. Personally, I hate being given a project plan that I had no input over.
  
• Provide fanatical support. Even though I love software development, I am the first to admit it can be frustrating. It is easy for developers to get bogged down and stuck. The smoothest implementations we have had were when the dev team actively engaged the client developers. I admit that sometimes I felt like my time was being stretched too thin. But when you think about it, how can you get more leverage than helping a partner use your service and bring you business? I also enjoyed working with external developers. First of all, they are savvier than regular business users so you can rule out silly things like being disconnected from the Internet. Second, it was fun to troubleshoot with them as they sent requests and we inspected what onDemand received. Pinpointing errors can save a client developer a lot of time. This work had the side benefit of improving our error handling to provide more informative responses.
  
• Treat your development sandbox like production. This should sound obvious but a lot of services that I have integrated with have very unstable developer sandboxes. They are not always available and they have issues that you don't see in production. There is nothing more frustrating than trying to fix your code and realizing that the problem is in an external system you are integrating with. For this reason, we manage the sandbox as a production environment. It gets the same monitoring as a production environment and we release new code to sandbox after it has been in production for a couple of days.
  
• Test like you mean it. Software is incredibly picky about the slightest detail so API testing needs to be extremely thorough. You can't just verify that you are getting data back. The data you get back needs to be precisely like what is in the documentation. For this reason we do what I call double-blind testing. The development team writes tests that run whenever new code is merged into the integration branch. An external QA team writes and runs tests based on the documentation whenever we have a release candidate. The hope is that having two independent approaches will everything. When it doesn't, we have a major debrief.

If you do it right, an API can revolutionize your business by opening channels that extend your reach. But getting it right requires commitment and attention to detail. If you underperform in any aspect (design, implementation, or support) your program is doomed. You won't always get everything right but if you maintain your focus and address your failures, you can get things back on track.

Is Wordpress the Microsoft Windows of Web Content Management?

We run our corporate marketing sites on Wordpress. It's not the perfect web content management system for us but, as long as we keep things simple, it does the job reasonably well. When we want to do something that Wordpress doesn't comfortably handle, we tend to use an alternative platform such as Marketo, UnBounce, or develop static web pages.

Wordpress is great, but one thing to consider when using it is that you make yourself a target to all sorts of hacker attacks. When planning server capacity, we need to accept that a lot of our traffic comes from bots trying to hack into WP Admin. There are three things about Wordpress that contribute to this.

1. Wordpress is by far the most commonly used web content management system. According to BuiltWith, 47.90% of CMS powered websites run on WordPress. The second most commonly used CMS is Drupal with 13.10%. Now I know that those statistics are not perfect but it is clear that Wordpress is head and shoulders above the competition when it comes to CMS adoption.

2. Wordpress is incredibly easy to identify. If you look at the source of any Wordpress generated page, Wordpress's signature is impossible to miss. Moreover, Wordpress makes it really hard to hide these tells even if you wanted to.

3. Wordpress is the "go-to" platform for people who know nothing about web development or security. While there are plenty of savvy WordPress developers out there, the majority of WordPress sites were built by people with no clue about security and operated by companies with limited technical know-how. Many of these sites were insecure from day one and only got worse as patching and other maintenance practices were neglected.

Put these three facts together and it is obvious why WordPress is the most attractive platform for hackers and botnets to attack. If you are a malicious hacker and want to get the most out of your efforts, you go after the biggest and most vulnerable target. And in that way, WordPress is a lot like Windows. Windows is everywhere because it is the go-to OS for people who just want a computer at a reasonable price. If you walk into a BestBuy/Staples/Costco to buy a computer, you will walk out with a Windows PC unless you have something else in mind. The majority of these computer shoppers know very little about managing their computers. These users will not keep their software up to date and will accept any dialog. Most of us have spent countless holiday hours removing adware, browser bars, and viruses from these computers.

Just to be clear: Wordpress and Windows are not inherently insecure. With conscientious maintenance, both of these platforms can be as safe to use as the alternatives. It as a sign of success for both Windows and Wordpress that they have earned the distinction of being prime targets for hackers. It is also a great opportunity for external software companies to market services to secure these platforms. The Windows security software market is already large and mature. The number of Wordpress security options is growing fast.

So my advice to everyone is to keep on using Wordpress if it meets your requirements. But accept that your site will be a target for hackers and plan for security. Work with Wordpress specialists (not designers who happen to know a little about Wordpress theming). Follow all the advice in the "Hardening Wordpress" page. Look into 3rd party services that help protect your site. Be safe

Radio Silence

You might have noticed that I haven't been posting here much over the last year. More likely, you haven't noticed at all. Blogs are often like that. They come and go depending on the whims of the blogger.

The reason for my silence is that my focus has shifted from pure content management to lean product development, web application development, and cloud-base architecture. At Lionbridge, I have been helping to build a business called Lionbridge onDemand. It has been a little over a year since our first sale and I am in a constant state of amazement about how things are growing. Like most of my projects, we followed a lean product development model of launching a minimum viable product and continually improving it to support the needs of our growing customer base. In this case, we started with a tiny website to translate videos. Since then we have grown to the point where:

• We now have a wide array of services that support nearly 40 different content types. We even have services that do not involve translation at all such as proof reading and CRM data cleanup.

• There are enterprise sites for many name-brand clients. It turns out that large organizations are full of individuals who prefer a simple consumer style eCommerce experience. With onDemand Enterprise, we can quickly create a custom site for a corporate account. These enterprise sites have the same simple "consumer" feel but they also have the ability to offer custom services and can tap into corporate payment channels.

• We have a Public API with a developer program. We started with an API for eCommerce systems to translate product catalogs; but then we grew into a full featured translation API that can handle our full complement of content types. While there are other translation APIs out there, ours is unique because it exposes different translation services ranging from pure machine translation to professional translation by subject matter specialists.

• We are now a global team working around the clock to deliver projects with industry leading quality. We have operations specialists in North America, Europe, and Asia. Managing a service like this requires a special mix of problem solving skills. This is content management at a level of complexity that I have not seen before. The process requires the constant attention of highly skilled and conscientious individuals.

The last point is my favorite. I am currently en route from Warsaw, Poland where I have spent the last five weeks working with the operations core team. It was an incredible experience to meet the people that I had only known through email and conference calls. From the start, I was impressed by their dedication and can do spirit. Now they feel like family.

So, back to this blog. What has made Content Here a worthy endeavor so far was that it provided a useful place for me to explore observations and concepts that I encountered as a content management professional. If I learned something, I would flesh out my knowledge by writing it here. If I did a decent job of explaining something to someone, I would reproduce that explanation here. If that was all blogging did for me, it would have been enough. But blogging provided so many more benefits. In particular, it was a way to connect with other people. I made many business connections and friendships with this blog.

I am hoping that I can continue experiencing these benefits by shifting the focus of this blog to be more aligned with my day to day work. It won't be a total departure from my older posts. My involvement in web development and open source software has stayed the same. But I will probably write a lot less about content management software, product selection, taxonomy, workflow, and other pure content management concepts. To be honest, I feel like there is not much more for me to write on those topics. There will be more posts about my experiences from growing a web business. Topics will include things like working with distributed teams, lean product development, customer support, web application development, and web operations.

Hopefully, along the way, I will meet new people who are struggling with these same topics. The web is a pretty big place so I think that chances are good.

Internet Explorer, you did it again

I learned something new about IE9 today. Apparently, when visiting a site in the same domain as the computer, IE9 defaults to compatibility (quirks) mode. I am guessing that this is Microsoft trying to accommodate crappy intranet sites (cough cough SHAREPOINT cough cough).

So, if your site depends on standards mode, you might find that it looks fine in the real world but not in the office. I work remotely and this has burned me twice. Both times my launch celebration was cut short by complaints from colleagues in the office who saw broken pages.

Now I know.... And you do too.

Hat tip to Marjoe Bacus for letting me know about this "feature".

Evolutionary Software Development: A Model for Maintaining Web Sites and Applications

Since I got into software development back in 1995, I have been exposed to many different software development methodologies. I started out with a highly structured waterfall model (which is hard to avoid with fixed bid projects). Whenever possible, I have advocated agile approaches and I have been on teams that have practiced agile methods like Scrum with varying degrees of fidelity. Overall, I love the values of agile but the agile methodologies that I know of don't quite feel right for the kind of work I do now.

These days my job focuses on managing several different web sites and applications. Officially, you could say that these applications are in "maintenance mode" but the truth is that they were always in maintenance mode. All of these applications have been built on the philosophy of a minimum viable product. That is, we developed a minimal solution to test a) that the problem actually exists and b) that our idea is an effective way of solving it. The initial solutions were just complete enough to answer these questions and create a foundation for an evolutionary process towards continuous improvement. Everything since has been "maintenance."

The agile development methodologies that I know of don't quite fit because they all seem to focus on a notion of defining a 2-3 week "release" or "sprint" and putting the entire team onto cadence that begins with planning and ends with some kind of review. But my teams do not work that way. We release one feature at a time. We don't wait for some large milestone to push new code into production. In fact, we push a new feature as soon as it is ready. We see an un-published feature as a huge liability. Worse than simply not being able to get the benefit of the feature or see how the audience responds to it, unpublished code is a risk. When code sits in an unpublished state it needs to be maintained like working code. Otherwise, when you deploy it, you are likely to break other things. Also, large deployments are riskier than small deployments and make problems harder to diagnose.

We try to define features to be small as possible. Some features are "below the waterline." That is, they are not visible to the end user and are only deployed to support another feature in the future. A very common example of this pattern is that we usually do our database work up front. For example, if we need to build a new page design, we will start by deploying the new fields that the design requires. Then our content team can add the data. Later, once the data is in place, we can deploy our page templates and other application logic that relies on the new data. We also commonly deploy infrastructure upgrades ahead of the features that they support. We also try phasing in features with an initial simplistic implementation to test out the concept and then a series of enhancements to reach the full potential.

When you are maintaining a live application, the line between a bug and enhancement is blurred and the same team should responsible for both. Anyone on the team needs to be able to pull herself away from the feature she is working on to fix an urgent issue. This is another reason why keeping things small is very important. It is also why it is so important to have a very clearly defined prioritization protocol. Ours is:

1. Site down

2. Feature broken with no work around

3. Feature broken with work around

4. Revenue opportunity

5. Customer Usability

6. Operations Usability

7. Brand consistency

The product manager is in charge of setting the priorities and assigning high priority issues that need to get taken care of ASAP.

The lines between coding, content, infrastructure, and support are also blurred. Sometimes an issue is noticed and the cause is not immediately apparent. For example, let's say a customer cannot download a file. It could be that the file was not added in the first place. The code to retrieve the file could be broken. The server could be out of space and the file could not be saved. It could be a usability issue and the customer was clicking on the wrong link. Triaging and coordinating this work is critical needs to be core to the methodology.

Refactoring is another big part of the methodology. You often run into situations where a feature gets a lot of traction but not in the way that you expected. You might need to change how it was built to allow it to evolve in the right direction. You will also need to refactor your successful experiments to support active use. The concept of a "user story" (common in agile methodologies) does not lend itself well to code refactoring.

As you can see, traditional agile methodologies do not accommodate the day to day activities required to maintain and extend an actively used web application. This is because they are designed at their core to support software development projects where the team has the luxury of ignoring the operational aspects of running the application as a service. But that luxury comes at a price: alienation from critical feedback by actual consumers of the application. In agile, a "customer" role filters and simplifies end user needs and tastes. This customer makes a lot of guesses about what the end customers want. The guesses tend to be big and there is no process for correcting the wrong ones. The agile approaches that I know of seem better for building packaged software or for integration companies that are brought in to build something and leave. These are cases where you cannot or don't want to be told that you need improve something right after you thought you built it to specification.

Here is a very real world example to illustrate that point. We use LivePerson to chat with customers who are on our sites. Sometimes there are cases when a customer gets stuck because he does not notice or cannot understand an error message — such as one telling him that he needs to enter something into a certain field. If it is common enough, we will use that feedback to design, implement, and deploy a fix that makes the validation message more visible and understandable. Fixing this issue could be hugely important to conversions. But think about how this problem might be solved in Scrum. A "user story" would be added to the backlog. At some point, this story makes it into the next sprint. It needs to wait for the rest of the sprint to finish before it is deployed. If you do two-week sprints, that could be up to a four-week turn around. You might say that you would handle this in a maintenance track that runs in parallel to your real development. But I would counter that tweaks like this are where applications succeed and fail and should be the focus of (not the exception to) your process. In fact, I think you should think of everything as a tweak.

Despite the fact that lots of organizations are maintaining sophisticated web applications and want to experiment with new features as fast as possible, I have found little writing on formal methodologies to support this. The best writing comes from the DevOps community but they don't directly often address the actual software development as much as I would hope. I like Eric Ries's chapter on continuous deployment in Web Operations: Keeping the Data On Time

. Speaking of Eric Ries, lean startup literature is also a very good resource. But this community emphasizes customer development and doesn't explore the architecture/implementation side as much as I would like.

What really inspired me to write this post was this relatively obscure research paper called "An Online Evolutionary Approach to Developing Internet Services." This fit the bill when I was looking for a term to describe how we work. The word "evolution" is perfect. It captures the idea that development is a series of small modifications that respond to stresses and opportunities. Each modification is tested in the real world. The ineffective ones die off. The good ones are the foundation for future progress. It is true natural selection. We just try to be a little less random than biological evolution.

I would love to hear your feedback on this. I go back and forth between thinking that we are outliers for working in this way to thinking that this process is so universal that nobody thinks about it. I also think there is a lot to discuss with regards to testing, communicating changes to users, and localizing the solution.

Chaining DNS Entries

Warning: geeky network admin post

I see a clear trend of marketing groups taking over full responsibility for their organization's digital presence. This includes maintaining various publishing systems such as the web content management system and running the website hosting infrastructure. Once you go down this path, you need to get with IT and start dividing up ownership of the different systems. Some of these decisions are easier than others. But the hardest one is often the DNS — which maps domains and subdomains to actual servers. Both groups have a legitimate claim over the name server. IT needs to make sure that email and other back office systems are properly mapped. Marketing needs to be able to route external audiences to the right applications. Both groups are afraid of the other group accidentally causing an outage by deleting or updating domain records that they shouldn't be touching.

To work around this problem, I recommend chaining DNS entries across two sets of name servers like this:

In this pattern marketing registers a domain for its private use. What the domain looks like doesn't matter because nobody will see it. Then marketing sets up DNS entries for public subdomains like www and points them to the IP addresses of the servers or other network infrastructure (like load balancers) that host the sites. Then the IT group create DNS (CNAME) entries in their name servers that point to the marketing entries. The end result is that a browser looking for the IP address behind www.example.com will be referred to get its answer from www.examplemktg.com, which will return the correct address.

Why is this useful? If marketing wants to temporarily or permanently move a site onto different hardware, no coordination is needed. Marketing has full control over what the domain is mapped to. This may not sound like a big deal but imagine it is 3AM and your primary hosting infrastructure goes down. Relief from your disaster recovery setup is just a DNS update away. But the IT help desk is offline or can't reach anyone from network operations to make the change. Your urgent request would just have to wait as audience associates your brand with 500 or Server Not Found errors.

CMS Adoption. Think Vertical, Not Horizontal.

"Adoption." For years that word has been on the top of the list of critical success criteria for any web content management initiative. "This project will fail if we don't achieve sufficient adoption." The goal of adoption instigated the CMS industry's usability crusade that brought us improvements like better rich text editors and in-context editing. Still, as I have written in "The Myth of the Occasional CMS User" (and Jeff Cram took one step further with "Step letting people use your CMS"), people don't clamor to use a CMS no matter how usable it is.

The truth is, most successful websites are managed by a proportionally small team of dedicated professionals. Gerry McGovern makes this point very eloquently in "Decentralized publishing equals amateur web management."

In most situations, the decentralized publishing model has been disastrous. The people trained tended to be relatively junior staff, for whom publishing to the website was just one more responsibility. The result was lots and lots of poor quality content that was never updated or reviewed.

Does this mean that we should give up on adoption? Hardly. But I do think our thinking about adoption has been all wrong. Most people measure adoption as the number of users who consent to using the platform. The more people using the system, the greater the adoption. I call this "horizontal adoption" and, like Gerry says, it is a recipe for failure.

Forget about horizontal adoption and focus instead on vertical adoption.

"Vertical adoption" is a measure of how much the CMS is used. High vertical adoption means using advanced features of the platform. Vertical adoption has always been pathetically low in web content management. Back in 2006, Lisa Welchman nailed it with her post "The Six Million Dollar WYSIWYG Editor." Nothing has changed. Most of those flashy features that you see in a software demo are hardly used and the problem is getting worse, not better. Most CMS customers are simply not ready to handle today's advanced Web Experience/Engagement Management functionality. I can't tell you how many customer references I have talked to that only use the most basic features. And the software vendors are as concerned as I am about this. At least they should be. If vertical adoption doesn't improve, customers will migrate to cheaper, simpler software.

Of course, vertical adoption isn't just about protecting license revenues for enterprise software companies. If we don't improve vertical adoption, we will never achieve meaningful digital marketing goals. The best that we can do with horizontal adoption is to have more people to fix spelling and grammar errors (and Gerry would argue that outcome is unlikely). If we want to truly engage an audience, we need power users that can get the most out of personalization functionality and uphold the company's side of the conversation.

How do we improve vertical adoption? That is the billion dollar question. There is certainly a usability component to vertical adoption but it is different from usability aimed at horizontal adoption, which focuses on reducing training by making things intuitive and point and click. Usability for a power user assumes expertise and focuses on power and efficiency. Look at an expert in any software. They use keyboard shortcuts. The user interface appears to dance in response to the slightest movements of the operator. But to the novice, these user interfaces can be inscrutable. Remember the Saabre terminals back when we went to travel agents to book our vacations? Is anyone else that old?

Achieving this level of expertise requires training and specialization. You need guidance from other experts and you need a lot of practice. This means that your marketing operations program has to have reached a critical mass where you are doing these initiatives more or less continually. Advanced functionality (like personalization or lead nurturing) is not something that you get right in the initial deployment and then put on auto-pilot. You only get results when you actively use them. Incidentally, most systems integrators are primarily focused on content modeling and template development. They are not very good at the using advanced functionality within the context of a real content strategy — like looking at the full lifecycle from planning to analyzing the results.

Most organizations are really far from this level of operational maturity. They probably know these truths to be self-evident at some level; but they are all too willing to suspend their disbelief when a software vendor tells them that, with their solution, advanced digital marketing is so easy that even the CEO could do it. On the other side, I can see the temptation of the software vendor. A lot of these customers are still justifying budget for software with an ROI based on cost savings. Better tools equals less effort equals smaller team. Would you risk being the only vendor in a selection saying that your solution will raise operational expenses by needing to hire more staff?

As an industry, I think we would all benefit if we focused on promoting vertical adoption by:

• changing the conversation from "look how easy it is to edit a web page with our CMS" to a more realistic view of web operations.

• setting realistic expectations for team size and composition.

• helping to focus attention on marketing performance goals.

• promoting professional services and mentorship programs to help keep customers on track.

• identifying and recognizing teams that are doing it right.

Until we improve vertical adoption, the CMS industry will continue to run around in circles and customers will never get the results that they hope for.

There is no partial credit in digital marketing

• You sweated over SEO but forgot to set your robots.txt to allow. Fail.

• Your content is brilliant but you can't drive traffic to it. Fail.

• You bought all the right keywords but your content stinks. Fail.

• You have the content that a visitor wants but you show him something else. Fail.

• You target the right content to a visitor but the display gets in the way of his enjoyment of it. Fail.

• Your content goes viral but your site crashes. Fail.

• Your visitors are devouring your content but you wouldn't know because your analytics isn't tracking properly. Fail.

• Your visitors are ready to engage but they can't find a call to action. Fail.

• Your visitor fills out a form but the data goes nowhere. Fail.

• You are capturing leads but nobody is doing anything with them. Fail.

• You have valuable data but no actionable insight. Fail.

​

We have all been there. We focus on one aspect of digital marketing but neglecting another critical step eliminates our impact. To be successful, you have to be good at lots of things and pay attention to the details. It is better to be proficient in all of the dimensions of digital marketing than to be excellent in any one. So much for the hope that you are just "one viral video" away from achieving your most ambitious marketing goals. Welcome to the grind.