I've been in the startup business for a while and it still amazes me how many
founders (including me at various points in my life) have completely irrational
views on how life at a startup is going to be.
As it turns out, lots of success requires a sprinkling of luck to work, but
counting on this luck to come up at the magical times is foolish. So, stay up
late at night working on the business and improving the product for customers --
not what deciding what you're going to wear to the startup ball when the magical
startup fairy comes tapping at your window. In other words, quit running
advanced spreadsheet models on how your revenues are going to grow if you can
get only 1 out of 4 users to tell their friends. (See #1 below).
Founders: Stop Hoping for Magic and Start Working
1. Somebody's product is going to "go viral" this year. Someone is also
going to win the lottery. Just not you. Don't count on virality, but
add some simple elements to your product that make them easy to spread.
This will increase the probability that your product will go viral to
something slightly above zero (instead of zero).
2. Venture capitalists are not swash-buckling risk-takers that are going to
fall in love with your startup at first sight -- and write you a check.
Unnecessarily daring people do not become VCs -- the industry filters most of
those out. Work at not needing the money. If you could use
the money, get multiple VCs interested.
3. Smart people are not going to be lining up to work for your startup,
without salary, just for the sheer thrill of "the startup life" and an ability
to be associated with the brilliance that is your idea. Be reasonable
about it. Expecting team members to take some risk for some time is fine. But,
that's not a great strategy to recruit a great team.
4. Big company executives are not going to be inviting you into their
wood-panelled offices with old leather chairs offering you increasingly
lucrative partnership deals just because of "synergies" they might have with
you. Big companies have teams dedicated to keep an eye on startups like
yours. Just because they spend time with you doesn't mean you're getting a deal
anytime soon. Just because you get a deal, doesn't mean it's a good
one.
5. Google, Microsoft and others are not going to be falling all over
themselves trying to acquire your company. Acquisitions are great when
you can get them. But, they're usually complicated and take time. Get great
counsel.
Now, here's the good news. If I happen to be wrong about any of the above
ones and you do indeed get lucky on one of these things, the chances that you're
going to get lucky on others goes up. So, keep crankin'. The magical startup
fair may never show up, but you're better off not waiting for her anyways.
Article has
4 comments.
Click To Read/Write Comments
I've been invited to speak at the upcoming Business of Software conference in
Boston (my home town!) on September 8, 2008.
As such, I've been thinking a bit about the business of software. I do this
regularly because my day job (and most of my night job) is running a software
business in the area of internet
marketing.
more info: Business of Software Conference
There are a ton of great speakers scheduled for the conference -- and then
there's me. Other folks that will be there include Joel Spolsky (who is
sponsoring the conference), Seth Godin, Eric Sink, Steve Johnson, Richard
Stallman, Paul Kenny, Jessica Livingston and Jason Fried. It promises to be a
great conference and I'll do what I can to not bring down the average quality
too much.
If you're planning on making it to Boston for the conference, please reach
out.
Meanwhile, here are somewhat pithy thoughts on the business of software.
Pithy Insights on The Business Of Software
1. Software businesses are not a low-cost play. You're probably better off
producing great software somewhat expensively than producing average software
somewhat cheaply.
2. Great software is produced by great people. Mediocre people don't ever
accidentally produce great software that makes millions of dollars.
3. Programmers have not been, and never will be, commodities. If you think
this way, I'd quit now.
4. Pricing software is hard. More people charge too little than charge too
much.
5. If you're charging really small price-points, consider going to
a freemium model (some version for free, the upgrade is paid for). The free
version is a great way to get some distribution and customers.
6. Just because people should buy your software doesn't mean they
will.
7. One of the trickiest parts about a software business is figuring out the
right level of services to sell. If the answer seems blindingly clear, you're
not thinking about it hard enough.
8. It's getting harder and harder to make money on pure software innovation
(i.e. lines of code and the product itself). Increasingly, business
innovation is what companies are using to drive differentiation and better
margins.
9. It's a great time for software startups. Capital costs are very low
(infrastructure, systems software are getting cheaper every day). And,
distribution is actually possible with some creative marketing on the internet.
Tiny companies have a shot at reaching big markets.
10. There are still people that believe massive spec documents and months of
planning will produce working software that users are going to be delighted
with. I feel sorry for these people. Think agile, folks!
11. Make sure you're deciding correctly between a horizontal offering and a
vertical offering. Horizontal offerings are tempting because of their potential
scale -- but they're much harder to execute.
12. Programmers often like to build platforms, not applications. But,
building a business around a platform takes lots of good strategic thinking (and
often a fair amount of capital and/or luck).
That's all I have for now. More on this particular topic in a later
article. I'm on vacation today, so didn't have enough time to really dig
in.
Article has
6 comments.
Click To Read/Write Comments
My co-founder, Brian Halligan and I are both big fans of Warren Buffet.
Brian wrote an article a while ago on the HubSpot blog "Quick Insights From Buffet and Gates". If you're a Buffet
fan, like me, I encourage you to check it out.
Recently, I had the opportunity to skim through the Berkshire Hathaway annual
report. There were some really amusing insights in there. It's refreshing to
see even a large, successful organization like Berkshire Hathaway maintaining
their personality and pragmatism in a document that for most companies is boring
and watered-down. My comments are in italics.
1. We are also happy to buy small portions of great businesses by way of
stock-market purchases. It's better to have a part interest in the Hope
Diamond than to own all of a rhinestone.
Venture Capitalists: Are you really sure you just absolutely MUST have
X% of that hot new startup? Instead of making the investment you want, why
compromise and do something else just because you can get 5-10% more?
2. You only learn who has been swimming naked when the tide goes out. [With
relationship to the recent housing bubble]
This made me think about pre-revenue startups. When the tide of funding goes out, and you have to start charging money, will your business model
be naked?
3. For the entire 42 years, our compounded annual gain in per-share
investments was 27.1%.
Ok, this isn't really amusing, but it is impressive.
4. A truly great business must have an enduring "moat" that protects
excellent returns on invested capital. The dynamics of capitalism guarantee
that competitors will repeatedly assault any business "castle" that is earning
high returns.
I like to think of this in terms of a wall rather than a moat. Build the
wall that protects your companies interest from those that would take your
profits away. My simple strategy for building a great wall: Step 1: Start
building wall. Step 2: Add at least one brick to the wall every day.
5. If a business requires a superstar to produce great results, the
business itself cannot be deemed great.
Though depressing for us startup entrepreneurs that think the entire
company revolves around us, it's true. A truly great business should likely be
able to run without the need for it's current founders or management team. Of
course, in the early days, this is rarely true.
6. The worst sort of business is one that grows rapidly, requires
significant capital to engender growth, and then earns little or no money.
Think airlines.
This is very interesting. A lot of the big infrastructure plays end up
here. You have to continually invest more and more money to get lower and lower
returns.
7. If his I.Q. was any lower, you would have to water him twice a day.
I felt guilty when I smiled at this, but had to admit it was
funny.
8. From Bobby Bare's country song: "I've never gone to bed with an ugly
woman, but I've sure woke up with a few."
9. Mitt Romney's wife Ann, when asked: "When we were young, did you ever in
your wildest dreams think I might be president?". Response: "Honey, you weren't
in my wildest dreams."
10. Charlie and I are not big fans of resumes. Instead, we focus on brains,
passion and integrity.
If you had to solve for any three attributes when hiring, these are about
as good as any. Intelligence, Passion and Integrity.
11. I've reluctantly discarded the notion of my continuing to manage the
portfolio after my death -- abandoning my hope to give new meaning to the term
"thinking outside the box."
12. Queen from Alice in Wonderland: "Why, sometimes I've believed as many
as six impossible things before breakfast."
Hope you enjoyed these. If you have other great Warren Buffet related quotes
or insights, please leave a comment We're always looking for more.
Article has
7 comments.
Click To Read/Write Comments
I recently came across an article by my friend Allison Shapira about Blue
Man Group as a business. The article is based on a reading Allison did as
part of her "Strategic Communications" course and looks at the business of Blue
Man Group.
Here's the part that struck a chord with me:
"How did Blue Man Group manage to maintain their vision, even with 38
performers around the country? They wrote a “Why To” manual. Not a “How To”
manual, which tells you how do things, but a “Why To” manual, which tells you
why to do things - it explains the vision..."
At my startup, we talk a lot about the "why to" part of the business (partly,
because we're all pretty analytical and like to have debates on just about
everything). We don't call them "Why To" discussions, but probably should.
Here are some examples:
Why To Charge Monthly Subscriptions (instead of yearly contracts):
Because it breeds the right company culture. With monthly
subscriptions, we have to earn our customer's business every month. There are
no "drive-by sales". Also, the data is worth more to us than the cash right
now. We want to learn as much as we can (and right now, the lessons are
cheaper). If we charged yearly, it'd defer a lot of this learning until the
customer had to decide whether to renew.
Why To Not Sell To Anyone Willing To Pay: Because the
product is not going to be equally beneficial to everyone. Our happiness (and
our profits) is going to be based on how happy our customers are in the future.
If you know a customer is unlikely to be happy in the future, don't sell them. Make them sell
you and convince you otherwise.
Why To Resist Hiring For Resumes: Just about the entire
team at HubSpot wasn't hired for their resume. We solve for intelligence,
passion and integrity. Why? Because someone with 14 years of experience at a
Fortune 500 company managing a $100MM budget may not know much about our
customers and our market. We'd rather bring people on that are smart and will
jump in and figure things out.
How about you? What kinds of "Why To" concepts are floating around in your
startup? Does your team often ask the "why" question?
Article has
5 comments.
Click To Read/Write Comments
One thing I've been pondering this weekend is figuring out why startups
fail. But, in order to figure that out, I had to first decide what constitutes
failure. The more I thought about it, the more I realized that a
definitive failure is when the startup simply stops trying. And, the
only reasons to stop trying are that you run out of cash, or you run out of
commitment -- or both.
Let me elaborate a bit. Lets say your startup had an unlimited amount of
cash (hypothetically). Whenever you needed money, you'd go to the money tree,
pick some more cash, and go back to your business. If this were the case, it's
likely the number of startup "failures" would be vanishingly small. Why?
Because you haven't failed yet, you simply haven't figured out the model that
works. As long as you still had commitment, you could keep going indefinitely.
Of course, there's no such thing as unlimited cash.
Similarly, lets say you had a day job, and your startup didn't really require
any cash. And, you were fanatically committed to your vision or idea. In
theory, you could run your startup for decades and still never really
"fail". You'd just keep going and rather than being a failure, you'd be a
startup that hadn't succeeded yet. As long as you were committed, you could
just keep going.
So, with that set of abstract concepts in place, let's dig in a little
deeper.
Constraints On Cash and The Paradox of Venture Funding
Given that you have a finite amount of cash, how long your startup can
survive is a function of how much cash you put in (revenues + funding) and how
much you take out (expenses). You'd think that a venture-funded startup would
be more likely to succeed, because it has longer to "figure it out" (i.e. more
time to get to success). But, I'm not sure that's true. What ends up happening
is that VC-funded startups tend to increase their expense-base such that their
time horizon is actually pretty short (about 1.5-2 years on a Series A
funding). On the flip-side, a bootstrapped startup might not have a large
influx of cash, but might actually have more time to figure things out.
As an example, my first startup was bootstrapped. No VC funding. We did
things the old-fashioned way. We charged people money, and spent less than we
made. We were profitable from our first year of existence (and remained that
way for 9+ straight years). We were profitable, because we had no
choice. How much we spent was always a function of how much we made. In
the long run, we didn't grow as fast as we might have otherwise, but overall we
succeeded.
Contrast this to a couple of venture-backed competitors of this bootstrapped
startup. They had each raised $25MM+ in venture funding. Of course, this was
in the midst of the bubble, but the lesson is still similar (it's an issue of
magnitude). These companies ran through their cash, and couldn't get funding to
keep going. They failed.
This is just one data point, and it would be silly to try and generate any
conclusions from it. But, it does generate an interesting idea:
Perhaps startups should simply be trying to give themselves enough time to
figure out what will work. And, the time available is not a function of the
amount of cash raised, but the amount of cash being consumed.
Profitable startups don't consume cash -- they generate it. Hence, they've got
more time.
For the record, my current startup, HubSpot, is venture-funded. This means I have some work to do
to figure out how to get to the point of having an infinite amount of time to
figure things out (otherwise known as becoming profitable). The good news is that profitability is something we actually talk about (which you would think would be a common conversation in startups, but it's not).
In a follow-up article, I'll discuss the tradeoffs between bootstrapping and venture funding a startup. Having seen it from both sides, I'm beginning to form an opinion (always a dangerous thing).
Article has
21 comments.
Click To Read/Write Comments
Chances are, that if you've been involved in the creation of software or any
kind of product, you've probably heard the advice: "Don't develop in a
vacuum".
A vacuum is a space that is essentially empty of matter (according to
Wikipedia). It's a philosophical concept because practically it is not possible
to have a space that is completely "empty". But, I like to deal in abstractions
anyway, so that's good enough for me. "Don't develop in a vacuum" generally
means not to go off and write code in the absence of customer feedback. This
should not be particularly controversial advice. Developing software without
knowing whether users will like it, based purely on speculation and conjecture
doesn't seem particularly smart. I've never met a single person that has
said: "You should go build your product in a vacuum!"
So, I think it's good to not develop in a vacuum and ask users what they
think as early as possible and as often as possible. But, it's great
to actually be users of the product yourself. This advice has been widely
circulated too. If you build something you would use yourself, your chances of
success go way up. The reason is not particularly complicated. It's more
efficient to have conversations with yourself than it is to try and go find
users. There's a lot less lost in translation as well. Rumor has it, the most
successful products at Google (like GMail) are the ones that Google employees
actually use.
So, if developing without user feedback is developing in a vacuum, then
what's the opposite? Developing under infinite pressure? I'm not sure, and I'm
not smart enough to stretch this analogy along this particular dimension. But
what I do know is that "developing for yourself as a user" starts to present
risks at a certain point.
Let me give you a real world example. My startup, HubSpot, develops inbound marketing software. For
purposes of this article, it's not necessary for you to know what that means.
Lets just say that many businesses need it as it helps find more paying
customers and increase sales. We originally started building the product
because we had the problem ourselves, and couldn't find a reasonably good
solution. So, we built something we thought we'd use ourselves. And we do. We
don't just casually use it either. We're extreme users. We run our
blog on it. We get sales leads from it. We track marketing analytics on it.
We live inside our product. We could not imagine life without it.
Most of the time, this is a really good thing -- except when it's not.
Here's when it's not: At a point, you have to stop and ask yourself how
representative you are of your potential market. If you're a lot like them,
then you can get away with having conversations with yourself pretty often and
not lose sight of the customer too much. If you're not like them at
all, conversations with yourself are not productive. My startup is somewhere in
between. Although we resemble our target customers a lot (we're a small
business with 25 employees, we sell to other businesses, and we have real
marketing people on staff), we're not a perfect fit. Most of our customers are
not as technical as we are, don't read SEO blogs all the time and actually have
lives . But, the biggest difference is that we know too
much. Not that we're smarter, but we're just around the problem too much.
We live it too much. We have people that think about nothing else all day.
Hence, it's easy to over-complicate the product because it seems "obvious" to
our internal users. They fly right through the new features. The solution? Go
get good, honest feedback from real customers/users whenever you can. There's
no substitute.
Summary: Don't develop your product in a vacuum. If you can, be
your own customer. But remember that conversations with yourself can only go so
far because you know too much and it's unwise to try and pretend that you
don't.
What do you think? Are you your own customer? Have you hit the limit of how
much feedback you (as a company) can give yourself? Would love to hear your
thoughts in the comments.
Article has
7 comments.
Click To Read/Write Comments
I've recently been thinking a lot and discussing with my colleagues at
HubSpot the implications of Saas (Software as a Service). We're looking at this
from many angles: operational cost, development cost, support cost, etc.
One of the big advantages for SaaS startups is the opportunity to be
economically efficient along many dimensions through multi-tenancy.
But, just because the opportunity is there doesn't necessarily mean that
every startup is exploiting it equally.
In my online readings and research, I came across an article about the SaaS Simple Maturity Model. Though I'm not particularly fond
of the name, the framework is very useful.
Here's my (even simpler) interpretation of the levels of maturity of a SaaS
architecture:
Level 0 (Chaos); Every time you add a new customer, you add
a new instance of the software. If the customer needs something specific, you
change that software instance. Each customer is essentially running on their
own "version" of the software. Yuck!
Level 1 (Managed Chaos): Every customer runs on the same
version of the software and any customizations are done via
configuration. But, you still have different instances for each customer (their
own website, their own virtual server, their own physical server, etc.).
Level 2 (Multi-Tenant, Highrise): You've got all customers
running on a single version of the software, and they're all running essentially
on one "instance". The good news is that you're getting the benefits of
multi-tenant (sharing resources across customers). Even better is that you're
not writing custom code for each customer -- everyone essentially runs on the
same version. The big challenge is that as you add more floors to your building
(to stretch the analogy a bit), it gets more and more expensive. And, there are
limits to how high you can build to accomodate a large number of tenants.
Level 3 (Multi-Tenant, Build-Out): This is when you've got
multi-tenant, single version of the software model. But, you can scale-out (add
buildings at will). This is optimal because instead of letting the architecture
decide how many tenants you put into a building, you can let the economics
decide. And yes, there is an optimal number of tenants per instance
and this number varies on your situation.
Level 4 (Utopia): This is like Level 3, except you've
figured out an efficient way to run different versions of the software on
different "instances". You're doing this not because you're writing custom code
for a customer, but because you want to run different code for different
customers -- to try things out. The best example is having an "early adopter"
instance where customers that want to use your latest and greatest features can
do so. Helps them. Helps you. Helps everyone. As long as you're efficient
about release management. [Note: This last one is my own fabrication and
wasn't part of the original framework referenced above).
HubSpot, my startup, is currently at a Level 2 and shooting for Level 4 this
year (with a brief stop at Level 3 as an intermediate point). The good news is
that we're adding cusomers quickly so this is more than an academic exercise for us.
We can actually rationalize the investment in terms of economics because the
benefits that we get from improvement actually makes us money.
---
Are you a superstar startup developer in Boston? Consider applying to
HubSpot. Help us figure out how to delight thousands of customers and make
money at it. Share in the fun and success. You can email me at dshah [@]
onstartups.com. If you have what it takes, we've got some awfully smart and
passionate people you'd enjoy working with.
Article has
8 comments.
Click To Read/Write Comments
There has been a lot of discussion on the web about the value of simplicity in software. Generally, I agree with the notion of simpler being better (all other things being equal). But rarely are all things equal.
The goal for software developers should not be to make things simpler just by reducing features. The goal of software should be to make it simpler for the user to do what they are trying to do.
Too often lately, I've seen software that makes users do unnatural things in the name of simplicity. The common defense for not adding something is that it would make the user interface more complicated and/or there's a workaround.
The behavior seems more motivated by selfishness than simplicity for the user.
When trying to decide whether a given feature or capability should be added to a software product, here are the things I ask myself:
1. What is the user trying to accomplish? Will this make it easier for her to accomplish it?
2. By not adding this feature, am I likely making the user go through an unnatural act?
3. Is the existence of this feature expected? Will it delight users by being there? Will it frustrate users if it's absent?
Of course, all of the above are reasonably obvious questions that boil down to one thing: Will the feature make the users you care about happy? A sub-optimal line of reasoning goes like this: "Users hate complexity. So, users like things that are simpler. By not adding feature [X], things are simpler. Hence, it will make users happy if I don't add [X]." This is an indirect way of thinking about making users happy. I prefer a more direct path: Will adding feature [X] make a majority of my users more happy?
There's also the temporal dimension: Things that make users a little unhappy today, might make them a lot happy later. Examples are advanced features that users are unlikely to want/need in their early experience with the software are often *critical* at some later point. A powerful "export" feature is often examples of this.
For those that think that I'll I'm doing rationalizing and promoting bloatware, I'm not. I hate bloatware. Not just because of the impact on user happiness but also because unused features are like unused inventory. It costs money and is bad for business.
For more on what I think on this topic, you can check out a previous article:
Disagreeing With 37Signals: Less Is Sometimes Less
By the way, this blog just hit the 8,000 RSS subscriber benchmark. If you liked this article, now would be a great time to subscribe: Here's the feed URL: OnStartups RSS Feed
Article has
7 comments.
Click To Read/Write Comments
The selection, care and feeding of a co-founder (or co-founders) is one of the key determinants of long-term success in a startup. Lots of startups have issues like a lack of market, technology challenges, distribution challenges, etc. But, a lot of these can be addressed with a great founding team (just about all startups tweak their model in order to address challenges along the way). But, if you have the wrong co-founders (or none at all), that's a hard problem to get over.
7 Insights On the Co-Founder Conundrum
1. Dispel the delusion that you don't need a co-founder. You do. You may have all the requisite skills, but even then, co-founders help spread the work and make better decisions. Sure, you can talk to your brilliant self, but that's not as effective.
2. Make sure at least one of the founders can build the product. This is so you don't have to try and outsource the development. Killer apps that delight users and conquer markets are not built by outsourcing. You could also hire your lead developer, but then you need to be *really* good at finding and recruiting this kind of talent. This is hard.
3. Make sure at least one of you can sell. Sure, you can bootstrap and it's not about the money and you want to build something people want, and you're going to be acquired by Google some day, and Google doesn't care about revenues. But, most startups (particularly yours) is going to need to sell something to someone someday. And, by accident, you might someday acquire a taste for something other than Ramen noodles.
4. It helps to have known your co-founder a bit before you start a venture. Unless you're the swashbuckling, risk-taking type that proposes marriage to someone on a train ride to Paris while you're on a 2 week vacation despite there being no alcohol involved, chances are, you don't want to start a company with someone that you haven't spent some time with before.
5. You better like them. If things don't go well (and in the early stages, they don't), you're probably going to spend more time with your co-founders than you do with your significant other. If things do go well, you're going to spend a *lot* more time.
6. Ask all the hard, important questions as early as possible. These include questions about committment, equity, compensation, goals and exits. Here's an article on the topic: Questions You Should Ask Your Co-Founders.
7. Remember that many real great potential co-founders are *already* running their own startups. Be open to creative ways to joining forces with these folks.
So, which insights and ideas do you have on picking co-founders? Are you one of those rare individuals that has succeeded in doing it all alone? Would love to read your experiences and thoughts in the comments.
Article has
19 comments.
Click To Read/Write Comments
If the title of this article made you smile, then chances are that at some point in your life you've worked for a big company and/or been subjected to a Dlibertian pointy-haired boss/manager.
If you're not familiar with the stereotype of the pointy-haired boss, wander on over to The Dilbert Site.
One of the things I personally *love* about startups is that the likelihood of any given startup management team being totally clueless is much, much lower than that within a big company.
Lest you think I'm completely biased, because I've worked in and around startups for so long, I will let you know that I've experienced companies with billions of dollars of revenue and thousands of people -- all the way down to companies with two people and no revenues. Though my opinions might be biased, I don't think they're wrong.
Why Startup Management Is Usually Less Likely To Be Pointy-Haired
1. Closeness to Customers: Even within startups that have grown quickly, the management team is usually pretty close to real customers. They don't just sit in wood-panelled conference rooms and plot strategy. They're on the street talking to real prospects, closing real sales and addressing real issues that customers report. Startups where this is not the case are usually dead startups (or soon to be dead startups).
2. Aligned Incentives: Though it would be nice to think that managers everywhere are incented to act in the interests of the companies they work for, it's just not the case. In big companies, there are any number of possible motivations for management behavior -- only one of which is the success of the company. The primary competing incentive is job preservation and career growth. In a big company, career growth can often be independent of passionate committment to the company. In startups, the company *is* your career. There are few corners to hide in if you're not performing.
3. Emotional Commitment: Startup manangers often "live" their startup. They're committed. They have skin in the game. If the startup fails, *they* fail. Sure, they're likely recover and go on to live productive, satisfying lives. But, the experience will leave it's mark. In bigger companies, not so much. You go out, you find another job. More often than not, it's better.
4. Execution Counts More Than Strategy: In a big company, managers can often overly focus on strategy. They plot big, company-changing things. They think out-the-box. They pontificate on what they think will drive innovation, quality, service, sales, or whatever it is that they happened to be focused on. This is all fine and good, but it takes a while to measure whether a given manager's strategy was actually "good" (i.e. effective). At startups, managers are more often than not measured by less lofty things: like what they get done, or help get done. Nothing wrong with strategic thinking, but I've never read a Dlibert cartoon where the pointy-haired boss actually did something useful and productive. He's usually doing something "strategic" (and lame).
So, what do you think? Am I being overly harsh on big companies? Have I spent too much time at startups and as such have a distorted view? Or, do you find yourself nodding your head at most of these points and think I've got an uncanny knack for the obvious? Would love to read your thoughts and experiences in the comments.
Article has
13 comments.
Click To Read/Write Comments
I came across an interesting article on the NYTimes.com website today:
LinkedIn Plans To Open Up In A Closed Sort of Way
The article is an interview with Dan Nye, the CEO at LinkedIn.
A few points from the article:
1. LinkedIn will have to "approve" any company that wants to tap into its system.
2. Nye wants to keep the apps "all business".
3. There will no food fights on LinkedIn. So, unlike Facebook there will be no "frivolous" apps that allow users to throw food at each other, send each other virtual beers or some of the other fun and frolicing that occurs.
4. LinkedIn will take a revenue share from any apps that are built on it's platform.
As a Facebook user, I personally find most of the applications built by third-parties inane and time-wasting. I don't want to be a vampire or throw food at my Facebook friends. Perhaps you don't either. But, that's not the point. As a software entrepreneur, I think what makes a platform appealing is the ability to exercise some creativitiy -- within technical and infrastructure limits.
When I first started developing for Windows (and for that matter DOS), I knew there were restrictions. But, the restrictions were not that I needed to seek approval from Microsoft -- they were technical limitations and market limitations. If I wanted to develop a silly application that reversed the characters in a string and printed it out, so be it. If I wanted to make that application available to everyone. So be it.
Though I can understand the motivations for LinkedIn focusing on its users/customers in order to ensure they are getting maximum value, I'm not sure that trying to be highly selective about which apps are approved and available is the optimum strategy. One of the big advantages of building a platform and allowing third-parties to create value on top of it is that you are not limited by your own creativity. Others with interesting ideas can try them out. Some will succeed and some will fail.
Back to Facebook. Sure, lots of the apps are silly, but I get to decide which ones I use. Just like Windows (another platform), there are literally tens of thousands of apps that are out there. I use a small fraction, but in many cases, it’s a *different* small fraction than the ones you use. A good platform allows this "free market of ideas" and fosters creativity. You're going to get a lot of crap, but that's the price you pay for the good stuff.
So, although I agree that virtual food fights are a waste of time, sometimes you have to allow a bit of fun and frolic in order to flourish. And, there is such a thing as going too far in order to "protect" your customers. As a customer myself, I'd rather decide what I find useful or interesting. What do you think?
Article has
7 comments.
Click To Read/Write Comments
First off, let me say I'm very impressed with Salesforce.com. I admire the company considerably. My startup, HubSpot, is a Salesforce.com customer. We're also about to become a partner so we can integrate our marketing product with the SFDC CRM/sales application and create some benefits for our customers.
As a CRM applications company, I think Salesforce.com is simply brilliant and the company deserves much of the success it has achieved. I even like the fact that they built an API so that third-parties can create value around the core Salesforce.com CRM application. This is just smart as it further extends their reach and gives the ability for customers and partners to create more value.
However, I'm a bit troubled by the recent announcement of force.com, SFDC's new "platform as a service" offering. My concern is not with the actual underlying technology, as I don't know much about it. I've never written a line of Apex code in my life (this is SFDC's proprietary language introduced as part of the hosted apps on AppExchange). My concerns are primarily strategic in nature and centered around software entrepreneurs looking to build businesses on top of force.com. My guess is that startups are the initial primary audience for force.com as I don't believe large, established enterprises will be buliding or porting apps to force.com anytime soon.
So, if you're a software entrepreneur, here are my thoughts on the tradeoffs of building your shiny new startup on top of force.com:
1. Lack of an ecosystem: I think the ecosystem surrounding a platform is as important as its underlying technical merits. Where will you find other developers? Books? Training? Tools? Components? If you have to initially rely on SFDC and it's small pool of early partners, chances are, you're going to pay higher than average costs for all of these things.
2. Upper Limit On Growth: Lets say your idea really is as brilliant as you think it is. How far do you think you can take it on if you're running on force.com? $10M? $100M? The next Facebook? I'm going to argue that there's an intrinsic limit on how big your company can get while running on force.com. I clearly have no data to back up this argument (yet), but see point #3 below for some rationale.
3. Royaties: So, what will being on force.com cost you? Unlike successful platforms of yesteryear (like DOS, Windows, Mac or the Internet), force.com has a royalty. You're going to pay Salesforce.com $25/month/user to run your app on it. I like the simplicity of this, but it does limit the kinds of apps you can build. There are lots of software businesses out there where $25/month/user would likely be over half the revenue generated. Sure, you get infrastructure, distribution help (in theory) and a shorter development cycle. But, this comes at a price.
4. Price Controls (or lack thereof): I would worry that in the long term, Salesforce.com would have significant "power" over the price -- and would likely find ways to exert that power over startups. I'm not saying that they're necessarily going to *raise* prices, but they're likely going to take a larger fraction of the "market value" for the capabilities they're bringing to the table. So, 5 years from now, when processors, storage, bandwidth and other infrastructure components are even cheaper, there's no requirement that SFDC has to reduce its prices to match "market". Once you're on, you're on. Another alternative would be to come up with force.com "Enterprise" (basically a segmentation and price discrimination strategy). The features included in the "Enterprise" platform would be just those those successful on the platform really have to have.
5. Focused Competitive Power: Since this is "platform as a service", SFDC would have considerable power over the startups that run on it's platform. Back in the day of DOS/Windows, there was suspicion that Microsoft went out of their way to ensure that apps like Lotus 1-2-3 and WordPerfect had "trouble" running on their latest OS. But, back then, the product update cycle was pretty long and there were literally thousands of developers using the platform that Microsoft didn't necessarily know about. Even if they Microsoft hated your guts (because you were competing with them), it would take them some time and effort to really single you out and do damage. They couldn't easily change the platform to make your life (individually) hard. But, with force.com, the power to change is immediate. If you failed to negotiate a new partner agreement, pay your royalties, or (gasp!) wind up in a situation where SFDC really liked your market, they could (technically) turn you -- and your customers -- off in a second. There's nowhere to hide. I'm not saying they'd do this, but simply having the *ability* to do this gives them a fair amount of power and future negotiating leverage.
My point is, though I find the force.com "platform as a service" idea interesting, I'd be a little leery of actually putting all of my startup eggs in that basket. I'm sure there will be entrepreneurs, VCs and other folks that will support SFDC in this effort and work to make it successful. But, for now, my bet is that SFDC won't be nearly as successful in the broad "platform as a service" market as they were in the CRM apps business. It's just a very different game.
This is why I like the Facebook platform. You get the advantage of a large and growing number of users on the platform -- without all the muckiness of having to use their language, tools and technologies. In fact, you could simultaneously build an app that lives on Facebook -- but also runs on it's own, thereby giving you the best of both worlds. Sure, you still have to worry about infrastructure -- but that stuff is geting easier and cheaper.
What do you think? Are you considering spending the next couple of years building something on force.com? Am I being overly paranoid here and missing what will prove to be the greatest opportunity since Windows for software developers? Would love to read your thoughts in the comments.
Article has
14 comments.
Click To Read/Write Comments
I talk to entrepreneurs all the time that are very excited about their idea because "…the market opportunity consists of millions of potential customers!". This line of thinking then eventually leads to reasoning that goes something like this:
"Since the market consists of millions of potential buyers, all I need is to capture 1% of the market and my startup will be a huge success!".
I think too many entrepreneurs fall into this "market of millions" trap. Although there's nothing wrong with eventually having a big market opportunity (in fact, I encourage it, and investors require it). I think success is often much more correlated with a startup's ability to identify (and sell) individual customers as early in the process as possible than waiting to serve a much bigger market
Also, on the "1% of a big market" argument, the probability of you capturing a 1% share of a mega-market is near zero. Either you'll get no portion of the market, or it'll be more significant. It's rare for startups to get 1% (or some other small percentage) of a massive market.
Why A Real Market of A Few Is Better Than A Mythical Market of Millions
1. If you build a product that serves the needs of a few *real* customers, it's unlikely your opportunity will be limited to just these few. You'll likely find a way to extrapolate and address larger markets later.
2. By focusing in on a smaller market of real potential customers, you'll actually stand a chance of selling them something. If you're going after a market of millions, it's easy to fall into the complacent thinking of "I'm investing for the long-term and building something that will appeal to the masses later…". I think your chances are much better of you have something to sell to a few people *today* than a hypothetical product that will theoreticaly appeal to millions later.
3. The cost of acquiring customers seems to be proportional to the broadness of the market you're going after. This should not be too surprising. It's more expensive to reach a broad market with a meaningful message that will sell them than a small, contained market. The smaller market is easier to get data on, easier to address, easier to convince and easier to delight (hence resulting in referral business).
Now, here's the one big risk to going after the smaller, more contained market of a few: If you're not careful, you can fall into the "custom solutions" trap. This is where you are so focused on meeting the needs of the few that you have a hard-time making the eventual leap to the market of millions. This is one of the reasons why I refer to the "market of a few" rather than the "market of one". A market of one is dangerous -- as there's a high chance that you fall into the custom solutions trap. But, as soon as you try and serve the needs of two or more real customers, your odds of falling into this trap go down. The trick is finding the right balance: Enough of a market so you build something that is relevant for many, but not so broad that the market becomes hypothetical.
Article has
13 comments.
Click To Read/Write Comments
Most of the startup writing out there (including articles on this blog) addresses issues of strategy, finance, innovation, product development and other "fun" topics.
For this article (which I hope will become the first in a series), I'd like to take a slightly different angle by looking at some of the not-so-pleasant sides of the startup experience. What I call the "Dark Side Of Startups".
The following is a list of the types of co-founder conflicts that I have encountered in my 15 odd years working in and with startups. Some of them are from my own personal experience, some are from late night conversations with other entrepreneurs dealing with co-founder issues. If you've kicked off a company and had one or more co-founders/partners in it, chances are some of these might resonate with you -- I'd be very surprised if none of them did. If you're on the outside, looking in (i.e. thinking about starting a startup), don't let this list dissuade you. I still think startups are great things, but it's often useful to look at the dark underbelly of exeperiences sometimes to get a fuller understanding of things .
5 Common and Corrosive Co-Founder Conflicts
1. The "Who Gets What?" Conflict: This conflict is likely the most common. Anything that impacts the amount of money made for the various founders has the potential to generate conflict. The most obvious example is equity in the company. Who gets how much? Why? What happens if one of us leaves? Another example is the issue of founder compensation. How much should each founder get paid? Why? Who gets to change it? The good news about economic conflicts (vs. some of the others we'll talk about later) is that the conflict itself is understandable and rational. Everyone wants to be treated fairly and at some level, there is a natural conflict of interest (i.e. if I get more shares, someone else gets less).
Under good circumstances, most conflicts in this category can be resolved through discussion, negotiation and perhaps some outside intervention (i.e. an advisor or mediator). Under bad circumstances, this cannot be reconciled the "easy" way and as such, the legal documents get visited, people hire lawyers and unpleasantness ensues.
2. The "I Work Harder Than You!" Conflict: It is mathematically impossible for each founder to work at exactly the same levels in a startup. It is natural for each co-founder to invest time/energy based on her situation. This could be influenced by how much time they have available, how passionate they are about the company (yes, you heard it here first, not all co-founders are totally passionate about the company), their own style, their personal obligations, etc. When founders begin arguing about who is doing how much, this can often be rooted in the "who gets what" conflict. Example: I'm working 100 hour weeks and Joe's only working 50 hours weeks, so I should get twice as many shares as Joe!".
3. The "Who Gets To Decide?" Conflict: If you and your co-founders are well matched, chances are your skills and talents are not totally overlapping (i.e. they are good at some things and you are good at others). This resolves most of the "who gets to decide" issues as lots of decisions fall into the area of expertise of one co-founder or another. If the founding team is functioning well, most decisions never become issues. But, there are two areas where issues do arise: When you both have some background/expertise in an area (or believe you do) and when neither of you has any background -- but both have opinions. One common example of this is raising capital when all/most of the co-founders are first-time entrepreneurs. Everyone has opinions on whether or not to raise capital -- and if so, how much and from whom. Since there are no easy answers to this (even when you have had prior experience), conflicts can occur. A lof the conflict in this category really comes down to personal goals of the co-founders. Some want/like control. Some like/want a certain outcome ("We've raised money from a major VC -- woo hoo!") and some just want to build something cool. When decisions impact the various personal goals of the founders, tensions can arise. My only advice here is to have conversations about this as early in the process as possible.
4. The "I Can't Stand Jill, One Of Us Has To Leave!" Conflict: This is the worst. If the situation degenerates to the point where two co-founders are so conflicted that one or the other has to leave the company, several bad things can (and likely will) occur. In some situations, it's not the loss of a co-founder that's the most traumatic for the startup -- but the time leading up to the loss. If there are other members on the team, their morale is impacted. If there are other co-founders (besides the two in conflict), they are pushed to "take sides". Lots and lots of unpleasantness. Of course, getting to this point is not always a bad thing. There comes a time in the evolution of a startup that it makes good sense for a co-founder to leave. Everyone involved discusses the situation, determines what the best path is for the company and parts friends. It's all rainbows and sunshine. If you find yourself with this situation, congratulations, you're working with some great people. If not, and you have this conflict, your life is going to suck for a while. My sympathies are with you.
5. The "We're Going Down In Burning Flames…" Conflict: In my experience, most startups have near-fatal experiences regularly. In my first startup, not a year went by that we didn't he a day where we just thought the company was going to die. It could be some major product issue. Could be the potential loss of a significant client. Could be the draconian activities of an important business partner. Whatever it was, something really bad was going on and it was easy to come up with all the reasons why the company would just not be able to survive this setback and the "why don't we just cut our losses" type thinking begins. The conflict arises because not all the co-founders will see the situation in the same way. Some, because they're natural optimists (like me) and will ignore the evidence. Others, because they are influenced by having too much, or too little at stake in the game. Regardless, the conflict arises because one or more co-founders want to just go ahead and call it quits -- and the others do not. As is usually the case in these situations, there's no clear answer. Perhaps it is time to call it quits, but nobody really knows for sure In my first startup, we had several of these near-death experiences, but did not decide to call it quits and were reasonably successful. In another of my startups, we probably should have called it quits sooner, but didn't. In any case, it's hard to know the right answer and even if you knew, it's sometimes hard to get everyone to agree.
So, what do you think?
Have you experienced (or are you experiencing) any of the above conflicts now? How do you deal with them? When do you bring in outside help? [Note to self: Write future article about the difficulty of finding competent, non-conflicted advisors].
Have I missed any major types of conflicts? Leave a comment, and let us know (even if it's just to vent).
Article has
30 comments.
Click To Read/Write Comments