We are changing things up next week and offering our “Getting More Customers” on a Friday instead of a Saturday at a location that’s farther north than we’ve ever gone: Redwood Shores. The FortisGC folks have graciously allowed us to use their main conference room.
The Getting More Customers workshop will give you focused time to develop a sound strategy and workable plan to find new customers. At the heart of every startup is the plan for attracting new customers and expanding the customer base. We distill the fundamentals of how to find more customers and explain why these marketing techniques work. This workshop addresses how to get a potential customer to contact you. This initial contact may be in the form of a visit to your website, a phone call, an E-mail or an IM chat. For simplicity, we group all these together into getting the phone to ring.
We assume that you have already figured out what you tell them in your marketing collateral: business cards, website, demo, company backgrounder, datasheet, references, testimonials, and pricing. These all need to be prototyped, tested and revised BEFORE you spend much time getting the phone to ring. If you do not have the right message, it does not matter how many prospects call.
These proven techniques are divided into a couple broad strategies for reaching prospects:
What other people say about you: referrals, indirect, or joint sales.
What you say: speaking engagements, particularly in community of practice groups (professional groups, users groups) are ways of reaching customers. Some leads will be immediate, others may follow over 6 to 12 months
What you write: blogs, articles, electronic and paper newsletters are all proven methods for getting your message across and reaching your customers.
Getting found when prospects are looking: advertising and making your site easily found on search engines are two ways to do this.
This workshop has consistently enjoyed very positive feedback and the last couple have sold out: register now.
If you are interested in the content but the day or location are unattractive, please contact us with suggestions for what would work better. We have given workshops at the Moorpark Hotel in San Jose, Plug and Play in Sunnyvale, Fenwick & West in Mountain View, and now at FortisGC in Redwood Shores. Our plan for this year is to work up to a half dozen or so locations that are convenient and we are still looking to add another two or three.
Inspired by Dharmesh Shah I have also started to post these irregularly to my Twitter account. But to save you from having to add one more time sucking application that would take you away from your E-mail I will also be posting them in batches (at the end of the month after this post) on the blog as well. Enter your E-mail if you would like Feedburner to deliver new blog posts to your inbox.
+ + +
“Pressure is on us by the nature of the job. Performance releases pressure.”
J. T. Fisher
+ + +
“Life must be lived forward but can only be understood backward.”
Soren Kierkegaard
+ + +
“The superior man is distressed by the limitations of his ability, not when men do not recognize the ability he has.”
Confucius
+ + +
“The entrepreneur always searches for change, responds to it, and exploits it as an opportunity.”
Peter Drucker
Further info separating metrics from models would be helpful in fueling discussion.
Great Roundtable. Lengthen the time.
Well moderated, very on point.
Discussion was useful.
Good format and without a sales pitch.
SaaS is a great topic, I would be interested in other aspects, e.g. business models.
Well presented, good interaction
We had a 90 minute facilitated discussion with a couple of slides to help spur conversation and some informal networking afterward for about 30 minutes. It was very enjoyable. We have been shooting for one of these a quarter, we will probably do another one in July/August depending upon what else comes up.
Next Friday we have a Getting More Customers workshop in a new venue in Redwood Shores, the FortisGC folks have graciously allowed us to use their main conference room. Front row seats still available.
It’s starting to become clear that beyond just storm clouds, we are in for a recession in Silicon Valley. Which I suppose means that the next bubble will be delayed a few more years.
We started our business in mid-2003, helping several small consulting and software firms who were struggling to recover from Silicon Valley’s nuclear winter of 2000-2 when local employment dropped 25% from the height of the dotcom era. So we are not worried that bootstrapping firms will suddenly stop needing customer development. And, although fewer folks may decide to quit their jobs to raise VC funds, some may still choose to launch a consulting career or a software startup and discover the need for bootstrapping.
Clearly expense control at VC backed companies is going to be increasingly the focus at board meetings. But bootstrapping firms are born with expense control, for the most part they can’t exist on “build it and they will come” business plans.
Most new software firms are looking at Software as a Service models for deployment. And SaaS has implications on the sales model and the salesperson’s job. If you are wrestling with these issues, you should consider attending a roundtable we have scheduled for tomorrow that will look at sales issues for SaaS firms. In particular how does SaaS change sales management, sales compensation, and selling strategies.
I first met Debra Willrett, founder of Expert Software Consulting, at the IEEE Consultants Network for Silicon Valley (CNSV) when she gave a great talk on the new CNSV website in February of 2006. When Francis and I learned that she was the inventor of the Macintosh application MacProject, an application that has defined a paradigm for interactive graphical project management tools for the last 25 years, we asked her for an interview for our Founder Story series. What follows is Debra’s experience of turning an application into a business.
Q: Inventing MacProject is quite an accomplishment. What problem were you trying to solve when you started?
The initial motivation was to manage software projects. I was working in the lab at Hewlett-Packard, and my manager at the time was drawing large Pert charts by hand and taping them to the walls of our cubicles. But having a project with multiple people and complex dependencies between the components is a universal problem which applies to building nuclear reactors, bridges or software systems.
At HP , I was the user interface developer for a PC-based CAD system, one of a number of similar projects at HP at the time. My job was to build a graphical layout program for printed circuit boards.
When I saw a pre-release of Apple’s Lisa computer, I realized I had the components in place for a business. I had the problem to solve, the system to build it on, and the skills to build a WYSIWYG application with broad appeal. I proposed my product to Trip Hawkins, a member of the Lisa marketing team at Apple. Trip immediately understood the concept and we worked out a contract to develop the first implementation of my idea, LisaProject. This contract gave me the courage to quit my job at HP and work full time on pursuing my dream. By the time the Mac was released I was on my second revision, MacProject.
Q: What aspects of the process were a surprise?
The process was more challenging and exciting than I anticipated. Within the space of a couple of years, I started my first business (SoloSoft), negotiated my first contract, became the first Independent Software Vendor (ISV) for the Lisa, and shipped the first ISV application on the Mac. On the technical side, I wrote the first version of LisaProject in 6 months and released it to a community of users which grew to number 5,000 within 2 years. While I was supporting LisaProject, I wrote a new version, MacProject, for the yet-to-be released Macintosh.
Q: What alternatives existed when you started? What differentiated MacProject from your competitors?
First of all, Microsoft Project did not exist when I wrote either LisaProject or MacProject. The competitors at the time were complex non-graphical products. It took a specialist to understand how to apply them and consultants to help you figure out the data. I wanted to build something clean and elegant that anyone could understand and apply, even on a very small scale. Whether you are building the space shuttle or planning an event with friends, you are working with a group of people on a schedule and you need a vehicle with which you can communicate and monitor your plan.
Q: Today are many project management tools on the market: do you use any of them? What do you see as some of the aspects of project management still to be addressed by software?
I’m not a project management specialist today, but I have been asked for recommendations about what to purchase. More often I get asked the question, where can I get something like MacProject today? I think the tool that you pick should be easy to use and quickly be of value to you. Many solutions are more complex than they need to be. Also, project management is not done by one person working alone, so the social networking of the Web should revolutionize the way we approach the problem. I haven’t seen anything which I really like, so I’m thinking about getting back into the business. Stay tuned.
Q: It is very challenging to be both the inventor and the entrepreneur. Can you talk about your experience at SoloSoft and how you successfully structured the Apple deal? At the time, what were SoloSoft’s biggest challenges in negotiating the Apple deal?
My first contract with Apple for the Lisa was enough to pay the bills and keep the lights on. More importantly, building LisaProject gave me experience and relationships with people in Apple. I was in the right place at the right time when the Macintosh was developed. It can take years of work to make your investment pay off and many people get discouraged too early.
Another problem occurs if you ask for too much at the beginning. Until you demonstrate both your ability to deliver and the viability of your idea, you don’t have much leverage. The terms of the customer’s proposal for the first contract will reflect this. when They often feel that their work is worth more than it really is, and they walk away from a deal. I have also seen things fall apart when people get too fussy about every line on the contract.
You need to be flexible and realistic. In exchange, you can be firm about the issues which are important to you. One of the key terms of my contracts with Apple was that I would retain ownership of the software.
I also found that I could profit from being underestimated by others.
I requested a number of significant bonus incentives for meeting scheduled deadlines. Since software schedules are routinely slipped as additional features are added or the scope of the project changes, no one believes you when you say you will deliver something on time.
They will happily add terms in the contract which pay more for meeting delivery dates. And I happily collected on every one of my bonus payments. Of course, the customer also won, because having the new features earlier increased sales.
Once MacProject became a big success, there was pressure to restructure my agreement. Since I was making significant money, Apple wanted to reduce the royalty rate. Another consequence of success was that as the user base expanded, the list of desired features grew rapidly. I rejected many of these feature requests to maintain the elegance of the user interface. Nevertheless, the list of good ideas for new features eventually exceeded my ability to write the code. Tension developed between SoloSoft and Apple over this issue. I considered scaling up SoloSoft’s development team by hiring its first employee. Apple wanted to control the development by bringing it in-house. Apple offered to buy out the royalty stream. Any successful contract has to keep working for all the stakeholders. I was torn between my ambitions to grow SoloSoft into a large business and the demands of my growing family. I ultimately decided to sell MacProject to Claris, Apple’s spinoff of its software business, and went into a period of professional semi-retirement.
Q: You have started a new firm: can you tell us a little about what you’re doing with Expert Software Consulting?
Expert Software Consulting builds web applications for various types of clients. I like being my own boss. I enjoy the challenges of running a business, and I hope that some of my ideas today will enable me to make a larger contribution in the future. Recently a group of Stanford students led by B.J. Fogg created Facebook applications and found out that they had an installed base of millions of users within weeks with applications like “Kiss Me” or “Hug Me.” The Web is a phenomenal playground, and things are changing all the time. It’s exciting and fun to be a part of, and I enjoy going to work every day.
I had my eyes opened about analyst firms this month. Even though I had a rather jaundiced view of them in the past, I had a couple of interactions that really illustrated the shallowness of their approach and the undoubted unreliability of their research, if it actually can be spoken of with that term.
First up, I got an email from one firm wanting to research an open source topic. The email was something along the lines of “I’m interested in learning more about XXX. I’d like to interview you for 45 minutes to an hour and would like to talk to two of your customers. Please let me know when would be convenient for you to speak.” I found the assumption that I would offer a bunch of my time for free and would impose on clients all in the service of the analyst firm’s business incredibly presumptuous and so naturally, though politely, declined.
The second interaction was an actual conversation. An open source company asked me to speak with another analyst firm to discuss the potential for their application from my perspective – in other words, to discuss my opinion about how their application might be used in the marketplace. I agreed and arranged a time to speak to the analyst. She called me and immediately asked me to describe my firm’s business and then wanted to know how many engagements it had done in the previous year. When I demurred to discuss my business – remember, the purpose of the call was to talk about the potential for an application released by another company – the analyst got very huffy and rather frostily ended the conversation shortly thereafter. And, by the way, the insights offered by the analyst during our conversation were, to my mind, extremely puerile and unsophisticated.
These interactions illustrated the reality of the analyst business. For all its supposed accuracy and sophisticated research methodologies, it is founded on opinions formed on the basis of discussions with people who are willing to have their time wasted in intrusive conversations with interviewers who really have very little deep understanding of the topic. In other words, it’s anecdote dressed up as science.
It’s fascinating, however, that commercial open source companies, despite their brave insistence that they are upending the bloated and irresponsible proprietary software industry, still kowtow to the traditional practices of the industry, including focusing on currying favor with analyst firms in the hope of gaining a coveted endorsement or at least recognition. This despite what last month’s newsletter discussed: most open source software enters enterprises in a very different fashion than the historic patterns of proprietary products. That’s why the traditional handmaidens of proprietary software, the big system integrators, have heretofore played no role in the spread of open source.
There are a number of good analysts out there, Gary Smith in the EDA space comes readily to mind, as does Bryan Lewis for the semiconductor market. But especially in emerging markets like collaboration, SaaS, open source, and social media, we may have yet to separate the wheat from the chaff.
Do you think selling as dishonest and manipulative? Some of the teams we encounter are looking for the most accomplished liar they can find to jumpstart their sales process. Perhaps you feel that way?
“Studying the ’sales process’ the doctor uses to sell a cure, you will notice …
A doctor is important enough for you to go to them.
Generally a long wait is worth your time to get to see the doctor.
The more important the problem you have, the more important the doctor becomes. And, by the way, you don’t try to go the least expensive route.
Doctors don’t sell you – they diagnose you using data points you provide. And you believe them and act on it.
Doctors can tell you about a problem you don’t even know you have.
The diagnosis and recommendations you get from doctors always trump those you get from a friend or family member … or even a website.
The ’sales cycle’ is very short.
Doctors are always going straight to the decision maker for the decision.
Every time you have a problem you go back for another consultation.
We tell our team, “You are not a salesperson, you are a DOCTOR”. When we find ourselves working with prospects to DIAGNOSE their problems we seem to end up in a doctor-like situation. Our prospects buy more quickly, they trust our recommendations, the decision maker is involved early and often, and they appreciate our advice and come back for it often.”
For the record we believe that integrity is essential to the startup sales process, many times you are promising future performance and the team needs to be mindful of the consequences not only to the customer and but to their reputation. We follow Steve Blank’s “Four Steps to the Epiphany” customer development model, which means that we believe the founders must sell. Why? Sometimes it’s the presentation and sometimes it’s the product. In the early market it’s too easy to blame the messenger if you weren’t part of the conversation with the customer and don’t want to hear that your product needs to be changed.
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:
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.
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.
In 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 effort 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, which was originally developed by Intranets.com. It was an intranet application where a manger would use it to send 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.