Pragmatic VC: Stop Coding, Start Marketing. Getting Your Positioning Right.(blog.stevebarsh.com)
blog.stevebarsh.com
Pragmatic VC: Stop Coding, Start Marketing. Getting Your Positioning Right.
http://blog.stevebarsh.com/pragmatic_vc/2008/05/stop-coding-sta.html
10 comments
"The risk with Steve's method is inbuilt assumptions you can make answering his questions, long before a real person ever sits in front of your program."
Not really risky if you iterate this the same way you iterate software.
Not really risky if you iterate this the same way you iterate software.
At the risk of sounding inane, you have to do both. Iterate, release early, and listen to users (PG). But also think deeply about the market, how you differentiate yourself, how you'll get the message out, and be sure you're really building something worthwhile (SB). Both contribute to the same goal - figuring out what your product or service will look like - but they attack it from different sides.
No reason why you can't do both. But if you naturally lean in one direction, you might want to be careful that you don't ignore the other.
No reason why you can't do both. But if you naturally lean in one direction, you might want to be careful that you don't ignore the other.
A poor title selection detracts from what is otherwise very good advice.
The formula is simple and elegant and the result quite useful: an elevator pitch. I can't count the number of times over the years that I've tripped over myself trying to explain what I'm working on.
The formula is simple and elegant and the result quite useful: an elevator pitch. I can't count the number of times over the years that I've tripped over myself trying to explain what I'm working on.
If anyone ever tells me to stop coding, I stop listening.
Unless you have a partner that will take care of the marketing and sales side of things, that's probably a mistake.
There are several things that making the effort to new customers will give you:
1. Money. If you have more paying customers, you have more revenue. More revenue means you can pay to make problems go away. Taxes, accounting, web design (if that's not your forte), and even the sales process itself (though it's almost certain that no one can sell your product better than you can early on).
2. More feedback. You might be going the wrong way. Early adopters have a very different set of requirements from the average user (generally). So, the more mainstream your sales process becomes the more likely you are to find out that you're on the wrong path. It's very easy to keep going further and further into a niche--and if that niche is too small, you're gonna be in big trouble before you even realize it. It's entirely possible to featurize yourself out of the big markets by focusing on the tiny niches that your early adopters live in. For example, our early adopters tend to push for scalability solutions for single websites--but our mainstream customers just want to fit more customers onto the same box. If we spend all of our time building scalability solutions, we'll find ourselves only being able to serve 2% of the market extremely.
3. More users who can help you help other users, via forums or mailing lists or wikis, and can help you make more sales. It is a reinforcing cycle. We had an amazingly great sales day today, because we got mentioned by people we don't even know on Slashdot. Because we reach out to our community regularly, we support the sites and communities that would use our software, and we (or I, rather...Jamie is full-time on coding, always) try to close a deal with a new hosting provider (even small ones) every week or two.
Building a better mouse trap isn't going to make you rich. You have to "ring the cash register" sometime, or you not only won't get rich, you also won't be serving your customer as well as you should be.
But, I do think the blog post in question spends a bit too much time on checklists and making elaborate plans.
There are several things that making the effort to new customers will give you:
1. Money. If you have more paying customers, you have more revenue. More revenue means you can pay to make problems go away. Taxes, accounting, web design (if that's not your forte), and even the sales process itself (though it's almost certain that no one can sell your product better than you can early on).
2. More feedback. You might be going the wrong way. Early adopters have a very different set of requirements from the average user (generally). So, the more mainstream your sales process becomes the more likely you are to find out that you're on the wrong path. It's very easy to keep going further and further into a niche--and if that niche is too small, you're gonna be in big trouble before you even realize it. It's entirely possible to featurize yourself out of the big markets by focusing on the tiny niches that your early adopters live in. For example, our early adopters tend to push for scalability solutions for single websites--but our mainstream customers just want to fit more customers onto the same box. If we spend all of our time building scalability solutions, we'll find ourselves only being able to serve 2% of the market extremely.
3. More users who can help you help other users, via forums or mailing lists or wikis, and can help you make more sales. It is a reinforcing cycle. We had an amazingly great sales day today, because we got mentioned by people we don't even know on Slashdot. Because we reach out to our community regularly, we support the sites and communities that would use our software, and we (or I, rather...Jamie is full-time on coding, always) try to close a deal with a new hosting provider (even small ones) every week or two.
Building a better mouse trap isn't going to make you rich. You have to "ring the cash register" sometime, or you not only won't get rich, you also won't be serving your customer as well as you should be.
But, I do think the blog post in question spends a bit too much time on checklists and making elaborate plans.
I agree with all of this.
What does any of it have to do with "stop coding". If you can't juggle eggs, you should probably be someone else's employee.
I do the things you mention and I still code every single day. For a software startup, coding is like breathing. Stop and die. Only hackers understand this. Whoever downmodded my previous post is probably an MBA.
What does any of it have to do with "stop coding". If you can't juggle eggs, you should probably be someone else's employee.
I do the things you mention and I still code every single day. For a software startup, coding is like breathing. Stop and die. Only hackers understand this. Whoever downmodded my previous post is probably an MBA.
"What does any of it have to do with "stop coding"."
Ummm...Because most of us can't code while working on something else. I think each of us is just taking a different view of the words "stop coding". I think it means "for a few hours so you can get all of the other stuff done", while you seem to think it means "and never fire up vim/emacs again in your life". Obviously, I'm not telling anyone to stop coding forever (or even for more than a few days). If you're a tech entrepreneur you have to build things and keep building new things, or you won't be able to retain customers in the face of competitors that are always building new things.
(And I'm not among those who voted you down. I merely wanted to chime in with a bit of what I felt was important about the subject...not really in disagreement with you.)
Ummm...Because most of us can't code while working on something else. I think each of us is just taking a different view of the words "stop coding". I think it means "for a few hours so you can get all of the other stuff done", while you seem to think it means "and never fire up vim/emacs again in your life". Obviously, I'm not telling anyone to stop coding forever (or even for more than a few days). If you're a tech entrepreneur you have to build things and keep building new things, or you won't be able to retain customers in the face of competitors that are always building new things.
(And I'm not among those who voted you down. I merely wanted to chime in with a bit of what I felt was important about the subject...not really in disagreement with you.)
If I sound a little sensitive on the subject, here's why:
As long as I've been doing this, 100% of the time I had problems implementing, it was always for the same reason: not enough software. Whether analysis wasn't sufficient, features were missing, testing wasn't complete, whatever, we were always deploying before we were ready. I understand that there's a school of thought that says to push like this, and naturally, I know how important the non-coding items are, but still...
I never had project difficulty because an invoice wasn't mailed, or a meeting was missed, or a prospect wasn't engaged; it was always, always, always because we simply needed more time/people/resources to have more software.
Imagine swimming the English channel and realizing you had other things to do. Would you stop swimming? Of course not. That's how I feel about coding.
For a software endeavor, coding is the critical path. Do other stuff, but don't stop coding.
As long as I've been doing this, 100% of the time I had problems implementing, it was always for the same reason: not enough software. Whether analysis wasn't sufficient, features were missing, testing wasn't complete, whatever, we were always deploying before we were ready. I understand that there's a school of thought that says to push like this, and naturally, I know how important the non-coding items are, but still...
I never had project difficulty because an invoice wasn't mailed, or a meeting was missed, or a prospect wasn't engaged; it was always, always, always because we simply needed more time/people/resources to have more software.
Imagine swimming the English channel and realizing you had other things to do. Would you stop swimming? Of course not. That's how I feel about coding.
For a software endeavor, coding is the critical path. Do other stuff, but don't stop coding.
Nice article.
So take a little time and hypothesize about your market and marketing plan.
I believe what is unsaid is that you iterate, and both the product "code first" and the plan "marketing" continue to iterate and evolve.
Over time your idea of who your market is becomes one with your solution and your sales.
Seems like a non-controversial and practical piece of advice. I liked it.
So take a little time and hypothesize about your market and marketing plan.
I believe what is unsaid is that you iterate, and both the product "code first" and the plan "marketing" continue to iterate and evolve.
Over time your idea of who your market is becomes one with your solution and your sales.
Seems like a non-controversial and practical piece of advice. I liked it.
PG tends to argue the other way - code first, release early, GET USERS, and then have them define the solution they need.
Working with a number of businesses I don't think there's a right or wrong. The risk with Steve's method is inbuilt assumptions you can make answering his questions, long before a real person ever sits in front of your program.