Technical marketing — what we do here at UpBuild — can be hard work. Not in an overwhelming way, but in a way that stretches the mind and forces a push toward the limits of one’s own ability. I’m thankful because that’s what keeps me interested, excited, and fulfilled after nearly fifteen years of doing this.
When I began to explore potential topics for a blog post (what has become this post), I was facing a wickedly-hard technical challenge to which there was no clear, easy answer. At least that’s the way it seemed when I was brought in.
I don’t actually do a lot of hands-on technical marketing work at UpBuild these days; I’m busy running the business and leading UpBuild’s team so that THEY can do the hands-on work. Yet I found myself being brought in to help in whatever way I could when all else seemed to have failed. I love being able to help out in that way and aim to carve out more time for it in the future, but that’s a subject for another post.
Returning to the main thread: a deadline was fast approaching, and progress had stalled. Each issue resolved in the project seemed to give rise to two more.
I then got involved, and following about four days of work — distributed over roughly two weeks — we solved the problem. Even better, we did so through a solution that provides more value to our client than if the original plan had worked perfectly on the first try.
I could have written a post about how the team and I ultimately solved this specific challenge. However, I vetoed that idea almost as soon as I had it.
The Process Behind the Solution
I didn’t want to write about that specific challenge or, frankly, any particular fix. I want to step back and write about my process. The process I used to solve the challenge that we just recently overcame; the process I find myself using again and again.
- Stop
- Question
- Profile
- Vet
- Work
- Confirm
- Refine
- Ship
- QA
I believe it’s that process which would provide the most value to the great folks who give their valuable attention to my writing, to this blog. By contrast, a tutorial on solving a niche problem based on unique variables, while it might be interesting, would provide very little value to most folks.
Therefore, this post will walk you through my process: How I solve challenging technical marketing problems in eight steps. To illustrate with a bit more detail what this process looks like in practice, I’ll also include an “Example In Practice” for each step. I’ll refer to the example case as the “October Challenge.”
0. Stop
The first step, Step 0, is to STOP.
For better or worse, I’ve found that my first instinct is to dive right in. To tackle the problem head-on by just banging out code or shooting off an email. Between Slack, meetings, phone calls, and emails that often seem to make up my work life, it’s easy to see everything in 15-minute increments. “Let me see if I can just knock this out and move on to the next thing.”
Well, when facing a genuinely nasty technical marketing problem, a 15-minute sprint is never enough. And it’s not exactly challenging to identify when a substantial challenge has just landed on your virtual desk. It’s just about having the awareness to acknowledge it for what it is rather than rushing to white-knuckle through it.
And so, step one (or step zero, as I often like to call these sorts of “pre-steps”) is just to stop. Stop and acknowledge that there’s a significant challenge that needs solving through focused attention.
At this point, I’ll either block off time on my calendar or, if my schedule is already getting pretty full, carve some time out. Hard problems, by their very nature, are rarely solvable in 15-minute work moments.
Example In Practice
With the October Challenge, I finished a meeting with the account team working on the problem and physically stepped away from my desk. Then I went on a walk. When I got back, I looked at my schedule for Thursday (it was a Tuesday at that point) and moved all my meetings for that day to the morning, and blocked off the rest of that day to think about the problem.
Takeaway
Resist the urge to dive in, and just take a breath. Ease out of reactive mode and then calmly move on with the process.
1. Question
The next step is to ask, “Why?” and I don’t mean, “Why is there a problem?” or “Why is someone unhappy about its existence?”
At this point it’s helpful to ask:
- If the problem is that a result isn’t happening or a process isn’t working as expected, why do we want that to happen in the first place?
- If the problem to be solved is related to a stated goal, why is that goal important?
- Will resolving the issue at hand help us arrive at where we need to end up?
While this line of questioning might not change the situation at all, it can often reframe the problem, change the path forward completely, or even render the issue irrelevant.
Example in Practice
When I critically questioned the October Challenge, it became clear that there were actually two challenges that could be decoupled and solved one at a time. The second is, in fact, still unresolved (long story), but the first — while not easy to fix — was one that could indeed be addressed and would, by its resolution, provide outsize value (certainly over continuing to struggle over both in tandem and solve neither).
Takeaway
Ask “why” to understand the reason you’re working on what you’re working on; don’t merely assume that the first approach happened to be the right or best one.
2. Profile
The next step is to profile the problem. Once I’ve asked enough questions to pinpoint the problem and, more importantly, be sure that the problem IS a problem, I like to get clear on precisely what’s tripping us up.
As an initial sub-step here, I’ll meet with anyone I can who might already have first-hand knowledge of the issue and get their take. I want to steep myself in as much information as possible and just absorb it before taking action.
Then, I’ll map out what should be happening. From there, it’s easier to identify where there’s a break in the chain. There’s also the possibility that as a result of profiling the problem, you realize the original (or pre-existing) way of doing things was fundamentally flawed; it could be time to go back to the drawing board.
It’s important to pause here and note that I prefer doing this away from my computer or a screen of any kind. Those with greater discipline than I may not struggle as much. Still, I’ve found that trying to thoughtfully understand a complex problem in front of a high-powered computing machine where I can open a new tab for every single half-formed idea frequently gets me nowhere.
In contrast to the ideals of Hustle Culture where the preferred time frame for solving any problem is “ASAP,” slowing down and taking time with a complex problem is critical. It’s often the difference between success and abysmal failure (a failure that doesn’t make itself known until dozens of hours are wasted and everyone with exposure to the problem is left burnt out and demoralized).
Slow down to move faster.
Example in Practice
While working on the October Challenge, I sat down with only a pen and a notebook at a makeshift desk I’ve set up. There’s no space on the desk for a laptop or for any other distractions. Through a combination of written text, crude illustrations, and arrows, I wrote down what I thought needed to happen. I then annotated where important things weren’t happening (e.g., data being dropped, a tag not firing, etc.)
In the days when I worked in a downtown office, I’d grab my noise-canceling headphones and commandeer a conference room with a whiteboard for this step.
Takeaway
Use whatever analog tools you have on hand to allow your mind to think deeply away from digital inputs.
3. Vet
Step three is to vet your idea and sell yourself a clear solution. At this point, I’m still away from my computer. Before I crack open GTM, log into a WordPress admin panel, or begin firing up a half-dozen Chrome tabs, I write out my solution on paper.
I’ve developed clarity on what the problem is, so what is the ideal solution? What does the perfect end state look like? What steps need to be taken, or what changes need to be made to get there?
I want to have a clear plan in place before subjecting my often-fragile focus to a digital playground of rabbit holes and other distractions.
The goal of this step in the process is to sell me on the solution. By playing the role of both “seller” and “buyer,” I ask critical questions.
- Is this the best way to do X?
- Will that be a reliable long-term solution once you’re not involved?
- Is this too convoluted or more complex than it needs to be?
- Are you proud of this solution?
If I can ask myself these questions and confidently respond, I know I have something worth working on.
Example in Practice
There’s not much in the way of “show your work here” since, for me, this is primarily an internal dialog with myself. It involves staring at the crowded pages of my work from Step 3, along with much tapping of my pen. That and a fair amount of pacing. Occasionally, staring out the window comes into play.
However, with the October Challenge, this vetting stage helped rule out using 3rd-party plugins and solving certain obstacles though manual data entry in a spreadsheet; neither of which would have been a solution to be proud of nor particularly reliable long-term.
Takeaway
Take a moment to vet your idea and make sure it holds up under intense scrutiny.
4. Work
The next step is to get to work. It’s time, finally, to get back in front of screens and implement the solution I’ve mapped out. This is almost never as simple as “do this, do that, then do the next thing, and we’re done.” There are always diversions and rabbit holes, as well as new things that need to be learned. But the point is, having the game plan in place makes all the difference. It’s my tether to forward momentum so I don’t get lost along the way.
Example in Practice
With the written plan on my desk in front of my monitor, I opened up CodePen.io, an old LunaMetrics blog post on a relevant topic, the client’s site, and the console log in Chrome. Of crucial importance was the fact that I did not open email, calendar, or even Slack.
In the case of the October Challenge, there were rusty skills I had to polish up (I had not written a ton of vanilla JS in 2020) yet the clear plan in hand allowed me to comfortably divert my attention so that I could brush up on JavaScript array functions while providing easy access back to focus.
Takeaway
The investment in steps one through four (Stop, Question, Profile, Vet) multiplies your productivity and dramatically increases your chances of success here.
5. Confirm
The next part involves getting some outside confirmation: a second opinion once your initial solution has come together. Every writer knows (or should know) that you can’t proofread your own work. You’re too close to it. You’re too invested in it. You’re too proud of it and/or you’re hyper-critical of it.
So whether a particular technical marketing challenge looks more like text content, JavaScript code, or database queries, you’re going to need to have someone else proof your work. I’ve found that it’s largely unhelpful to simply ask a peer, “Hey, does this look good?” and more constructive to ask, “Look at this and tell me why it won’t work. How would you break this?”
Example in Practice
The feedback I received during this stage of the October Challenge was worth its weight in gold. While it was admittedly a bit of a gut punch to hear and realize at first, I had reinvented the wheel for one aspect of the solution. Even though I was excited about the code I’d written for this particular portion, Will found an existing open-source solution that did what I was trying to do but in a much more elegant and stress-tested way.
Takeaway
You, ostensibly, like your own solution and have invested a lot of time and energy into it, so use an outside perspective to confirm or deny that what you’ve done is as great as you think it is.
6. Refine
Step six is to refine from complexity to simplicity. This step might be considered optional and if the solution to a technical marketing challenge that you’re working on seems perfect after your first attempt, kudos. Mine rarely are. Things can almost always be simplified. A step can be removed; a function can be optimized; the logic could be made more intuitive. Unfortunately, it’s only after the first attempt that these opportunities for further optimization make themselves known.
Example In Practice
Armed with the feedback I got in step six, I refined my solution here. These two steps, building on one another, caused me to look objectively at the quality of my work, scrap part of it, and emerge with a comprehensive fix that was much more elegant and reliable than it had been as a “first draft”.
Takeaway
While there may be a powerful urge to call it “done,” take the time to pare away anything nonessential and apply some polish. It’s always worth the extra time.
7. Ship
And at long last, step seven is to cross your fingers and ship the solution! After working on a tough challenge for a long while (the last two big ones I worked on took four hours and three days, respectively), you kind of start to question yourself. Is this really done? Am I just burnt out and this is going to fall apart once this goes into production?
I’ve found that by following the preceding seven steps, the process has already done a lot of work to protect you from potential pitfalls. The pitfalls typically stem from rushing, not vetting things carefully enough, or working in complete isolation.
Example in Practice
With the refined solution ready to go, we hit Publish in Google Tag Manager and popped over to real-time Google Analytics to watch as the prized data started coming in.
Takeaway
If you’ve followed the process, you have every reason to celebrate when you hit “save,” press “publish,” or commit your new code.
8. Quality Assurance
But don’t celebrate just yet. The final step is Quality Assurance! This will look different for different solutions and take varying amounts of time (e.g., a website with copious web traffic will allow for thorough QA of said data much faster than a website that attracts a few dozen visitors per day), but it’s critically important.
Example in Practice
After some careful quality assurance over the next few days, we could certify that the problem was solved. As icing on the cake, it seems like what we did here could provide value to some other organizations as well. Though, of course, it’s never just about the data you collect; it’s about the action you’re able to take on it.
Takeaway
Ensure that you and — if possible — at least one other person test that the solution is working as intended. If what you’re building needs to work in a variety of browsers and/or on mobile devices, make sure to test in those environments as well!
Thanks for your time and attention. I hope reading through my problem-solving process has been helpful. Until next time, happy optimizing!
Featured image courtesy of Kelly Sikkema, via UnSplash
