Monthly Archive for September, 2007

Startup Advice - Own Your Domain

Last night I went to a sneak preview of ClayValet.com, hosted by founder and all around wonderful guy Mikhail Seregine. If you haven’t checked it out yet, I encourage you to do so.

Before the event got into full swing I was chatting with a couple of other entrepreneurs. Two different entrepreneurs - in totally separate conversations - each shared with me something that just seems totally inconceivable from a doing-business-smartly perspective.

Both have startups that weren’t able to secure the .com domain to match their company name. Let’s call them Trovel and Sniffl. Both names are fictitious. Sorry if that’s really your company name. Trovel was able to get trovel.net but not the .com domain. Trovel hasn’t launched. Nobody knows them from a hole in the wall yet. Sniffl was able to secure sniffl.us but not the .com domain. They’ve been in the market for a couple of years and have a huge brand asset in the Sniffl name.

The current owners of the respective .com domains have offered to lease the domains to the respective startups. For Trovel, the offer is $10,000 for a 1-year lease and then the right to buy the trovel.com domain later, but price will be negotiated at that time. Sniffl’s offer was even worse. The current owner offered to lease the domain for 3 years at $17,000 per year. The offer includes a right-to-buy but the current owner won’t negotiate the price until the end of the lease.

I have two pieces of advice:

1) Don’t name your company anything, unless you can get the .com domain that you actually want. Think of your .com search just like your trademark search. You wouldn’t name your company anything without ensuring you could get a trademark for it. Make sure you can get the .com domain too.

2) Don’t lease the .com domain if you don’t know how much it will ultimately cost you to buy it outright. Your .com domain isn’t like an office lease where you can just pack up and move at the end of the lease. The more successful you are and the more time goes by, the more that domain is going to cost you.

A right to buy without establishing today the price it will be at time of sale is a right to nothing. What a horrendous mistake it is to do this deal. If you have a blowout year, the current owner of the domain has you by the cajones and is really going to make you pay.

So you might be wondering what these two entrepreneurs are going to do. Trovel is going to go ahead and lease the .com domain for $10,000 for 1 year. Sniffl has hired a marketing consultant and has decided to change the name of their company soon, so they can finally get the .com they want.

I’m Looking for Something called Prospector

A few weeks ago I received a phone call from a guy in Miami. Here’s how the conversation started:

- My phone rings.

- me “Hello, this is Kevin

- Miami guy “Kevin Merritt?

- me “Yep, Kevin Merritt

- Miami guy “The same Kevin Merritt who once knew a guy named Neal Kaskel?

- me “Um, uh, yeah” (this is weird, I’m thinking)

- Miami guy “Eureka! I’ve been hunting you down for weeks

- me “uh oh

- Miami guy “Are you the guy who made some software called Prospector?

- me “Well, I led a team that built it, but yes Prospector was my baby

- Miami guy “Great. I want to buy it. Can you sell it it to me?

That odd conversation went on like that for another 20 minutes. Miami Guy wouldn’t take no for an answer, even when I told him that Smith Barney now owns Prospector and it’s not for sale as far as I know, not to mention 10 years out of date. He had to have Prospector.

Prospector is an application we designed and built between 1997 and 1999, when I ran IT for a 400-person investment bank. Smith Barney bought the company in 2001, in part because they thought Prospector was pretty cool and could use it in other parts of the company.

On the surface, Prospector was a multi-dimensional customer relationship management (CRM) system. It reflected our role as an infomediary (information intermediary) doing mergers & acquisitions (M&A). We didn’t buy a company and then sell it to a bigger company. We introduced sellers to buyers and then facilitated a deal being consummated.

Miami Guy recently started his own M&A firm. News traveled 3,000 miles from California to Miami. He heard that Prospector is unequivocally what you need to run an M&A firm.

The amazing thing about Prospector was that to its users it was a CRM system, but to its developers it was a platform for modeling, organizing, manipulating and analyzing data. No one on the dev team knew anything about CRM or investment banking, yet the people who used it thought it was the best CRM system you could ever invent for doing M&A. We didn’t create a malleable platform because we were smart. Rather, we built a platform because we really didn’t know what the app needed to do. We did what seemed natural - we delegated functional specification to business people.

Bringing this post back into context and 2007, blist has its roots in Prospector. We’re developing an innovative platform for modeling, organizing, manipulating and analyzing data. Want to track applicants or sales leads? blist will be good for that. Want to share your favorite recipes with friends? blist will be good for that too. Want to create your own VC done deals database? Yep. blist will be able to do that too. As importantly, you won’t need a DBA or even anyone in IT to get the job done. blist is for you, whether you’re from Miami or not.

Why I Joined A Startup

You’re reading the blist blog. To date, the posts have all been authored by Kevin Merritt, blist’s founder & CEO. From time to time other folks from blist will author some of the posts. Last week Kevin wrote a post on the benefits of working at a startup and shared a brief anecdote of how Paul (that’s me), interjected himself into our email marketing process. Today I am writing a more in depth post on why I decided to leave Microsoft and join a startup:

As Kevin mentioned in a prior posting, I spent almost 4 years at Microsoft before joining blist. He asked me to share my reasons for joining a startup (and blist in particular), and I’m happy to oblige. If anyone else is like me, making career changes are always a difficult situation - if you’re reading this and in a similar situation, perhaps reading some of my thoughts will clarify yours.

In the month before leaving Microsoft for blist, I had a number of goals in mind by changing jobs:

1) I wanted to work on a small (< 20 person) team. Contrary to perceptions from those who’ve never worked inside of Microsoft, there are plenty of small teams inside of Microsoft that are doing mind-blowingly cool work. I’d worked on such a team inside of Microsoft, but after a recent re-organization I found myself in a much larger group than I was comfortable with.

2) I wanted to work in a product I believe in, and my teammates also believe in. It sounds obvious, but I’ve seen both situations - and things go much more smoothly when everyone is working toward the same goal. This is related to team size - in general, the larger the team, the harder it is to keep everyone on the same page. That’s not to say a small team is immune to this problem - it may be less common to have divided vision on a small team, but the consequences can be more dire.

3) I had to work in the greater Seattle area. Although I’m originally from San Diego and still love it down there, after having just purchased my first home here in Seattle, the thought of moving and dealing with mortgage paperwork again so soon was enough to keep me in the rainy emerald city.

4) I wanted to expand my role beyond pure development. My parents have run a family-owned small business my entire life, and someday I see myself doing the same thing. It’s not everyone’s cup of tea, but I want to learn about datacenter operations, profit models, customer service, sales, and even negotiating commercial real estate leases. While all of the constraints above could be easily satisfied inside of Microsoft, this was what drove me to also look outside the company.

Switching teams inside of Microsoft is similar to joining another company, without having to deal with paperwork, health insurance, 401k, etc. Teams post openings to an internal website, and after a series of interviews, the team chooses whether to extend an offer. I had identified a few opportunities inside of Microsoft I was pursuing, as well as looking outside the company by contacting some other employers who had positions I found interesting. I updated my personal website, posted my resume online, and made sure I was proud of my profiles on some social networks. You’d be surprised how much these things help - employers really do look online for what information they can dig up on you - the more positive things they can find, the better it is for you.

Updating my presence on line paid off. At this point, I hadn’t even heard of blist. Kevin found my profile on LinkedIn, read my blog, and invited me out for lunch. After a long lunch discussing blist, something interesting happened: I spent that evening, and many other evenings after that, pondering the architecture for creating a service like blist. The ideas started flowing, and I realized I was more excited about building blist than any of the other opportunities I saw. Wrapping up interviews at blist and a few other places took another 2-3 weeks, and after considering a few different options, the decision was very easy.

In a future posting, I’ll talk about the differences between actually working at Microsoft and working at blist.

-Paul

Avoiding the IT Department

Today’s Wall Street Journal has an article by Jeannette Borzo titled “Do-It-Yourself Software.” The subtitle is “New tools let businesspeople avoid the IT department and create their own computer applications.” The article describes some of the pros and cons of using tools from statups like Coghead selling do-it-yourself application builders. There are other startups in this space, including Wufoo and LongJump.

The subtitle of the article highlights the perception that there’s an ongoing tension between department managers and IT departments. That topic provides an opportunity to share a little more about our blist product vision. As I’ve shared previously in this blog I spent six years as the CIO of an investment bank (question for LazyWeb: should blog posts be totally self-contained or can an assumption be made that the reader has read all prior posts?). I had both a reasonably good sized budget and development staff. Department managers would call me from time to time and ask for a meeting to discuss a custom development need they had. I’d listen to the manager describe her problem. I’d ask how she was solving the problem today. Often it was a collection of manual processes and/or Excel spreadsheets.

More often than I’d like, I’d encourage the department manager to keep limping along with the home grown system. Why? That’s always the question. The honest, matter-of-fact answer is that good CIOs are good in part because they can discern what’s opportunistic and strategic from what’s not strategic. Invest in what provides competitive advantage and outsource or ignore the rest.

How do good CIOs feel turning department managers away empty handed? The good ones feel awful. Good CIOs want to solve problems. They want happy constituents. They want to empower people to do their best work. Today’s WSJ article suggests that these new do-it-yourself application builders can help you avoid IT. Actually, if they work and they’re secure and relatively open, IT will be their biggest fans. If they work, nobody’s going to have to sneak them in at all.

And that’s where we bring this post back to the blist product vision. blist is in large part a response to the disappointment I felt as a CIO whenever I turned a department manager away empty handed. We’re building a platform that empowers department managers to easily solve their own problems, strategic or otherwise. But we’re doing so not in spite of IT, but from the premise that this is the do-all platform that IT would build if they had the bandwidth in the first place. Isn’t the best technology the solution that just gets out of the way and lets people get their job done without friction? That’s what we’re building at blist.

It’s a win-win. The department manager gets the perfect solution - designed for her and by her. The CIO gets what he wants - a happy department manager.

Focus on Customers not Competitors

In the last few weeks we’ve started to come out of our stealth shell. We republished our corporate website with a little more detail of what we’re building. We started blogging, sprinkling in a little of our product vision. We’ve started letting people give us their email address so they can receive alerts and be invited to try the beta version of blist when we’re ready for that.

Over the last few days an interesting thing happened. Some of the key folks at Dabble DB signed up for our alerts and to join our beta. I like Dabble DB. Of all the web-based databases - Trackvia, Quickbase, Zoho Creator, eUnifyDB, Caspio and a few others, Dabble DB has been the most innovative. Clearly we plan to compete with them when we launch, but that’s not the focus of this post. Some of the guys on the blist team asked how we should respond. Should we suppress them from our email list? Should we email their founder and ask him what motivated him to sign up? It provided the impetus for a good philosophical discussion.

I think startups focus way too much on competitors and not nearly enough on customers.

Here’s a real world example from our early days at MessageRite. Email archiving services are comprised of two functional areas:

1) A set of processes that parse email messages and store them in an archive
2) A user interface that allows people to search for and review messages

When we started building the MessageRite service, we figured out how to parse and archive messages. We really had no idea what the user interface should do. Sure we knew that it needed both full-text search and some kind of structured search (for example, “find all email messages from Henry Blodget between April 5, 2001 and June 14, 2001“) but we didn’t know what else it should do. We could have taken one of two paths to solve that problem:

1) We could have done what our competitors do
2) We could have asked customers to tell us what our application should do

We chose the latter, not for any grandiose strategic reason other than I enjoyed talking to customers and was a little intimidated talking to competitors. While competitors want to annihilate you, with customers there is a win-win equation somewhere to be found.

You might think it would have been awkward to conduct sales calls while not having a very feature rich user interface. We turned it into an opportunity. We positioned it as “the fist companies to sign up for our service are going to have great influence over how the application works.” You know what? Prospects loved the idea. Finally a vendor was listening to them. What we learned over the next few months is that all email archiving solutions in the market suffered from the same inadequacy - poor compliance workflow. All of these prospects-turned-customers told us they were suffering real pain in fulfilling the obligations of reviewing emails and satisfying discovery requests. So that’s where we focused and how we differentiated ourselves in the market. Within 6 months we went from zero customers to turning customers away (due to our bandwidth limitations). It was a nice problem to have - much better than having built another me-too product nobody wanted.

By focusing on customers, not competitors, you have a much higher probability of creating a product the market really wants and that’s the key to not only startup success, but professional satisfaction.

The Benefits of Working at a Startup

The press tries to stir up the notion that there’s an ongoing competition between big software companies (Microsoft, Oracle, Amazon, Google, et al) and startups for the limited pool of software engineering talent. While it’s true that good software engineers are needed by both mature and fledgling software companies, there’s such a distinction between the two environments that the perceived competition is overblown. This post is the first of many that will try to enumerate the differences. If you’re a software engineer, one of your first decisions is figuring out whether you are currently a better fit at BigCo or LittleCo.

A couple of weeks ago we started blogging and republished our blist corporate website. One of the enhancements we added was a way for people to sign up for announcements and early enrollment to our beta program, even though our application isn’t ready yet. Lots of people have already signed up, which is terrific. By the way, you can sign up too. Just enter your email address at the top of this blog post.

Yesterday Matt, our Online Marketing Director, sent an email blast to the subscribers of the list. Most of us at blist are on the list, so we too received a copy of the email. Paul, one of our phenomenal software engineers, quickly sent a note to Matt, me and the rest of the team, suggesting two enhancements to future email campaigns:

1) Fix the problem with line wrapping
2) Give recipients an unsubscribe link right in the body of the confirmation email, instead of merely telling them “you can unsubscribe at any time”

Paul’s suggestions were unsolicited and welcome. The changes were quickly made for next time. Paul spent the last three years at Microsoft. My reply to Paul, cc’d to everyone on the team, was simply

“You bring up one of my favorite things about startups. Everyone gets to wear a lot of hats. If something isn’t right, chime in and let’s work to make it right. Do you think the programmers at Microsoft get to influence email campaigns?”

BigCo can’t compete with the diversity of influence every individual has at a startup. Diversity of influence. We’ll call that benefit #1 of working at a startup.

Is there a lack of diversity of influence in your diet at BigCo? There’s still a couple of open seats at our table.

The Most Important Cost to Manage - Opportunity Cost

All companies, but especially startups, operate within the constraints of finite resources. Usually the two most precious resources are time and money. Web 2.0 has, in part, encouraged startups to bootstrap and has inspired them to revel in their thriftiness. The 90’s mantra to “get big fast” has been replaced by the more pragmatic exhortation to “get real.” Develop the core feature set and iterate quickly post launch. Sublease office space downtown and commute via public transportation. Buy used Aeron chairs on Craigslist. Use Skype for phone service. The list goes on.

Todays entrepreneurs have gotten real and are doing a great job of managing real cash - the green kind. What I’m not seeing though is strategic opportunity cost management and I’d argue that the success of a startup hinges as much on good opportunity cost management as it does on good physical cash management.

Let’s say you and your co-founder have pulled together $200,000 in startup capital. You each can afford to go without salary for 12 months, after that each of you need $5,000/month to survive. You are a pretty good coder. The other co-founder is an online marketing wiz and product visionary. It feels like you need two really strong software engineers to complete the team in order to launch your service six months from now and catapult your company to success. If you meet that goal, you think you can get revenues up to $25,000/month within 12 months after launching the service. What’s the real constraint in this scenario? What’s the magic number?

Most of you are probably looking for a piece of scratch paper or you’re opening up EditGrid to forecast cash flow out for 18 or 24 months. You’re looking at the wrong variable.

The magic number is 2. That’s how many really good software engineers you need to succeed. That’s the more critical constraint. Hire one mediocre engineer, and you’ve got only one bullet left in the chamber. Shoot that at another so-so programmer and you’ve just ensured failure for your startup. When you’re interviewing candidates, you should not only be asking yourself “is this programmer worth $90,000/year?” but as importantly you should be asking yourself “is this one of the two extraordinary programmers we need to succeed?”

At blist, we’ve been saving our last two bullets for a while. Are you one of those exceptional software engineers who is the difference between success and failure? If so, we’re hiring.

I’ve Wanted and Needed blist for a Decade

Most of us are list makers. Shopping lists. To-do lists. Wish lists. Honey do’s.

Back in the 90’s I managed a team of network administrators and network engineers. They were good at what they did, but not so good at remembering what to do and in keeping me up to date on their progress. I did what any technically inclined CIO would do - I whipped out Excel and created a template for a status reporting tool. But this was no ordinary status report. It had six or seven columns and about 4,000 lines of VBA code I wrote over a few evenings. That VBA code created a floating “Status Report” menu, brought in some cool status icons (Done, Not Started Yet, Blocked, Won’t Do, On Track, Slipping, etc.) and linked in hidden worksheets containing departments, employees, network engineers, cost centers, etc. to feed combo boxes in the main status report sheet.

My network engineers found that using this tool wasn’t too burdensome and even kind of fun. It was a really easy, visual tool for quickly updating status. They would send their sheets to me at the end of each week and I had some tools to filter them quickly to look for tasks that were blocking or slipping. It really helped keep the team cranking and me in the know.

As useful as the tool was, there were problems with this approach to solving problems:

* Not everyone can write VBA code
* The solution was very specific
* Collating the sheets from the engineers was painful
* Adding new tasks was a manual chore

    Excel alone didn’t solve my problem. It was the combination of Excel with VBA that worked for me because my background prepared me to code. The universe of people with problems is much bigger than the universe of people who can code.

    We’re creating blist to solve this and many other kinds of problems in an easy, powerful, flexible and generalized way. When blist launches, anyone can easily recreate my status report tool without any coding, without having to create status icons, without having to link data from other sheets, without having to collate and reconcile changes.

    The blist vision is a culmination of a dozen real pain points and real solutions for all kinds of real people. We’ll be telling more of these stories in the future.

    No Wiggle Room

    One of the best examples of the positive impact a confident leader can have on his team is a neat little vignette about Steve Jillings, CEO of FrontBridge Technologies before it was acquired by Microsoft in 2005. This was before FrontBridge acquired MessageRite in 2004, so I wasn’t there, but the story was shared with me by a few of the founders. In the early days FrontBridge was still only ten or a dozen folks and the founders were trying to persuade Steve to join as CEO. They were running out of cash and ongoing viability was a legitimate worry. The founders had been trying unsuccessfully to raise venture capital. While trying to recruit Steve, the founders were jointly conducting a group interview of him and one of them asked “If you had to place odds on your ability to raise venture capital, what would it be?” Without hesitation Steve instantly responded an emphatic “100%!”

    That’s what I call no wiggle room. The difference between 99% and 100% is the difference between “something will probably go wrong” and “guaranteed success.” It’s flying a plane with no parachute. It’s burning the ships when colonizing a new territory. It’s exactly the confidence the team needed from its leader and was the start of an impressive path to a very successful exit.

    One Buyer is No Buyer

    Between 1996 and 2002 I took a 6-year hiatus from the commercial software industry to try my hand as CIO of an investment bank. Specifically we did mergers and acquisitions - M&A. We represented the owners of mid-sized, privately held companies. Interestingly we didn’t represent ourselves when we were acquired by Smith Barney in 2001, but that’s a different story for a different day.

    Anyone can sell their own business. Many do. One of the value adds that we offered our clients was the ability to line up multiple potential buyers in parallel. We justified our handsome commission in part because we could create a competition among buyers for the company we represented. Our goal was to present the seller with three or four letters of intent (LOI) simultaneously. The simplest principle of economics is that supply and demand greatly influences price. So if you have three buyers and one seller, demand exceeds supply, so theoretically the price is higher or the terms are better.

    Without a pool of potential buyers, the one buyer negotiates against YOU instead of against the other potential buyers. The point here is that if you are an entrepreneur and you think it’s time to sell your company or time to raise capital (which is really just a partial sale), then you’d do well to heed the cry of the CEO of our M&A unit - “One Buyer is No Buyer!”