“Now What? Your Post Launch Growth Plan” Podcast and Transcript

Add comment April 1st, 2008

Adapted from a presentation on “Now What? Your Post Launch Growth Plan”
at the KASE Entrepreneur Seminar on October 16, 2007.

Download: MP3

If you take away nothing else from tonight, it’s that going from your beta to your launch requires that what used to take an enormous amount of effort to achieve a level of performance has to become routine. You cannot rely on heroics once you are scaling the company: you have to build process and procedure into it. So, we are going to talk now about how you grow after launch in three areas:

• at company level
• in customer development (sales, marketing, and business development)
• in product development

At a company level, what’s the challenge after launch? The challenge is that you have to build an effort that you can sustain and scale, which means you have to develop things like process and metrics and dashboards.

So…process, metrics, and dashboards…most of you probably have left big companies where you had process dashboards and metrics, and you are thinking “I don’t want any more of that.”

Just as little process as possible is a good thing, but you can’t get away from it completely.

After launch, you grow from a small team of generalists to a larger team of primarily specialists, because with that comes division of labor and the ability to scale. You can’t just keep hiring generalists, utility infielders who are comfortable in the white space on the org chart–an org chart that used to be pretty much entirely white space now has a lot of boxes on it. You’ve got to hire people that are outstanding in that one particular box, in part because they can rely on the folks in the boxes around them to be outstanding as well.

In the beginning, as you are adding customers one by one, you are just trying to get that next customer. After launch it’s about next quarter, it’s about a business plan; it’s about a revenue target, it’s no longer one by one.

In the beginning there are only one or two people–typically the CEO and CTO–who can actually make a binding commitment. But for your company to scale up, a whole bunch of people start to make promises to a lot more customers. This means two things:

1. If you don’t have a plan, it’s like running a development effort without a source code control system: you don’t know what you are changing, so you need a plan.
2. If you don’t agree how you’re going to change that plan; if you don’t develop a change process, you are going to spend more time arguing about how to change the plan, then on the merits and drawbacks of the change that is being proposed.

So post launch, there is much more need for a plan of record and a change process that people buy into.

Audience Question: Roughly, how long are these plans? It sounds like there is lot of work to develop these plans and targets and commitments and keep updating them.

So, one or two pages is reasonable length for a plan, that’s what most people can absorb. Especially for your near horizon, a one or two page written plan is normally enough to get you there; you don’t need a book. But, you have to have it written down and documented: it can be a wiki page, it can be something as easy as that to change–and track changes–but it has to be in writing.

How many people have sales guys in their company? [No one raises a hand.] Okay. Well, after you launch they may become more important.

Right now the sales incentive for Beta is very simple, if we make the sale we all get to keep our jobs. It’s a pretty easy thing to focus on. But, after you launch you get what you reward, so you want to pay very careful attention to whatever you put into that compensation plan, and how it aligns with your business model.

As you scale up, it’s more than just new accounts. Right now for most people that are in Beta or just have early customers, it’s all new accounts. Later on there are also renewals and upgrades, these require a different focus and different incentives.

So, we do a lot of work with software companies; this talk is aimed more at software companies than hardware companies. With hardware it is hard to add features to a chip once you’ve shipped. The point is that software startups are tempted to of accumulate a whole bunch of small features into some kind of shotgun blast full of birdshot, and hope that something will stick; some golden BB against the wall.

The reality is this that big features, important features, are what drive interest and adoption. So, as you are doing your planning, think about one or two things that are actually going to move the needle on prospects’ interest, and plan the release around that.

Also, just because you don’t know about the bugs you are going to have to fix in the next two weeks or four weeks or six weeks: they are going to show up. Leave some cushion in the schedule: don’t try and put eight pounds of feathers in an eight pound sack and discover another three pounds as you are half way down the road.

In the beginning, as we are going one by one for customers, a special for this customer makes a lot of sense. After you launch, when you are going after markets, this becomes a much more unattractive approach. You want to limit the amount of work you do for any one customer.

Early on, early adopters are very smart people, and they have a couple of wonderful features:

• They are highly risk-tolerant.
• They don’t mind if things don’t quite work–as long as you ultimately get them fixed.
• They’ll actually buy the product without having to be sold.

Problem is they are just not enough to actually build a company on, but they are wonderful folks in the beginning. And, a lot of people think this is going to go on forever, and alas it doesn’t.

So, nobody had any sales guys, so right now the CEO is selling in your startups? Who is selling in your startups? CEO, alright; so typically one guy is kind of like the gorilla, the tall thin engineer whatever doing the selling, right? And, still figuring out what works in the sales pitch and what doesn’t.

The founders have to be directly and intimately involved in selling, because maybe it’s not the sales pitch, maybe the product sucks, right? Maybe the business model is not quite right for what you are trying to do. The founders have to be intimately involved to be able to make adjustments between the message, the product, and the business model. Also, if they are not involved now, they can’t manage later on as they scale its sales force. So, you have to learn what’s involved with managing the sales force. It’s not magic. It’s not hire the best liars you can. It’s a real art.

We sometimes talk to firms that have hired and fired several sales people. They don’t yet have a sales pitch that works, and they are just burning money. Don’t do this. A real sales guy will give the same pitch over and over again, because that’s what works in the corporate world, and that’s what normally works post-launch. Because, most of the time they have been handed the pitch that works, and so if it didn’t work with this prospect, then it’s the prospect’s problem. During beta and for your early sales, your pitch may suck and will need to be changed.

A lot of engineers we talk to say we can’t figure out how to get the sales guys to do what we want them to do.

We reason with them.
We talk to them.
We invite them to meetings.
We show them the corporate mission statement.

Let me explain you, it’s very, very easy to get a sales guy to do what you would like. You adjust his compensation plan; you pay for what you want and you manage against that. It’s very simple. If you don’t do that, you are wasting your time and his.

Now we are going to look at customer development in Beta versus after-launch. In the early market you are exploring; you launch when you believe you are going to accelerate. You’ve found a market; you’ve found a way to go.

In the early market, you’ve got a number of hypotheses that you are testing. After you launch, you better be working based on facts and metrics. Now, some people launch and nobody comes, I submit to you, you are still back in the early market.

In the early market, you are trying to adjust your business model, adjust your promise. After you launch, you are penalized for changing that promise a lot, so you better figure that out before you start to put the big megaphone in front of it.

In the early market you are trying to find a niche, you are trying to find some place to insert and get some foothold. After you launch, you are trying to find a big market. Don’t confuse those two.

Here’s an example of how I learned how sales guys look at problems. At the time I was running support at MMC Networks and over a period of about nine months we hired nine or ten new staff. We scaled support from about six to fifteen people. We were supporting more than sixty active design projects with more coming in every month.

I went to John the VP of sales and said, “we can’t support all the people you are bringing us, can we slow down? Can we focus on the big guys? Can we–you know–focus for effect?”
John would say “you know you are absolutely right.”
So I would say “Great!”

Next month more new evaluations.
Back I go to John: “We can’t support this many new firms, they are falling on the floor. We have so many that the thrashing in talking to them is taking more time. We are actually getting less done then if we had fewer evals.”
“You are absolutely right.”

Next month, more evals. Finally asked him, “John, how are you compensated? Are you compensated on revenue?”
He says “No, that’s way too hard to figure, that’s way too downstream. We are compensated on design starts.”
So, then I knew my argument was not with him.

How many people have heard of Jotspot? About two years ago they were kind of struggling against Socialtext, they announced three thousand beta users. Big press release, big news, big noise. Months go by, much testing, the development guys are very happy, because we are getting the product tested; this is great, this is great. Then they launch, and they say now that we are launched it’s not free anymore. You have to pay, or in thirty days we are going to turn you off.

They figure they’ll get probably half or at least a third of these beta users. It’s more like 2%. They have to go back into the garage and figure out how is it that you actually find guys that want to pay for the product, that don’t just want to use it for free.

For all of you that are doing free, freemiums, social networks, and all this free stuff, I would submit to you, there’s a hell of a difference between getting guys to use stuff for free than for a penny. You are better off now–day one, user one–figuring that out.

Finally, we get to product development.

The interesting thing is we talked in customer development about how things change. The challenge you have in running product development post launch is, you want to hang on to the values and the things that got you where you were. So in fact, you don’t want things to change; in particular you still want a fast clock cycle in decision-making. And, you want to maintain as much creativity, flexibility, and intelligent reaction as you can. You want to fight bureaucracy as hard as you can.

Iin beta its really simple; does the thing work yet? No. OK let’s not ship it. Later on, you can’t do it that way, because you end up in an infinite loop where more bugs flow in, more feature requests flow in, and the release balloons into a whale that never ships.

Also, QA is a function of about the cube of the number of features. So, as that release grows large, your ability to test it gets away from you exponentially. What works; pick a date, stick with it. Let one or two major features drive that date, fix the problems you can; live with the rest until the next release.

There is always a reason to hold the release.
There is always a reason to hold the release.
Resist that it and get it out.

If you have a faster decision cycle, several things get a lot easier:

• You don’t have to be as smart about the market, because you are going to be in contact with it sooner.
• You don’t have to look six months ahead; you will have a product out there in two.
• You don’t have to forecast customer needs; you are going to be bringing them ideas asking “what do you think?”
• You don’t have to anticipate your customer’s actions next year, because you are going to be inside their reaction cycle.

Audience Question: So, what’s the difference between a faster decision cycle and a slower one?

Historically the on-premises software guys were working on an annual release cycle. I would submit to you that you guys should be looking at least quarterly and better monthly releases. That way you are moving well inside of their decision making cycle. It’s different for chips, different for other kind of companies; but you want to be much faster than your more established peers. And, you want to stay fast as long as you can, because the risk of somebody flying up your tailpipe is much more than somebody stepping on you.

Question for Audience: How many of you are working in a startup that can still fit around one table? Say, a table with eight people, OK?

If you have to have a meeting, everybody in the company can be in the room. The executive staff is the product team is everything else: conversation, fast decisions, everybody is there.

You get bigger, your temptation is to have the executive staff hang on to all of those decisions. But what you really have to worry about is growing the company, you need to delegate to a product team that has a representative mix of folks from the various functions to drive the product.

If you are one of the founders, you have to worry about growing the business; let the product team run the product. You might at some point have two products, or three products.

At Beta: not so many commitments, and actually a lot of the commitments you make don’t matter, because the customer doesn’t buy, you can forget about them. Later on, more people remember.

Early on when it’s ready you can ship it; later on you’ll go dead doing that. Early on what’s that guy need; later on you better be working to a plan: maybe one page, two pages long.

In the beginning you could be customer [deal] driven, but later on you have to be market driven. You can’t just satisfy a handful of folks, and somewhere around nine customers; a customer driven model starts to break down. So, unless nine customers gets you to where you want to go; you’ve got to be thinking about making a transition to a market focus.

What stays the same: fast decisions, stay creative, stay flexible.

Another story: we use WebEx Office, and we use that for our calendaring.

So, we invite our customers to come to meetings with us using Webex Office, WebEx Office was originally developed by Intranets.com, which was an intranet application where typically a manger is sending an invite to a subordinate. In that context you can say things like, “you are required to come to this meeting.”

Now, in a consulting context, when I require my clients to come to meetings, they write back and say “I don’t think it works that way, you can invite me to a meeting, but you can’t require me to do a damn thing.”

We call up WebEx and ask can you fix this, can we change that little piece of text you are generating with my name next to it, that’s pissing my customers off?

Roach motel: request goes in, no sound, no picture, who knows. So, knowing a little bit about things, I call the sales guy and say “you know we may quit paying you for this.” Because we pay them every month. So then, we get a meeting with product support, no roadmap, no tracking; and I get a lecture about how hard the product manager’s job is. I go hey I’ve got a hard job too.

If anyone knows a good alternative to WebEx Office I’d actually like to hear it. Don’t be these guys.

Who knows what a whole product? A whole product is everything that’s needed to solve the customer’s problem: documentation, interfaces, useful error messages, etc.. In the beginning you can have a partial product. You can have a product that geeks can love; later on it’s a product your Mom has to be able to use.

Audience question: How does a transition take place from where we are all running around ad hoc to where we are doing these one page plans that make it scalable and repeatable?

Typically there are one or more failures, some people lose their jobs, and then new people come in and things change. Don’t be those guys either.

Audience question: At what point, you know when you have a CEO that’s so hands on in the company, and then things start to specialize and differentiate. I mean is there any point at which CEO starts to delegate? Say for sales department for example?

There are a couple of challenges. The CEO is either sales oriented or development oriented or maybe customer support oriented. He may be trying to get out. The challenge comes above some headcount–say twenty-five–he’s got to learn to manage managers, so that happens pretty fast.

The first bottleneck is if he is the mobile sonic boom who closes business: you miss a quarter, you miss a deal. He has to be able to delegate, and teach other people how to sell. He’s got to be able to let go and other people run the product. But, that occurs pretty fast; I mean you can get to sixty people or eighty people, but at that point the wheels are going to fall off if you’re not able to delegate; so it’s pretty fast.

Another difference between beta and after launch is that normally, in beta, if you don’t have it, they won’t believe you. So, it’s much harder to fool your customers. Later on when you are a bigger company, maybe you’ve got some VC, you can show customers a roadmap and actually decoy them in ways that can do them real damage. So, meeting those commitments later on has to be done, because your customers are more trusting of you than in the beginning.

If it’s three guys in a garage, they are only going to believe what they see. If you tell them you are going to bring out a box, you can show them a picture but they are not going to give you money until they see the box. Later on if you bring out a second box, you might be able to scam them amount of some money, because you’ve given them the first box. So, commitment tracking becomes even more important after launch, because your customers become more trusting–fewer early adopters more mainstream users.

The other thing that happens is that engineering’s access to the customer gets more and more mediated. You’ve got more marketing guys, you’ve got more support guys, maybe you’ve got a customer advisory board. So, making that work, and learning how to work through intermediaries becomes more important. In the beginning, between somebody bringing the deal and what engineering wants to do, you can pretty much decide what’s going to happen. Later on, you get more input from other folks.

So we help very early stage software companies with strategies for customer and business development. We help them find early customers, early references, and early revenue.

Focus On Your Prospect’s Pain Not The Brilliance of Your Product Idea

Add comment February 1st, 2008

Any of these sound familiar?

• Are you an entrepreneur with a business idea that just can’t seem to get the support you deserve?
• Maybe you’ve completed a business plan but no one seems to want to read it.
• Or you’ve created a fantastic product that no one seems to want to buy.
• Perhaps you’ve pitched dozens of investors and no one seems to want to put money into your deal.

Will Schroter suggests you consider that “maybe your idea just sucks.”

In my direct experience starting companies and in working with a number of entrepreneurs, I think one of the key challenges an entrepreneur can face is knowing who to listen to. Most of us are surrounded by folks who prefer to be employees, and therefore most of the advice we get is essentially “be an employee.”

Moreover, many successful entrepreneurs can see their particular path as the only path, and they in effect tell you “stay on this path, it worked for me.” I think forming an advisory board from folks whom you trust and who have relevant business experience is one of the keys to success. You can’t just go it alone all the time, you have to be able to expose your plan and your thinking and get knowledgeable feedback. If you don’t have a plan, how do you know what to tinker with to evolve your business model (or what you are changing when things are not working out).

I think it’s easy to become fixated on an implementation or invention: it’s harder to go wrong if you focus on customer pain. Schroter cites a quote by Sam Walton, founder of Wal-Mart

“I guess in all my years, what I heard more often than anything was: a town of less than 50,000 in population cannot support a discount store for very long.”

Walton lists this as the tenth rule in his “Sam’s Rules for Building a Business”

Rule 10: Swim upstream.

Go the other way. Ignore the conventional wisdom. If everybody else is doing it one way, there’s a good chance you can find your niche by going in exactly the opposite direction. But be prepared for a lot of folks to wave you down and tell you you’re headed the wrong way. I guess in all my years, what I heard more often than anything was: A town of less than 50,000 population cannot support a discount store for very long.

Walton may have re-framed the problem as “folks in towns with less than 50,000 in population must be very hungry for a discount store. How could I build a franchise that would serve them?” If you can keep your focus on your customer’s pain then failure sounds like everyone telling you “I don’t have the problem or I don’t view that as a pain” instead of “I think you have an ugly baby (your new product).”

It’s much harder to get defensive when someone tells you that a particular situation is not a problem for them, or they say “I have the problem you have outlined, but I don’t think your offering represents a useful/viable solution for me.”

HP’s Early Customers Came From Fred Terman’s Social Network

1 comment January 29th, 2008

The founding team for a startup typically provides the basic intellectual capital, and frequently the initial seed capital. But a young team often has to rely on advisors for social capital, that is existing relationships based on mutual trust and prior shared success. These relationships act as points of departure for market exploration and social navigation. One early example in high technology is Fred Terman’s role in the formation and early success of Hewlett Packard. In “The Engineer Who Jump-Started Silicon Valley” a 1997 Business Week article by Joan O’C. Hamilton it’s clear that he provided the founders with considerable social capital:

Packard’s recollections complete the picture: “We built the first production model by Christmas, and I clearly recall having [the first oscillator production unit] sitting on the mantel above the fireplace,” he wrote in “The HP Way.” “There we took pictures of it and produced a two-page sales brochure that we sent to a list of about 25 potential customers provided by Fred Terman. We designated this first product the Model 200A because we thought the name would make us look like we’d been around for awhile.”

Social navigation, or the ability to navigate in a population and gain cues and guidance from individuals both directly and by their actions, is a key skill that founders must develop. As much as they want to focus on technology, finding prospects to validate that they are solving a real problem and that their solution is compelling is twice as important. Navigation requires that you know where you are, where you want to go, and how you want to get there. It may also involve experimentation and exploration of the market, and in many cases for a startup’s founders, one or more revisions to your destination.

Postscript: just so it’s a little clearer that a few of the names that Terman supplied became customers, here is another paragraph from same “Litton Answers the Call” section of the “Garage Becomes Workshop” chapter of the “The HP Way” the first excerpt above came from.

“We weren’t expecting much from our first mailing, but amazingly enough, in the first couple of weeks in January back came several orders…and some were accompanied by checks.”

Steve Blank on Customer Development Process for Startups

4 comments January 22nd, 2008

Steve Blank gave a great tutorial last August at TIE on his “Customer Development” and “Customer Validation” methodology. These are the first two steps of “Four Steps to the Epiphany,” his textbook on how high technology startups should approach the marketing and business development challenges they face. His slides are here (note that this is a PDF file) http://www.tiesv.org/TGS/EM/manageEvent/presentationDocument/471_790

Blank outlined the default high tech startup process and key phases for engineering team

1. Seed Stage: develop concept
2. Product Development
3. Alpha & Beta Test
4. Launch - First Customer Shipment

and then looked at how other customer facing functions contribute (note Seed Stage omitted because customer oriented typically not involved).

Engineering	Product Development	Alpha / Beta Test	Launch / First Customer Ship
Marketing	Marcom Materials Positioning	Hire PR Agency Early Buzz	Create Demand Launch Event Branding
Sales		Hire VP Sales Hire Sales Staff	Build Sales Organization
Business Development		First Bus. Dev. Hire	Do Deals to Support FCS

Answering his own question “What’s Wrong With This?”

• Embeds premise of “Build it and They Will Come” that only works for life and death products like a cancer cure.
• Ignores real risks for most new technologies
• NOT Can we make it work?
• Will Customers Accept it?
• Will Markets Adopt
• Has Everyone Chasing the First Customer Ship as the Goal
• Sales & Marketing costs are front loaded
• De-emphasizes Learning & Discovery to Focused on Execution
• Execution & Hiring Predicated on Business Plan Hypotheses
• Heavy spending hit if product launch is wrong
• You don’t know if you’re wrong until you’re out of money.

His prescription for the fact that most startups die from a lack of customers not a product development failure is to propose a customer development process that runs in parallel to the product development process. In fact, this is what most bootstrappers do, they focus on customers and markets from day one because they don’t have enough resources not to.

In addition to the slides Steve has one of the best books for product development management in a startup called “Four Steps to the Epiphany” that outlines in excellent detail his customer development methodology.

Postscript: I went to buy a couple copies of Steve’s book and found that they were $10 cheaper on CafePress, so if you are thinking of buying a copy, compare the Amazon link above with Four Steps to the Epiphany on CafePress.

Fostering Technology Adoption: Early Customer & Early Revenue

Add comment December 19th, 2007

Software companies typically have to convince prospects to adopt new technologies based on their shared history, their service track record, and their ability to accurately predict and deliver real results that overcome the cost and friction of adopting new tools and methodologies. There are a number of lessons we draw on to help startups attract their first paying customers.

A lesson we can draw from the networking industry is that competitors must corporate to create a market. Everyone who developed their own proprietary protocols lost: no one else could connect to them and customers were leery of an investment in a closed system.

A lesson from open source community is that you are not a leader if you cannot get people to follow you. There are tens of thousands of open source projects, with new ones added every day, but the successful ones get people to contribute.

Social media tools like blogs, wiki, podcast offer this lesson. Below a certain team size, it’s all a social process not a workflow.

The Internet Engineering Task Force (IETF) model reminds us that elegant plans lose out to ugly working code based on rough consensus. In the words of Dave Clark in “A Cloudy Crystal Ball”

We reject: kings, presidents and voting
We believe in: rough consensus and running code.

Two lessons from the success of Software as a Service (SaaS) offerings are to focus on the under-served segments and provide the whole solution.

Gaming industry and SaaS remind us that people have to like using your product. IT has largely forgotten this and tends to rely on mandated usage.

Early adoption continues to be one of the more challenging parts of every deployment. Understanding the various options for deployment of a new technology and their affect on adoption by organizations is critical for startups.

The Best Feedback From Your Early Customers Is a Story

Add comment November 29th, 2007

Building on yesterday’s post that stressed the importance of serious conversation with your early customers I want to explore the kind of stories you should listen for and how to take advantage of them.

Peter Cohan in “Four Opportunities to Harvest: The Value of Informal Success Stories” outlines the benefits an kinds of stories that are extremely useful to gaining a better understanding of the value and uses your customers have for your product. Peter identifies four kinds of stories that each have their own uses:

Vision of a Solution: The customer gains an understanding of his problem and then builds a Vision of a Solution, often in concert with the sales team. This Solution is what the customer has in mind when he moves through a typical buying process – and is the first opportunity to harvest. This information, along with the sales strategy, is what is occasionally gathered in “win/loss” analysis.

This gives you some idea of the real problem the customer is trying solve and the benefits they are seeking. Make sure to capture their own words, don’t force you phrasing because theirs is much more likely to be compelling to other prospects.

Solution as Initially Implemented: Once the purchase is completed, the customer implements the initial application or applications he has in mind. These deployments may be rough, incomplete (or over-complete), and often only partially address end-user needs. This Initial Implementation is the second harvest and can represent very useful information to share within the sales and marketing organization. Often, these early implementations will be the same or similar to what other customers want to achieve, as well.

Pay a lot of attention to how long it actually takes the customer to get some benefit. Your risk of “putting a dent” in your internal champion’s career goes down dramatically once a basic system is in production use. One of the secrets of Silicon Valley is that it’s not that large (most industries aren’t really that large, and in particular for startups don’t have that many early adopters you can sell to). One thing early adopters and internal change agents have a very long memory for is a product that couldn’t be made to work in a basic way, in a SaaS application the customer may be quite willing to exit the arrangement quickly.

Solution as Consumed: Now things begin to get interesting…! How much of what is initially rolled-out is actually consumed by users? 30% of the capabilities delivered? 40%? While the real number depends on individual situations, as an aggregate we often find that the capabilities actually consumed by users is a fraction of what is deployed. What is most important, however, is that the capabilities actually consumed represent the real success story – and this information needs to be captured as an Informal (or Formal) Success Story by your team to be leveraged by your organization.

It’s also the case that if most or almost all of your customers aren’t using certain features you should probably delete them. Certain capabilities (e.g. the ability to deliver data in a portable interchange format) may be important in lowering a prospect’s perception of the risk of adopting your product, but may never actually be used in a production case. These you can’t delete without escalating the perceived (or real) barriers to exit, which will make prospects more chary about adopting your solution, no one likes to go through a trap door.

Solution as Evolved: Have you ever visited a customer and noted that they have implemented applications of your software that were never envisioned by you, the vendor? Is this exciting? (Say “Yes!”). How can this information be used? Solutions after they have evolved are often the most valuable of all Success Stories. These are applications of your offering that often represent new market opportunities, increased deployment, and deeper market development. These stories can help you make your numbers!

These are the most useful but sometimes you are tempted to tell your customers “You are using my product incorrectly, it wasn’t meant for what you are doing.” This is OK if it’s really not a good fit, but it’s conceding an opportunity to someone else if this customer is not an outlier but a harbinger of others you haven’t met yet.

There is a real temptation to “be more efficient” and automate your “data collection” but genuine conversation is what drives “story collection” and stories are the real key to understanding how your customers value your product.

Update Dec 3: I just learned that Peter Cohan will be giving a webinar on “Four Opportunities to Harvest Informal Success Stories” on Wednesday December 5 at 12pm EST. Peter is an articulate, insightful, and dynamic speaker. It’s a great topic and should make for a great webinar.

The Best Way To Get Feedback From Early Customers Is a Conversation

1 comment November 28th, 2007

One temptation to avoid when trying to get customer feedback on your product is premature automation. There are a number of excellent low cost survey tools out there (we use SurveyMonkey and Zoomerang and have been happy with both) but there is a real risk when you only have a dozen or two dozen early customers that a questionnaire may only give you the answers that you are looking for, not the information that you need.

Direct conversation, either face to face or over the phone works best in our experience. It’s important early on to ask open ended questions and to consider your product more of a hypothesis (See Steve Blank’s “Four Steps to the Epiphany” for more on this framework) than an accomplished fact. Even though your product has been debugged and is ready for rollout, it doesn’t mean you that understand the benefits that customers (much less prospects) perceive that it offers.

You should also consider instrumenting your product if it’s SaaS (or adding a “software flight recorder” if it’s on-premises software or delivered as an appliance) that with the user’s permission can “phone home” some usage patterns. In particular you want to be able to assess how much use (and what commands, command options, service areas, etc.. are being accessed) they are making. It’s not uncommon to start removing commands and command options that are little used. Two companies that offer usage monitoring software are Tealeaf and OC Systems. There are more out there, but these applications are intended to be deployed in production, there are many QA applications th at will monitor execution but they may or may not be suitable for deployment on the customer premises or as a part of your SaaS production infrastructure.

You should pay as much attention to your “dropouts” as much as your “frequent flyers.” With early customers you should be trying to e-mail/IM/Skype/call as much as construct a survey. Even up to a 100 or so early users you want to be as open ended in your data collection as possible. It’s important to discover how your customers are “mis-using” your product in ways that may indicate additional market opportunities (or at least alternative messaging around unanticipated benefits).

It’s easy to become frustrated or wish for “smarter users” when your customers look at the value of your offering differently than you do, or don’t adopt certain features or commands that you thought would be compelling. Sometimes it can help to have a third party interview customers and non-customers as they may have less of a “are you calling my baby ugly?” reaction.

One thing to focus on as you scale up and add more prospects is how your existing customers invite new folks to evaluate your offering. What is the value they promise if someone new adopts: this “language of referral” is extremely important. You should probe for it in your conversations and incorporate it into your messaging. It can help you to identify distinct types or segments of users who get different kinds of value from your offering.

Surveys tend to channel answers along pre-determined paths. This can cause you to overlook real benefits, and real problems, with your product. Surveys don’t let your customer tell you a story about your product.

And it’s stories that are viral because they can combine a real benefit with a dramatic difference and a reason to believe. Data can substantiate a real benefit or a dramatic difference but won’t give you a reason to believe. More on customer stories tomorrow.