Startup Advice – Own Your Domain

Posted by Kevin Merritt on September 28th, 2007

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

Posted by Kevin Merritt on September 27th, 2007

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.

Avoiding the IT Department

Posted by Kevin Merritt on September 24th, 2007

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

Posted by Kevin Merritt on September 24th, 2007

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

Posted by Kevin Merritt on September 20th, 2007

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

Posted by Kevin Merritt on September 19th, 2007

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

Posted by Kevin Merritt on September 18th, 2007

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

    Posted by Kevin Merritt on September 16th, 2007

    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

    Posted by Kevin Merritt on September 15th, 2007

    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!”

    Startup Advice – Host an Inception Mixer

    Posted by Kevin Merritt on September 13th, 2007

    Some startups agonize over finding good software engineering talent. Here’s an idea that worked well for us at blist and it might work well for your startup too.

    In February we started drawing up sketches and narratives of what blist is and what it would become. To turn these diagrams into a working service, we needed a few really good software engineers. By now hopefully you know one thing that all programmers love is free food! We scheduled what we called an “Inception Mixer” for the early evening of Friday, March 2. Then for the rest of February I networked, recruited and met with as many qualified candidates as I could. I conducted an informal, introductory meeting with each one. In that meeting I painted a little of the vision for blist and told them we’d be hosting an inception party to share more details. It was by invitation only. Good engineers only. We arbitrarily set the limit at 20 guests.

    Leading up to the event on March 2, a real frenzy started happening. Software engineers heard through the grapevine that we were a “startup to watch” and they wanted to come, too. I told them the event was by invitation and for qualified engineers only and asked if they could meet me for an informational discussion. That last week leading up to the event I met with another 12 or 14 engineers. One local reporter, two VC’s and one distinguished local entrepreneur all got wind of the event and asked for an invite. Nope. It’s by invitation and only top notch engineers are invited.

    We rented out the back room of a pizza restaurant. I told the restaurant folks to keep the pizza and salad coming and the beer flowing. I brought a half dozen bottles of wine from home.

    The event was a huge success. We had about 30 engineers show up. Believe it or not I ran through a 179-slide presentation in less than 15 minutes in a style that would make Dick Hardt of Sxip proud. We unveiled our logo, about the only thing we had to show that we existed.

    The event worked great in a few ways:

    1) An artificial deadline forced those we’d already interviewed to act. We actually hired two engineers before the event, including one at 4:00 p.m. the day of. The enticement was “c’mon, you know there’s going to be some really strong engineers there who are going to get really excited. Don’t you want to be employee #1? Wouldn’t it be great to introduce you to the crowd as the guy with the courage to jump in?”

    2) The event fueled the fires of the others to make a declaration. The event ended around 10:00 p.m. and between 10 and 4:00 a.m. I received 6 emails saying “I’m interested. How do I go to the next step?” 30 engineers are smart enough to recognize that a startup can maybe swing hiring a few of them. It created a reverse auction for the few slots.

    3) It filled our long term recruiting pipeline. A good 1/2 of the engineers left there excited by our vision, but didn’t have the stomach lining to have an employee # less than 10. A growing company needs good engineers at different stages and it requires very little effort to ping these folks every 6 weeks or so to check in.

    The entire night cost us about $300 – way cheaper, way more effective and way more fun than hiring a headhunter. If you’re starting a company and need good software engineers, think about hosting an inception mixer.