Author Archives: Fernando Pizarro

I’m an entrepreneur based in the Bay Area. I don’t take myself too seriously.

Group video – need suggestions!

So Cinecandy is about group video – basically creating a single video with clips from a lot of people.  We already are making things like wedding tribute videos (with best wishes from the bride and grooms friends), tribute videos (for birthdays and anniversaries), and more.  But it’d be cool to get suggestions for other kinds of videos we could make with clips from all sorts of people – all over the world!  Please respond in the comments section!!

Facebook FAILS at customer support w.r.t trademarks

There is a point at which an interaction with a faceless corporation becomes a lifesucking bane – and I’ve reached it.  As is usually the case with this sort of thing, I have to ask myself whether I should just let the matter drop, or escalate.  The hell with it.  Facebook – this problem is of your creation, not mine.

If you are reading this blog you know that I am in the process of starting Cinecandy, a cool little social/group video concept.  I have spent a ton of time developing the product, and am getting ready to launch.  I began preparations over six months ago, picking the name, securing the domain, the twitter handle, and the the Facebook fan page.

The thing is, when the fan page hit the requisite 25 “Likes,” I was still not able to claim the username.  It was unavailable, but no one was using it.

Facebook needs to figure out and communicate their trademark policy

I own the trademark, so I had recourse – or so I thought.

I filled out the trademark infringement form on Facebook and waited for a response.  Their response was come back in 60 days.

Specifically:

“we’re unable to process your request because another entity has made a previous request concerning this username. If you are still interested in claiming the username, please contact us in 60 days for an update about its availability. “

So, I came back in 60 days.  Still the page with the username is unused.  A second “come back in 60 days.”

“Unfortunately, this username is still unavailable.  Please feel free to check back with us again in 60 days, or you can reply to this email a different username that you would like to add to your account.  If you would like for us to look into adding an alternate username, then please also provide us with the relevant trademark information.”

WTF???  I might even be willing to pay the friggin’ squatter if I could contact them, but no:

“Unfortunately, we are unable to provide you with contact details for this other entity.  Please feel free to contact us again in 60 days, and we can provide you an update regarding the availability of this username.”

So my last email was a request for them to explain what their policy on trademark infringement and squatting is, exactly – because it is not posted anywhere.  I get back crickets.

I have now sent them multiple emails with what I think is a reasonable request – please tell me what your policy on this is – and not a single response.

Am I crazy here?  I own the trademark!  No one is using the damned username!  It’s not even FOUND when you go to http://www.facebook.com/cinecandy!

The complaint number is

#255038642

Anyone have any ideas?

5 Tips for Startup Outsourcing

Ok – so you decided to outsource because you figured out in my last post that you have enough money, know a good developer, and have a very clear vision for your product, among other things.  It’s not all over.  Managing an outsource relationship is not a hands-off thing.  It is far less forgiving than having a co-founder or an employee, and requires at least as much work, though the work tends to be skewed towards the requirements gathering phase and deliverables review.

Here are several things that I’ve learned along the way.

1)  Get a fixed price bid

I’ve heard this argument go both ways – hourly bids properly compensate developers and keep clients reasonable, fixed bids can lead to unexpected consequences.  To me it is clear, however – as the paying party your interests lay with a fixed bid.  Of course you should be careful – anything that sounds too good to be true is too good to be true.  But within the realm of the reasonable, a fixed bid protects you, and also incentivizes your vendor to work quickly – the longer it takes the less money he makes, after all.

2)  Spend twice as much time doing requirements as you normally would.

Successfully outsourced projects hinge on well written requirements.  There is no figuring things out on the fly.  There is no pending features queue a la Agile.  You need to figure out what you want built and define it at as high a level of granularity as possible.  Do this after you have paper tested, done your customer development, figured out your theoretical MVP parameters, and settled on your design.  Mock it all up – in detail.  I confess that I did not do as much work at this stage as I should have – and it definitely added both time and money to my final bill.

3)  Don’t be tempted to add features – MVP rules still apply.

This is possibly the most underestimated pitfall to working with an outsourced developer.  You will usually have arrived at a scope based on a set of requirements, and that scope will include a fixed price bid.  However, you will find yourself tempted to slip features in as part of the natural process of sharpening those requirements.  Don’t.  The issue with new features isn’t so much that they might cost you more (they don’t, necessarily), it is that they distract attention from the key focus of your product.  You should be as disciplined about feature creep when working with an outside developer as when you are managing your own resources.  If not more so.

4)  Schedule regular check ins.

Outsourced developers handle multiple clients and prioritize work, much as you do.  You don’t want to get put in the “difficult client” bucket by complaining all the time, but you also want to make sure that your vendor knows you are on top of things.  The best way to do this is to schedule weekly reviews during which you ask after the various aspects of development.  Because iterations are more widely spaced when you outsource, not knowing about a problem can have a larger impact when you only find out about it come deliverable time.  So, even if your developer is out of sight and out of mind…have a call and encourage them to talk about what they are doing.

5)  If you are not technical, make sure you get someone who is to review the product.

Presumably one of the reasons you hired your developer is that you do not know how to code yourself.  If that is the case, you are completely blind when it comes to the deliverables you get.  Beyond the obvious – things that are broken – can lay many issues which will cause you problems later – everything from non-standard implementations that subsequent developers will have a hard time with, to structural issues that will affect your ability to scale.  For this reason, you should absolutely get a friend or even hire someone to do a code review for you prior to signing off on the final product.

 

One way to think about the outsource relationship is that it hinges on the three variables that affect all development projects:  Speed, Quality, and Cost.  A fixed bid caps your cost, detailed requirements ensure quality, and regular check ins encourage speed.

Good luck out there!

6 Questions to Ask Yourself Before You Outsource

Since we’re getting close to releasing an MVP, I thought I’d do a couple posts on things I’ve learned over the past few months.  The first thing that comes to mind is how I got this far by using outsourced development.

Startup founders have a million different variables to fix in place in order to turn their vision into reality.  Most of those variables have no single best optimized answer, rather you just have to put a stake in the ground and move on.  Deciding whether or not to use outsourced development is just one of these variables, but it can have tremendous consequences for your business so it is a variable worth considering carefully.

While things may change with the current stockmarket downturn and likely cooling of the early stage funding market, the past year has been a hard time to find highly talented technical founders.  I spent about six months recruiting (including what I thought was a fairly successful Hacker News campaign, which I talk about here) but failed to find someone that had both the skills and personal fit I was looking for.  Was I too picky?  You betcha.  But then I knew that when I started interviewing, so I hired outsourced developers to code the first version early on.  Boy, am I glad I did.

Here are six questions you should ask yourself before taking the plunge:

1)  Can I build an MVP myself?

This seems obvious, but given much of the lore out there about business founders learning to code so that they can build their own product, it’s worth considering.  I do not know how to code, and my personal take is that while there is great value in learning enough to have an intelligent conversation in which I recuse myself at the right point, it’s not the best use of my time to learn enough programming to produce an MVP.  Opinions differ, clearly.  I thought a nice treatment of the subject was done by Tom Eisenmann at HBS.

2)  Do I have sufficient money, not only to get to an MVP, but a couple of iteration cycles beyond it?

This is an important one.  How much you spend on your outsourced development will NOT equal the agreed upon price for your initial set of deliverables.  Remember that the pattern for managing an outsource vendor is:  Define Requirements>Build>Change Order rather than:  Prototype>Feedback>Iterate.  You will want to change things.  It will cost you money.  And given that the rules about finding product market fit still apply – the ones that say that you have to tailor your MVP to the market, not the other way around – it will cost you much more to outsource than the initial price tag.  This isn’t a bad thing.  Just a thing.

3)  Do I know any developers personally whom I trust, or am I going to be picking one from scratch?

I was lucky enough to get a fantastic referral from a friend for a dev shop whose owner is based here in the Bay Area, but whose team is based in Russia.  I was familiar with their work and had a good sense for likely outcomes.  This confidence made it much easier for me to take the plunge.  In the time we’ve worked together, the relationship has been maintained personally here in the US, which has allowed us to get through the unavoidable rough patches.  If you are starting from scratch – don’t.  Get a referral.  Even better – get a referral from an existing customer whose business will be imperiled in addition to yours if the relationship goes south.

4)  Is my vision of my MVP clear?

I royally screwed this up.  I had two competing visions of what my product should be and ended up spending all kinds of time and money on design.  If you plan to use outsourced development, indecision is your enemy.  While this isn’t necessarily something I could have avoided by using a good mockup tool, I was certainly aware of the two options because I had to mock them up directly.  Here’s a good comparison of the tools you can use to get to your vision – but I think the larger lesson is:  settle on a very definite path to your first deliverable.  You’ll get to iterate – later.

5)  Do I have a clear sense of where I stand on the Speed/Quality/Cost tradeoff?

More money buys you better product faster.  You can make a crappy product quickly and cheaply.  We all live these tradeoffs – but knowing where you stand is hugely important in determining whether to go with outsourced development.  For instance, I have had several bad experiences with Elance developers when I chose the cheapest option, so I was happy to pay more for peace of mind regarding quality this time around.

6)  What are my prospects for finding a technical co-founder?

Finding someone qualified with whom you click is very hard.  But having gone through the process – if you can sell a co-founder you like and respect on your vision, you should.  Ironically I don’t think you should do this because of the drawbacks of using outsourced development, but rather because of the benefits of having someone to rely on through the tough times – an intellectual partner.  I quickly figured out that anyone worth talking to would want to see traction and that I would be very picky about who I jump into bed with.  Because I was new to the Bay Area, I didn’t have any friends who might have been game to join me on my quest.  My prospects, in other words, were bleak.

Of course – the upside to the way things played out is that a year later I do know people, and I’ve taken lots of risk out of the project by building an MVP.  Couldn’t have gotten here without the help of my friendly neighborhood outsourced developer!