(photo by https://unsplash.com/photos/HOtPD7Z_74s)
What’s the most important thing you do at work?
Most of us, when asked “how do you create job security”, default to explaining a way of interacting with others that only we can do. If you have unique skills, of course you would want to create a solution where you can solve the problem. It’s romantic to think that you – the cowboy or cowgirl – can race into the important situation and solve the problem where no one else can, or do it faster than anyone else.
Described differently, “I am the only one who can get it done on time and under budget” also looks a lot like “I am a bottleneck”, or “my company is now vulnerable to the ‘Bus Problem’, where if I get hit by a bus my company will have absolutely no way to do the things I know how to do. These statements now look a bit different.
A Corollary To What You Do Today
But what if creating personal job security looked completely different and had more to do with creating systems everywhere you go that help everyone else in the company raise their game? In this version of the bus problem, maybe the solution is to make bus schedules (so that all buses run on time), and develop contingency plans (like snow routes) for what happens when there is inclement weather or other unexpected behavior like traffic?
The best way to solve the problem of institutional knowledge sharing is to share that knowledge. Duh. But it means more than simply barfing out that information in whatever messaging suite happens to be the flavor of the month. True knowledge sharing means that you can isolate the facts and share the strategy implications of changing course, that you can write a procedure anyone in your company can follow, and that if you are not in the office the process works without you there.
What does this look like in practice?
Let’s say for the moment that you are responsible for updating the team on a new feature in your product. As a consumer of that information inside of the company, each person in each role needs something different. Sales might need to know if the price of that product changes or if specific customers had been waiting for it. Marketing might need to know if there are marketable features that could be shared with a wide audience. Engineers might want to know if there are new things to test and build. And Customer Support needs to know the typical things customers will ask and how to solve their problems.
Compare your original goal of becoming the only one who can solve a critical problem with the goal of sharing information with everyone in the company at the right time to ensure a productive product release. If you don’t create systems that ensure people on your team know what they need to know before you can tell it to them, you will fail. Your participation in the process should be the reinforcement of the knowledge, rather than the only way they know that information.
Start today by writing down an important thing that no one knows into instructions that person can follow, and then take the day off. Train a trusted resource, take the day off, and see how things went. If you get to “One in a Row” on this problem, you’re ready to tackle the next critical business process you own until the whole business can run without you telling them which buses run next on the schedule.
(Photo courtesy of https://unsplash.com/photos/3IVOgGIBsM0)
I recently had a (great) idea for a product. In my head it made perfect sense – a way to make it easier for people building presentations to get instant help from a trusted freelancer. Surely many people would be excited to try it out.
The idea went from sketched-out prototype to tech exploration to see if it was possible to execute the thing I was thinking about, and two things happened. First, two very smart people asked whether this is a problem that anyone has, and whether I had any data to prove the size of the market. Second, I realized I hadn’t done enough work to move from idea to execution.
“Of course,” I said, sharing market validation stats and thinking about channel partners. But then it hit me – I hadn’t yet taken the fundamental step to validating the market need by hand with no tech investment and no real effort spent. Ideas are a dime a dozen until they have some traction.
And it made me consider the optimal way of moving from idea to idea++, or taking the first next step toward validation. “Paper prototyping,” – the effort to simulate the experience of building product without actually building that product – is useful when combined with tests to establish demand.
In this case, what was needed was a plan to ask people (ideally those I don’t know) to state that 1) they needed help with presentations and 2) that they are willing to pay other people to solve that problem.
One way to test that would be to use an existing site where people request freelance assistance (let’s say Fivvr, Upwork, or similar) and put up an ad for services. The responses to this ad would give one set of signals for demand. Then, the type of work that resulted might help me determine whether the initial hypothesis is worth more thinking. And third, the initial revenue would give clues to the potential profitability of the idea.
Do I know whether I have a great product idea? Not yet. The next step is to validate whether presentations made “good enough” are sufficient for most people, most of the time. If that’s the case, on to the next idea, until there’s a bit more signal that this one is more than a momentary aha!
Marcus Nelson’s blog post today about the potential for creating a renaissance at familiar names like Flickr, Digg, and Yahoo challenged me to think about the internet services that I actually pay for (and don’t just use as a beta customer) and the critical differences between these “gotta-have-it” products and the rest of the Internet chaff that’s easy to try these days in an almost zero-friction way thanks to the power of social login (which reminds me, I’ve got to clean up my Facebook and Twitter authorization.)
Sorry Design Hackers, Design is Not Enough
Marcus’s axiom that “it’s all about people” is a powerful one because it’s not enough to build a beautiful site (or app) these days – you also have to build a habit that allows people to learn and practice a known process that brings them tangible benefits. Yes, you say, great design is necessary for great apps (I agree). I also think that it’s not sufficient to have a beautiful design where the principal message to new users that don’t get it is “you didn’t do it right.”
Great Apps Start with Unmet Needs – and Fill them
A perfect example of a service that’s both well designed, beautiful, and deadly accurate and functional is Sanebox. We all have the problem (or at least most of us do) of having too much email and not enough time to deal with it. And an even greater problem is the inability to know which emails are likely to deserve our attention. Enter Sanebox – it takes this unmet need and addresses it with an elegant solution – categorizing the mails you see into filters that allow you to scan and review your mail (and bacn) easily. Do I have other solutions for this problem? Yes. Do I pay for Sanebox? Yes.
A Great Need, Unmet
As Marcus points out when talking about some of the “original” internet apps like Flickr, Digg, and Yahoo, they have stagnated because their customers still have great, unmet needs, and have moved on to other services that offer adjacent substitutes (and oftentimes leapfrog innovations). I started using Instagram because it was an easy way to share photographs in a social way – and it offered a fun way to manipulate images that was easy and satisfying. I stayed with the service because it’s still a lightweight way to share photographs. I – like Marcus – still subscribe to Flickr Pro – and I’m wondering why I still do. If Instagram were to offer me an easy way to archive photos (perhaps through Dropbox) and gave me a way to upload non-square images, they would have me as a customer (until the next big thing comes along.)
People are Sometimes Stuck, but that Doesn’t mean you should stop innovating
People resist change (or I wouldn’t still be a Flickr Pro member, obviously) for lots of reasons. But that doesn’t mean that your product should stay the same. Keep building the features that people use (and get rid of the ones they stop using) and you’ll be farther along the path of building an innovative, interesting product that people compelled to pay for, even when new and shinier products come along.
Build your marketing plan so that the “Oh that changed” moment doesn’t derail you – Agile Marketing Principle #2
Have you ever started a project assuming that the end product you were delivering would look exactly like the original specification? Yep, everyone’s done that once (or twice) and then realized that the process of product development lends itself to greater certainty the closer you get to the delivery date – and not before. It would be great if agile development always delivered the results of the original team’s vision. The second principle of Agile Marketing is to build your marketing plan with the knowledge and expectation that your product deliverables will change – and to not let the “oh s$%^t” moment prevent you from being successful in communicating and delivering value.
The Product Process: Capturing Rainbows and Unicorns
It’s easy to think that the first (or even second) iteration of a project will somehow emerge, full-formed and testable, feature-complete and pixel perfect, at the time that development teams, product managers, and marketers agree. And this turns out to be about as easy as procuring unicorn hairs or gathering gold at the end of a rainbow – because the real product that gets delivered is a product of the process, the people, (and the users, if they are lucky enough to use the product during this process.) in the digital world, where the prototypes are usually built in someone’s head or delivered as sketches rather than physical products, the gap can be bigger and unexpected. What’s a marketer to do to mitigate this product shift?
Products provide solutions to customer needs – sell those needs
Any product worth its salt provides a tangible solution for an unmet customer need. Dropbox solved the problem of being able to share files across desktops. Stubhub allowed customers to sporting events and concerts to buy tickets more efficiently on the secondary market, and for season ticket holders to sell their unwanted inventory. Twitter gave people a mouthpiece to speak to the entire world (albeit in very small 140 character bursts. And all of these products didn’t end up exactly as their creators expected originally. Selling the customer’s need (resolve an immediate work process pain; access unwanted and “secret” inventory; and share news with the world) gave the marketers of these products a broader brush to sell the idea until the product caught up.
Focus on the activity that will address those needs
Simply selling an idea falls flat if there is no specific activity that delivers on the promise of the idea the product is selling. In the previous Agile Marketing post on delivering what people need, we talked about an end-user benefit – the specific thing the customer will get by using your product – and how critical it is to selling the habitual use of your product. Your marketing plan needs to focus on the activity that addresses the customer’s needs, and educate the customer directly on that benefit.
Build the marketing campaign off of the “Paper Prototype”
What’s it going to look like? During the design process, you should have built a “paper prototype” – or some sort of approximation of the eventual functionality, user experience, and feedback the user receives when using your product. This prototype gives you a design idea (what you’re selling), the end-user benefit (why the user wants to use this product and the motivation for continuing to use it) and the user experience (what they will do and how they will feel while using it.) These are all emotional reactions that you can harness in your marketing plan that won’t change even if the product experience is a bit different than that original paper prototype.
Put in place a good feedback process to understand where you missed
Except that sometimes, the product does change in a way that’s contrary to your original marketing plan (even if it’s agile.) So part of your marketing process needs to be intelligence gathering that can foster a continuous improvement process matching how the customer feels about the end-user benefit you’re selling, and how well your product lives up to that promise. 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.
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.
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.