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.
]]>
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!
]]>
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.
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.
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.
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.
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.
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.
]]>(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.
]]>
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.
]]>
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.
That's it.
The survey should have these four questions: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.]]>
Hours | Per Hour |
1-4 | $150.00 |
5-9 | $125.00 |
10 or more | $100.00 |
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% |
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%.
]]>
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.
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:
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.
]]>Ask a QuestionDo Background ResearchConstruct a HypothesisTest Your Hypothesis by Doing an ExperimentAnalyze Your Data and Draw a ConclusionCommunicate Your Results
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.
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:
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.
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.]]>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 ]
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. ]]>
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.
]]>