June 6th, 2013
After 20 years in the software industry, there is one absolute truth I can share with you: someone has solved this problem before. The “this problem” that I mean can be anything from creating new software to a new marketing campaign to content creation. If you are struggling with it, look around to see how the problem has been solved. Best practices and process will often evolve over years for a given organization, but you can flatten the learning curve by learning lessons from other industries and adapting them for your use.
When I joined the Sales Engine International team, I knew I had to learn about the sales and marketing process quickly in order to effectively do my job. And despite stereotypes and the occasional friction between the engineering and marketing worlds, I’ve found the processes used by each to be remarkably similar.
In software development, we follow a process for creating our software. And regardless of the evolving ideas and current “buzzwords”, the software development process has some core steps that it shares with marketing processes. Just as software has borrowed and adapted processes from manufacturing, so too can marketing adopt processes from software development.
The first step in any process is often skipped because it seems so obvious. Namely, what is it that you want? Software has a requirements gathering phase at the beginning of any new application. For software, the aim is fairly straightforward, we are defining what this application will and will not do. For your marketing campaign, be certain you understand what the goal is. What are you creating? What do you hope to accomplish? Are you driving eyeballs to your website? Creating brand awareness in a new space? Touting your superior feature set? Define the goal and then reference it often as you work. It may seem obvious to say that you have to know where you are going before you can get there, but remember that even folks who wander aimlessly always end up somewhere.
After a software development team gathers requirements, they spend some time architecting a solution. I don’t mean to imply that they jump right into creating the new software; in fact, they spend some time thinking of the impacts and repercussions of the software requirements. This may mean creating a proof of concept or mocking up a user interface. It may mean defining some additional tasks such as modifying a database schema. The requirements likely didn’t specify that the database needed to change, but it could flow from the requirement that the software have a particular feature.
Your marketing campaign will also have some of these unforeseen impacts. Perhaps the marketing team needs to create collateral for the sales team to use as a result of this campaign. After all there’s no point of driving qualified leads to your sales team if sales has no idea what’s made the prospect so interested. More than any other, this is the part of the process where you need to write everything down, even your most basic assumptions. This is getting added to your checklist and augmenting your process. If you are creating a campaign that includes a testimonial from a client, for example, don’t skip the step where you actually get the testimonial.
Once you have completed those first two steps, you are ready to actually build some software. This part of the process used to follow a software development methodology called “Waterfall”, because the diagram often drawn to illustrate the process vaguely resembled a waterfall. In that process, the programmer would go away to a badly lit cubicle for weeks, months, or years and then come back when they had written the software application. Unfortunately, requirements, expectations, and understanding can often change while the project is being coded.
To solve this problem, a new methodology called “Agile” has slowly pushed Waterfall off the stage. In Agile, the coders are constantly checking in with the architects and the folks who created the requirements to reaffirm that the code is still matching expectations. The programmers work on a small piece of the product for a period of two to three weeks, then stop, and demo it to the stakeholders. This gives everyone a chance to see the progress but also chime in if the project is veering off course. At most, only a couple of weeks of effort would be lost rather than an entire project failing because it diverged from expectations.
This same process could apply to a marketing campaign. The team could regularly show the deliverable to the stakeholders and get feedback on whether the campaign is moving in the right direction. This also allows for course corrections along the way. Perhaps your competitors have recently released a new feature set or campaign of their own; following an Agile development process allows you to respond quickly and keep the product of your efforts relevant. For large projects, this will also help the team manage the sometimes overwhelming tasks in front of them.
Testing and quality assurance checks are essential before you release the product or begin the campaign; we’ll discuss those in depth in a later blog post.
As an organization, it is also important to make the commitment up front to follow your process. If you aren’t going to do that, there is very little point wasting your time defining and improving it. No matter how skilled your team is, following a process can save you embarrassment and headache. The problem is that the process can feel constraining, especially to smart, experienced team members.
But the process, or what is essentially a checklist, is critical for continual, repeatable success. After all, even though an airline pilot has flown for thousands of hours, he will still use a checklist at the beginning of every flight to make sure he hasn’t missed anything. For the pilot, every trip must be a success, and so they follow the process religiously. If your organization also wants every campaign to be a success, consider adopting best practices from other industries.