Build Customer Satisfaction by Delivering Rapidly – Agile Marketing Principle #1
What do your customers ask for (either from a product or product marketing perspective?) Chances are, it’s not always what they need. In this second post on Agile Marketing, I’m thinking about ways to deliver what your customers need, not just what they ask for at the moment.The first principle of Agile Marketing is to build customer satisfaction and market acceptance by rapidly delivering solutions that people ask for and need.
Agile Marketing, as we discussed previously, is a process to:
“Create, communicate and deliver unique value to an always-changing consumer (or business) in an always-changing market with an always-changing product.”
What do your customers ask for
Customers often ask for the thing that’s on their mind at the moment – and the best customers also consider some of the ways they might use a feature or service in the future – to solve the problem that they have at hand right now. This might be a reasonable request (can you move the doohickey a few pixels to the left) or a less reasonable request (we really need to make this work in a case we’ve never seen before, but are worried that it might happen.)
What do they need
But wait. Remember, you are not the customer – you’re simply helping them to share their requirements in a way that makes sense to them and communicates value to your organization – so the “unreasonable request” might actually not be so unreasonable. To find out what they really need, ask a few questions:
- Who will use this feature?
- What are they trying to accomplish?
- Can they do this today, and is there any alternative way to get this done?
- Are there other places you’ve seen this type of feature, and where can I find them?
- How will the user know that they’ve been successful?
This may seem to some to conflate the process of marketing and product development, and I believe that customer-driven product marketing needs to start with an understanding of what the customer is trying to accomplish, and then move to the product definition that will accomplish that vision.
What makes sense to build (and when) – start with a statement of end user benefit
Starting with a statement of customer end benefit is an excellent way to share these findings with your product development team (or, of you’re also the product development team, to establish a clear goal for the improvement you’re trying to make.)
This is actually pretty simple, and should look like:
[my customer] uses [my feature ] to [accomplish a goal] and knows when they have have accomplished their goal when [what happens]. The feature is relevant to the rest of the product because [why is this feature not a one-off], and the customer will use it [how often]
If you can write out this statement for the customer (and it doesn’t sound ridiculous), you’ve started to create your messaging points to the customer and to the internal team.
How do you deliver it – statement of end user benefit
Now comes the challenging part: how do you deliver this solution quickly, while maintaining fidelity to the end user benefit statement and also not driving your internal team crazy with spurious requests? One great way to start is to build a “PowerPoint prototype” (thanks @tamccann for the inspiration) which demonstrates how this idea might work. Then, test it with both your customer and a sympathetic member of your development team. You should get some good ideas, some questions you haven’t thought of, and some possible options to deliver the idea to the end user.
How to know when you’re succeeding
Make sure that your end delivery fulfills the user benefit statement – when it does, and when you’re able to deliver it rapidly, you’ll be closer to the goal of delivering solutions that the customer wants within a time frame they can live with. Note that the goal is not to shove poorly realized solutions out the door – it’s to understand what the customer wants, identify some options that may solve that want and validate it as a true unmet need, and to get the 80% solution out into the wild so that customers can use it and provide feedback.
It has been my experience that SCRUM has very limited applicability outside of anything but a toy project (such as an iPhone app). I think this video explains perfectly, however, why companies try agile:
Greg, it’s all about the iterative process… there’s a sense of, “I-can-do-this” that your post enables. Thanks for doing this one…oh, the line that jumped off the screen:
“Starting with a statement of customer end benefit is an excellent way to share these findings with your product development team…”
Jason – thanks! I agree -> fail forward (and learn something along the way that helps you reach the real product.)
I like this idea of delivering what people need. However, I also wonder if there’s a nuance here. Part of the definition of marketing (from the CIM, not the AMA) is satisfying customer needs profitably. As such, we as marketers don’t develop our marketing strategies in isolation, we develop them in line with business strategy, and also with technology strategy.
To become the leader in the industry you have to discover what people need, make sure you satisfy those needs efficiently and profitably, and that you are doing something over and above what your competition is doing. The competitors who jumped into the tablet market over the last two years, may have had the right business strategy to satisfy customer needs, but they didn’t always have the right technology strategy to be successful against Apple. It seems to me that really only Amazon.com succeeded with its Fire product, not because they built another tablet, but rather because Amazon thought about what product they could build that would satisfy different needs from Apple’s iPad. And we might even argue that Amazon wasn’t competing with Apple in the Tablet market, but rather making sure that Apple didn’t eat into Amazon.com’s leadership in the ebook category.
I think your statement fulfills the marketing definition’s tenet about satisfying needs, but I think it has to be coupled with profitability, RIM satisfied customer needs with its tablet product at the individual user level, but in a broader market level, their product was a me-too product that wasn’t worth the investment by customers.
How about changing the tenet to “Deliver what people need profitably?” or “Deliver what people need and meet your business objectives.”
I agree completely that you need to make a profit at some point to succeed, and also think that technology is not always the answer.
Sometimes it is a behavior change that provides a big difference. Who would have thought in 1997 (or even in 2007) that people would use mobile devices more than desktops? Technology made it possible, and people changed their behavior.
Finding the right combination of a technology that enables a new behavior, a behavior that people adopt (and adapt) according to their needs, and the ability to do it profitably are sufficient but probably not necessary to create a blockbuster success. But if you get all of those attributes together, do it profitably, *and* create that market opportunity before anyone else, then you create a grand slam (brand new market and market leadership) like Apple did with iOS.