A buddy of mine just IM’d me about cheap hosting in the US. His requirements are:
- non shared hosting i.e. dedicated server
- a linux distro which doesn’t have package management issues i.e. gentoo / debian / *bsd
- a non astronomical monthly fee ( he needs at least 2 servers from day 1 to build a clustered architecture)
- ssh access w/ some kind of decent web based admin tool like webmin
- ability to do some kind of disc mirroring / heartbeat with drbd or something similar. This is a high reliability application but he can’t afford to buy his own hardware*
I’ve heard good things about ServerBeach but I don’t know. Anyone have any thoughts? Niall? Where’s your box? Kevin what do you use ? (and yes I could traceroute but I think its a good conversation to start)
*I know that’s inconsistent on the face of it. Don’t bug me about it. Bug him (oh crap; he requested anon)
I think the most common questions any entrepreneur has are always about money — how to get it, where to get it, how much to get, etc. And, sadly, I see everyone always make the same mistake. They focus on what they can raise but NOT on what they actually need. Oy. And I’ve done it myself too.
So here’s my little bit of web 2.0 startup advice for the day:
- Understand your own business.
- There is an inflection point for any startup where a linear increase in growth or capacity requires a non linear increase in capital needed.
I’ve thought about this a lot lately. And I mean a lot and I think the best analogy I can make is from architecture. Reading Paul Graham’s Hackers and Painter’s* book 2 years ago at Foo Camp made me think a lot about architecture. And I think the lessons from building buildings are very applicable to software.
Lets say you live in the Bayou and you want to build a dog house. That can be done with a few scraps of plywood, a 2×4 for 2 and Rover’s is just as happy as a clam. So now you get a 2nd dog and you want to make it bigger. Well more plywood and another 2×4 or some additional lathe and you can easily double the capacity of the dog house. No worries. Now your neighbor asks you to dog sit for them. Ok no problem. You make it bigger still and you can hold 3 dogs. Then all your neighbors bring over their dogs. And guess what? Your dog house sinks into the mud. Why? Well you never made a foundation.
That’s what I mean about a linear increase in growth or capacity leading to a nonleaner increase in capital. You could easily double or triple the size of the dog house and rover et al were fine. But when you needed to quintuple it you really had to rip it down and pour a cement foundation or it would just sink into the mud.
Having had lunch with Kevin Burton from Rojo / TailRank a few weeks ago, I worry that he’s making this type of mistake. Now don’t get me wrong TailRank rocks. But as the quantity of data he’s trying to process expands, he’s going to face this issue. Heck FeedLounge seems to be in the middle of it. Controversy. My guess is that WordPress.com / Matt either have hit this point already or will soon.
So I think this is a basic either VC or engineering principle and I’m going to be cocky enough to name it after myself:
Scott’s Law of Funding: Linear increases in growth / capacity will at some point require nonlinear amounts of capital.
I look back at the founders of Google and that giant pile o’ money they took back in the early days ($25 meg from Kleiner if my memory serves me right) and, damn, were they ever right. Yeah they might a lot richer now and less diluted if they had taken smaller drips as they went but what they didn’t do was ignore this. Whether by luck or planning they had enough money to deal with this up front.
An Internet Example:
When I built out the first data center for Feedster, I bought cheap switches (D-Link gigabit switches to be specific) for our internal LAN backbone**. Why? Well switches are complex and I didn’t know enough to buy the right ones. Now we’re using *censored* but its an enterprise level switch. Our traffic may have gone up by *censored* fold but our switch costs went up by *censored* fold but its a nonlinear price increase.
So keep this in mind. For whatever you do, whatever your startup, there will be a point where your growth rates are going to be such that you need a non linear increase in capital. Yes I know you’re a hot web 2.0 startup and you’re going to be acquired before then. Well that’s the plan and that’s always the plan but it rarely actually happens that way. Sometimes you have to actually operate the thing you’re building and, if so, are you going to be able to.
*If you haven’t ready this yet then you need to. If you haven’t re-read it lately then you should. Heck I just did.
**I did however use Cisco for our external facing side.
i.e. How to Bring Web 2.0 Company Engineering Under Control
Yes Virginia this is another article in my Engineering Management 101 series of posts which can all be found under my Software Engineering tag.
Process is often to many engineers a dirty word. Sometimes its a very dirty or #*$&#(*$ word. However this is not necessarily the way process has to be. When implemented correctly process actually aids engineering increasing the ability of the organization to deliver quality product. Alas, that one word “correctly”, in the previous sentence makes all the difference. All too often process is handed down as an edit from above as if the hand of god had graced it upon the organization. Whenever this happens, process is almost always a failure — particularly in small, highly technical groups that are used to full control of their activities.
[ And, yes, given that web 2.0 companies are often started by a single "hackerish" individual that's the type of "hackerdom" I'm referring to. ]
These types of groups, if not directly involved in the authoring of the processes, will tend to fight them tooth and nail. As in any type of successful organizational change, HOW you go about implementing things makes a world of difference.
So here are my Ten Tips towards Implementing Successful Engineering Processes:
- Make Sure that the Precipitating Indicent for the Process would actually be Solved If There Was Process in Place. Generally the move towards process comes as a result of some sort of incident that makes senior management throw their hands up and say things like “Those (#$*#($ hackers; we need to bring order to our chaos”. The problem is that all too often the precipitating indicent wasn’t one that process might have solved.For example a network event happens like a partner’s ad server goes down intermittently causing unreliable site performance. Now any software engineer knows that when something happens to software that’s outside of your control to which a network connection is being established is devilishly tricky to debug. Unless you’ve specifically instrumented your code around that sort of thing, you’re just going to be scratching your head when the error occurs. And you’re going to be rapidly debugging just to diagnose the problem. When you run large production web sites these types of things do happen. And, when the partner has large server farms with some kind of dynamic server rotation based on DNS, it gets worse. When a large online portal first debuted their Add Feed to MyCustomPage buttons, we tried desperately to support it and it would work one time. Then we’d refresh the site and try and subscribe again and it would fail. What was happening, as best as we could diagnose from the outside, is that in the pool of servers that handled end user feed subscription there was one or two that were using an older version of code that couldn’t handle feed urls longer than (if I remember correctly) 128 characters. Given that we make long urls, this was clearly an issue to us. Now you could have all the process in the world and all the units tests and it still stands a very good chance of NOT catching that.And, engineers, particularly the really good ones, the ones you have to have to succeed in today’s Internet business are logical. When you try and justify a process change based on a precipating incident that simply isn’t valid and no amount of process would have solved, they immediately and dramatically discount the process model on its face. No matter whether or not the process model actually has valid elements, they discount it and dismiss it. This is sometimes referred to, or at least similar to, “Flipping the Bozo Bit“. Yes engineers do this both too easily and too frequently. Never the less if you want to work with engineers its important to understand.
- Pick the Right Time to Implement Process.Here’s a secret about process that I probably shouldn’t say. If you want to make sure that you get process implemented, its almost as important to pick WHEN you implement the process as WHAT the process has in it. Let’s say that your engineering department has a new release under way. If you try and change processes before the release is finished, no matter how valid the process is, they will kick, scream and howl. They will fight the process model with every fiber of their being.Why? Well engineers purely hate the rules being changed on them. When an engineering group agrees to ship a product, they do so knowing that there are one or more constraints on them. An example of a constraint is the feature set. Engineers go into a release process knowing the feature set. Add more features to the release and, well, the rules have been changed. The engineers know all too well, whether explicitly or implicitly that new features have costs and that they may well cause the release date to be missed.But, if you wait until after the release is done, then the engineering group is often so damn tired that they’ll simply agree to anything just to have management stop annoying them. Once upon a time I was in a large, publicly traded software company. We had a release team of probably 35 people across our Cambridge, Boulder and Albany departments. We met our delivery date and the Chairman of the board walked through Engineering with a Shopping cart passing out bottles of champagne because we had actually shipped in Q4 thereby fulfilling his promise to Wall Street. And, promptly thereafter, new engineering processes were implemented. None of us were happy but we basically shut up and accepted it. It was the peace of exhaustion.
- Avoid Holy Wars. There are exactly 2 holy wars in all of programming. One is the Editor war (VI versus Emacs versus an IDE) and the other is the Platform war (Windows versus Mac versus Unix). Any process document which mandates one of these has a high chance of failing. Any process document which mandates both of these has an even higher chance of failing.
- Make sure that any process you want to implement is economically viable. Engineers tend to be logical (they can also be irrational of course; they’re human). If an engineering process that’s requested isn’t economically viable, well, they know its going to fail. And they simply won’t take it seriously. Lets say for example that someone gets the “Pair Programming” bug and they want to implement it. Well that’s great but if you have engineers that work from remote locations regularly, its not economically viable. Why? Well unless you’re willing to fly people to someone’s home office it ain’t going to work. Now lets say that your organization works with code in 3 different languages (C, Perl, PHP) and you want to implement a process by which all checked in code is reviewed by another person. Well unless your organization has substantial excess engineering capacity that process requirement is not valid. Multiple languages in the same organization generally means your staff are broken into specialists by language. So you might not even have the capacity which means you’re going to have to go out and hire another say Perl programmer just to review your existing Perl programmer’s code. And that’s not going to happen; its just management speak.
- Don’t leave gaping logical inconsistencies in your process model. The classic mistake the virtually all web process models make lies at the database layer. Engineering process simply isn’t a matter of code checkins anymore. Often there’s significant process issues tied to how you implement changes at the data level. As an example I have regular jobs I kick off on our core data warehouse that can affect the categorization of 100K feeds or more at a time. Recently I changed the categorization of more than a million feeds in a single day. Any process model has to take into account row level versioning across multiple tables. And that dramatically impacts the process model. Where the heck do you check that into Subversion?
- Identify the influencers and seek buy in. A long time ago I spent 3.5 years building, selling and installing high end ($250,000 + ) corporate knowledge management software. One of the key lessons from experience i learned is if you want new organizational processes to succeed then you find out who the influencers are and you go to them BEFORE you define a new process and you get their buy in as part of the definition step of the process. If you go around the key influencers then they’ll torpedo you every time. The way to succeed is to get the influencers to be part of writing the process spec. This is basic politics 101 / management 101.
- Make sure its uniformly applied. Process models work when they’re rules in general not rules in specific. If you’re going to have a process model then it applies across the board; every programmer; every project from big to small.
- Be Specific. Don’t leave a term in their like “Senior Software Engineering Staff”. If you’ve got someone in mind for, say, code reviews then use a name. Let people know who’s actually going to do what.
- Make things such that process is required. Engineers always fight against new. things. Believe it or not we’re actually the most conservative people in the world. We know that most technology doesn’t work; heck we wrote the bugs that keep it from working. So if you want to get engineers to do something then make it so its actually required. Now let us say you have a sole engineer on a project and he’s not checking into subversion regularly. He owns all the code and he’s solely responsible for every single change. Well if you ask him why, he might reply “Look — I can use Subversion but its slower. I know every change I’m making and when I need to I make backups.” But, however, assign another engineer to that project permanently and I’ll bet you dollars to donuts that Subversion use won’t be a problem anymore. Why? Simple. At that point the use of Subversion is required.
- Don’t ignore ongoing work in process. Directives like “Cease all coding until the requirements of this process model are met” in any business aren’t realistic. In an Internet business really aren’t realistic. Often times there are significant projects that have to be completed before a process model can be started. Its rare that engineering management knows everything that’s going on. We’ve seen this in case study after case study of factory floor workers and software engineers are new age factory workers.
- Make sure it matches business constraints. When I was at Dataware, the company was recovering from an engineering manager who required an SEI (Software Engineering Institute) process model. Dataware had traditionally been a hacker driven culture which some of the most talented people I’ve ever been privileged to work with (Hi Jim Kearney; Hi Andrew Willemsen; Hi Pete Jenney; Hi Brian Giedt; Hi Ed Fischer). Anyway the company had newly gone public and management wanted to concurrently deliver innovative new products and have a dramatically more rigid process model. The problem is that the business constraint (innovation) didn’t match the process model (rigid). This dichotomy basically crippled Dataware’s ability to innovate for a long time. However it made lots and lots of pretty Gantt charts.
- Beware blogged lists of steps. The advice you find on the web may only be worth what you pay for it.
My buddy “Mike Down Under” has an interesting post on Web 2.0:
Web 2.0 – $9.95 per monthI’ve been thinking about writing this post for some time now and today I saw a post from Michael Arrington that touched on what I’ve been thinking for a while.
So it’s Web 2.0. we’re all pretty much decided on that. We’re seeing lots of very cool things popping up, mashups of services and access to technologies that are really quite awe inspiring. We are fast reaching the point where we feel we *must* have these sorts of tools to conduct our daily internet use.
Still, what I find glaring me in the eyes is that there is still a very strong mentality that we shouldn’t have to pay for things on the internet.
Well clearly people don’t like to pay for things. That’s obvious but I don’t think its all of it. I think a big part of of it is:
- Simplicity of transaction
Simplicity. One of the main reasons why I use Amazon is that I **generally** don’t have to re-enter shipping info, credit card, etc. And it keeps your shopping cart across sessions. That makes commerce so simple. At least it used to. I used Amazon yesterday to buy the new 37 Signals book and I lost my shopping cart twice, had to re-enter my address and my credit card info. It was so **jarring** that it didn’t even feel like Amazon. One of the main reasons why I no longer like to buy from PC Connection is that they idiotically persist in using a session based shopping cart. And that’s saying something since in 2000 I spent well over $1,000,000 with them at the height of the dot com boom. 80 proliants, EMC storage, cisco gear, etc.
Trust. Now I founded a web 2.0 company and let me ask you this — who among the Web 2.0 crowd would you think will be here in a year? Now for me trust breaks down to:
- If I use it can I get my data back?
- If I give them $$$ will I get my value out of it?
I could go on and on about this one but trust is one of those fundamental things that is:
- Hard to get
- Easy to lose
- Damn near impossible to recover from
Let me give you an example of a web service that I would gladly pay $20 per month for: Photo Backup. Yes there lots of online backup services but I wouldn’t pay any of them for the privilege. But if Google or Yahoo offered it? **Damn**. Yeah I know intellectually that these guys can screw me over just as well as anyone else. And I also know that I’m likely to get better customer service from a web 2.0 company (test this — IM one of the Feedster founders, me, at Feedster2003 with a Feedster problem and see if you get a response). But that’s largely irrelevant unfortunately. There’s simply a trust factor that both Yahoo and Google will be around a long time.
So if you can’t solve the trust issue maybe you can make the transaction process easier. And I know that Dave McClure would say “Paypal”. I’m starting to be a bit dubious on this actually. The constant phishing attacks and paypal spam I get EVERY day bit by bit make me scared of paypal. And I strongly doubt I’m the only one. Perhaps there’s an opportunity for a Web 2.0 version of PayPal.
Note: Typo corrected. Thanks to Mark for this one. Oy.
Evan of Blogger and Odeo fame just wrote a damn good essay about being “10 Rules for Web Startups” and I thought “Damn but I need to understand that better”. So I figured I make an annotated version and relate it in context of my own startup lessons. This is, after all, how I tend to learn — I take something and dissect it. Anyway. Thanks Evan! Great essay.
#1: Be Narrow
Focus on the smallest possible problem you could solve that would potentially be useful. Most companies start out trying to do too many things, which makes life difficult and turns you into a me-too. Focusing on a small niche has so many advantages: With much less work, you can be the best at what you do. Small things, like a microscopic world, almost always turn out to be bigger than you think when you zoom in. You can much more easily position and market yourself when more focused. And when it comes to partnering, or being acquired, there’s less chance for conflict. This is all so logical and, yet, there’s a resistance to focusing. I think it comes from a fear of being trivial. Just remember: If you get to be #1 in your category, but your category is too small, then you can broaden your scope—and you can do so with leverage.
Me: Yup. In my first company we made a product called HyperWriter which was a pre-Internet GUI based hypertext editor and browser. Think FrontPage but starting in 1987. Yes, Virginia there was a Hypertext industry before the web. No Virginia it did not survive the advent of the Internet with one exception — Eastgate Systems, makers of the ever wonderful Tinderbox run by the equally wonderful Mark Bernstein. Anyway this was a very horizontal product with users in literally every industry like BASF (intranets), Firestone (online training), Higher Education (online courses about nematodes). Those were just a few of the uses that our thousands of customers had for the product. And, while it was a great product, we suffered from lack of focus. Applications for the product broke into two main categories:
- Text based such as online documentation
- Interactive such as education and training
We ended up adopting the positioning statement “HyperWriter – Your one solution for online documentation and interactive training”. This, honestly, served no one well and our rationale at the time was that one of those was too small and we’d be better off not “limiting ourselves”. Clearly both were huge industries and focus would have served us well. Go Ev Go!!!
#2: Be Different
Ideas are in the air. There are lots of people thinking about—and probably working on—the same thing you are. And one of them is Google. Deal with it. How? First of all, realize that no sufficiently interesting space will be limited to one player. In a sense, competition actually is good—especially to legitimize new markets. Second, see #1—the specialist will almost always kick the generalist’s ass. Third, consider doing something that’s not so cutting edge. Many highly successful companies—the aforementioned big G being one—have thrived by taking on areas that everyone thought were done and redoing them right. Also? Get a good, non-generic name. Easier said than done, granted. But the most common mistake in naming is trying to be too descriptive, which leads to lots of hard-to-distinguish names. How many blogging companies have “blog” in their name, RSS companies “feed,” or podcasting companies “pod” or “cast”? Rarely are they the ones that stand out.
Me: Yep. Google clearly thrived by being the best in the world at something that everyone else disregarded (search and then advertising). Look at Oddpost, the best damn web mail client ever. Look at all the new startups around doing AJAX versions of “traditional” web apps like calendaring. New platforms always give an opportunity for retakes of prior apps.
Now — about the name. Yes Evan is right about making your identity stand out but you need to be really careful about it particularly when you mess with things that sound cool.
My good friend Shimon is doing it with a wicked cool AJAX based Todo List manager (Voodoo Todo) after he did excellent work on Frassle a very, very cool blog publishing platform. And I’d love to give you a link but I just googled his name and several variants on it and damn if I can find it. I gave you the Frassle mention in the hope that he had a link from Frassle to Voodoo. Sigh. He doesn’t.
Update: Its voo2do.com.
#3: Be Casual
We’re moving into what I call the era of the “Casual Web” (and casual content creation). This is much bigger than the hobbyist web or the professional web. Why? Because people have lives. And now, people with lives also have broadband. If you want to hit the really big home runs, create services that fit in with—and, indeed, help—people’s everyday lives without requiring lots of commitment or identity change. Flickr enables personal publishing among millions of folks who would never consider themselves personal publishers—they’re just sharing pictures with friends and family, a casual activity. Casual games are huge. Skype enables casual conversations.
Me: Interesting. I hadn’t ever thought about it but Evan’s right — there is a huge opportunity by looking at the web from this perspective. My gut says there’s a huge opportunity still in photos. Flickr nailed the single user photo sharing solution but, having spent the Thanksgiving holiday with my inlaws, I firmly believe that the problem is really easy sharing amongst the family unit. But that’s the point of another blog entry… Got it. Be casual.
#4: Be Picky
Another perennial business rule, and it applies to everything you do: features, employees, investors, partners, press opportunities. Startups are often too eager to accept people or ideas into their world. You can almost always afford to wait if something doesn’t feel just right, and false negatives are usually better than false positives. One of Google’s biggest strengths—and sources of frustration for outsiders—was their willingness to say no to opportunities, easy money, potential employees, and deals.
Me: *chuckle*. Very true. Everyone always wants something and often its not good for you. One tweak here and one tweak there and soon you have a whole big mess.
#5: Be User-Centric
User experience is everything. It always has been, but it’s still undervalued and under-invested in. If you don’t know user-centered design, study it. Hire people who know it. Obsess over it. Live and breathe it. Get your whole company on board. Better to iterate a hundred times to get the right feature right than to add a hundred more. The point of Ajax is that it can make a site more responsive, not that it’s sexy. Tags can make things easier to find and classify, but maybe not in your application. The point of an API is so developers can add value for users, not to impress the geeks. Don’t get sidetracked by technologies or the blog-worthiness of your next feature. Always focus on the user and all will be well.
Me: Man oh man is that true. I can point to things in my own site that aren’t user centered where I didn’t fight hard enough for the user’s perspective and Evan’s dead on here. User. User. User. (Said to the tone of “Marcia Marcia Marcia”). Note to self: Buy the new book from 37 Signals.
#6: Be Self-Centered
Great products almost always come from someone scratching their own itch. Create something you want to exist in the world. Be a user of your own product. Hire people who are users of your product. Make it better based on your own desires. (But don’t trick yourself into thinking you are your user, when it comes to usability.) Another aspect of this is to not get seduced into doing deals with big companies at the expense or your users or at the expense of making your product better. When you’re small and they’re big, it’s hard to say no, but see #4.
Me: Well that’s why Feedster exists. I’m a search guy and I saw an idea on a blog for “RSS Search Engine” and I said “I Can Do That and, damn it, I want that” and 3 days later I not only had one but it was featured on Slashdot. And, initially at least, we did hire people who used it. And we did add features based on my desires (although we’ve moved away from that). I’ve called this “Scratch Your Own Niche” before.
#7: Be Greedy
It’s always good to have options. One of the best ways to do that is to have income. While it’s true that traffic is now again actually worth something, the give-everything-away-and-make-it-up-on-volume strategy stamps an expiration date on your company’s ass. In other words, design something to charge for into your product and start taking money within 6 months (and do it with PayPal). Done right, charging money can actually accelerate growth, not impede it, because then you have something to fuel marketing costs with. More importantly, having money coming in the door puts you in a much more powerful position when it comes to your next round of funding or acquisition talks. In fact, consider whether you need to have a free version at all. The TypePad approach—taking the high-end position in the market—makes for a great business model in the right market. Less support. Less scalability concerns. Less abuse. And much higher margins.
Me: Yep. We used to actually have a self service advertising system using Paypal to allow people to place their own ads on the Feedster.com site. Before our first CEO wanted it taken down we had made some $6,000 cash in ad revenue. Teeny numbers I’ll admit but I wonder what it would be if we hadn’t taken it down. Perhaps I should have fought harder for that one. Alas. Seriously though its ok to charge money. I just counseled a startup recently to give special pricing to Web 2.0 companies but charge less if they blog. Charge even less if they blog regularly.
#8: Be Tiny
It’s standard web startup wisdom by now that with the substantially lower costs to starting something on the web, the difficulty of IPOs, and the willingness of the big guys to shell out for small teams doing innovative stuff, the most likely end game if you’re successful is acquisition. Acquisitions are much easier if they’re small. And small acquisitions are possible if valuations are kept low from the get go. And keeping valuations low is possible because it doesn’t cost much to start something anymore (especially if you keep the scope narrow). Besides the obvious techniques, one way to do this is to use turnkey services to lower your overhead—Administaff, ServerBeach, web apps, maybe even Elance.
Me: Yep. Acquisions are, without question, the end game for most firms these days. Being tiny is definitely a way to go. I’d question Elance though. I’m not an outsourcing guy. I believe in creating and owning your own intellectual property.
#9: Be Agile
You know that old saw about a plane flying from California to Hawaii being off course 99% of the time—but constantly correcting? The same is true of successful startups—except they may start out heading toward Alaska. Many dot-com bubble companies that died could have eventually been successful had they been able to adjust and change their plans instead of running as fast as they could until they burned out, based on their initial assumptions. Pyra was started to build a project-management app, not Blogger. Flickr’s company was building a game. Ebay was going to sell auction software. Initial assumptions are almost always wrong. That’s why the waterfall approach to building software is obsolete in favor agile techniques. The same philosophy should be applied to building a company.
Me: Well said. Startups should be able to turn on a dime and react to new things. We were slow to react to podcasting but we’re starting to do the right things in that area now.
#10: Be Balanced
What is a startup without bleary-eyed, junk-food-fueled, balls-to-the-wall days and sleepless, caffeine-fueled, relationship-stressing nights? Answer?: A lot more enjoyable place to work. Yes, high levels of commitment are crucial. And yes, crunch times come and sometimes require an inordinate, painful, apologies-to-the-SO amount of work. But it can’t be all the time. Nature requires balance for health—as do the bodies and minds who work for you and, without which, your company will be worthless. There is no better way to maintain balance and lower your stress that I’ve found than David Allen’s GTD process. Learn it. Live it. Make it a part of your company, and you’ll have a secret weapon.
Me: Given that I’m blogging this at 2:08 am after a hard core day I hear you Evan. Clearly I need to look at GTD and I will. Note to self. That said, you will have crunch times and you best know how to do it and survive it (I’ve got a blog piece on this coming out).
#11 (bonus!): Be Wary
Overgeneralized lists of business “rules” are not to be taken too literally. There are exceptions to everything.
I’ve got a good friend, someone I know via IM, that wants to start a company. He’s always asking me for advice, which is good of course, but I thought it would be better to just start blogging it since I know he’s a reader. Anyway. Here’s today’s “Advice Bit”:
Now I’ve been through the startup mill a few times now and there’s one thing that’s starting to **finally** sink in: Metrics Matter to VCs. I’ve spent a few bits of odd time lately revamping the Feedster internal stats system so I can better gauge how to manage what features on Feedster need improvement and its been illuminating. One of the things that I’ve learned also is that, in a web environment, you can get metrics on ***anything***. A product manager asks you for a tool? That’s fine. But start capturing usage metrics. Then, when you’re having trouble debugging the tool, see if Feature foo is actually being used. If its not then just delete feature foo.
Now the true lessen here for new startups is that if you’re starting out and you have NO codebase then you can build metrics in from the ground floor. Every engineer knows that if you know a constraint on a problem early its a lot easier to solve the problem. Accept that you need metrics on every facet of the organization and build that in early.