Ugrás a fő tartalomra

The Agile Marketing Manifesto

The Agile Marketing Manifesto

“Agile” methods are typically associated with software development--but to employ them fully requires embracing the paradigm at an organizational level. Often, web or software projects are driven by marketing goals, and the way marketing is practiced by a company ends up influencing the way IT projects are managed.
This does not bode well for many projects, because traditional marketing planning and execution bears little resemblance to Agile software development. Instead it mimics a waterfall process—which explains why many developers are still stuck doing non-iterative, non-discovery-based development, despite their fervent desires to practice Agile.
These projects, as defined by the marketing strategists and handed to the development team, are characterized by fixed scope and fixed deadline parameters, demands of predictable milestones, costs and time frames, and a hefty development cycle for a product stuffed with "required" features.
It’s no secret in the IT world that project plans of this type have an awful track record, often ending up with projects being late, over-budget, hard to maintain, and plagued by quality issues. In response, many companies opt for ever stricter control measures. Even more checks and balances are enforced to ensure that everything goes exactly according to plan. This, of course, is self-defeating, as those that recognize the emergent, malleable nature of software development know —and makes it ever harder to transition to a more successful model of Agile development.
Marketing success these days is often driven by web and software development, although many companies are oblivious about how to manage such projects, and cling to strategies which are counter-productive to their effective execution. This is understandable, but unfortunate. The antidote is simple; align the marketing and development strategies so that they synergize, instead of conflicting with, and ultimately defeating each other.
In this spirit, I offer an “Agile Marketing Manifesto”; a guideline of values for this new era of marketing in which technology—and the ability to develop it—has become a deciding competitive factor. As with the original Agile Manifesto, I will express this as a series of contrasting principles--both of which have value--but with with a bias towards one over the other:

CROSS-COLLABORATION OVER SILOS AND HIERARCHY

Many companies are built around a "divide and conquer" mentality. Separate specialized departments deal with specialized parts of the business, and decision-making is carried out in a top-down manner.
The problem is that the projects we want to do touch people, interests, and knowledge areas across the organization.
The marketing folks don’t understand the technical issues and the technical folks don’t understand the marketing issues, and by not collaborating it sets the stage for missed expectations, frustration, and stress on both sides. This is more than just “feature level” collaboration. The goals, direction, and architecture of the project must be fully understood and accepted by all sides in order for it to be correctly designed and implemented.
In fact we need everyone touching the project--including product owners, designers, marketing folks, analysts, testers, and developers--all in the same room and communicating effectively—and frequently--throughout the project, from initiation to launch. It’s when you have people making decisions and planning in isolation that things run into trouble. A strong agile team is not just a cross section of developers, but a cross section of the organization itself.

FREQUENT SMALL EXPERIMENTS OVER MAJOR CAMPAIGN PLANNING

A little planning is good, if it facilitates decisive action. A LOT of planning, however, has a paralyzing effect, resulting in long delays in getting anything out the door as companies remain mired in meetings, approval processes, and rounds of analysis.
The traditional marketing experience is to plan giant campaigns and roll-outs where hundreds of tiny details are examined and coordinated like a complex symphony. Meanwhile, the winners in today's technology-driven market are testing and implementing while others are still poring over the drawing board.
What is worse then taking a long time to take action is finding out that the action is not as successful as hoped, resulting in large expenditures of time and money being wasted. This is the dark side of placing "big bets". A more Agile approach would be to employ a "small bet" strategy, by constantly testing small, even rough concepts, to gauge their potential. Failures can be quickly discarded without incurring huge expenses, and successes can be further built upon with the benefit of actual customer data and reactions as guideposts.
The key to the strategy is speed--being able to quickly draft a concept, develop it, test it, and follow up on the results. That means putting aside the notion that the only winning strategy is to compete on features--spending months in the lab "building the better mousetrap" before we make a public reveal. The fact that technology changes, competition changes, and market changes occur at a pace never before seen in the history of commerce has diminished the value of long term planning and increased the value of responsiveness and agility.
This is an advantage in itself because many large companies are so hamstrung by their own process that they can only move slowly and with great deliberation. Discovering what works and what the customer wants through frequent small experiments will ultimately result in a better strategy than spending large amounts of time thinking about strategy itself.

TESTING AND MEASUREMENT OVER EXPERT OPINION

Business in general is rife with personal judgment as a guiding principle. We tend to judge things by the way we think, the way we perceive, the experiences we’re familiar with.
Marketing and PR, especially, is beset with folks claiming to be “experts” on customer behavior and “best practices”—much of which is actually based on personal opinion, anecdotal evidence, or untested theories.  The "expert opinion” is very convincing--yet time and again, is proven wrong by actual customer behavior.
This is a frequent occurrence because ideas propagate easily based on factors such as authority, ease of transmission, popularity, group consensus, and imitation. This approach, influenced heavily by biases, is "hit-or-miss" when it comes to reflecting reality.
The Agile approach, conceptually speaking, is an empirical one; and while in the past marketing was faced with a "black box" dilemma in terms of customer data, this is no longer the case. Sophisticated data tracking is available for every type of online activity, as are testing platforms that can be used for research and optimization. Customer reactions can be observed and measured in intricate detail.
The shift in thinking is to apply the scientific method to marketing. While this has already happened in the academic world, in the field many marketing managers still operate based on lore, consensus, and personal judgement.
Changing our approach requires humility and an investment in new skills and tools. Learning the principles of good test design and analysis are now key in marketing. Equally as important is investing in the infrastructure that will allow this testing to take place--the right software systems, resources, facilities, and budgets. By informing ourselves with better data, we can avoid wasted efforts and achieve dramatically improved results.

AUTHENTICITY OVER CORPORATE IMAGE

The projection of image is so over-done in the business world that we can't take anything at face value anymore. Everyone tries to appear larger than they are, more successful than they are, more capable than they are. It is an age of hype, pretense, and hyperbole.
A campaign of propaganda often exists inside an organization as well; human resources maintains a flow of "positive vibes" while bad news is carefully hidden or spun in the form of carefully worded memos and press releases.
All of these things serve to decrease transparency and visibility throughout the organization, which is contrary to the Agile spirit.
Is it so scary to share information and status freely with all parties? Is it so scary to accept and admit failures as part of the process of running a business? Is it so scary to admit limitations? Yes, it is, but that fear is mainly fueled by our own feelings of inadequacy. Customers, in contrast, love being spoken to in a straightforward, unpretentious way. The truth is, they will forgive almost any mistake and be willing to support any company that they feel has treated them honestly and authentically. Employees are usually more motivated to help an organization succeed when it is transparent and treats them as equals.
Today’s consumer is more perceptive than ever before—and can detect even subtle attempts to deceive or manipulate them. Armed with social media, the backlash against any perceived lack of integrity is swift and punishing. Honesty and authenticity is expected. To do it right means making it an organization's policy from top-to-bottom.

EXECUTION AS COMPETITIVE ADVANTAGE

This is not so much a principle as it is a conclusion. Back when I was studying business in college I had a professor whose favorite topic was competitive advantage. He enjoyed asking the class for examples of competitive advantage, which he would then gleefully dismantle. We would propose technology, talent, process, service, quality, cost, barriers to entry—and he would methodically explain how each advantage was tenuous and short-lived, and the numerous ways it could be copied or worked around. The concept of sustainable competitive advantage was an elusive one.
Having worked in the business world for many years now, I have come to the following answer:  the ability to execute well.  This has become more prominent because projects today, with their intertwining of strategy, communication, marketing, technology, and project management, are more challenging than ever. The required amount of collaboration and shared knowledge is through the roof. Very few companies can do it well. Great ideas are everywhere; and so is talent. But being able to bring those ideas to life, practically and successfully, is a skill possessed by few. As can be said about Agile in general, the framework is simple; the acceptance and implementation is tricky.  

Megjegyzések

Népszerű bejegyzések ezen a blogon

SW Documentation: Requirements

Requirements Nonfunctional Requirements Q&A FEBRUARY 17, 2010  ~  ANDREW STELLMAN ~  3 COMMENTS Non-functional requirements Q&A: We answer questions from readers about using  nonfunctional requirements  on a real software project, and how to use them on a real software project. Non-functional requirements: Planning out how well your software will work A couple of months ago I wrote a post called  Using nonfunctional requirements to build better software . It’s basically a step-by-step guide for creating an easy, practical technique to use nonfunctional requirements on a real software project, treating them in a way that’s similar to how a lot of Agile teams treat user stories, scenarios and other functional requirements: by sticking them on index cards and using them to do some lightweight planning. Since then, I’ve gotten a lot of questions about nonfunctional requirements (or, as some people call them, non functional requirements...

Privacy Notice for Visitors to Our Users’ Sites

Privacy Notice for Visitors to Our Users’ Sites Sections Who’s Who and What This Privacy Notice Covers Information We Collect About Visitors to Our Users’ Sites Information a Visitor Provides to a Site Information We Automatically Collect from the Site Other Information Provided by Our Users How We Use Visitor Information How We Share Visitor Information Other Tools Other Resources Hi there! This Privacy Notice explains how we, at Automattic, process information about the visitors of our users’ websites in connection with the services we provide through WordPress.com, Jetpack (including WooCommerce Services), IntenseDebate, Polldaddy.com, and Akismet. Read on! Who’s Who and What This Privacy Notice Covers Let’s talk first about who we are at Automattic, what we do, and what this Privacy Notice covers. We are the folks behind a variety of products and services designed to allow anyone–from bloggers, to small business owners, and enterprises–to create, publ...

THE RIGHT WAY TO WRITE A SINGLETON

THE RIGHT WAY TO WRITE A SINGLETON July 17, 2015 by   Hector Matos Even though I've written about the woes of managing state in my previous post, sometimes there's just no way we can avoid it. One example of managing state is something we're all quite acquainted with - The Singleton. The problem we find in Swift is that there are SEVERAL ways of implementing them. But which way is the right way? In this post I'm going to show you the history of the singleton and then show you the right way to implement the singleton in Swift. If you want to see the right way to implement the singleton pattern in Swift along with proof of it's "right-ness", you can scroll to the bottom of the post and see it there. :) A TRIP DOWN MEMORY LANE Swift is a natural evolution of Objective-C. In Objective-C, this is how we implemented the singleton: @interface Kraken : NSObject @end @implementation Kraken + ( instancetype ) sharedInstance { ...