Real Valley Stories: Nearly Quitting Over URL Structure

Editor's Note: Part 4 in an irregular series of stories from my 12 years in Silicon Valley. Part 1 discussed interviewing for my first job. Part 2 discussed the role. Part 3 talked about my boss getting let go while I was retained by the sister company.

At my second job in the valley, I had the title of Web Marketing Manager. It meant I owned the company's Web sites, including content, look and feel, search engine optimization, and more. Beyond that, given it was a startup, I did my unfair share of quality assurance, product planning, including my first marketing requirements document (MRD), which was terrible, and even picked up the phone to answer support calls when they cascaded to me. The company initially started out selling a web-based fax service, which was the majority of revenue for the entirety of my two-plus years there, but that line wasn't particularly sexy, and it wasn't the end goal, as we later rolled out a Web-based phone conferencing service, with Web meetings and advanced desktop sharing. The eventual goal was a suite of Web-based office products for remote workers and Web-centric employees. We were probably ahead of our time, and understaffed, but in the later stages of the dot-com boom, we were scrappy and we tried to do a lot with miniscule budgets.

After much testing, we readied the launch of our Web conference calling product in January of 2000, called PhoneCube. The application had gone through all manner of review on all the top browsers of the day, and it was good to go as far as version one was concerned. So too was all the copy for the Web site, including frequently asked questions, product overview, pricing tiers, and all manner of screenshots, complete with fake names and phone numbers. As we readied launch, my colleagues and I uploaded the new content to a test server and started clicking around to make sure all the links worked, images displayed and so on.

Immediately, as I clicked through to the product page, something caught my eye. The page loaded as it should, but the URL structure was not what I'd expected. I anticipated that clicking on Products would lead to a clean URL like www.phonecube.com/products or at worst, www.phonecube.com/products/index.html. Instead, the URL had an additional directory which looked like www.phonecube.com/phonecube_site/products/index.html. What was this "phonecube_site" deal? So I went to my boss and asked, saying we could easily make a soft name alias to hide the unnecessary and ugly directory. The two of us then went to the lead engineer on the project, who, folding his black and gray beard upward toward his lower lip as he talked, explained that this was impossible.

What had happened was that our Web site and our application were running on the same server, in parallel directories, with the phonecube_site directory showing the Web site and the phonecube_app (or some other similar name) directory powering the application itself. All of the calls to images and other code in the application had hard-coded URLs, so masking the phonecube_site directory would require dramatic work to the app itself, and delay the project.

I was incredulous. I thought the new URL structure was ugly, and it was something all our visitors would see as they clicked around our site. It would be ugly to link to, ugly to share via email, and made us look bad. In response, my boss (the VP of Marketing) said that many popular Web sites on the Internet, with Amazon being the clearest example, had ugly URLs, and yet they were successful. I thought the excuse that other sites were worse didn't really make us better. As far as I was concerned, the URL was as important as the words on the page, and as I argued my case, I started to feel that if the Web Marketing Manager who theoretically owned the Web site couldn't even have impact to how the URLs would be displayed, that my role was pretty much toothless.

After much discussion, with my viewpoint clearly being in the minority, I had to cede the position. My vain request for clear URLs that were as human readable as machine readable didn't persuade my team, and I was going to have to live with it. This realization that I could not even convince my boss to back me up on something I thought was so clear and obvious was incredibly frustrating, and I remember driving home that night, late, fuming, thinking I should just quit if I couldn't even stand up for our users and common sense. But, luckily, I decided to display a rare moment of maturity, and I came back the next day and went to work. I don't know that my boss or colleagues realized how seriously I took the fight and how I had seriously considered leaving, my powerlessness being made so transparent.

Since that time, URLs have clearly gotten uglier, and most folks have survived. I've had other conflicts at other companies, and haven't always gotten my way. Sometimes the frustrations are short-term and others long term, but what the episode did show me is that no matter of ranting and raving can push people who are certain they are right, especially when the benefits of change don't outweigh the drawbacks. I've seen other people try to hold fast to a hard line on other little things like fonts, graphics, logos, splash pages and more, where exercising a little flexibility and respect for the other person's point of view can do wonders. But back when I was only 22, getting shot down and losing a product decision I thought critical was demoralizing indeed.