Product Strategy, Product Thoughts, Uncategorized

One of the most difficult product decisions is ‚Äúnot yet‚ÄĚ


(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!

Advertisements
Agile, Customer Development, Innovation, Marketing Strategy, Product Thoughts

It’s not enough to build a beautiful site

photo by http://www.flickr.com/photos/stasiland/

“It’s about people.” –Marcus Nelson

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.

Marketing Strategy, Product Thoughts

The Product You Deliver Will Change – Agile Marketing Principle #2

ahhh
photo by http://www.flickr.com/photos/javierbravo/276681175/

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.

Tweet this

Customer Development, Customer Service, Marketing Strategy, Media Mind

Deliver what people need – Agile Marketing Principle #1

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.

Tweet This

Agile, Agile Marketing, Customer Development, Customer Strategy, Innovation, Marketing Strategy, Product Thoughts, Startup

Ready, Fire, Aim – A Manifesto for Agile Marketing

Give your customers the ice cream they want, fastest!

Agile Marketing: How to succeed at high speed during great ambiguity

The Agile Manifesto describes 12 principles for creating software:

  1. Customer satisfaction by rapid delivery of useful software
  2. Welcome changing requirements, even late in development
  3. Working software is delivered frequently (weeks rather than months)
  4. Working software is the principal measure of progress
  5. Sustainable development, able to maintain a constant pace
  6. Close, daily cooperation between businesspeople and developers
  7. Face-to-face conversation is the best form of communication (co-location)
  8. Projects are built around motivated individuals, who should be trusted
  9. Continuous attention to technical excellence and good design
  10. Simplicity
  11. Self-organizing teams
  12. 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 …

Tweet this

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…

Tweet this

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 …

Tweet this

Principle 5: Sustainable marketing requires you to keep a constant pace and pipeline РAlways Build Content

A good acronym to keep in your mind is ABC ‚Äď Always Build Content.
Maintaining the pipeline of content helps you to keep up the frenetic pace
of your developers and gives you some room for more mistakes. How many
tweets, blog posts, and customer contacts will you complete today? At least
some of those items in the pipeline will generate future business (you just don’t
know which ones yet.) Read more …

Tweet this

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…

Tweet This

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…

Tweet This

Principle 8: Plan for everyone to get it right 98% of the time, and double-check the important stuff.

We all make mistakes ‚ÄstAgile¬†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…

Tweet This

Principle 9: It‚Äôs your Job ‚Äď be good at it.

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 …

Tweet This

Principle 10: Keep the marketing simple, stupid.

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 …

Tweet This

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 …

Principle Next – Please Join In

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.
Product Thoughts

Are you selling a vitamin or a painkiller?

Vitamin, or Pain-Killer?

Which conversation would you rather have?

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”

OR

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.