In my line of work, I’m constantly asked to design solutions for unique* business needs. It may be a brand new analytics implementation, or perhaps it’s porting an existing one over to a new web platform. Maybe I’m placing marketing beacons/tags in a tag manager on a site with no data layer and no engineering support. Whatever the task, one thing is for sure: You can do it the right way, or you can do it the correct way.

Wait. What?

Look, all the best online tutorials, the vendor documentation and consulting teams, and all of the “thought leaders” on [insert topic here] will tell you exactly how to complete [insert task here]. I agree. They’re right. They’re all right.

My argument, though, is that they’re only right in the perfect scenario. In an ideal, textbook environment, they’re right. Any other scenario — any real world scenario — brings with it its own unique set of circumstances and requirements. Perhaps it’s a legal requirement, or an engineering restriction. Whatever it is, it’s a fact of life, and it prevents you from taking the “by the book” approach.

In these real world scenarios, I’d argue that you really have two approaches to successfully completing [insert task here]:

  1. The Correct Way
  2. The Right Way

What’s the difference?

Honestly, I don’t really know. What I do know, however, is that one of these approaches is that previously-mentioned “by the book” approach. The other is the approach that fits best in your environment. It’s the approach that understands your unique resources, challenges, and options. It’s the approach that recognizes that the path to success is not always a straight line.

So, how do you do it? Is it the Correct Way, or is it the Right Way?

*Right. Nothing is truly unique. I understand. But, is that really the case? Perhaps the goal is what’s not unique, but the approach to achieving the goal quite often is.

Sharing what little I know with the world.