tag:sachinagarwal.com,2013:/posts Sachin Agarwal's blog 2024-02-23T14:04:00Z tag:sachinagarwal.com,2013:Post/1363024 2019-01-13T22:52:33Z 2024-02-23T14:04:00Z Solving Problems For the Right Beneficiary

As a product manager, your job is to identify problems to solve, do some prioritization, and ensure that you solve them as fully as possible, given the resources and constraints of your organization.  (To be super explicit: the best solutions aren't necessarily delivered as new features.)

In enterprise product management, you often have multiple constituencies that you need to solve for.  Attention must be paid to all of them to keep both customers and the team happy.  In my mind, when you're choosing problems to work on, you should be explicit about whose problem you're solving.  I use the term "beneficiary" to denote for whom or for what I'm solving for.  Here are the most common beneficiaries:

* The user. 

The user is an individual human.  In consumer, the user is the customer and is the only thing that matters.  In enterprise, there are often many different kinds of users - some users aren't even end users of your product: they're administrators or finance folks.  Even within end users, there can be many different kinds of users.  Some delineations are: novice and expert users of your product, end users with different job roles or responsibilities, or folks in different geographies that have different contexts and capabilities (iOS versus Android, slow connections versus fast connections, etc.)  

If you have different kinds of end users, the best way to have a quick way to be specific about who you're solving for is to go through a persona exercise.  Individual (and team) personas can be incredibly helpful to make sure that you can shorthand a set of motivations, problems, capabilities, and limitations for end users.

* The customer.

Again, in consumer, the user is the customer - the person who pays.  In enterprise, the customer can be one of many folks: an IC putting down a credit card, a manager authorizing a purchase, a procurement department that will "right size" the offering to be bought.

At scale, if the person paying isn't the person using the product, you're going to have to do affirmative work to prove to the purse-strings-holder that you're delivering value commensurate with the price being paid.  Fun note: this work often helps lead to step-function expansions in deal size.

* The system.

Sometimes you're going to solve a problem that makes your system more reliable, available, resilient, or performant.  For example, work that makes it easier to scale (either horizontally or vertically, your choice) or lets you increase placement (standing up an EU region is the most common example for US-based startups targeting EU-based customers) has "the system" as the beneficiary.  To draw a line in the sand, this work will have no user-facing changes in the experience of a working application (with the exception of decreasing latency).  Solving for the system is also different than solving for...

* The team.

Sometimes you will solve a problem that is borne by your internal team - perhaps your developers, your sales team, your support team, or any collection of groups of folks inside the organization.  Solutions often end up automating manual processes or making it easier to make changes to the product.  Solutions can include everything from new ticketing systems, string repositories, cron jobs, documentation, full on code reorganizations, and just hiring a bunch more people.

* The business.

Lastly, problems that are borne by the business are generally problems where the outcome is either "increase revenue" or "reduce costs".  These are where the value you are creating is almost entirely captured by the business that offers the solution.  Being intentional about pricing and packaging helps immensely on the revenue side; sadly, there are often no real alternatives to large infrastructure projects to make reductions on the cost of goods sold (COGS) side.  

You may also find that there are other classes of beneficiaries that your organization needs to consider - that's fine!  Being clear and up front about which beneficiaries you are serving will allow you to make much better prioritization and sizing decisions as a product lead.

]]> tag:sachinagarwal.com,2013:Post/1360884 2019-01-07T03:59:54Z 2024-02-23T13:50:07Z Product Management Is Not Just About Creating Value, It's About Capturing Value

Traditionally, when people think about the role of a product manager, people generally talk about working with a cross functional team (usually engineering, design, and data science) to deliver value.  I've come to believe that is necessary but not sufficient.

As a product manager, your day-to-day work is some combination of gathering information, synthesizing it, sharing it, and helping others make better decisions collectively.  When this work is only about delivering value to the user, the PM has not done a complete job.  Many times, the right problem to solve or the correct thing to build is different based on the organization's ability to capture the value that's created.

This is why PMs need to pay so much attention to pricing and packaging when thinking about prioritization.  If your current go-to-market strategy or your current pricing structure won't allow you to capture the additional value the proposed project would create, it's absolutely not worth prioritizing that project until you fix your GTM and/or pricing strategy first. 

For consumer/prosumer/SMB products, the value you're creating is often on one axis - access to songs for Spotify, access to the people you care about for social networks, storage space for Dropbox, and "store of information" for Slack, to name a few(1).  In the enterprise, there are often many different axes of value, some of which may pose tradeoffs to either the user or to the customer.  In these cases, having the value capture conversation before building anything is even more acute.

One last note: being clear about the ability to capture value can help avoid the next feature fallacy that can plague organizations of all sizes, not just those that haven't hit product-market balance(2) yet.  If the next feature doesn't give you any additional pricing/stickiness power, then it's not worth doing.

(1) This is why these organizations fight and fight and fight to introduce a second successful product, or to produce new user experiences that extend the core value.  For consumer, Facebook groups is a great example.  For prosumer/SMB, Dropbox's introduction of Carousel and acquisition of Mailbox are prime examples.

(2) One of my favorite quick posts; still holds up great even ten years later!

]]> tag:sachinagarwal.com,2013:Post/1150931 2017-05-02T17:47:12Z 2024-02-23T14:02:48Z Product Tools and How To Use Them

There's a lot of advice around standard metrics: don't have more than 2-3% monthly churn, convert at least 2% of your free users to paid under a premium model, response rates should be 200 milliseconds or less, and so on and so forth.  There's a little less out there of *how* to get and measure these core metrics.  I wanted to share exactly what we track and how for Nylas Mail, the freemium cross-platform desktop email client I've been working on for the last few months.

We track four main things: user actions, performance, errors, and user happiness.  For each one of these core areas, we use a different tool.

User Actions: Mixpanel

For core user actions, we use Mixpanel.  Since Nylas Mail is an Electron app, it's just as easy for engineers to add Mixpanel events to Nylas Mail as it is to your standard web-based SaaS app.  We want to see what actions users are doing in Nylas Mail so we know what we're good at and where to improve.  Of course, we don't look at what people are sending or who they're corresponding with - that's not useful to us, it'd be a ton of data, and it's just plain wrong.  As it was the big feature when they launched, and still their best feature, we use Mixpanel funnels to track newly acquired users and try to make sure that we're eliminating all the rough spots so that we can get someone from trial to habit as soon as we can.  We also use Mixpanel's built-in notifications feature to do a drip of onboarding emails after a new user signs up.  I have lots of gripes about Mixpanel, which makes sense since it's a ten year old tool and things have changed in internet land, but it's still the best tool I know for seeing just what users are doing inside your app.

Performance: Honeycomb

Honeycomb is a relatively new entrant in the analytics space, and while it can be used for a lot of things, we use it to track performance.  In particular, we use Honeycomb to track 90th percentile performance versus counts on key events - this lets us make sure that we aren't introducing performance regressions as we push our new versions of the app.  There are great filters and ordering options, so we can slice and dice data pretty easily.  A really nice feature - Honeycomb runs are discrete events with discrete URLs, so we can paste these into Slack and refer back to that exact data set and those graphs days or weeks later.  (This sadly isn't possible in Mixpanel.)  Honeycomb is still new, so the ramp up period is a bit longer and you always have this feeling that you're not using the tool as well as you can, but once you find something that works, it's really addictive.

Errors: Sentry

We send errors to Sentry automatically.  We use this for two things: we want to see which errors happen the most often so we can prioritize bugs and we can also use Sentry to let us know if we've introduced new errors when we've released a new version of Nylas Mail.  We can see if a small handful of users are seeing lots of errors or if errors are being seen more broadly by a large set of users very quickly. We also look to see if errors are concentrated on a particular platform, release, or type of connected account (Google, Office 365, or IMAP.).   One thing to look out for: Sentry can get overloaded with errors very, very quickly if you ship something broken or are too generous with sending errors to Sentry, so beware of going over your limits.

User Happiness: Zendesk

Yes, Zendesk.  Lookit, for product managers or anyone building something where the customer is the user: vox emptor, vox dei.  The voice of the customer is the voice of God.  You can look at cohort data, you can ask for CSTAT and NPS, and you can dive into logs until the cows come home.  The best way to hear what the customer is experiencing is to hear it with their own voice.  When customers choose to reach out to you, it's your job to listen to every word they say.  If the customer says "the app is slow" but your telemetry shows that your response rates are under 200 ms, guess what?  Your app feels slow and it's your job to fix it, period.  We look at every support ticket as an opportunity to understand the problem that the customer has and for us to learn how they tried to use our app to solve it.  It's customer development, right in your inbox.  Zendesk can be slow and the analytics leave something to be desired, but it's a critical part of our product development process.

We've found lots of neat things with our data sources.  Some highlights: it turns out that sending emails is the very best predictor for retention, even though people receive a lot more email than they send.  Perceived performance is way different than the performance of the app - in both ways.  Electron may be cross-platform, but there's something about Windows users or Windows itself that throws a disproportionate number of pull-your-hair-out bugs.  And even the most non-technical users will jump through hoops to get you logs if you're patient and understanding with them.


]]> tag:sachinagarwal.com,2013:Post/1082269 2016-06-15T19:00:00Z 2024-02-23T12:33:59Z Introducing Braid


Introducing Braid

One of the hard things about doing a startup is finding problem/founder fit. Since successful startups take forever, it’s really important for founders to go after a problem that they want to keep solving. If you’re going to end up working on something for a decade or more, you better know the problem really well and be highly motivated to solve it.

Some people are lucky — they have lots and lots of ideas for lots and lots of problems that they want to solve. They keep notebooks in their bags, by their bedsides, and in their glove compartments so they can write down ideas any time inspiration strikes. (Or, at least they did before iPhones.)

Anyway, I’m not so lucky. I’ve only had one idea I’ve been excited about for the last half-decade.

As I moved up in my career and moved from company to company, I found that I spent more of my time doing administrative work and less of my time doing the job I was hired to do. Building and problem solving gave way to tracking things down and filling out forms. I stopped being excited about my work and started dreading the artificial deadlines and TPS reports required to keep our teams in some semblance of cohesion.

For better or for worse, we define ourselves by the jobs we have. But when we go to work and we can’t even do the jobs we’ve been hired to do, it’s just a total waste. Handcuffed by tools chosen by IT and policies imposed to solve a problem one person had 15 years ago, we become exhausted and disillusioned with our jobs.

For me, at my recent jobs before starting this company, I became disillusioned and exhausted by the constant barrage of unnecessary fire drills and meetings that piled up on the calendar. Instead of being able to talk to customers and mock up wireframes, I spent most of my day making PowerPoints and writing long updates that no one ever read. People were less concerned about helping projects move along and more concerned about making sure they could blame someone else for the inevitable delay. It’s what I call the “cold comfort of soft numbers”.

No one is excited to come home and say “I went to four status update meetings today!”. No amount of money or private offices can replace the joy that comes from doing a job well. What we want as employees at an organization is pride of ownership — to be proud of the thing we built, the team presentation we delivered that impressed the client, or the finally solving that problem bedeviling the team for the past three weeks.

I wanted to build a tool that just let me — and my friends — get back to work and work better together.

Braid is designed to let teams work better together—by taking advantage of the work that we’re already doing. We’ve added Braid to be a light layer on top of Gmail and Google Calendar, targeting those organizations that live in their inboxes.

Braid is a collection of simple news feed feeds that are available where you need them — in your Inbox, and out of your way when you don’t. It’s simple to add emails to a feed with a click of a button — no more copy and pasting from an email into a wiki or a task list. Add events or jot a quick note as well. Upload files so that they’re all in one place. Tying together all the important things we do in one cohesive place is what we’re about.

The motivation behind Braid is to build a tool that respects people and respects their existing workflows. We believe that Braid will help you get better results for your projects. Braid is a quiet enabler instead of a chore. Braid is a tool that enables people to get credit for what they’ve done when they’ve done it. And the bonus is that managers and clients can feel secure seeing the progress of a project in real time.

Braid is built to be a single, simple source of truth that everyone can actually trust. So there’s more time to get things done and everyone is pulling together.

I hope you’ll try Braid and see if it helps you and your team free up more time for the things that truly matter. If you want to read more about Braid the product, check out the launch post. And please reach out with your ideas to make it even better. Thanks for reading.

]]> tag:sachinagarwal.com,2013:Post/992265 2012-06-06T19:00:00Z 2024-02-23T13:55:30Z Please Shut Up About Growth Hacking.

(This post originally appeared on my Svbtle site: http://sachinag.com/please-shut-up-about-growth-hacking)

All of a sudden, growth hacking is the new Carly Rae. I’m so completely bored with this boomlet because growth hacking isn’t anything special.

Point one: growth hacking isn’t new.

Let’s posit that growth hacking is finding channels (sometimes new) that work, then jamming everything you can at them until they stop working. Essentially it’s getting in front of Andrew Chen’s law of shitty clickthroughs. The newest new thing I know here is Gchat spam. You find an inefficiency or underexploited channel, you rush to get there before your competitors do, they flood in, the channel gets bid up, the ROI dries up, and you go on to the next thing. That’s just arbitrage. Just cause you’re doing it online doesn’t make it new.

Furthermore, you know who has been doing this for more than a decade? Affiliate marketers. Folks like Jeremy Shoemaker and Zac Johnson have been building landing pages, writing reams of copy, testing ad networks/formats/placements/CTAs/whatever since they were 15. You want to hire a growth hacker? Go to Affiliate Summit and hire a speaker.

Point two: growth hacking doesn’t work if your product sucks.

PayPal paid both sides $5 for signing up, but Yahoo PayDirect paid $10. Everyone else gives away more free space than Dropbox. Friendster started getting really aggressive with email once people were jumping to MySpace and Facebook. Dropbox’s videos and Mint’s blog posts shot up Digg for free, launching a million paid submissions, but no one remembers who did the paying. The original NCAA game on Facebook led to Zynga on Facebook, and then everyone else’s Facebook spam, none of which worked as well as Zynga’s did. Everything autoposts to Twitter. And there are a million untold stories for products that nobody’s ever heard of. Because they sucked.

Plus, there’s no evidence that these dedicated growth hackers - magical unicorns who can market and code (designers who can code, you had your 15 minutes) - can reliably identify and exploit new channels over and over again. A supposed professional growth hacker may be lucky to find one great new channel, but finding three? That’s a James Simons-level of consistency. If someone really can do that, go forth, find her, and pay her the equivalent of 5 and 44.

Point three: growth hacking accelerates traction; growth hacking does not create traction.

Let’s say you find a magical new channel that’s cheap (or free!) to exploit. Then you shove a bunch of users at it. Then they sign up. Then they leave because your product sucks. You know what that is? A best case scenario because you’ve managed to snooker some investors into giving you cash before the bottom falls out. More likely, you won’t find a magical new channel and you’re going to have to rely on people organically sharing your product with the world. It’s called word of mouth. It’s been around for about 5,000 years. (Yeah, even before Delicious bookmarks and Facebook Likes and Tweet buttons and Pinterest pins.) Word of mouth still works pretty well for products and services that people like. And it’s free. Once you see enough word of mouth, or an organic hockey stick, or a 40% very disappointed, or a 50%+ DAU/MAU number, or whatever else the metric flavor of the month is, then you have traction, and then you can think about hacking some additional growth to accelerate your organic traction. Doing it before then is dumb. That’s because growth hacking is just about getting people into the beginning of the funnel, not about making them happy customers.

Lookit, a product manager should be doing inbound and outbound messaging. If the product owner/manager/CEO/whatever doesn’t know when to market, who to market to, how to market to them, and what to say, then your product probably isn’t ready to be marketed. Dedicating precious engineering time to marketing experiments prior to sustained and repeatable traction is a waste of everyone’s time and money.

Frankly, I think that all this talk about growth hacking is the result of the Valley’s ridiculous inability to recognize and discount survivorship bias. Sure, I’m as happy as anyone to recognize and celebrate the success stories and buy successful people beer to gain some wisdom. But taking them as proscriptive is learning the wrong lesson. So stop worrying about growth hacking and get back to work building something useful.

]]> tag:sachinagarwal.com,2013:Post/45991 2010-12-08T01:32:00Z 2024-02-23T13:50:25Z PCI Compliance In The Cloud: This Changes Everything
Amazon announced today that they have PCI compliance certification for the entire AWS stack: EC2, S3, EBS, and VPC.  This is huge.  Almost every startup these days uses some cloud hosting provider, and until now, it's been literally impossible to be PCI compliant in the cloud.

To be PCI compliant, the website owner needs to be able to provide physical access to the servers in the event of a credit card breach.  If you're running in the cloud, you can't provide physical access to an auditor, since you have no way of gaining physical access yourself.

The merchant account providers don't know the first thing about hosting, and they don't really care.  And no startup I know has moved to bare metal and hired a sysadmin just to follow the letter of the standard.  Startups have better things to do than subject themselves to an audit by Trustwave or some other QSA that certifies PCI compliance.  (See, you thought you were PCI compliant, but you're not.)  But if some companies now magically have PCI compliant clouds, then they have every incentive to rat on their competitors who aren't to Visa/Mastercard, effectively shutting down their ability to process credit cards.

Given that this is a rather large deal, I've asked Amazon PR to send me a copy of the QSA report.  Just to prove to yourself that this is a big deal, look at the list of PCI compliant providers: http://usa.visa.com/download/merchants/cisp-list-of-pcidss-compliant-service-providers.pdf (PDF link)  Amazon is like that Sesame Street song: one of these things is not like the others.

One of things I want to figure out is if Engine Yard's EC2 instances are de facto included in the PCI compliance report, or if only customers contracting directly with Amazon are covered.  Hopefully, the QSA report answers this, but if not, I'll try to run this down with Amazon and Engine Yard.

Upshot: my best guess is that this raises the table stakes for every other cloud provider out there, and if you're in a competitive market and you're not on AWS, your competitors can attempt to report you for PCI violations.  You should ask your cloud provider when they'll provide PCI compliance, and if they can't give you a roadmap, you should investigate moving to Amazon.  
]]> tag:sachinagarwal.com,2013:Post/45994 2010-08-03T13:52:00Z 2024-02-23T12:34:02Z Ten Steps To Ten Thousand Sign Ups Before We Even Launch Our Startup

Blueleaf is building the world’s first truly personal financial planning platform.  It’s a complex product with a lot of features to meet all the different problems that our customer discovery has shown that people want.  Here are ten concrete things we’re doing to get 10,000 sign ups before we even launch our product.

1. Making Potential Users Ask Publicly To Get In

There are two ways to get into Blueleaf: get an invite from us, or get an invite from a current user.  We let in a limited number of users every week, and we choose who we let in based on how much they want in.  Only people who request an invite and follow us on Twitter, Like us on Facebook, or otherwise make it clear that they want in, get in.  This means they have to sign up with us and tell everyone else about us before they can get in.

2. The World’s Strictest Invite System

The other way to get in is to get referred in by a current user.  We’ve developed our own twist on refer-a-friend: rather than limit the number of invites someone has, there are an unlimited number of invites – but we’ve limited the time frames to invite a friend.  We turn on the ability to invite a friend for just an hour or two so that people who want in have to beg everyone they know who’s on to let them in before the window closes.  When we announce that invites are on, potential users need to plead for invites publicly on Twitter and Facebook, privately over IM and e-mail, or however else they can reach current users.  Again, this kicks off a viral loop before the app has even launched.

3. Splitting Up Blog And Library Content

We write – a lot.  We publish something new almost every day.  However, most of our new content isn’t on our blog – it’s in Blueleaf's library of articles about financial planning.  It makes no sense to hide an article about bond funds and bond ETFs on a blog, where it’ll be impossible to find in a month.  We’ve segregated our greenfield content so that someone looking for that topic five years after we publish it can find it easily.  Plus, we can easily update and change this content as laws, tax policy, and the investment environment changes without confusing new or returning visitors. 

4. Having A Strong Point Of View

When we write content, we rarely do six of one, half a dozen of the other.  When we write about Roth versus Traditional IRAs, we don’t do pros and cons.  We say that if you have to ask the question, you should open a Roth IRA.  The vast majority of Americans qualify for a Roth.  They should open a Roth.  For the people who should open a Traditional IRA, we go through the reasons when it would make sense – but we don’t do false equivalence.  On our opinionated articles, Blueleaf’s position is front and center, up front, before the rest of the content to deliver as much value as we can in as few seconds as possible. (BTW, we do absolutely no SEO analysis or keyword stuffing.  That stuff is lame.  We write answers to the questions people ask us, simple as that.)

5. We Don’t Blog About Our Product

The Blueleaf blog has three components: Blueleaf Stories, Blueleaf Thoughts, and (to come) Blueleaf Tech.  Our Stories are the Blueleaf staff writing about their own personal financial experiences so that we can make it clear that we’re making a product that we’re very emotionally invested in.  Over time, we’ll ask our users to contribute their own.  Blueleaf Thoughts are about things we find interesting that we think will also be interesting to our audience.  We want to provide value for everyone who is saving for their financial futures, regardless if they’re interested in our product right now or not.  If we have interesting stuff, we’ll get links and traffic.  That’s it.

6. Link Roundups For Users And Relationships

The other thing we do on our blog is post twenty links every Friday afternoon, comprised of the four handpicked links we tweet out each weekday.  Not everyone follows @blueleafcom on Twitter, so it’s a nice convenient place to have some leisurely reading over the weekend.  However, the real clever thing about link roundups is that they provide Trackbacks to the financial bloggers we want to establish relationships with.  Bloggers click through on their Trackbacks, see the Blueleaf site, and get interested in the product.  This makes it much easier to develop relationships and approach them for coverage as we get closer to launch.

7. Using Facebook And Twitter Very Differently

Instead of using our blog to announce new features, we use Facebook Notes.  Also, Facebook is the only place to get a feed of every new piece of content we post when we post it (there’s no RSS feed for our Article content).  Facebook is Blueleaf's broadcast medium for people who want to keep up-to-the-minute with what Blueleaf is up to.  We use Twitter to share interesting links and we’ll use it as a cornerstone of our customer service as we add additional users.  We’re so big on sharing links on Twitter that we have two accounts for it – @blueleafcom and @BlueleafLinks.  The only thing we do on both?  We’re diligent about responding to anyone who comments on Facebook or @replies to us on Twitter.  

8. A/B Testing The Hell Out Of Everything

We A/B test a lot – we’ve tested calls to action, button colors, button size, headlines, images, and a litany of other things using Visual Website Optimizer and Performable.  But we make sure we don’t end up in local maxima.  We’ve A/B tested radical redesigns of our homepage, and the current page is the one that beat the pants off our old one.  We do this A/B testing so that we can maximize our conversion, regardless if the traffic to our site is a trickle or a flood.  We’re ready to catch all the fish in the sea that just happen to be swimming by.

9. Being Smart About Paid User Acquisition

We’ve tested all sorts of various paid acquisition channels – everything from Google and Yahoo to reddit, Facebook, and directory sites.   We’ve been able to drive down our Customer Acquisition Cost (CAC) to a very reasonable amount – not the blended CAC between paid and free, but our CAC on paid alone is very, very attractive.  Even though I’m the guy who called AdWords “a gateway drug to unprofitable user acquisition”, being smart with small paid tests that get your CAC down to a reasonable number makes potential investors all hot and bothered.  Proof that you can get affordable paid acquisition makes fundraising much, much easier.

10. Knowing Just Who The Hell Is Signing Up

We run every single e-mail we get through Flowtown so we know a bit about who’s coming in through the open door.  Doing this, we can stagger who we let in when and we can have better content for our e-mail newsletters to those on the waiting list.  We reach out to people we’ve identified as potential influencers and we make sure that we don’t let people who are potential investors until the time is right.  (Join the club, folks – not even our current investors have access to Blueleaf.)  Letting in the right people at the right time means that we prime the pump to yield water only when we’re thirsty for new sign ups.

]]> tag:sachinagarwal.com,2013:Post/45996 2010-08-02T18:04:00Z 2024-02-23T12:34:03Z Be Careful About Outsourcing Your Customer Acquisition

One of the great things about services like AdWords, Wufoo, Mailchimp, Flowtown, Performable, and so on is that they allow the marketing side of a startup to work independently of the engineering side of the startup.  Whip out your credit card and you can have a source of traffic, lead generation forms, e-mail marketing campaigns, social media insights, A/B testing of your landing page, and all that great stuff.

The problem with this is that as these tools have begun to play better together (thanks to the magic of Webhooks), your data becomes a bit more trapped inside each of these programs.  It can be hard to audit your data and even harder to integrate this data into your core application.  You end up going to each service independently to answer basic questions such as "when did this user give us their e-mail address?" and "just where did we get this e-mail address from?"  And if you want to answer more complex queries such as "just what is our overall (blended) customer acquisition cost (CAC)?", you have to export your data into CSVs and manually massage them together, which can be a very painful process indeed.

The bigger issue is when you try to integrate this information with your main app so you can do cohort analysis.  Cohort analysis is the magic analysis that tells you how you're doing on your key retention and engagement metrics over time: "did our June signups come back to the site more often than our April signups did?"  Trying to import user acquisition dates into your database of existing users (once you've sent them an invite to your app) is very time-consuming as you want to make sure that you don't break anything - there are a large number of edge cases you have to deal with: you'll have users who gave you their address more than once (for example), you'll have users that have changed their e-mail address inside the app from the one they gave you on your lead gen form, and you'll have users that have invited other users.

When you're a pre-launch or early startup, you don't have a lot of data points to deal with.  This is good because it means that you can, with effort, use Excel or some other tool to tie together all these different repositories of data.  But it's also bad because you may not think to have systems in place to more elegantly handle measuring your AARRR metrics post-launch.  You'll be so busy putting out fires and doing PR that you may end up neglecting instrumentation.  

While you may not have to do everything in-house, it's critical to have an engineer on your team who's involved in business/marketing support from time to time.  Defining and implementing an integration and migration paths (a lot of these services *do* have APIs for example, but those aren't something the mouthbreathing "business guys" can do anything with) before you launch is critical to make sure that you can calculate and measure the things you'll need to calculate and measure as you scale your business.

 

]]> tag:sachinagarwal.com,2013:Post/45999 2010-05-11T19:23:00Z 2024-02-23T12:38:18Z Lapsed Users - Your Most Valuable Untapped Resource

You're struggling with user acquisition.  No one's coming back.  Your product is robust and full-featured and you're adding new features every week.  You're only building the features that your users want, so you're not wasting any time on "wouldn't it be cool if" problems.  But no matter how hard you work, your graphs just aren't up and to the right. 

What to do?

One of the most valuable resources that startups (consumer web, again) have are the e-mail addresses of their registered but lapsed users.  It can be very valuable to reach out to them and figure out what part of your message or product didn't resonate.  Remember, if your "very disappointed" score is between 25% and 40%, it's often the message - and not the product - that isn't resonating.

Of course, if only 2 or 5% of your registered users remain engaged, it's probably both the product and the message. 

Here's a simple way to find out what's going on.  First, find a well-defined cohort of users.  This cohort could be from your last marketing push, or even "all users who signed up in winter" - you want they survey respondents to be as similar to each other as possible.  Grab the e-mail addresses for all of the ones who registered who fall out of your engaged metric (last 7 days, last 30 days, etc).  Send those lapsed users from that cohort the following e-mail:

Dear $user,

Thanks so much for signing up for $product!  We noticed that you haven't been back in a while, and we would love to know what we could do to make $product better for you.  If you click on the link below, we have a quick, two-minute, four-question survey that would really help us out:

$survey_link

If you fill out this survey, you'll get $free_product/be entered to win $free_product/have our undying gratitude.

Thanks so much!

$founder_1 and $founder_2

That's it.

The survey should have these four questions:
  • Why did you sign up for $product?
  • What did you think you were getting with $product?
  • How did $product disappoint you?
  • What can we do to make $product better for you?

These are, of course, unstructured questions, so you're going to have to read all the answers.  Don't worry about missing stuff - the patterns will be repeated over and over again so you won't be able to forget about them.

If you want, you can add a checkmark box or a field to capture phone number for follow ups.  Make sure that you don't ask for name or force respondents to leave any personal information if they don't want to.  You want them to give their unvarnished feedback.

Take their feedback - figure out if it's the product or the messaging that's falling short.  If it's the product, add those features (and think about killing the ones they're not using).  If it's messaging, that's even easier to fix.]]> tag:sachinagarwal.com,2013:Post/46001 2010-05-04T01:15:00Z 2024-02-23T12:34:04Z Introduction To Online Payments - TL;DR: It's A Total Bitch
Online payments are a bitch.  Just over a decade ago, you had to hook up your online commerce system to an actual terminal that would send bleeps and bloops to the gateways, but even today, it's not much better.  There are still a plethora of players who have to touch your information to process a simple credit card transaction, and each and every one of them gets to take a little bit of your money and introduce their own technical hassles.  While there are never any easy answers - every option has pretty severe tradeoffs - I'm going to try to shed some light on how the process works and look at some of the major players/options you have for accepting payments on your website.

The traditional way to process online payments is to have an internet merchant account, and talk to that account via a payments gateway.  Nowadays, many internet merchant accounts come bundled with a gateway as part of the cost (notably, Authorize.net), but they are separate and you can always choose to use the gateway of your choice (as long as they work with a processor platform that's supported by the merchant account).

"Wait, what?" you say.  "You said you were going to shed some light, but you're just confusing me with all this talk about accounts, gateways, and processors."  Well, I told you that online payments were a bitch.

OK, let's start at the top.  An internet merchant account is what you need to accept credit cards on your site.  Despite its name as an "account", it's really not an account at all.  An internet merchant account merely gives you permission to accept credit cards.  At the end of every day, the internet merchant account will deposit all of your funds into your real checking account that you maintain with your bank.  So think of an internet merchant account as a holding pen of sorts.

The vast majority of business banks (Bank of America, Silicon Valley Bank, etc.) can provide you with an internet merchant account, but you will rarely want to go that route.  While the costs are often higher, the real reason you don't want to go that route is that you're more likely than not to be denied a merchant account as these banks (SVB, Square 1, etc excepted) are more used to traditional brick-and-mortar merchants and you can often spend weeks or months applying for an internet merchant account just to be turned down for being "too risky".  If you just Google "internet merchant accounts", you'll see a bunch of companies who are dying to give you their business.  

Personally, I highly recommend TransFS to find an internet merchant account.  All of the merchant accounts on TransFS are "interchange plus" accounts.  Interchange is the fee that Visa and MasterCard charge to process their cards; these fees vary depending on the type of card - consumer versus business, plain vanilla versus rewards, and so on.  (The complexity and fees are actually a big enough deal that there are advocates to reform interchange in Congress.)  Interchange-plus passes along these charges plus an incremental amount; in almost all cases, interchange plus is both cheaper and more transparent than "qualified/non-qualified" bundled rates.  While the bundled rates may be simpler, they're often mischaracterized in a way to benefit the merchant account provider at the expense of the merchant. (If you want to learn more, read this post on TransFS' very comprehensive blog.)  These merchant accounts will generally charge you a "statement fee", aka "the fee you pay us monthly for the privilege of being a customer" plus a small percentage (usually between 0.15% and 0.30%) and a flat per-transaction fee (usually 10-15 cents).  I have worked with a merchant account provider called CoCard that I found via TransFS and have generally been very happy with their customer service and fees. 

It will take you about three to four weeks to jump through all the hoops to acquire the internet merchant account, so you need to plan ahead to have a merchant account ready to go before any launch.

Once you have an internet merchant account (or while you're going through the process), you need to find a gateway.  Again, you write your code to talk to the gateway; the gateway takes the credit card information that users input on your site and talk to the processors (First Data, Paymentech, Global Payments, etc.) to get the funds released to the merchant account (which then sweeps into your regular bank account).  Most internet merchant accounts will resell or bundle a gateway - most often, it's Authorize.net.  Auth.net (for short) is a perfectly serviceable gateway for most use cases, but if you need a more elegant gateway API, you may want to pay extra for Braintree's payment gateway.  Braintree has focused on e-commerce since their founding and they (while not perfect, especially with their documentation) are generally considered the easiest gateway to work with.  However, if you decide that you want to use Braintree's gateway with your internet merchant account, you need to make sure that your merchant account supports the First Data Nashville processor.  (There's actually a First Data Omaha processing network which does not work with Braintree.  Why?  I have no idea.)  Braintree's gateway will add significant costs to every transaction, but you're paying for a more elegant API and premium customer support.  If you're doing large dollar ticket sizes, these additional fees may be worth it; if you're doing lots of small dollar amounts, they may not be.  (And forget about it for microtransactions.  Use PayPal or Amazon Payments' specialized solutions for microtransactions.  I'd recommend PayPal as it's easier to grow into their other offerings as necessary.)

Well, that's a lot of work.  Why not just use PayPal?

Actually, that's a very good question.  While many people may have poor experiences with PayPal, they are invariably easier to get set up and understand than the combination of hoops and charges for an internet merchant account and gateway.  In addition, PayPal can often be cheaper.  Here's a pretty little chart that PayPal has on their site:

Let's be clear; this isn't to scale, but it does accurately display the differences in complexity.  (One note - if you use interchange-plus pricing, you're not subject to the downgrade fees that kick in for qualified versus non-qualified transactions.)  What's confusing about PayPal is that they have three products that you can use: Website Payments Standard, Website Payments Pro, and PayFlow Pro.  PayFlow Pro is a standard gateway that works with any internet merchant account (PayPal actually acquired this line of business from VeriSign back in late 2005).  Website Payments Standard and Pro are combined merchant accounts and gateways.  The main difference between the two is that with Standard, the transaction happens on PayPal's servers.  With Pro, it happens on your servers.  In addition, with Standard, you have to accept PayPal as a payment mechanism; with Pro, you can accept credit cards only.  (Why you would want to comes to how PayPal funds their accounts; e-checks don't clear for three to five days and introduce risk to merchants that credit cards, with their instant money transfers, do not.)

In some cases, PayPal can be cheaper than the combination of merchant account and gateway.  In particular, if you have very high tickets (average order sizes) and a mix that is skewed towards business cards (which have higher interchange fees), PayPal can often be more economical.  PayPal's simplified rate structure is a marketing tactic that, on balance, does make PayPal more expensive than the more complex option.  EDIT: You can compare PayPal versus a standard merchant account with the PayPal Upgrade Calculator built by TransFS.  (Disclosure: I worked with TransFS to build this calculator, a relationship that happened after this article blew up.)

However, there is one additional downside to PayPal: they will oftentimes hold back up to 25% of your proceeds for three months as a fraud prevention/risk management effort. This means if you charge a customer $100, you will only get $75 immediately and will have to wait three months to see the $25 balance.  If cash is tight, or you are running inventory, this can kill your business.  

There is one additional issue to consider when deciding on your merchant account, gateway, PayPal, and your options: vendor lock-in.  In most cases, you are locked into a particular vendor.  This is because they store the credit card information on your behalf (unless you use a standard merchant account and decide to try to be PCI compliant - which is a whole 'nother ball of wax that requires audits and precludes using cloud hosting for your e-commerce).  In particular, if you have a subscription recurring billing model, this vendor lock in can be killer because you can't switch providers without forcing your customers to return and re-enter their credit card information in a very limited timeframe between your switch and the next billing cycle.  To avoid this, there are a small number of vendors who provide "vaults" that store credit card information in a portable manner.  

The two most well-known vaults are Authorize.net's CIM and Braintree's vault.  A newer company focused on their elegant subscription payment API, Recurly, also provides a vault (but they are not a gateway provider themselves).  These companies offer credit card portability if you ever choose to store credit card data yourself.  (You may be able to move from one vault to another, but I'm not sure if this is actually possible.)  These vaults are the only way I know of to offload PCI compliance while still maintaining some flexibility in changing merchant account or gateway vendors.

OK, so here's the million dollar question: so what should you do?

As far as I'm concerned, there are three real options:
  • PayPal Website Payments Pro
  • Braintree Gateway + Account
  • Authorize.net + Merchant Account (add Auth.net's CIM, Braintree's vault, or Recurly if you need vendor flexibility)
PayPal will be the easiest to get set up, by far, but the 25% holdback can be a killer.  Braintree's single-source solution will take longer to set up, and will be the most expensive option for most cases, but they provide the most flexibility and best customer support.  Getting your own merchant account and using the bundled gateway will presumably be the cheapest option, but will invariably cause you the most headaches.  You can avoid some headaches by writing to Braintree or Recurly, but then you will lose much of your cost savings, but you'll retain the flexibility to host the card numbers yourself or possibly switch vault providers.  

Of course, if you don't mind having the checkout transaction happen on someone else's servers, PayPal, Amazon Payments, and Google Checkout are all (non-exclusive) options.  Here's a good rundown of all three.

I recognize this is both a very long and completely uncomprehensive review of online payment processing.  As I've repeatedly said, online payments are a bitch.  I intend on revisiting and editing this post as comments and additional information becomes available. 
]]> tag:sachinagarwal.com,2013:Post/46004 2010-04-30T13:01:00Z 2024-02-23T12:18:41Z Why This Startup Guy Is Going Back To Business School

Today is my last day as Operations Lead at oneforty.  In the fall, I'll be headed to the Ross School of Business at the University of Michigan to pursue my MBA.  
 
Because I've been asked a bunch of questions about this, I figured it might be fun for others to see (and critique!) my thinking.
 
Why business school?

Amongst startup folks, MBAs get a bad rap. Some smart people don't even want to interview MBAs.  But it turns out that a lot of companies won't interview you without one.  I literally have an e-mail in my Inbox from a recruiter at a very prestigious company that is one of the largest traditional recruiters of MBA students who loves my experience, but can't hire me without a graduate degree.  While we can debate the pros and cons of the company's position, it does mean I'm precluded from even considering a position with this firm until I have my MBA.
 
An MBA isn't a substitute for startup experience and drive, but it doesn't preclude it either.  From my perspective, it's easier to go to school full time and work on startups part time (both mine, and helping others) than working at a startup full time and trying to swing a part-time MBA.  My read is this: getting an MBA has the highest option value out of the things I could do with myself at this point in my career.
 
Besides, there's precedent - if Tristan can pull it off at Foursquare and Stanford, then I can certainly pull it off as a part-time consultant while I'm at school.
 
Why Ross/Michigan?
 
Out of the top ten business schools, Michigan was easily the best fit for me.  The environment at Ross is very different than some other schools; Rossers are driven, but not competitive.  They have fun without being self-indulgent.  They're friendly without weird forced group hugs (thanks, John, for unwittingly providing me that dig at your alma mater).  The new building is the best learning facility I've ever seen.  And I couldn't be more excited about having a chance to watch the first night game ever at the Big House.  I hate Notre Dame.
 
Of course, professionally, it's a slam dunk.  Every single company that traditionally recruits MBAs that I would want to work for recruits on campus at Ross.  If I want to go the strategy consulting route, I can do that.  If I want to join a large technology company in a product management or product marketing role, I can do that.  If I want to get hands-on experience with consumer marketing at a CPG company, I can do that.  And, yes, if I want to join or found a startup, I can still do that.
 
In addition, Michigan has more top-ten graduate programs than almost any other school in the country.  This means that I can complement my formal business school education with classes from the law, engineering, and other schools on campus.  For example, you know how the Lean Startup movement has strong roots in the Lean Manufacturing processes pioneered by Toyota?  The guy who wrote the books on Toyota's processes is a professor at Michigan.  If there's ever been an opportunity to do a formal academic dive on the base assumptions underlying lean startups, this is my best chance to do so.  I don't need to wait for someone to modify an existing class to incorporate Lean Startup principles; I can write a few chapters of the damn textbook myself.
 
Why now?

I'm 29, which puts me at the upper edge of your traditional full-time MBA student.  I didn't feel comfortable putting off school, if I was going to go at all, any longer.  Being older also means I have a number of friends who have already finished B school.  Talking to them, one of the most frequent pieces of advice was to take the summer "off", so I decided to do so as well, now that oneforty closed its Series A round, launched e-commerce, and moved to its more permanent offices in Central Square.  The Company is in a great position, and I can take the summer to learn Ruby on Rails, travel a bunch, and make the most of an opportunity to do interesting things before I take on new obligations.
 
What now?
 
I'll be taking a desk as an Advisor at TechStars here in Cambridge for the next month (thanks Shawn), helping out the startups there with product, marketing, positioning, pricing, and other questions/issues.  In addition to the 2010 Boston TechStars companies, I'll also be helping out at a small handful of more established startups in town.  I'll also be blogging more regularly, and tweeting some more as well.
 
I want to close this out by offering my thanks to Mike, Michael, Robby, Yifei, Jamie, and Jason for being awesome to work with.  I also want to especially thank Laura for letting me come out from Chicago, run the Series A process (from first meeting to close in 37 days - beat that with a stick), do customer development, user testing, marketing, and own point on a myriad of other tasks as well as letting me leverage her insane, awesome network for my own personal benefit.  You really should consider joining the team.
 
]]> tag:sachinagarwal.com,2013:Post/46006 2010-04-26T18:00:00Z 2024-02-23T12:38:26Z Setting Pricing for a Startup - The Rule of 80%


In just the last week, two different people have come to me to get feedback on their pricing. One was a startup selling a very sophisticated product to corporate enterprises. The other was selling consulting services to individuals, small businesses, and trade associations. In both cases, however, the questions were the same: how should I price this on a per-head basis? When should I charge a flat fee? How do I make sure I'm not leaving money on the table? How do I make sure I'm not losing customers?

First thing I said was: you need to have a public rate table. I believe that people like to comparison shop, but that they only choose amongst those providers who make it easy to compare prices. If you provide a rate up front, you are at a substantial competitive advantage to your competitors who require potential customers to fill in a lead generation form. Second, if you have a premium product and you have a competitive advantage because you make it easier for customers to compare you against the competition, for the love of God, raise your rates. Higher costs are a signaling mechanism that you're selling a premium product. I can't find a link, but there's an apocryphal tale that Cadillac sales actually went down in the 1980s when Cadillac lowered prices. Traditional economics says that lower prices means you move right on the demand curve, leading to higher sales, but it didn't happen because consumers thought the lower prices were a signal of lower quality.

OK, now that we'd established better base rates, the question came down to how do we set the appropriate levels based on demand? Surely you want to have quantity discounts, especially for those parts of the business that are easily scalable. Well, to start, let's take a look at a business I know intimately well.

Here are my rates for business consulting and GMAT tutoring services (two wildly divergent services, one simple rate table):

Hours Per Hour
1-4 $150.00
5-9 $125.00
10 or more $100.00

As you can see, there's a substantial price break for pre-paying for more hours. This allows me to better manage my schedule and worry less about new client recruitment, and it encourages my clients to buy more hours as they get more "bang for their buck". It's a traditional win-win situation.

(Note: I've actually since raised my rates since this was originally published in November 2009: they're now $300, $250, and $200 an hour for the various pre-payments.  Read on for why.)
How did I pick my rates? Well, they just "feel" right. It "feels like" a good balance of encouraging larger purchases, but there's no real rhyme or reason. To me, it's like the golden ratio: it just "feels" right. However, it also turns out that there's a constant that shows up again and again in other successful companies' pricing. Let me demonstrate with pretty pictures:

Here's a graph of my consulting/tutoring rates:

As you can see, there are two steps: one at 5 hours and one at 10 hours. Everything else is constant. As you can see, at the 5 hour mark, my new rate is 83% of the rate for 1-4 hours. At the 10 hour mark, the new rate is 80% of the 5-9 hour rate. So the reduction in rates is very similar: about 80% of the prior rate.

Well, remember how I said we see this in lots of other places? It's really quite uncanny. Let's start with everyone's "it just works" darling, Dropbox:

Dropbox has a free account up to 2 GB, then paid accounts that go up to 50 GB and 100 GB based on payment. As you can see, the price per GB spikes once you need just a little more than 50 GB, but then it comes down to the levels from 30-50 GB. It turns out that you pay exactly the same amount per GB at 80 GB as you do at 30 GB ($3.00/GB per year) and exactly the same amount at 100 GB as you do at 50 GB ($2.40/GB per year).

Here's the graph for 37signals' Basecamp:

Basecamp comes in four paid flavors: 3 GB of storage for $24 a month, 10 GB of storage for $49 a month, 20 GB for $99 per, and 50 GB for $149 per. Again, you see the same spikes in yearly price per GB at the break points. Again, as you get into larger amounts, the difference for every marginal GB becomes relatively minor. Again, it's a bit asymptotic at the tail (in this case, in the mid-$30s per GB per year).

Lastly, let's take a look at Freshbooks:

Unlike the others, Freshbooks charges per client, not per GB, which makes sense as it's an accounting system, not a file storage repository. Freshbook charges $19 a month for up to 25 clients, $29 for up to 100, and $39 for up to 500. In this graph, I don't go all the way out to the "Starship" and "Time Machine" packages (seriously, guys, WTF?), but you can see the same spikes in per client costs at the 25, 100, and 500 client breakpoints that we saw for the GB breakpoints for Dropbox and Basecamp.

"But wait!" you say. "These graphs show spikes in the per-unit costs only at the break points - they're almost flat at the other points The graph for your consulting services showed troughs in the break points." This is true, grasshopper. Except! Take a look at the first few data points for all three. Notice something? At the small amounts, there actually is a substantial difference at each incremental GB or client (the lighter line). Let's look at these differences in table form:

Dropbox

GB Price Per GB % of Previous
0

1

2

3 $39.96
4 $29.97 75%
5 $23.98 80%
6 $19.98 83%
7 $17.13 86%
8 $14.99 88%
9 $13.32 89%
10 $11.99 90%

Basecamp
GB Price Per GB % of Previous
0

1 $288.00
2 $144.00 50%
3 $96.00 67%
4 $147.00 153%
5 $117.60 80%
6 $98.00 83%
7 $84.00 86%
8 $73.50 88%
9 $65.33 89%
10 $58.80 90%

Freshbooks
Clients Price Per Client % of Previous
0

1

2

3

4 $57.00
5 $45.60 80%
6 $38.00 83%
7 $32.57 86%
8 $28.50 88%
9 $25.33 89%
10 $22.80 90%

That's right - early on, there's a lot of 80-something percents in the per-unit differences.

So here's my rule: The rule of 80%.

For anyone selling on an incremental basis, set your break points that the per-unit costs of the new tier are 80% of the per-unit cost for the previous tier. If you're a consultant, whatever your break points are, charge 80% on a per-hour basis at your breaks. If you charge $1000 an hour, whatever your break point is - 5 hours, 10 hours, 1000 hours, make sure the per-hour charge after the break point is no more than $800 an hour. If you sell beer at $5 a bottle, make sure the cost of a six pack (the logical break point) is no more than $24, for a per-unit cost of $4.

If you're selling at a fixed price, it's a no more complex. You just must make sure that your break point from your first paid tier to your second paid tier is high enough to clear the 80s on the light line and it gets into the 90 percent range. If you set your second paid tier too early, before the dramatic savings in per-unit use peter out, your customers will be able to "feel" that you're trying to rip them off and they may not sign up with you in the first place. Once you give them enough goodies at the first paid tier, then you can feel free to ratchet things up - just make sure that your third and fourth tier ratchets don't kick in until the per-unit cost is at or below the limits of the previous tier. (Essentially, make sure your dark line is at the low point in the graph before you create a new tier.)

Well, based on this rule, it looks like 37signals is ripping users off on their Plus plan when compared to their Basic plan. Perhaps that's why they highlight the Plus plan - to avoid comparisons to the Basic plan in favor of comparisons to their Premium and Max plans, where the Plus plan does look like a fair deal. Or, perhaps, maybe the per-GB comparison is the wrong one. So let's take a look at the per-project comparison:

Well, shiver me timbers, but that looks just like the other graphs in the series: same severe downslope with humps in the dark line, same gentle curve with spikes in the lighter line, but no spikes until you hit the 90's.

Now, of course, I'd recommend that 37signals bumps up storage on their Basic plan, with the attendant bumps down the line, but hey, that's just me and my Rule of 80%.

]]> tag:sachinagarwal.com,2013:Post/46008 2010-04-19T13:37:00Z 2024-02-23T12:18:41Z Presentation: Don't Be a Douche - Best Practices For Game Mechanics In Your Web App
Here's my presentation from BarCamp Boston 5 on Sunday, April 18, 2010.  It doesn't work as well without me jumping around, questioning the audience, berating their answers, and generally acting like a, well, douche.

http://www.slideshare.net/sachinag/game-mechanics-best-practices-bar-camp-boston-5

Because most of the deck is very text-light, here's an overview of the general structure of the presentation:
  • First, for fun, I introduce Irwin R. Schyster as our Chief Revenue Officer character and The Million Dollar Man, Ted DeBiase, as the founder/philosopher king character.
  • I review the differences between game mechanics and viral mechanics because I've found that people often just think "FarmVille!  Zynga!  Wall posts!  Game mechanics!" and I need to disabuse them of that notion.
  • First "ah ha": viral mechanics lead to additional revenue by reducing customer acquisition costs and game mechanics lead to additional revenue by getting engaged users to pay for things that make engagement more fun/easier.
  • Based on what I've read, I talk about how 2% of users upgrade from free to premium in freemium apps (Freemium Summit) and 2% of game players purchase additional content (MIT Business in Gaming conference).  Just putting it out there as an observation, not a hard and fast rule.
  • Then there's a basic overview of three different types of karma trappings, and how points lead to completion lead to achievements.
  • Second "ah ha": using Foursquare as an example, I talk about how viral mechanics have more utility to the sponsor/company than to the user, whereas with game mechanics, all of the utility accrues to the gamer/user.
  • Jumping off of Jesse Schell's 2010 DICE talk, I introduce two hypotheticals - Twitter and Etherpad - on how existing web apps could use game mechanics to incentivize and reward "good behavior".
  • Third "ah ha": I talk about how if web app makers use game mechanics to incent good behavior, they could also use the same scaffolding to monetize additional features on a one-by-one basis through microtransactions. (My favorite tweet from this section of the presentation.)
  • Lastly, I wrap up with two text-heavy slides that bring together and revisit the core themes and learnings from the presentation.  (Those of you who know such things will see a lot of David Sirlin in my recommendations.)
Because this is a work in progress, I've chosen not to (yet) make full notes available or the deck available for download.  (Also, it's a sneaky bleg to get people to invite me to give the speech again.)

I'll be in the comment section to answer questions and take abuse.

 

]]> tag:sachinagarwal.com,2013:Post/46009 2010-03-01T12:08:00Z 2024-02-23T12:38:27Z Good Game Mechanics In Your Web App Are Good For Your Users

  

There are two things I know more about than you: marketplace dynamics(1a,1b) and game mechanics(2).  I was planning on doing the marketplace one first, but there's a little blogging bubble about the pros and cons of game mechanics, so I might as well strike while the iron's hot.  

Let's start off with some background reading.  Wikipedia's entry on game mechanics is as good as any, and in particular for web startups, Yahoo!'s Reputation Patterns overview is a must-read.

Done?  Good.

When most people talk about game mechanics in web applications, they generally are talking about one of two things: karma (which rewards quality engagement, see eBay, Kongregate, or Reddit) and virality (which comes from incentivizing user-to-user referrals, see FarmVille or any other Zynga game).

The stuff in Yahoo's Reputation Patterns are various methods of scoring and presenting karma; these things are neutral-to-good for users.  Social proof has utility; the value of the utility differs from user-to-user.  (Most people play Xbox 360 games for the fun of the games themselves; some, however, are achievement whores who will play numerous terrible games just to increase their Gamerscore.)  These Reputation Patterns show the myriad ways that applications can reward and display good behavior - they're all just different methods of displaying social proof, what I call "the trappings of karma".  The general objection to game mechanics is usually about these trappings, in that they obscure "more important" things - the main game/app itself or, extended out, real life.  While I understand these objections, they aren't sufficiently convincing - these objections tend to come from situations where the game/app/experience itself is poorly designed, making the external mechanics more attractive on a relative basis.  If you don't like achievements, points, and badges, you're free to ignore them.

The rewards for making referrals to others - as you see in Zynga games, most notably - are designed to benefit the game creator/website operator/the company/whatever more than the user herself.  Any benefit to the user, while it may be large, is less than the benefit that accrues to the corporate entity sponsoring the game: i.e., Zynga designs their rewards precisely so that the company gets more benefit from a user referring a new user to a game than the user herself gets for the referral.  As you can imagine, I'm a bit less enamored of these sorts of referral game mechanics than I am game mechanics that reward users directly.  These sorts of referral incentives feel the same as AdWords arbitrage to me - they can be tremendously lucrative, but must be carefully managed and actively tweaked at all times; there's no "set it and forget it".  Ideally, the product itself is so good that users start signing your praises - sneezing - without any formal incentive structure; examples of this are Dropbox, Google, and Mint.com.  I'm more interested in making products better; at the very least, great products don't have to be monitored 24/7 and I enjoy my sleep.  :)

Also note that the notion of rewarding virality is different than products that have increased utility as the number of people using them increases, notably social networks like Facebook and Twitter.  (I leave out eBay here for reasons that I'll get to when I do the marketplace dynamics post.  It's fallacy #1 and the fallacy makes me physically angry.)

The reason people get excited about game mechanics in web apps is that they're directly tied to two of the five things in  Dave McClure's AARRR framework  - retention (as a result of increased engagement spurred by the quest for karma) and referral (virality from incentives).  Retention is great because it increases pageviews (which gets you more ad impressions if you're monetizing via advertising) and referral is great because it reduces your customer acquisition cost (remember, your LTV/CAC ratio needs to be greater than three or four to account for fixed costs.  If you can reduce your CAC, you're on your way to making a dimes-into-dollars machine).

However, these are the easy things to do with game mechanics.  I'm much more interested in game mechanics that make a product inherently better so that you have natural sneezers.  Users who talk about and promote your product because the product is so damn good are the best kind of users to have; they're much more valuable than incentivized users, because you can only throw so many incentives at users before you've exhausted them.  

So what are the game mechanics that make a product inherently better?  How can you use game mechanics to get true sneezers?

The first example of game mechanics that make a product better are interactive tutorials that make it easier for users to understand and use your product.  The most notable of these is Microsoft's Ribbon Hero.  Ribbon Hero on-boards new users to Office 12, making them more productive within the Office Suite even after they have stopped playing the Ribbon Hero game.  If users want, they can share and compare their scores with others, but that's not the key mechanic.  The increased productivity is the end-goal and the immediate reward.  Productive users of Office 12 are much more likely to be effective sneezers than users who are motivated by incentivized referrals from the game.

The second example of game mechanics that make a product better are those mechanics that increase an individual's utility as they add additional information to the site.  This particularly works for applications that are built upon collections - applications like Delicious, Mint, and Google Reader have increased utility to the user as the user adds bookmarks, accounts, and RSS feeds, respectively.  Game mechanics that reward users for engaging in these actions - actions that they should be doing anyway since they're already users of the app - benefit users directly without the need for the trappings of karma.  (None of these applications, by the way, use game mechanics anywhere near as much as they should.  In Delicious' case, in particular, it's a crying shame.)

At oneforty, I spend a lot of time thinking about how we can use game mechanics to have a better inherent experience for our users.  Most new visitors to oneforty aren't even aware that there are such things as "Twitter tools" or "Twitter apps".  These visitors might be familiar with a Twitter app on their iPhone or Blackberry, or maybe even a desktop client, but they're completely unaware of the hashtag monitoring tools, networking apps to find new people to follow, or entertainment sites that show off people's funny tweets (among 2,500 other Twitter tools and apps).  Well-designed game mechanics that help educate and expose our users to the best Twitter applications and tools for what they don't even know that they're interested in is a true win-win for users and for the Company: they're mechanics that will create natural sneezers rather than incentivized referrals.

Please note that you can't just bolt on game mechanics onto an existing application or experience; if you do, you're much more likely to end up rewarding behavior that you don't want - you'll end up with users gaming the system to the detriment of other users.  This is what happened with Digg's Leaderboard, for instance - they ended up having to kill it because a small subset of users were more motivated by their rank than by the rewards they received from natural interaction with the site, resulting in a "less good" experience for all other users of the site.

There are probably other ways that game mechanics can make web applications better that I haven't even considered - but retention, referral, education, and engagement should be more than enough to convince you that you need game mechanics in your app.  If you're still not convinced of the utility of game mechanics for your web applications, go read the interviews that Josh Porter has done with Amy Jo Kim and Bryce Glass.  If you want to leave money on the table, fine by me.  Makes my job to beat you in the marketplace that much easier.

(1a) Especially if you study auction theory for a living.  You think eBay proves you right about everything.  You're wrong for many reasons.  To start, see (1b).
(1b) For all values of "you" that are not Scot Wingo. 
(2) For all values of "you" that are not Danc, Randy Farmer and Bryce Glass, Amy Jo Kim, Raph Koster, Jane McGonigal, Jesse Schell, or David Sirlin.

 

]]> tag:sachinagarwal.com,2013:Post/46011 2010-02-25T15:55:00Z 2024-02-23T12:38:29Z The Evolution Of The Customer Development Interview

Back when I did my very first customer development interviews, way back in 2007 for an aborted Slacker-player-over-cellular-networks company, they were called "requirements gathering".  Go out, get a big list of requirements, write a product spec, release, and bask in your glory.  Pretty simple.  

Needless to say, my approach and techniques since those halycon days has changed a lot.  Now I believe that users have no idea about solutions; they only know about their problems.  

Inspired by Cindy Alvarez's (@cindyalvarez) post, here's a real-world list of questions I recently asked a number of potential oneforty users and my thinking behind each question:

1) How/why do you use Twitter? (Make sure to push on business/personal use to understand both)
2) Tell me more about what you think Twitter is (For others in your industry / average users).
3) How has your use of Twitter evolved?  Are there any particular things about Twitter that suck?
4) Do you use any tools for Twitter or other social networks?  (Note that I don't ask where they find Twitter tools; I don't want to assume that they go looking at all.) 
5) What sorts of Twitter tools would be so useful that you'd be willing to pay personal money for?  (The personal use question - do they *really* want/need Twitter tools?  Consider it a pre-emptive "how disappointed" Sean Ellis question.  If the answer is "none", it's the equivalent of a less than 40% "very disappointed" response.)
6) What sorts of tools would you be willing to spend your employer's money on?  What is your budget?  Do you need a Purchase Order or approval above a certain threshold?  (Pricing discovery to gather lower stakes information about willingness to pay - with OPM.)

One of the things that you'll note is that there are only six questions.  These are the six questions I want to get answers to; they don't have to come in this order, but I want to try to get to them.  They serve as jumping off points for each stage of the interview, not the next step.  If the interviewee goes off on a tangent, it is my job to follow her there.  I can cut her off if and only if we're running short on time.  If time's not a worry, exhaust the tangent, then and only then move on to the next kickoff question.

With these kickoff questions, I start as far back as I can so I don't assume that the problem I'm trying to solve is actually a problem for my user base.  Even if I've done previous interviews and come to a pretty firm problem statement, I always start from the beginning to try to get the user to come to that same problem statement organically.  If the user doesn't come to that statement, I abort the script and dive into the problem.  

I also never, ever suggest or test potential solutions during customer development interviews.  Once upon a time, I did.  I would suggest a number of potential solutions to my interviewees and ask them to rate or rank them.  Turns out they always chose the solution I secretly liked the best.  What a coincidence, that.  It almost convinced me that I could skip the whole discovery process because my market research (read: Googling) was so good.  

Maybe I'm not as good as others who conduct these sessions, but I had a hard time shielding my biases when talking about solutions with interviewees.  Users don't know what solution is best until they actually use it - they only know their problems.  So I stopped polling potential solutions and now I rely on interaction data and metrics by actual users of the actual product or MVP. 

Again, my magic phrase in every customer development interview is "that's interesting - tell me more."  (Note: this also works great on dates.)  Also, I never ask a yes/no question, I let pregnant pauses hang in the air until they're almost awkward, and sometimes I'll even willfully mischaracterize a interviewee's opinion to elicit their response - all in hopes of getting the interviewees to keep talking so I can get every last insight from the brief 30-60 minutes I have with them.

Hopefully, seeing a real, live customer development script used by a real startup with real potential users has been useful.  Fire away in the comments if you have any questions, concerns, or suggestions on possible new approaches.
]]> tag:sachinagarwal.com,2013:Post/46013 2010-02-22T16:37:00Z 2024-02-23T12:38:30Z On Incorporation - I Still Say Hold Off Until You Have The Cash To Spare

In my last post about startup cash management, smart people like Chris Dixon, Manu Kumar, George Grellas, and the Hacker News cabal all disagreed with my advice to put off incorporation until you absolutely have to. 

Every single benefit of incorporation cited by these people is correct.  However, I still caution against jumping right into incorporating from day one.  This is because when you incorporate, you should do it right and doing it right isn't a drop in the bucket.  Also, when you incorporate, you're subject to your state and federal taxes, Delaware franchise tax, foreign business license in the state where you're headquartered, and other administrivia hassles.  But keeping in line with the last post, I'll stick to the cash.

When I founded Dawdle, I engaged a local Chicago law firm that was well-regarded in the startup community to do a simple incorporation.  It ran us about $1,500.  I didn't want to use LegalZoom to do the simple incorporation because I wanted to develop a relationship with my lawyer that I could leverage to make introductions to local potential investors when the time was right.  

However, soon after incorporation, I realized we needed an option plan for a potential employee we were recruiting.  Because my lawyer had set us up as a subchapter-S Corporation, he was unfamiliar with how an option plan should be structured for an S-Corp and ended up having to do substantial research to get it done.  The option plan ended up costing us an additional $6,000.  There are additional pieces of advice that we got that was incorrect, the sum total of which ended up costing the company over $40,000 in additional, unnecessary legal expenses (hindsight is 20/20).

Based on this experience, I strongly believe that any company that may potentially seek institutional money should use a top-tier Silicon Valley partner at a top firm.  It doesn't matter where your company is; get a Valley partner.  Many of these top tier firms have "off the shelf" packages that include much more than incorporation - some include the option plan, convertible note template, NDA form, and other commonly used documents.  You can see a sample of the bare minimum set of incorporation documents at TheFunded.  If you hold off on incorporating yourself and you get into a top-tier accelerator such as YCombinator or TechStars, they will also incorporate the company, with the whole kit and kaboodle, for you.  YC even tells potential applicants to not incorporate "if you can avoid it".  You probably can avoid it.

If you aren't going the accelerator route, and you've decided the time is right to incorporate, you'll need to get a full incorporation package from one of these firms.  This package runs approximately $5,000 or so from a top-tier firm.  (Feel free to let me know if this has gone up since the last time I checked.)  Generally, a paralegal will just fill in the blanks and the partner you choose will do a cursory glance, but the partner is 1) the person who can answer your questions without any research, saving you money and 2) the person who will be making introductions to potential investors.  It's important to pick your partner carefully.  Thankfully, my ex-Broadview colleague Giff Constable has a great list of lawyers that do good work with internet startups.  If you want specific thoughts on how to pick a startup lawyer, read Mark Suster's post on the topic (even though he's in the "incorporate yesterday" camp, it's still a great post).  

My personal recommendation for startup incorporation and general corporate work is Yokum Taku of Wilson Sonsini.  In addition to being wicked smart and a straight shooter, Yokum's blog, Startup Company Lawyer, probably already answers the first five questions on the tip of your tongue.  Past that, any answer to something you can't find on the blog is going to be consistent with what he's already written, saving you from conflicting advice.  You can read my rambling notes from my conversation with Yokum about incorporation at my personal blog.

I also don't believe that you should take advantage of deferred legal fee loan programs offered by some Valley firms because you're locked into working with that firm until you've closed your Series A.  If the partner leaves, the firm overbills against the deferred fee loan amount (usually $25,000), or the relationship doesn't work out for some other reason, you don't want to be stuck.

Because "doing incorporation right" is a rather large expense, I don't believe that entrepreneurs should incorporate until they are playing with other people's money.  Solo entrepreneurs need to watch every dime and I firmly believe that small founding teams can set the parameters on a napkin when starting out, to be codified when the time demands it.  If you can't trust your co-founders to stick to a terms written on a napkin, you've got bigger problems to tackle.  Sure, all else being equal, you do want to incorporate as soon as you can to start the capital gains clock, minimize the value of founder shares, and all the other benefits or early incorporation.  But $5,000 is still $5,000 and cash is king.

 

]]> tag:sachinagarwal.com,2013:Post/46015 2010-02-15T14:37:00Z 2024-02-23T12:38:31Z Three Things To Put Off As Long As Possible For Your Startup

While there are often investments that should be made upfront, oftentimes new founders and new startups will waste money and time on things that they shouldn't.  I sure know I did during my first go-round.  Don't make my mistakes.  Here are three things you should put off as long as possible:

Don't incorporate until you're playing with Other People's Money.

There are two kinds of other people's money.  The first is Other People's Money - investment dollars from outside sources: friends, family, angels, VCs, certain grants, and so forth.  The second kind of other people's money is even more important - paying customers.  Any concern about your personal liability is misplaced; if your site has a bunch of Google AdSense ads, no one in their right mind is going to sue you.  You're going to need to be incorporated to deposit any investment (if you're so lucky) and you'll need to be incorporated to get an internet merchant account.  You can probably get by with a PayPal account (under the domain of the site; don't use your personal PayPal account) for a while, as well.  And don't worry about the intellectual property you create before incorporation; you can always assign it to the company later.  That's what Google did when they got their first check before they were even incorporated.  

Don't do any paid user acquisition until you can calculate your CAC and LTV.

It's very, very tempting to "experiment" and "test" various paid customer acquisition channels.  You start with AdWords, then do some cheapo banner ads on a couple of ad networks, and soon you're hooked on some hard affiliate stuff and paying thousands of dollars a month to an Outsourced Program Manager.  AdWords are a gateway drug to unprofitable user acquisition.  Only start throwing your dimes at paid acquisition when you're damn well sure your dimes-into-dollars machine is humming nicely.  And you only really know it's humming nicely until you have enough metrics around your unit economics - what your costs are to serve every new customer, and how much she's worth to you in revenue (if you're rigorous, gross profit).  These numbers have to come from real users using your real product; they cannot come from a financial model - that's just guessing.  Get hard data.  Then and only then can you think about customer acquisition channels that have direct costs above zero.  Until then, you're much better off engaging in inbound marketing - making remarkable content (you blog regularly, right?) and a remarkable product - and really thinking about your on-site SEO.  

Don't hire a PR agency, part-time sales force, or any other outside consultant.

You want to be focused on the product.  You get the market well from your industry background and you know you have your problem statement nailed from your in-depth customer development interviews.  You need to focus on building your product solution hypothesis and you just can't be bothered to do the legwork of developing relationships with bloggers, press, potential customers that you don't know, or potential business development partners.  You met some smooth business guy at some tech meetup who says he can do all this for you for a small amount of cash and equity.  Seems like a good deal, but it's not.  Managing someone who isn't a full-time employee and who isn't as invested in the company's success as you are is a path towards hurt feelings and wasted time, energy, and cash.  There are certainly times and places for help in all these matters, but pre-launch isn't it.  (The only exception is if you've raised millions of dollars in Other People's Money and you can afford to pivot your product, positioning, and or price if your big splash fails.)  You probably won't be as good as someone whose work life is dedicated to press, PR, sales, marketing, or whatever - but you're going to be a lot cheaper and you may not be all that bad at it yourself.  A passionate and articulate founder can go a long way - I was able to do all of this myself, getting into TechCrunch, landing new customers from cold-calling, and striking business development deals.  You can too.
]]> tag:sachinagarwal.com,2013:Post/46016 2010-02-01T14:42:00Z 2024-02-23T12:38:32Z The Other Stuff That's Not Product That You Need To Build Early

One of the things that I didn't think about before I started my first startup were all the parts of the infrastructure that weren't product.  They've also consistently been the things that other entrepreneurs forget about when they come to me with their "ohmygodIhavethisidea" ideas.  They're also vitally important because they allow the founding team to actually execute the pivots you'll need to execute quickly, intelligently, and without sacrificing development of the actual product that you're trying to pivot.

The first part of this infrastructure is the admin panel.  This admin panel is what will allow you to do troubleshoot for customer support, engage in administrative actions, and audit your payments in and out of your system without having to mess around with your production database.  I cannot impress upon the first-time web entrepreneur just how important it is to have a robust and well-functioning administration system.  When you're building your administration system, it is important to make sure that you can disable and delete users, view and change payment regimes, and reset user passwords (because they will invariably not be able to find your reset password form and they *will* e-mail you).  If your product takes off and you find yourself bringing on board a business person, they're going to be tasked with support, and you do not want whoever is doing support interrupting engineering to complete basic Level 1 and 2 customer support.  If your product really takes off, you may find yourself bringing on board a dedicated support person.  If you wait until traction to build out your administration panel, you're going to be ceding ground to the competitors that spring up when they see your traction.  Django's admin panel is so well developed that you may not have to build your own, and is a reason to strongly consider the framework if you're familiar with (or interested in) Python.  Even as your product pivots, the administrative support tasks generally don't.  

Make sure you've built a functional admin panel before you launch.

The second part of the infrastructure you're going to want to build (or implement with WordPress, Melody, or some simple bare-bones CMS plugin that someone has already released for your framework) is a content management system (CMS).  It should not take a push of new code to change the static content on your website.  Holding up basic changes and updates to your about section, marketing pages, terms of service, privacy policy, and help section because you need to wait on some guy to merge his branch into master (or check into trunk, or whatever your VCS calls it) is silly.  You don't want to have your marketing person or intern create some hot new copy then have to hand it off to engineering to copy/paste it into code and markup each and every link, line break, and image to get it live on the site.  It makes the business side frustrated with the pace of changes and the engineering side of the house gets frustrated at having to do such menial tasks when they could be building some crazy awesome technology that is your core long-term competitive advantage that you brought them on board to do.  Again, some web frameworks have bare-bones CMSs or templating engines built into the system out of the box.

Make sure you've built (or implemented) a content management system before you launch.

The third part of the infrastructure you need to build is a good metrics dashboard and logger.  The standard piece of advice is "pick a few metrics, but log everything".  The idea of logging everything when you've decided to focus on just a few Key Performance Indicators (KPIs) can often cause heartburn.  But it's relatively simple; build a separate table (or database) that automatically logs all the various things that users do.  Don't worry about duplicating writes that you're doing elsewhere in your database.  Having a separate table (or better, database) will save ou on reads and JOINs and whatever else when you need to dig in.  The one thing the logger needs to do is be *auditable* - that is, you need to be able to say that user_id=8273 did x on page one, then y on page two, then z on page three.  These loggers are so important that there are venture-backed startups that exist solely to help other startups collect these logs and make sense of the data they're collecting.  The KPIs are, of course, actionable metrics that exist in the aggregate, but the ability to see what any individual user has done will help you troubleshoot, audit, and make hypotheses for new features and functions.  Also, one quick note: Google Analytics aren't auditable at the user level nor actionable in helping you make forward-looking hypotheses.  Everything in Google Analytics is backwards looking.  The product is free as in beer and all-but-free from an engineering cost perspective, which is great.  GA does give you the ability to find exception cases and the basic funnel visualizations can be useful for getting conversion metrics up and running quickly, but don't kid yourself - Google Analytics is mostly data porn.  

Make sure you build a real metrics dashboard and implement a real logger before you launch.

]]> tag:sachinagarwal.com,2013:Post/46018 2010-01-25T12:57:00Z 2024-02-23T12:38:33Z Product Development Starts With A Hypothesis, Not A List Of Requirements
For a startup to be successful, the founders (or whoever owns product) need to have strong opinions about both the market problem and the product solution.  Sometimes - maybe even often - this means ignoring your users.

That doesn't mean that you don't listen to your users - even companies as insular as Apple and Nintendo do some work reaching out to others.  Apple designs for others; they just don't do formal market research. Nintendo has "random employee kidnappings".  But if you don't have the luxury of having the singular, strong editorial voice that Apple gets from Steve Jobs or that Nintendo gets from Shigeru Miyamoto (or that 37signals gets from Jason Fried), you probably have to set yourself up to conduct lots of experiments.

Do you remember your scientific method?  If not, here's a really, really good primer on the scientific method.  Never mind that it's written for children - it's good.  Here are the steps:

Ask a Question
Do Background Research
Construct a Hypothesis
Test Your Hypothesis by Doing an Experiment
Analyze Your Data and Draw a Conclusion
Communicate Your Results

If you've noticed, we've actually done the first two steps.  Asking a question is finding a market you're interested in.  Doing the background research is figuring out the problem statement.  The next step, where we are now, is to construct a product hypothesis.  Remember, when you test hypotheses, they're falsifiable - you only can find out what *doesn't* work for sure.

Below is a great slide by the guys at Watching Websites:

What this means is that you have to keep pivoting until you find yourself in product/market balance.  Too bad that every product hypthosis and every pivot costs you in time, money, blood, sweat, tears, and all the other various inputs.  You can't iterate forever; you're going to run out of one of those inputs (most likely money).  

The only way to reduce your time in this cycle is to make a really good hypothesis from the get-go.  If you're not playing with other people's money, then you better make sure that you don't have to pivot at all.

Listen to your users on the problem statement - they can feel that pain.  But listen to your judgment on the first product hypothesis - there's a reason you want to solve this problem, and it's not because you're a stenographer.  It's because you see something everyone else doesn't.  Asking better questions allows to more clearly see what others - even your users - may not.  Here are some better questions to ask:
  • Are your customers time poor or just frustrated with the time they have to spend on a task?  
  • Are your customers cash poor or not seeing value for their money?  
  • Are your customers status poor or are they embarrassed to use your product?  
Customers often will tell you one answer, but they often mean another.  It's your job to 1) ask better questions, 2) read between the lines of the answers, and 3) use your judgment to make a really good product hypothesis.

Dropbox doesn't save a large amount of time; but it makes saving/retrieving files thoughtless.  RC Cola just didn't have the status of Coke (or Pepsi); you can always get store brand pop if cash is king.  

If you better understand the true pain, you'll make a better product hypothesis.  Dropbox is great because it "just works", but it took Drew to define what "just works" meant above and beyond Mozy, Carbonite, XDrive, and every other storage in the cloud provider.  RC Cola "tasted better" (they won every blind taste test they sponsored, supposedly), but it turned out that people didn't pick their pop based on taste.  They picked it based on status, nostalgia, inertia, (and as the supermarkets found out) price as a tiebreaker between Coke and Pepsi.  Remember, your users may lie to you.  

Users may not know what they want in a product until you show them.  But they always - always - know their problem.  

(That's what Steve Jobs is so damn good at.  He keeps using Apple's prototypes until the stabbing pain of the problem Apple's identified goes away.  Then and only then does he bless a new device/program/feature.  See copy/paste on the iPhone.)  

Your judgment on how to solve the (real, maybe unstated) problem of your potential customers is your initial competitive advantage.  Your ability to get a product hypothesis out there that your users don't immediately reject (and hopefully would be terribly disappointed if you took it away) is what gets you paid the big bucks (when you exit).
]]> tag:sachinagarwal.com,2013:Post/46021 2009-12-18T16:11:00Z 2024-02-23T12:38:35Z Because You Hate Your Family, or, Stuff To Read Over The Holidays


Let's face it - you love your family, but that's today, before you see them.  By Boxing Day, you're going to want to curl up in the fetal position as your uncle yammers on about the Cleveland Browns.  As long as you're hiding out in the basement, or drinking alone at the depressing corner bar, you might as well do something productive.  Here's a special "must read" list of books, blogs, and presentations while you stew about in the hellhole your parents call home.

Steve Blank - the granddaddy of them all.  Steve coined the term "customer development" as a parallel process to product development.  Steve's blog is fascinating (the man has done some very interesting stuff), but the must-read is his book, Four Steps to the Epiphany.  In particular, it specifically talks about how to work when you're disrupting an existing market versus when you're building a new market for your product.  You have to read Four Steps first.

Eric Ries - the new hotness.  Eric took Steve Blank's class, learned about customer development and had the insight to pair the customer development process with extreme programming to create a continuous improvement/feedback loop.  Eric coined this process "Lean Startup".  Eric's blog is great, but he has a MVP beta of his posts in an e-book, which may be easier to read.  You should buy it now, since Lulu might take a while to ship.

Dave McClure - the pirate.  Dave's AARRR model is the best compilation of every driver you need to measure.  You can't just slap on Google Analytics and think you're done, folks.  He's kind enough to post new versions of his Startup Metrics for Pirates presentation as he revises it (video of an older presentation), but Dave's blog (while a bit all over the place) is chock-full of great insights.

Sean Ellis - the Glengarry leads guy.  You've built it; now what?  Sean only works with companies that have raised venture money and already achieved product/market balance (see why I don't call it product/market fit).  You don't even have a product yet.  Why is he a must read?  Because his approach to measuring product/market balance is better than anyone else's.  His startup pyramid tells you each necessary step before you can turn on the growth spigot.  Sean's blog is updated less frequently, but every post is great.

Andrew Chen - the savant.  Andrew's spent a lot of time thinking about viral loops.  Virality isn't something that just happens to great products - although that does happen from time to time - virality is something that can be baked into your product's DNA.  Andrew's blog is full of posts that go into viral loops in detail, and it's much easier to read now that he made a special categorized list of posts for you.  You can't possibly read all of this before you come home, so I'll stop there.]]> tag:sachinagarwal.com,2013:Post/46022 2009-12-14T13:38:00Z 2024-02-23T12:38:36Z Requirements Gathering Is Not Customer Development - But It Does Define The Problem Statement
Customer development is all about testing your hypotheses.  This is the Lean Startup diagram by Eric Ries that you (should have) seen before:

Let's start at the beginning and focus on the Customer Development Process, and in particular, the Customer Discovery loop at the very beginning:

Steve Blank has defined the Customer Discovery loop as four parts: Author creates Hypotheses; Author Tests Problem Hypothosis; Author Tests Product Hypothesis; and Verify, Iterate, and Expand (slide 11):  

http://www.slideshare.net/venturehacks/customer-development-4-customer-discovery-part-1

The problem that I've seen time and again is that people fall in love with the process and get so caught up in the notion that they can just iterate through their hypotheses that they create terrible hypotheses.

This is dumb.

People - especially smart people - love the idealized notion of "iteration" but, in practice, it turns into "throw shit against the wall and see what sticks".  Then they realize the hypothesis testing iteration process takes time and soon, they start to believe they're making progress merely because time has progressed.  Then they start product development too early.  Then they... well, you can guess what happens from there.  Don't do that.  Spend just a bit more time up front.  Understand the problem you're solving first, so you can make better product hypotheses from the get-go.

Simplify the Customer Discovery loop into two parts: requirements gathering to define the problem statement, and hypothesis creation that you test with actual potential customers in the Customer Validation step.  Here's the difference between me and Steve: you don't iterate on the problem hypothesis - the problem statement is a fact that you have to suss out from your requirements gathering.  Your job is to suss out 1) whether or not there is a problem, 2) how big of a problem it is, and 3) how big the market is that's affected by the problem.  (You don't want to develop a product to solve a problem that won't return your investment of time and money.  This is the result of jumping into the "test product hypotheses" too early.)  These are all verifiable facts; the problem statement is not a hypothesis.  Anyone else going out to the same customer base and asking the same questions will come up with the same problem statement that you do.  

Defining a problem statement really isn't all that hard.  Sure, you can read research reports and get market sizes and all that jazz, but the one prerequisite you must do is really quite simple: talk to enough potential customers until you've reached some point of diminishing returns.  (You'll know it when you get there.)  Often, this doesn't take more than a dozen.  If you really want to be rigorous and pretend you've gotten to statistical significance, talk to 30 people.  Here's a simple list of questions:

* How do you do [x]?
* What's the worst thing about doing [x]?
* How much extra time/money/energy does it take to deal with the worst thing about [x]?
* If I could solve the worst thing about [x], how much money would you pay me?  (Note that if it costs money to deal with the worst thing about [x], theoretically you could charge up to 99.9999% of that amount.  Theoretically.)

Everything else is optional.  My trick is to keep them talking with one simple phrase: "that's really interesting.  Tell me more."  You may even (read: you will) get product insights from your problem statement questions.  

Eventually, you should be able to hone in on what exactly is the jabbing pain in your customers' eyes.  For salespeople, it was that they had to input all their information into ACT and then do extra work when they got to the office to share it with their manager (Salesforce.com).  For runners, it was that the shoes they had weren't really comfortable for running long distances (Nike).  

The iteration comes only with the product hypotheses - and I use the plural because you want to consider all the different product approaches that can solve the problem.

Let me finish with this: you don't define the Minimum Viable Product.  The market does.  At the beginning, your job is to form good product hypotheses that you test.  These product hypotheses spring forth from spending the time in requirements gathering to sharply define the problem statement that you are going to solve with whatever your product solution ends up being.  

If you've done the work to define a robust and accurate problem statement as a result of a rigorous requirements gathering process, you'll receive much better market feedback when testing your product hypotheses.  Eventually, when you start market testing your alpha product, you'll have a much shorter process getting those orders/eyeballs/whatever to determine you've hit your MVP.  

Next time, I'll talk about when to follow and when to ignore your customers when defining and testing your product hypotheses.
]]> tag:sachinagarwal.com,2013:Post/46024 2009-12-13T17:06:00Z 2024-02-23T12:18:41Z Bring Back The Evening Paper!

Commodity national news is dead.  Newspapers are dying.  The AP wire on Yahoo News (or Google's more heterogenous and more cluttered version) and CNN.com are "good enough" that all other services providing "just the facts, ma'am" provide no incremental value.  Most observers recognize that this leaves a void in the local space, and predictably you see newspapers retrenching into their neighborhoods, fending off competitors like Outside.in, EveryBlock, and ESPN's local sites.

But newspapers have so much more than just news, and that's why I love to read them when I visit my family in St. Louis.  I find value from the comics, the circulars, the coupons, the crossword, and, yes, the columns.

But why do I only read the paper when I'm visiting my mom and grandparents?  Why, the NYT and Tribune executives plaintively scream, why oh why don't I subscribe where I live?  

My biggest issue is delivery.  At my former apartment in Chicago's Logan Square, I had no faith that any paper I paid for would still my at my apartment building's doorway when I woke up in the morning.  I even subscribed to the free Saturday Redeye and it never showed up.  My new apartment is one of those old houses in a better neighborhood near Somerville's Davis Square, and I'm considering getting the Sunday Globe and/or Times.  But only on Sundays.

But here's the other delivery problem beyond just getting what I paid for: when the paper comes in the morning, I don't have time to read it.  When it comes in the morning, half of it is stale the minute it hits the stoop because I read that information online the previous day and the other half is stale by the time I do have time in the evening.  It's completely useless to me (again, except on the weekends, where my mornings are leisurely and my evenings are packed).

But this can be solved with a change to the content and a switch in delivery time.  An evening paper that focused on analysis and columns, rather than the stenography that passes for reporting, would be fantastic.  I could indulge with 15-20 minutes attempting the crossword; I could read the comics over a cup of tea (or a glass of bourbon or whatever your racially- and temporally-appropriate stereotype is); and I could browse through columns and analysis of new and interesting topics that aren't top of mind during the workday.  

Giving up all pretense of presenting the bare facts of news would free an evening newspaper from the tyranny of the mid-day deadline.  An evening paper as I envision it wouldn't compete with the evening news hosted by Brian Williams, Katie Couric, or Diane Sawyer.  It wouldn't compete for the advertising dollars of incontinence products and life insurance.  It would be more alive and it would be a better vehicle for television, movie, and other entertainment advertising than the morning paper or the evening news.  

A new evening paper would require shunting aside any pretense of being balanced in favor of presenting a wide range of opinions (I think the Atlantic does the best job of this on the national blogging/magazine side), but it could easily be done given the newspaper companies' existing delivery infrastructures and brands.  

And that's the way it is.

One related note, since this is being passed around this morning: I don't in any way believe we are nearing the end of hand-crafted content.  Just read Ezra Klein, Matt Yglesias, Felix Salmon, Ta-Nehisi Coates, or any of the other brilliant writers who pump out fantastic free content with real, actual reporting on a near-daily basis, and you'll realize that at the national level, there's a plethora of great, handcrafted content.  (BTW, are there any female writers - aside from Digby - who I should be subscribing to?  Megan McArdle lost me a while ago.)

Maybe it's different if you're checking TechMeme every 15 minutes to see who gets "credit" for "breaking" some "story" about some "gadget", but the stuff that I read is great.  Hell, just follow Paul Kedrosky; it's like the dude was put on this earth to create and share interesting shit that's perfectly up my wheelhouse.
]]> tag:sachinagarwal.com,2013:Post/45988 2009-12-07T04:14:00Z 2024-02-23T12:18:41Z Forget Product/Market Fit; It's All About Product/Market Balance

In my time watching and working with startups as an investment banker, VC, entrepreneur, and consultant to startup teams, the notion of product/market fit has gone from a new insight to conventional wisdom. 

However, product/market fit never seemed like the right notion to me. 

After doing some thinking and working very closely with a handful of startup teams in the last year or so, I realized that a team isn't looking for product/market fit; it's looking for product/market balance.  The notion of balance highlights the delicate task of getting a product to meet a market's needs:

Even if a team builds a robust, stable product offering, the product can fail to meet the market's needs and the product lands with a thud:


The notion of balance serves another purpose; balance provides a basis to extend the metaphor into the other important parts of a product experience: positioning and pricing.  Here, you can see how the product supports positioning:

Likewise, the product + the positioning supports the price structure:


If the product itself balances with the market's needs, poor positioning can upset the balance and lead to everything tumbling down:

And a poor price structure can lead to defeat even with the right product and positioning strategy:


You can't decide to position a product as premium if the product is shoddy.  Likewise, the price you choose reinforces and strengthens your positioning - you can't have a "value" product that is priced higher than your competition.

Startup teams must make sure that everything about their product, positioning, and price structure maintains the delicate balance necessary for market success.]]> tag:sachinagarwal.com,2013:Post/45993 2009-09-17T14:53:00Z 2024-02-23T12:18:41Z Illinois' So-Called Tech Leaders Have Failed The State

So, Chicago's lacking in tech leadership, says a columnist in the Chicago Tribune.  No, it's not, respond the heads of various tech organizations in Chicago and the State.  As someone who's founded a startup here in Chicago, I'm certainly more inclined to agree with the Trib columnist than with the panel.  However, I'm also a policy wonk - so I decided to take a look at the data to see who's right. 

After examining the data, it is clear that the leadership at DCEO, the ITA, World Business Chicago, IBio, the NanoBusiness Alliance, and the ISTC has failed.  While the organizations that signed the rebuttal may do many things, as they list in their bullet points, it is clear that the outcomes one would find from successful leadership just are not there.  What they're doing is not working, and there are no signs of improvement in Illinois' technology competitiveness, no matter how you slice the data. 

The best independent, objective data I could think of was venture funding data for startup companies[1].  The assumption, of course, is that venture funding is very highly correlated with technology leadership and serves as a legitimate proxy.  The focus on startups is because organizational leadership can most help the smallest of companies and early entrepreneurs as they jump into the deep end.  (However, I've presented the overall data as well to avoid charges of bias.)  Employment figures are fuzzy - you probably don't want to include CDW salespeople in a list of technology employees, for example.  I gathered state-by-state data from PricewaterhouseCooper's MoneyTree Report.  My source of data was the State Science and Technology Institute (SSTI).  SSTI's Venture Capital data site further breaks down the MoneyTree into easy-to-use state-by-state data[2]. 

You can see the data for Illinois at the SSTI page for Illinois.  The data show that Illinois companies have raised roughly $440 million per year since the last bubble year of 2000, which sounds decent, until you realize that Illinois companies only attract, on average, 1.59% of all VC dollars - across all stages - raised in the US.  The average number of Illinois VC funding deals per year for the 2001-2008 period is 70.5, which is just 1.99% of all deals in the States.  (Here's the page for the US data.)

These numbers aren't any prettier for Illinois startup companies.  For the 2001-2007 period (there is no by-stage data for 2008 available on the SSTI state-by-state breakdown pages), Illinois startups raised a total of just $56.7 million, a pittance of just $8.1 million per year.  It's even worse on the per-deal statistics: Illinois had a total of just 32 startup fundings for the entire seven-year 2001-2007 period.  That's an average of just 4.6 startup fundings per year.  The total startup funding across the entire US for the 2001-2007 period was $5.6 billion, with a total of 1,845 deals over the seven-year span.  That's an average amount of $740 million per year and average number of 264 startup fundings per annum across the entire United States. 

That means that Illinois companies, on average over the seven years, raised just 1.74% of the seed money and did just 1.09% of the startup deals done nationwide.  This, despite the fact that Illinois has 4.24% of the US population.  For just the smallest startups that organizations like DCEO and the ITA should be helping the most, Illinois is getting less than half of the dollars and doing less than a third of the deals that you would expect for a state of its size.  (It's still less than half for dollars and deals overall, as well.)

The numbers are just as embarrassing when you look at Illinois relative to the other states in the nation rather than just the United States as a whole:

(Slide 4)

(Slide 2)

Illinois ranks an average of 16th among the 50 states, DC, and Puerto Rico in startup dollars for the 2001-2007 time period.  Illinois did a bit better and averaged a rank of 13th in startup funding deals for the period. (Illinois' median for dollars was 14th and its median for deals was 11th.)

However, again, these figures favor the larger states over the smaller states; i.e. you'd expect California to be the leader in both categories (and it was) since California has the most people.  To really compare, we must look at the states on an apples-to-apples basis by looking at the per capita figures: 

(Slide 3)

(Slide 1)

It turns out that the per-capita figures are even worse for Illinois than the non-normalized figures.  Illinois averaged just 20th amongst the 50 states, DC, and Puerto Rico in startup dollars per capita for the 2001-2007 period.  Illinois averaged a pitiful 23rd in startup deals per capita for the 2001-2007 period.  (Illinois' median for per-capita dollars was 18th and its median for per-capita deals was 24th.)

States that consistently beat Illinois in the rankings include Colorado, Texas, and Washington, to say nothing of California and Massachusetts.  However, even states like Maryland and Pennsylvania consistently beat Illinois' rankings on all four measures - startup dollars, startup deals, startup dollars per capita, and startup deals per capita - year after year after year.  On a per-capita basis, states like Connecticut and even New Mexico consistently outrank Illinois in dollars and deals.

By the way, Illinois' average rank in dollars for 2001-2008 (remember, SSTI has total figures for the 2008 year) - regardless of stage - was 13th, and its rank in deals was also 13th.  Again, the average per-capita rankings - the better apples-to-apples comparison - was much worse.  Illinois' average per-capita rank in dollars raised for the 2001-2008 period was 22nd, and its per-capita rank for deals done (again, for all VC deals regardless of stage) was also 22nd, both barely over the median - a median artifically low due to states like Wyoming and Alaska that see no venture activity, year over year.  Illinois is actually below the median when you exclude the inactive states - shameful.

That's just not leadership.

The data are clear - our technology organizations have failed to do their jobs and changes need to be made to make Illinois more hospitable to technology startups if the state has any chance at competing in a 21st century economy.  

Footnotes:

[1] Let me be clear: I fully acknowledge that one can grow a startup without raising outside funds.  However, I believe that those are exception cases, not the rule.  More importantly, I believe the environment that allows for funding is also the best environment for a bootstrapped startup.  In other words, the plural of anecdote is not data.

[2] Data geeks: I fully acknowledge that the MoneyTree data excludes deals done solely by individual investors (angels); however, 1) this is the best objective data I could find and 2) my guess is that individual investors would only further demonstrate the conclusions I'm about to make.  Feel free to grab your own source MoneyTree data and run it yourself.  I couldn't find industry breakdowns by state, and I believe that the overall data is plenty clear about the conclusions to be drawn.

]]> tag:sachinagarwal.com,2013:Post/45995 2009-05-05T01:11:00Z 2024-02-23T12:18:41Z This wasn't even a black swan - how the non-TARP Chrysler creditors made an elementary mistake

The goings-on on various econoblogs regarding Rattner supposedly threatening the creditors who didn't go along with the Chrysler debt cramdown is one of the more generally well-written "you people are missing the pot" things I've read in a long while. 

Chrysler, of course, filed for a Chapter 11 bankruptcy reorganization after all the creditors could not come to an agreement.  The Obama administration, by way of the Treasury Department and Steve Rattner (the "car czar"), managed to get the four largest lenders (who had no choice, as they're being propped up by TARP funds), the UAW, and Fiat on board.  But the agreement failed to get enough support from all stakeholders, and President Obama all but blamed the non-TARP debtholders for the bankruptcy filing during a news conference the morning of Thursday, April 30. Of course, the non-TARP guys objected to this characterization.  Later in the late afternoon April 30, Perella Weinberg, one of the leaders of the non-TARP group, came around and supported the administration's plan, but it was too late.   The bankruptcy was set.  A lawyer representing the non-TARP lenders said that Perella Weinberg only came around because of threats made by the administration to bring negative PR to bear by way of their supposed influence over the White House press corps.  Perella Weinberg, of course, denied this.

On Finem Respice, Equ Privat wrote that there was a more sinister threat - that the administration did not just threaten bad PR, but would bring the IRS and SEC to bear upon the non-TARP creditors, their employees, families, alma maters, dogs, and favorite sports teams.  Of course, this could be seen as an abuse of power (as we are all terrified of the IRS and all investment managers are scared of the SEC's ability to "slow them down").  Equ Privat called the purported Rattner threats "fascist".  For this, she was mocked, mercilessly.  The author of The Epicurean Dealmaker, used Looney Tunes to jab at the non-TARP creditors, saying "[i]t's called politics, you fucking morons. Stop being such a bunch of whiny pansies."  The point TED made was that even if such a PR threat was made, there were a lot of people in the government under under a lot of stress, and the threat was just a negotiating tactic anyway.

As Felix Salmon points out, the non-TARP creditors don't have much of a leg to stand on for their whining, coerced or not into a supplicant position at the mercy of the bankruptcy judge.  Their position in Chrysler was a moral hazard one - "of course the Obama administration won't let Chrysler go bankrupt".  Thus, if it won't go bankrupt, as senior secured creditors, they stood the most to gain.  Pretty simple arithmetic.  Problem was that they didn't think the administration would really let Chrysler go bankrupt - albeit a Chapter 11 reorg rather than a Chapter 7 liquidation - and they did, because they had all the post-event actors on their side: Chrysler management, the large banks, and a private actor, Fiat, to act as a savior. 

This was a completely predicatable outcome, and the non-TARP guys treated it as impossible.  They assumed that the sanctity of American bankruptcy law and precedent would strengthen their hands well enough to force a positive outcome for their vulture investment.  The non-TARP creditors are morons, not for whining, but for not seeing this play out the way that it did.

It's called political risk.

Look, we generally think of political risk when making investments in, say, Pakistan or Russia.  But to completely discount the political risk of a vulture investment in Chrysler debt is completely insane.   The notion that a Democratic administration was going to stand idly by as vulture investors were going to cram down the UAW and TARP banks is foolish.  One, there's a legitimate policy argument that the United States needs a Detroit-based domestic automobile manufacturing enterprise for national security.  You can agree or disagree, but it's a legitimate policy position.  Two, the UAW is a powerful union in a swing state.  To put it another way, the UAW ain't UNITE HERE.  Three, it was completely forseeable that the Obama administration would take advantage of the troubles at GM and Chrysler to kickstart their environmental policy goals. 

The idea that the administration would put all of that aside based on fealty to the well-established order of creditors that you'd have in any traditional bankruptcy, as the non-TARP creditors believed, is naive at best and a violation of the prudent man standard at worst. 

Look, in most vulture situations, the non-TARP creditors would be right.  You'd have an orderly liquidation, and the secured creditors would be in the front of the line to receive proceeds.  But not here - the political risk wasn't even close to zero.  It'd be like making a bunch of greentech investments with Dick Cheney and Phil Gramm as President and Vice President.  You have to, at the very least, merely consider that maybe, just maybe, future policy decisions will make your current investment thesis weaker.

The non-TARP creditors were insane to think their hand was as strong as they played it.  It wasn't even a bluff - they really thought they were playing Omaha high low and that they were holding a Wheel.  In the end, it turned out they were playing 52 card pickup and they lost.]]> tag:sachinagarwal.com,2013:Post/45997 2009-04-27T00:59:00Z 2024-02-23T12:18:41Z How To Legally Incorporate Your Startup (Quick Answer: Get a Good Lawyer) - A Conversation with Yokum Taku

One of the best things about Silicon Valley is that almost anyone will meet with you for a cup of coffee provided that you're reasonably intelligent and not an axe murderer.  My intelligence aside, I'm not an axe murderer, so Yokum Taku, partner at Wilson Sonsini Goodrich & Rosati, was kind enough to meet with me on Friday. 

As people who read Hacker News know, I consider Yokum's Startup Company Lawyer blog indispensable for budding and active entrepreneurs.  There is a wealth of information on all stages of a startup company's legal needs, free for the reading from one of the Valley's most esteemed lawyers.  Yokum most recently helped bring WSGR's termsheet generator to life and drafted the publicly available Series F documents for Adeo Rossi's Founders Institute.  Wilson also drafted YCombinator's "open sourced" Series AA angel financing documents.

In addition to Wilson Sonsini's work, Cooley Godward drafted a set of angel funding documents released by  TechStars and the NVCA also has publicly available venture funding documents, which were led by Sarah Reed of Lowenstein Sadler.

While we did discuss Dawdle, Yokum was kind enough to talk to me about a question I've been asked plenty of times: "how do I get started if I don't get into YCombinator/TechStars/LaunchBox/pick the clone of your choice?"  This actually ended up being a rather fascinating discussion, and with Yokum's permission, allow me to share with you what we talked about.  (Quotes are from handwritten notes I took during the conversation.  No recording was made.)

I presented the following hypothetical to Yokum: you have two people who want to create a startup.  They're convinced it has the potential to be a billion dollar company, and one of the founders was able to convince her parents to seed the company with $50,000.  The other founder has an uncle who's a small-town lawyer who's willing to create and file the paperwork to set up the company for free.  Given this situation, and incorporating Yokum's knowledge of financings and exits backwards and forwards, the question was "what set of documents should the founders give the uncle as a basis to form the company?"

After thinking about this hypothetical, Yokum responded "I don't think those docs are out there."  He volunteered that it would be "better to use [the YCombinator Series AA] docs than anything else [he] could think of", since there's "not much [the lawyer] could really screw up if he was reasonably intelligent."  But Yokum did volunteer that the ideal would be to have an experienced startup attorney at an established firm draft documents for the company given the firm's standard documents.

Surprised, I asked Yokum if he knew of any firm using the open sourced documents since they were available for free for anyone to use.  He said there was not a lot of actual use that he knew of since every investor already has their own set of documents with their preferred terms.  Yokum stated that the documents serve to "give entrepreneurs a chance to look at [sample docs] before getting educated [by] their attorneys," who ostensibly charge for the privilege.  The documents effectively serve to educate startup founders for free rather than actually replace seasoned counsel doing incorporation work.

Given that Yokum's advice was to forgo the free attorney and seek out experienced counsel, I asked "where does a startup founder find this counsel?"  Yokum responded with a list of regions: Silicon Valley, Seattle, Austin, Boston, New York City, and DC.  I joked, "not Chicago?" and he responded "well, I was just giving you a list of cities where [WSGR] has offices."  (A quick one, that Yokum.)  In fairness, Wilson Sonsini does not have a Boston-area office.  But upon discussion, I agreed that experienced counsel would naturally arise in areas that had active levels of investment, which Yokum characterized with two things: venture investors, and "companies that 'throw off' rich people to be angels."  Yokum volunteered that he only knew of one or two venture firms in Chicago, and I named a couple more in town.  He then asked about angels, and I had to concede that I knew of no active Internet angels in Chicago or the Midwest as a whole.

However, the list of areas that did have counsel that Yokum termed appropriate was higher than I thought it would be, meaning that there are a number of lawyers at a number of firms in a number of cities from which to choose.  I asked "well, how does someone find such a lawyer?" and Yokum responded, simply, with "an introduction."  He elaborated, saying that even the largest firms still do startup incorporation work, but that not every "bakery and restaurant" needs this sort of counsel.  Introductions provide a filter for hard-working partners to signal that a company is worth representing.  That said, Yokum was very clear: "any [WSGR] partner [in any city] is happy to sit down for coffee and chat" with founders.  Yokum made the further point that any startup "[has] to network to be a successful startup company" anyway, so it wasn't unreasonable for partners to want some sort of filter to meet for coffee.

I then asked "well, where should founders network to get this introduction?"  Yokum, being extremely patient with me, explained his thinking: in any startup hub, there are numerous events where startup founders meet.  Anyone can stick out their hand, introduce themselves to another founder, and strike up a conversation.  Startup founders are generally thrilled to recommend their lawyers to another founder (if they like their counsel), so it's actually rather easy to get a name or three.  Then the new company can do a little internet research and ask the founders they met at the event to do a quick e-mail introduction to the lawyer(s) they might want to represent them in their new venture.  Founders should meet for coffee with those partners before they make a final decision on representation - again, any Wilson Sonsini partner will meet with you as long as you have a warm introduction.  (And although it may sound like just talk, since WSGR is "Google's lawyer and Sun's lawyer", they still do startup incorporation work.  As Yokum quipped, "once upon a time, we did Sun's incorporation paperwork".)

I found this conversation extremely valuable: Yokum acknowledged that any set of open sourced documents wasn't appropriate to use as a "fill in the blank" template, but he also didn't state that only a small handful of Valley firms were qualified.  There are a number of firms in a large number of cities that have partners that not only "do" this work, but have the requisite experience to not make the simple errors that prove costly down the road. 

I personally would recommend Wilson Sonsini to any potential founder given my high esteem for Yokum and his colleagues, but there are partners at other firms in all these regions that may be a better fit for your given situation.  Please note that you are looking for a good fit with a particular partner, not just the "name" of the firm.  Even though each firm's documents are "off the shelf" and an associate - or paralegal - will do most of the work, having a good relationship with the partner is critical for quick and accurate answers to your well-researched questions.

[EDIT: Apparently YC may make their incorporation documents public, which may specifically address this issue by giving the "lawyer with a shingle" a fill-in-the-blanks template that would work: http://news.ycombinator.com/item?id=579872 ]

]]> tag:sachinagarwal.com,2013:Post/46000 2009-03-09T18:43:41Z 2024-02-23T12:18:41Z Economic Advice from an Entrepreneur that is Actually Doable in this Congressional Session This past week, a group of "young Internet entrepreneurs" were invited to meet with Obama's economic team to discuss innovative ways that the government could help entrepreneurs grow in this economy.  Despite my (1) avatar pledging my support of the Obama campaign and administration, (2) Illinois birth and residence, and (3) decidedly loyal Democratic activity, I was not invited despite being (a) young, (b) involved with the internet, and (c) and an entrepreneur.  Next time. 

I've seen some tweets and the aforelinked blog post, but I haven't seen a lot of concrete details on what was discussed.  However, if Aaron's post is an indication of what was discussed, the ideas were more abstract and less immediate (more education, yay H1-Bs) than I would like.  I'm also concerned that the ideas presented only apply to a miniscule subset of businesses (AMT only kicks in for employees with compensation at more than double the national average for household income).  Again, I don't have a formal list of what was discussed, so I'm projecting based on Aaron's post.
 
I don't want to just find fault with the ideas I've seen, but rather, I'd like to examine why the ideas that were presented were presented.  My thesis: because those invited were unqualified successes, and not those of us who are small but growing organically without outside funding, so the ideas they proposed reflected their reality, not the reality of the rest of us.  (Threadless has revenue of $30 million a year - they have have grown organically, but they're not small any more.)  Because small bootstrapped businesses and traditional small businesses (corner coffee shop, neighborhood laundromat, fledgling architect) don't have the resources of the companies invited to speak, we're both more constrained by the things government imposes on us and more likely to benefit from changes that could occur in the short term.  Here are some suggestions that would help both internet startups and your traditional small business and could be changed in this Congressional session.  I've grouped my four suggestions into two buckets.

Bucket One: The federal government needs to simplify the incorporation process among the various states and jurisdictions.

Incorporation is a mismash of state and federal law.  The Cono Project, Inc. (the legal entity that owns Dawdle.com) has a federal tax ID, is incorporated in Delaware, and is headquartered in Illinois (so we're a "foreign corporation" to Jesse White and his tumblers).  In addition to that, I had to file paperwork with the city of Chicago as a resident business.  I only knew that I had to register The Cono Project with the city because I happened to be in the office when Table XI had a city inspector drop by and fine them.  I dare you to guess which documents you need, and in what order you need them to get the next document in the process. 

The federal government should simplify this process, whether by legislation or regulation.  It clearly has this authority under the Interstate Commerce Clause of the Constitution.  There's no such thing as a purely local business anymore.  Making it easier to start a company and file annual paperwork would surely make it easier for tinkerers, students, freelancers, and others to incorporate, providing them the flexibility and protection of incorporation.  Quarterly estimated taxes, annual reports, and so on introduce "soft friction" that complicate the foundation and continued operation of a small business.  These should be simplified and streamlined.  Note that I have no complaints about the fees - just the process.  It's the friction of uncertainty and the different requirements of the various overlapping jurisdictions that causes me heartburn. 

I propose that the federal government set mandatory guidelines for all states regarding incorporation and tax jurisdiction to simplify the incorporation and ongoing filing process.

Bucket Two: The federal government needs to revamp the SBA.

The SBA is a wonderful agency in theory - it has a large number of various programs tailored to an equally large number of niche constituencies.  However, when you really consider all the programs, they have a single thing in common - increasing business liquidity.  Loans, grants (SBIR/STTR), and investments (SBIC) are all just ways of helping companies meet expenses and grow.  Helping companies navigate the cumbersome process of federal contracting is just helping companies raise funds through customers (the least dilutive source of capital).  However, these programs have not adapted to the 21st century. 

The SBA loan program most applicable to startup small businesses - SBA Express - sends companies to private lenders for loans up to $350,000.  Private lenders have collateral requirements that effectively restrict companies to use the funds for capital expenses.  These banks are looking for the funds to go into inventory, large capital expenditures, or seasonal buildups that will be torn down.  However, many new small businesses need funds for hiring - not secured property.  As we become a knowledge economy, where we want to have jobs that cannot be exported, the current loan program should be revamped and the requirements altered to better encourage the type of companies - high intellectual capital - that are likely to provide our best jobs. 

I propose a new SBA lending program for amounts up to $350,000 that cannot be secured by collateral to encourage investment in knowledge workers instead of physical implements.

The SBIR/STTR grant process is cumbersome and has a bias towards companies building "protectable" IP.  The existence of grant writers working for profit to navigate the SBIR/STTR grant process is proof enough of the cumbersome process.  It's been clear that proprietary IP has gotten out of hand and actually stifles innovation in current practice.  The sponsoring government agencies for the SBIR and STTR programs require a multiple-year process to migrate from Phase I to Phase III of the programs.  The most frustrating requirement is that the the entity receiving the SBIR or STTR grant must exist as a company even though SBIR and STTR grants are intended for pre-commercial research.  The only pre-existing companies that can reasonably qualify are those that already have a commercial product line with researchers available to divert once the grant is received, if they are lucky enough to win grant funds from a sponsoring government agency.  This reiterates the problems with the incorporation process discussed above.  The SBIR/STTR grant process and structure has the perverse effect of retarding actual innovation by emphasizing the grant process itself and increasing the risk to spinning out technology from host institutions. 

I propose that the SBIR/STTR programs be entirely replaced with a program to spin out companies from from our nation's land grant universities via the existing technology transfer offices of those schools using standard terms and forms.

The SBIC investment process is also broken.  Almost any fund with actual LPs can apply to be an SBIC licensee, but many of our best investors are not SBIC licensees.  Those who are in the SBIC program are restricted by geography, but there are no requirements on disbursed funds on an annual basis.  And the list of SBIC investment companies by state is full of useless information - here's Illinois'.  If the federal government is going to co-invest, it should demand that companies invest a set amount annually to encourage stable economic development.  Given the inability of traditional VCs and early stage investors to make capital calls in this economic environment, the SBIC program could be critical in keeping the innovation engine humming while the private credit and investment markets recover.  I am unpersuaded by the argument that "there is more money available than good investment opportunities".  That argument appears to only be plausible - if true at all - for traditional VC investment amounts in thematic "frothy" investment cycles.

I propose that the SBIC program be revamped to encourage the formation of new SBIC licensees based on industry, not geography, and that all SBIC licensees to required to disburse a given amount, which is public, per year to new investments.

These four proposals would require no new money, no new institutions, no new government regulation (indeed, the first proposal would eliminate and streamline regulation), and are uncontroversial regarding incentives and purpose.  All they do is bring existing institutions into the needs of the 21st century - they would reduce entrepreneur risk and make government an enabler, not a hindrance, to new company formation and hiring.  There are other concerns for small businesses and startups - among all the entrepreneurs I speak to, healthcare risk comes up the most, and by a wide margin - but baby steps first.

]]> tag:sachinagarwal.com,2013:Post/46002 2009-02-08T22:33:00Z 2024-02-23T12:18:41Z Quick Compare-and-Contrast of the Y Combinator and TechStars Series AA Model Documents

It's very clear to me that these documents were substantially informed by the YC docs' terms but that they were adapted from standard VC documents, and aren't just mere re-wordings of the YC documents.  Again, these documents and the YC docs are for the round *after* TS/YC funding.  Lastly, I'm just comparing the Term Sheets here (although I've browsed through the legal documents).  For my analysis of the YC documents, see my previous blog post.

Substantively, the instrument is the same as the Series AA Shares in the YC documents: convertible non-participating 1.0x preferred stock at a 1:1 conversion ratio.  Both the YC and TS Series AA documents give the Series AA investors rights to participate, on a pro rata basis (to maintain their ownership percentage of the Company after the closing of the Series AA round), in any subsequent financings.  However, there are many things in the TechStars documents that aren't in the YC documents. 

First, there is a three-member Board of Directors that splits 2/1 founders/Series AA investor representative.  There is no mention of the Board composition in the YC AA docs.  Second, the TS documents introduce the idea of a "Qualified IPO", which is a standard VC term sheet concept.  Again, the YC documents are silent on this.  Third, there are specific notes about conversion price adjustments in the TS documents - the "broad-based weighted average anti-dilution protection (with customary exceptions)" is pretty standard language for a formal VC round that protects the investor in a down round.  For a description of weighted average anti-dilution, see Yokum's post on the matter on his indispensable Startup Company Lawyer blog.  Lastly, it's nice to see that each side is specifically responsible for their own fees in conjunction with the Series AA round. 

There is something in the YC documents that isn't in the TS documents - the 180 day holding period for insiders.  Again, the 180 day period is awfully optimistic (especially in this environment), but it raised an eyebrow that the TS documents chose not to, at least, contain every term in the YC documents.  Again, this is probably due to the TS documents coming from Cooley's standard VC round documents rather than being a Cooley version of the Wilson Sonsini YC documents.  Further evidence for my theory is that, as of this writing, the Protective Provisions part of the TS term sheet makes reference to Series A, not Series AA.  (Associate lawyer/paralegal oops.  :) ) 

To me, I prefer the Cooley/TechStars documents, if only because they're more similar to standard VC documents, and I like that level of familiarity and I have nostalgia for the days when I'd wake up at 4am for a flight across the country.  (Note: not true - I hate to travel and I really hate to wake up early.)  The instruments are the same, however, and this is essentially just a style preference on my part.  If you have any questions, fire away in the comments. ]]> tag:sachinagarwal.com,2013:Post/46010 2009-01-14T18:44:58Z 2024-02-23T12:18:41Z You Have No God-Given Right To Your Business Model Just posted a lengthy blog post on the corporate blog: http://blog.dawdle.com/2009/01/you-have-no-godgiven-right-to-your-business-model.html]]> tag:sachinagarwal.com,2013:Post/46012 2008-09-16T02:34:00Z 2024-02-23T12:18:41Z My op/ed published in GameDaily


I had my op/ed "Gaming Needs A Real Sundance" published in GameDaily, the trade publication for the gaming industry.  I take the events and small publishers to task for not encouraging developers to submit complete games in competition to attract publishing in the same way the independent filmmakers take complete films to Sundance to sell to the studios.  (Well, their independent arms like Fox Searchlight and Sony Pictures Classics and whatnot.) 

I advocate for the creation of a standalone festival that is centered on business.  Take a gander.

]]>