Bryan Marble


June 17, 2011

What if you had a decade to live?


At some point in your life someone has probably asked you “what would you do if you had one day to live?” At which point you wrack your brain coming up with all of those little experiences you would want to pack into those 24 hours. You’d probably quit your job and spend as much time as possible surrounding yourself with friends and family. You’d spare no expense (and perhaps loads of debt) trying to check items off of your bucket list. We would throw our responsibilities to the wind and focus on pure fulfillment. Fulfilling small dreams, fulfilling promises, fulfilling selfish desires.

It’s an interesting cocktail discussion perhaps, but usually inconsequential. The odds of that scenario playing out are so unlikely that we toss it aside and continue on with our day, understanding that it’s not likely our last.

After reading this post by Derek Sivers and after receiving some terrible news about a friend, it lead me to wonder…..what would I do if I had a decade to live? Not a day. Not a week. Ten years.

I think that changes things drastically.

A lot can happen in ten years.

What would you change? Would you spend the next ten years in the same job? Maybe? Maybe not? After all you’ll need to make ends meet, but without the prospect of needing to save for retirement or to build a career, what would you do differently?

Who would you spend time with? Would you spend your time on facebook each night engaging in passing conversation with folks you’ve only briefly met? Or would you make a concentrated effort to visit friends and family in person, knowing with a little more clarity that each visit could be the last?

What would your legacy be? Do you want to change the world? You can change the world in ten years. Do you want build a family? You can build a wonderful family in ten years. Do you want to see the world and take it in, leaving nothing but footprints? You can do that too.

What would you do?

February 9, 2011

Push Perfection to V2.0


Here’s my scenario. I’m a perfectionist. I can find flaws in any design and especially mine. Which makes it excruciatingly scary to think about releasing this product into the world for other perfectionists to critique. And that thought has colored every design decision I’ve made in the last month. It’s slowing me down. And since “every moment you’re working on something without it being in the public it’s actually dying” (Matt Mullenweg), it’s time to cut the dead weight.

ImperfectI spent about 30 minutes writing down the ideal design; the design and the functionality that I would have in a perfect world where I have a couple of brilliant designers and engineers, infinite time and money, and while we’re at it, a beachhouse/office. Since I have none of those things, I took a picture of the notes, threw it an Evernote entitled “GroupTrip 2.0″ and forgot about it.

Now, every time I think about a potential redesign, instead of letting my mind wander to how I’d implement it and debate whether or not it’s worth it for the initial release, I just throw it in that note and get back to pumping out the last bits before launch.

Every new feature is an untested assumption that I know what the user wants. Since I’m already doing enough assuming for my Not-So-Minimal Hopefully-Viable Product (NSMHVP), I feel comfortable throwing those feature ideas into “two-point-oh”, and letting actual users drive which features eventually get implemented.

And my favorite tweet of the week comes courtesy of Tristan Kromer (@TriKro) “‘Anything worth doing well is worth doing poorly at first.’ – Anonymous”

February 2, 2011

How to Land a Dream Dev Job Without Web Experience


This presumes that your dream dev job involves working at highly competitive startups (or forward thinking behemoths). If your dream job is writing code in the relative obscurity security of a huge, slow-moving company with great benefits and little risk of having to do anything meaningful, then this isn’t for you. If you want one of those, just put Ada on your resume, you’re a lock.

No, this is for those like me, who took that secure job coming out of college because it was a great job by parents’ standards. Unfortunately that meant spending my formative years in waterfall development, falling behind on the latest technologies and being bored beyond belief. Don’t worry, it doesn’t have to end like that. I don’t care if you’ve been there 6 months or 6 years, if you’re reading this article, it means you care enough to get out. Here’s how to do it.

  1. Find Companies That Select For Smarts, Not Stacks

    Smart companies know they can’t rely on finding developers that know their stack in and out, they’d be wasting precious resources reaching out to those folks. Instead, the better ROI is to search for really smart engineers that can adapt to whatever technology is thrown at them. There isn’t a really simple way of finding those companies, but you might be able to tease out that info with a little google stalking. Search for the founder or CEO on google with keywords like “hiring” or “finding talent”. Many founders are asked the question about finding talent and if you’re lucky you can learn a bit about their hiring philosophies.

  2. Show The Effort

    You need to show you’re dedicated to making the switch, that you’re trying to learn on your own in your spare time. You may not know the innards of enterprise web development, but you better know the basics of software design and computer science. If you can’t explain why the seemingly-simple Twitter is a scalability nightmare, or how you would go about implementing a basic web-crawler you need to read up.

    If you haven’t worked in web development much, well, you need to get a crash course. Pick a framework, any framework, and build something. It could be as simple as an application that allows you to write notes for yourself. The point isn’t to build a crazy app, the point is to start learning the pain points of web development, because there are certain problems that every developer faces. Problems like version control, automated testing, browser compatibility, url routing, database optimization, etc. Unless you can appreciate the problems (if not solve them) you can’t hope to convince a fellow dev to hire you.

  3. Push Your Adaptability

    Show that you can come up to speed quickly on new technologies. In your resume and cover letter, highlight the times that you’ve been able to adapt to a new codebase, a new team, a new tech. These abilities are as important as your ability to write a decent line of code, and they’re especially crucial when switching industries.

  4. Market Yourself

    Your resume is not enough. Update your LinkedIn profile, get some testimonials, join groups centered around web development. Get involved on sites like StackOverflow. Even if you’re answering a question about VBA.NET macros, it’ll show off your thought-process and your coding chops (you do have those right?).

    Once you’ve contributed, make sure your resume lists your LinkedIn or StackOverflow profile to make sure all of that hard work gets seen.

  5. Research, Research, Research

    It’s a long hard road to learn a whole new programming paradigm on the fly. Make sure the company you’re applying to excites you beyond the simple tech or you’ll risk getting burnt out. Does their vision align with yours? Don’t know? Get out there and read about the company, the founders, the current employees. If they’re a forward-thinking company, that information won’t be hard to find. If you find your eyes glazing over when you read about the founder’s vision, just think how much uninspiring that will seem when you’re knee-deep in code you barely grasp.

  6. Kill the Phone Screen

    Many companies, particularly the competitive companies you want to work for need to screen their applicants for a basic set of knowledge before they burn resources on an in-person interview. They’re not looking for brilliance, they’re looking to make sure you’re not an idiot. Check out Steve Yegge’s phone screen questions. This is a must read for any prospective developer. Now it’s likely that those particular questions won’t be asked, but those types of questions should not be hard. If you think you’d have trouble, it’s time to do a little more research.

  7. Prepare to Make an Impression

    Not only should you be able to ask intelligent questions about the company you’re looking to join, but you should be genuinely interested enough to ask them. If you don’t care about the direction the company is taking or the product development process implemented at the company, the company probably isn’t a great fit.

  8. Finally, The Interview

    Once you’ve gotten this far, you’re pretty much on your own, but I’ll leave one final piece of advice. Have fun. That’s right, you’re going to be asked lots of questions you probably can’t just BS your way through. You might struggle a little. You might even think you’re in way over your head. Just don’t give up. If you get the job, you’re going to be in that position a lot so have fun with it. Ask intelligent questions, try to find the best answer you can. I even went as far as to ask what the actual answer was once we were done. If you show you can tackle a difficult situation with fundamental knowledge, some grace, a bit of humor, and a whole lot of humble pie, you’ll probably fit right in.

That’s it. That’s how I went from a behemoth defense contractor to a web startup. If you have any questions or additional advice, drop it in the comments. And as always…

If you liked this one, follow along with RSS or Twitter!

January 25, 2011

Productivity Hack for Bootstrapping a Company on 2 Hours a Day


Here it is, the single greatest productivity hack I’ve learned while building GroupTrip.

Perform a mental backup before you stop working.

Take 30 seconds in your editor of choice and write down what you would be doing for the next 15 minutes if you didn’t have to stop.

When you come back to work, you have an instruction sheet that you can immediately tackle without having to think.

If I sit down at my laptop from scratch, it often takes me about 20-30 minutes to get in the zone development-wise. I have to remember where I left off, what I was doing and load all of the pertinent info into my head before I can pick up where I left off. If I only get an hour or two at a time to work on a product, that means anywhere from 30%-50% of my time is wasted just getting to the point of being productive. Ouch!

This is kind of a micro version of Marc Andreeson’s write three tasks before you go to bed except instead of writing the major things you want to accomplish in the next day, you write down just enough detail to get you back into the frame of mind you were in before you stopped.

It takes 30 seconds and easily saves me 30 minutes of dev time a day. Not a bad ROI.

Your turn, what keeps you productive working on your side project?

January 18, 2011

Clear.CO or Cntortd.COM – Split Testing a Domain Name


I’m building a group travel platform to make the logistics of planning trips with friends as fun as the trip itself. I had a great name for it too. Since that was taken I started building under the name GrpTrp. It has symmetry, it’s relatively easy to describe (“grouptrip, no vowels”), and hey, I’m bootstrapping a proof of concept, I can’t be spending thousands on domains.

After listening to Jason Calacanis gush over .CO on This Week in Startups, I realized, you know, maybe I can have my cake and eat it too. The name I wanted with a big ole heaping of cash I can spend on more important things. Before I went through the effort of rebranding (while easy given I haven’t launched yet, still, it’s time I could be spending finishing out the beta) I thought I’d try to get a little data first. So here we go, the story of the vs the


My first concern with the was that users wouldn’t trust the domain. After all, outside of tech circles people still think of renegade Russian hackers when they see anything other than .com, .gov or .edu. Or so I thought. To find out, I ran two advertising campaigns (on Facebook) with the hypothesis that the Click-Through-Rates would skew towards the domain users trusted more.

The first campaign pitted the exact same ad copy with the only difference being the domain that was displayed by the link. In my case, “” vs. “”.

Ad Impressions Clicks Conversion Rate CPC 196,684 27 0.014% $0.83 143,583 28 0.020% $0.80

While it looks like the ad performed a bit better than the ad did, we can’t say with statistical significance that will always be better than However, it’s pretty clear that at the very least, doesn’t perform worse than, so the idea that folks don’t trust .co is pretty well bunked.

Just in case you’re not convinced, I ran a second test. This time the heading of the ad was the domain name (“” and “”) to draw a little more attention to it. The body remained the same, and the URL at the bottom of the ad matched the URL in the title. Here were the results:

Ad Impressions Clicks Conversion Rate CPC 141,374 29 0.021% $0.78 114,388 30 0.026% $0.73

Again, we’re not statistically significant, but through two tests covering almost a half a million impressions, it’s clear that the .co holds it’s own against, and perhaps beats out, the .com.*

*Open Kimono Note: One factor that might have influenced this test is that the logo displayed for the ad was the logo for GrpTrp. This may have actually held the numbers for the .co down as there was dissonance between the logo and the product name. I would’ve gone for an ad with no picture, but I had ad-block on and didn’t double check it before running the test. Mea culpa.

So it seems clear that users will click at a similar rate when presented with a vs a, but once they do, can they tell their friends about it and spread the word?


A common back-of-the-envelope suggestion is to see if your name is spreadable is to see if you could say the domain over the phone and have people understand exactly what you’re talking about. I would argue that that’s necessary, but not sufficient. Here’s how I came to that conclusion:

My original reason for choosing was that I could describe it as “it’s with no vowels.” I figured, if it worked for a company like SCVNGR then, hey, why not? Here’s why not. Search in google for scavenger. SCVNGR is nowhere to be found. If you go to page 2, you’ll see a sponsored ad asking if you meant SCVNGR, but guess who’s paying for that one? You think a one-time domain name expense is tough, try the recurring expense of running a sponsored ad every month until the end of time.

The point is, SCVNGR has made it work, but at what marketing cost? If you can’t afford the domain, you certainly can’t afford the marketing costs of overcoming an unsearchable domain. Make no mistake, SCVNGR is becoming a very successful company, but they’re doing it in spite of their name, not because of it.

Alright, back to the analysis…

To figure out which domain would be more spreadable, I broke out the mother of all ghettopreneurship tools – PickFu. For the uninitiated, PickFu uses the power of Amazon’s MechanicalTurk to get users to pick between two alternatives and provide reasoning for their choices. It’s quick, it’s dead simple to set up, and perhaps most importantly, it’s cheap ($17 for 200 responses).

Here’s the questions I asked:
Given the following descriptions and their associated addresses, which would you be more likely to remember and use?

The overwhelming answer was that people preferred the You can see the full responses here, but here’s a summary. The majority of the responses mentioned that the extra thinking involved in vowel-removal would make them less likely to remember the name. And guess where people go when they can’t remember the exact name? Google. See above.

Survey says wins 79% to 21%

Still, the responses that tended toward were largely due to people not trusting a domain. Over time I’d say that this sentiment will go away, but it’s there. One thing to consider, at least with .CO, is that .CO will be running Super Bowl ads this year a la GoDaddy, so that might make a big dent in fixing the legitimacy concerns with .co. time will tell.


As always, there are holes in this “study”, but I think the data is strong enough for me to make the move from to I think we’ve reached a trend of diminishing power for the .com TLD, and .CO is exacerbating that trend.

As always, I’d love to hear your criticisms and suggestions for further study. Of course if you want to leave a supportive note, that’s cool too :-)

If you thought this analysis is worthy of a little more discussion, retweet it and make your mark in the comments. And follow me at @LostMahbles.

January 7, 2011

5 Things You Need to Forget When You Join a Startup


A few weeks ago Mark Stephens wrote a guest post on OnStartups about the benefits of gaining experience at a large company.  Having worked at a large company, and having recently left said company for the startup world, I have to agree with much of what Mark says, but I think we need to flip the coin as it were.

It’s true that there are some benefits to pull from working at a large company, but there are also some seriously bad habits that can really impede your progress and your impact at a startup.  Here are five mantras you need to forget if you’re leaving a big corporate job for the startup world:

  1. That you need to ask for permission first.

    At the very first training session at HubSpot, we were told in no uncertain terms, “Beg for forgiveness rather than permission.” If you’ve been hired at a (good) startup, there’s a reason. The powers that be have deemed you competent and they trust you to do the right thing. Sure there will be mistakes, but mistakes pave the way for innovation, and startups are dead in the water without it.

  2. That you need to put in your time before you can make an impact.

    In the startup space, you need to make an impact NOW. If you’re not making an impact, your job could and should be replaced by someone overseas that will work for a fraction of what you will. You were brought on to push the capabilities of the company, not (just) to pump out code.

  3. That you’re here to work, keep your personal life at home.

    This was particularly jarring for me, as I’m a staunch introvert, but in a startup, everyone knows everyone’s business. This isn’t because startup folk are nosy, it’s because you interact differently with friends than you do with coworkers. And startups need employees to be friends. You trust friends. You do favors for friends. You push friends. You can make mistakes around friends. All of these traits help you do more faster.

    Being friends requires social interaction, a give and take, and likely a few yo-mama jokes. Don’t fight that. Embrace it. When the company grows you’ll miss it. So rather than spending lunch pumping out a few extra lines of code, go eat with your new friends.

  4. That you love/hate process.

    Regardless of whether you love or hate the processes at your big company you need to rethink your position. If you love the process at a big company then you’re going to hate the freeform day-to-day workings of a startup. If you hate the process with a passion, and you’re hoping life at a startup will be a do-whatever-you-want free-for-all then you;ve got another thing coming. Startups often shun process to innovate, but as they grow process is necessary in order to scale.

    It’s your job to delineate between the processes that can reduce time-to-market and the processes that stifle innovation and kill employees’ sense of autonomy.

  5. The phrase, “That’s not my job.”

    The Cleaner
    When a problem comes up at a big company, it’s often easy to say “Well, that’s not my job, it’s someone else’s job to handle that.” In fact, all of the extraneous process at big companies is designed specifically to make sure that problems are caught and directed to the responsible parties. Whether or not it actually accomplishes that end is a debate for another day, but at a startup, that process infrastructure likely won’t exist. You are the process. When you find a problem, your job description instantly changes from developer or CEO to “cleaner”. Like Harvey Keitel in “Pulp Fiction” it’s your job to get rid of those technical dead-bodies before your customers find them.

I’ve had to relearn all of these in my transition at HubSpot but they’ve been extremely valuable lessons. If you have any other tips leave them in the comments!

January 5, 2011

Phone Number UX: 3 Solutions to Avoid Pissing Off Would-Be Users


The standards for UI/UX are being raised every day. There’s simply no excuse for piss-poor user experience anymore. One example of an unacceptable experience that somehow seems to be sticking around is that of the phone number field. Before you consider making a field that takes this information, please consider the following:

I don’t want to give you my phone number. And if you happen to have worked hard enough to gain my trust to the point I’d give it to you, don’t screw it up. Just asking for it puts you on thin ice.

How would you screw it up? By giving me one iota of a chance to reconsider. If I have to do anything more than select a text field and enter 10 digits in succession, I’m sorry, you don’t get my business.

The phylum of acceptable phone number fields in order of preference.

  1. None. You probably don’t need it anyways!
  2. A single text field that would accept 888-867-5309 or 8888675309 or 88-86-75309, etc
  3. The triple threat, three text fields with auto-tab

Any other solution makes me wonder whether you care about the pain points in your application. And if this seemingly simple and avoidable pain point is overlooked, what hope should I have for the rest of your application?

November 5, 2010

Read Less Faster


When you’re just looking into building your own product/company, you don’t know anything. That’s not an exaggeration, and it’s not a problem, it’s just reality. There is so much information and so many things to do that you can’t possibly know it all. In fact, if you did know what was in store for you, you’d probably run screaming back to your cubicle and cling to its neutral-fabric walls.

There’s a ton of information out there. Do your diligence to know the basics. Read Paul Graham’s essays. Immerse yourself in Derek Sivers‘ insightful and inspiring blog posts. Check out Seth Godin, and Fred Wilson, and any number of other amazing resources.

Yes, read everything you can get your hands on. At some point you’re going to realize that half of the advice out there contradicts the other half, and that those nuggets that seem to be universal are so broad as to be rendered useless to a single developer. At some point you have to force the noise to the background and build your product.

I took too long to realize this, so here’s my advice to add to the pile:

Read a bunch, get up to speed, but get building…now.

June 7, 2010

Everything Takes Longer


So we’ve “pivoted” (still getting used to the word) away from SkierUnderground for the time being, and while I have a little bit of time between projects, I thought it apropos to reflect on what happened over the last three months and extract some tidbits to take forward. I was going to write them all down here, but it got a little lengthy, so I’ve made it a series.

SkierUnderground – Lessons Learned

Everything Takes Longer

Everything takes longer than you think it will. Over time, you’ll get better at estimating, but when you’re starting out everything takes multiple times longer than you thought it would. The trouble is figuring out what that multiple is.

As a SW engineer with 10 years of programming experience and a masters degree worth of theoretical computer science under my belt, I can pick up the general ideas behind just about any web technology. What I’ve learned is that it’s the specifics that bite you in the ass.

For example, when I first saw the Yii framework, I thought, “Hey it’s PHP (a language I have a lot of experience with), it’s object oriented (my bread and butter), and much like Rails, it’s an MVC architecture that favors convention over configuration.” Every one of those concepts, I have experience in. “Piece of cake!”

Not quite. Every technology has little nuances that have to be navigated. Every day there’s something you didn’t plan for eating at your development time.

I don’t know whether it’s because I’m generally an optimistic person, or because I truly didn’t realize what I was getting into, or even that my excitement over the project led me to believe that I’d be able to accomplish magical things with respect to productivity, but I was off. Not just off, WAY off. Two to three times off!

There were so many little tasks along the way that I didn’t anticipate. And for the most part, they weren’t things I should’ve expected myself to anticipate. The thing is, you just don’t know. Every day is a gargantuan learning experience, and even having immersed myself in development for three months, I’m still learning every single day. In fact, a lot of those little lessons are so simple, yet so mind-blowing that I wonder how it is I called myself a developer (or entrepreneur) having not known them.

With all of those unknowns out there, how can I expect to ship on time? I estimate.

I take into account that I’m overly optimistic, and I take into account that unexpected problems will arise, and I take into account the fact that my initial estimates usually only include the minimum for getting something to work, not to put the required polish on the new feature before shipping it.

Your mileage may vary, but I look at each task and say to myself, “With 85% confidence, how many hours will this take?” and save that number in my head.

Now, if there’s anything in the process that I haven’t done before, if I have to learn a new API, or need to try a new jQuery technique, I take my estimate and triple it.* That’s my number. Even if it’s something I’ve done before and I can’t see any potential gotcha’s, then I still double it.

*If I have to do anything related to layout in IE, I square it :-)

That’s my system, and from a project management perspective, I’d say my SPI is just over 1.2. That’s saying I’m overperforming my estimates. But again, that’s just a guess.

Going forward, I’ll be tracking my tasks more carefully so that I can track a more exact SPI value and adjust my estimating capabilities so that I come in on target. The goal isn’t necessarily to go faster (that’ll come on it’s own), the goal is to build my learning curve into my estimation so that I can hit deadlines and ship features as expected. It’s a bare-bones implementation of Evidence-Based Scheduling.

My lesson going forward is to track my productivity and use it to plan for the unexpected. There’s nothing worse than missing a deadline. You feel like a failure (and if you don’t, I’d argue you’re in the wrong business). You feel demoralized, and you’ve deprived yourself of the opportunity to build momentum with the “small win” of hitting a milestone. Don’t set yourself up for failure by being overly optimistic. Track it, and start being realistic.

June 3, 2010

Start From a Solid Base


So we’ve “pivoted” (still getting used to the word) away from SkierUnderground for the time being, and while I have a little bit of time between projects, I thought it apropos to reflect on what happened over the last three months and extract some tidbits to take forward. I was going to write them all down here, but it got a little lengthy, so I’ve made it a series.

SkierUnderground – Lessons Learned

Start From a Solid Base

They say that a downturn in the economy is one of the best times to start a business. Tough times force smart entrepreneurs to be lean, to make creative decisions to make due with what they have. Tough times prevent companies from being overfed with capital, and spending that money on people they don’t need and $1000 office chairs to sit them in. – see Bubble, DotCom.

Another symptom of the downturn is that big companies start pinching pennies, and employees start reading articles like this one and think “Oh boy, I can leave my job where they only gave us a 1% raise and make millions on a startup.” Doesn’t work that way. If you’re running away from your old job, just stop. The grass isn’t always greener, and the bills don’t go away just because you think you came up with the next social networking phenomenon (“But it’s like Facebook, for dogs…or backcountry skiers!”).

Make sure when you jump into the new business, that you’re doing it for the right reasons, and not out of emotional desperation*. Don’t rush into it with the thought that starting a company will fix all of your problems. If your work-life balance sucks now, believe me, it’ll suck worse. If you’re out of shape and can’t seem to find time to get to the gym, well, it doesn’t get easier. That doesn’t even begin to take into account things like personal relationships or mental health.

*Desperation in itself isn’t bad, in fact it’s downright motivating, but when you’re desperate and overly emotional, you start making decisions from the wrong places, and when every decision counts, that’s not the place to be.

In reference to the manic-depressive, entrepreneurship roller coaster that Tim Ferriss describes in this eerily accurate post, it’s a scary, gut-wrenching ride.

Do yourself a favor. Before you get on, give that roller-coaster the strongest (mental, physical, emotional, and spiritual) base you can. You’re going to need it.

Older Posts