Customer satisfaction by rapid delivery of useful software
Welcome changing requirements, even late in development
Working software is delivered frequently (weeks rather than months)
Working software is the principal measure of progress
Sustainable development, able to maintain a constant pace
Close, daily cooperation between businesspeople and developers
Face-to-face conversation is the best form of communication (co-location)
Projects are built around motivated individuals, who should be trusted
Continuous attention to technical excellence and good design
Regular adaptation to changing circumstances
This is an excellent cookbook for creating software (and is one of many good cookbooks for this process), and doesn’t describe in practice how the “close, daily cooperation between businesspeople and developers” can inform a measured plan to package, distribute and sell the software that meets a defined customer need in the market. Steve Blank describes this tension as follows:
“A startup begins with a vision: a vision of a new product or service, a vision of
how the product will reach its customers, and a vision of why lots of people will
buy that product. But most of what a startup’s founders initially believe about
their market and potential customers are just educated guesses. To turn the
vision into reality (and a profitable company), a startup must test those guesses,
or hypotheses, and find out which are correct. So the general goal of Customer
Discovery amounts to this: turning the founders’ initial hypotheses about their
market and customers into facts.” (Steve Blank, Four Steps to the Epiphany)
What Would Agile Marketing Do?
With Blank’s ideas in mind and considering the needs of the development team along
with the needs of the market, how can we develop a concept of Agile Marketing? Its
definition might look like:
“Create, communicate and deliver unique value to an always-changing consumer (or business) in an always-changing market with an always-changing product.”
During the last couple of years, I’ve worked at companies that ship product about every two weeks, and are continually developing a new product for a new market.
What are some of the methods and practices to test guesses, gain market feedback, evaluate competition, and gain distribution and awareness in the marketplace? More importantly, what might 12 practices for Agile Marketing look like?
Here are a few ideas, modeled on the 12 principles of the Agile Software Manifesto – I’ll be writing up details to these ideas in future posts, and wanted to place the 12 principles in a single post to get started.
A Manifesto for Agile Marketing
Principle 1: Build customer satisfaction and gain market acceptance by rapidly delivering solutions that customers ask for and need
You’ll have (more) success if some of your deliverables in any given sprint match things your customers have asked for (or that the market demanded through competition) and that you call out these deliveries specifically so that customers know you did what you said you were going to do. If the deliverable is not understandable by the customer, either ask yourself “why did we build it?” or produce a solid statement of end-user benefit so that your work can be better appreciated. Read more …
Principle 2: Build your marketing plan to acknowledge ambiguous and changing deliverables, even late in development
It would be great if agile development always delivered the results of the original team’s vision. Agile marketing responds to this uncertainty by focusing both on the deliverable and on the problem solved by the deliverable, leaving “wiggle room” if the team slips or weird things happen and opportunity to expand if everything goes perfectly. If you talk about a specific feature that you will deliver, you’re in trouble if you don’t ship – if you talk about solutions to a customer problem, you have more room to adapt. Read more …
Principle 3: Marketing frequently shipped software requires the problems it solves to remain similar
Using a larger “vision statement” to guide the framework of the deliverables frees the team to deliver portions of this vision on a frequent schedule; it also allows the marketing team to point at the larger picture using analogies the customer understands, rather than just software. At Gist, we called that “The
New Workstyle.” We gave the overarching strategy that name to signify that the problems we were solving were (or should be) fundamentally similar sprint after sprint – even if the technology required to solve them and the
methods to deliver them are new or recombined in novel ways. Read more…
Principle 4: Software that solves actual customer needs is the principal measure of marketing progress
When you get outside of the “bubble” and ask customers how they actually use your product (or how they’d like to use it), you’ll find customer needs. Solving these needs should be the principal measure of marketing progress. What does your customer want? And need? Measuring whether you’ve met customer needs (through a survey, user groups, user acceptance testing, or other methods) should be a critical team goal. Read more …
Principle 6: Maintain close, daily cooperation between businesspeople and developers
This item remains unchanged from the Agile Development Manifesto: the collaboration between marketers and developers is a hallmark of well-executed Agile Marketing. The more we’re all on the same page of delivering value to customers in a way that they can understand and champion to other customers, the more successful we’ll be in our customer development (and product development) efforts. Read more…
Principle 7: Use the right tool for the right job, favoring in-person communication where possible.
Mobile professionals can get most jobs done where they are using cell phones, mobile internet access, and laptops. Yet some communications (especially planning meetings with development teams) are best conducted face to face, in meetings as short as necessary, but no shorter. The concept of Agile Marketing means that we’ll use lots of tools to stay in touch (and we might be each using different tools along the way.) Read more…
Principle 8: Plan for everyone to get it right 98% of the time, and double-check the important stuff.
We all make mistakes – Agile Marketers delegate decisions to each other, confine the mistakes to the decisions that don’t matter, and ensure that the important decisions get extra care and attention from the whole team. You will fall down, make a mistake, and do something you wish you hadn’t – your team can help you succeed. Read more…
Strive for excellence that you can prototype today, solidify tomorrow, and cement through practice and process. It’s your responsibility to make yourself and your team better, and you should be working at that every day. Read more …
If you’re doing something (taking a survey, building a presentation, anything, really) … take a look and see if someone’s done it before. Finding an 80% solution is better than spending all of your time getting that solution to 98%. Read more …
Principle 11: “Spot it, Got it” – Begin with the answer in mind
Make life better for your team by suggesting a solution, not just pointing out a problem. Your guess is as good as anyone else’s on the team, and provides a straw answer for everyone else to test. Read more …
Principle 12: When in doubt, punt rather than wait.
Things will change during the next sprint. Change is a fact of life in Agile Marketing. Getting used to that change and the pace of change allows you to continually pivot to match product and market needs. Read more …
I hope you’ll join in on the discussion of Agile Marketing and let me know whether
you think I’m right, wrong, or pointing in a completely different direction. I’m framing a problem common to many startup marketers and product people. We’re all trying to create, communicate and deliver unique value to an always-changing consumer in an always-changing market with an always-changing
product – and we want to do that better more of the time.
Initial exchange with a friend: “Would you try my new product/service/idea?”
Response: “Of course, it’s great! I love it!”
2 Weeks later.
Asking the friend again: “Are you still using my new product/service/idea”
Response: “Yeah, it’s great! I love it! I can’t imagine living life without it”
Response: “Yeah, it was great. I remember it was great. It’s a really neat idea, but I don’t use it that much.”
Of course, you want to be having the former conversation at the end of the 2 week period, where the product, service, or idea that you propose to a friend (or share the value with a prospect) results in filling an unmet need on the other side. You can do this by providing a painkiller (solving a problem that causes the person pain) rather than a vitamin (nifty idea, nice to have, makes you feel good). In software land, I need to help customers identify their pain so that we can find the features they want to use (and, ultimately, to pay for) rather than just the features they think would be neat to use.
Identifying a real, rather than shiny/sparkly, need
If the prospect you’re dealing with is lower on Maslow’s needs hierarchy (water, food, shelter, etc) and you’re not selling one of those needs you might think it’s difficult to identify the real needs that person has and to identify their pain. Asking the prospect about their everyday activities is a great way to find the latent needs they don’t know that they have. “Tell me about your everyday work.” “What are the things that you do frequently?”
When you hear that someone is repeating the same process over and over again, it might be a good candidate for a pain-killer. When you hear that same need from other customers, it might be a common problem that would lend itself to being solved and would provide benefit for a larger number of customers.
Real life examples are sometimes murky and combine both Vitamins and Pain-killers:
It would be neat if … your application behaved the same way on the web as it does on my mobile device (vitamin: I like the mobile device and want my data everywhere. pain: inconsistent UI makes it hard for me to do what I want to do with your application. )
You should definitely export your information to system XYZ (vitamin: the customer wants to know system XYZ is supported. pain: the customer uses common data in system XYZ 20 times a day and thinks your application can make that process better)
Externalizing the need to make it more concrete: why would someone else use it?
You can make this process more concrete for the customer by asking why someone else would use the information. The act of explaining why someone else would use the product feature or why it would solve their pain helps to weed out the “nice to have” features from the “must have” features. Sometimes it makes the need go away — and other times prompts the customer to stack-rank that need more highly among the things she finds important.
The Best Way to Figure This Out: Listen to the Customer
The best way to figure out whether you are selling a vitamin or a painkiller is to talk to customers and understand their pain. Then, you’ll have a better idea whether you are selling a product, service, or idea what you can do to address the pain and make the customers aware of the solution. There’s no magic bullet, but the more people you listen to, the better you’ll be at expressing what the customer wants, not just what you think would be useful.