Upside and Downside

by Giff on May 9, 2015

Heidi Roizen has yet another great post this week: “How to Build a Unicorn from Scratch – and Walk Away With Nothing.” Every budding entrepreneur should read it.

Her post isn’t just about valuations and terms. It is also about thinking through downside. In frothy times, especially when equity starts to feel more valuable than cash (a condition not yet reached in New York, but which seems to have hit the SV/SF again), it is easy to focus solely on the upside. Growth, growth growth! Let’s make the business awesome! Let’s make the culture awesome! Let’s make the product awesome!

Awesomeness is indeed a desired, even necessary, goal, but you can’t forget downside protection.

What are some common examples where entrepreneurs lose their head and forget about downside?

Bizdev Deals
A common mistake in the dotcom era, which reared its head in Heidi’s post, is to do business development deals without downside protection. The startup agrees to a distribution deal of some kind and commits to certain levels of payment, but forgets to put performance metrics in place. Why does this happen? Because everyone is so focused on awesomeness! But if your partner’s performance doesn’t live up to expectations, you can get screwed. Believe me I know. In 2000, I sold my startup Ithority and took over business development at the the buyer – an Internet company that subsequently went public. I inherited a ton of these deals that promised cash in exchange for promotion or distribution. When the economy went south, I had to figure out how to re-negotiate these poorly performing deals, but the contract terms left me little leverage. It sucked – and could have easily been prevented with outs tied to metrics.

HR Issues
If you focus solely on awesome and forget the downside, you can get sloppy with employee and contractor practices. You gloss over creating clear terms for your contractors that makes it easy for you to terminate someon who isn’t working out. You don’t set up processes for managing poorly performing employees out of the business, which puts you at risk of spurious lawsuits when you finally crack and decide to fire someone. The truth is, no matter how rigorous your interviewing process is, some folks are not going to work out. Unlike big companies, startups can’t afford to let non-performing people linger.

A rising tide floats all boats, doesn’t it? Not in startup land. In each major category, there will be lots of competitors, but only 1 or 2 big winners (and sometimes none at all if the timing is wrong). When times are frothy, there is a clear temptation to think of things as a land-grab, and thus try to grab as much as you can as quickly as you can. That can lead founders to spawn multiple business initiatives in parallel, which dilutes the team and burns through cash quickly. The way to prevent that is to either 1. stay focused on one thing until you have a clear, very strong beachhead; 2. only allow yourself to look at things with very clear synergies; and/or 3. take a lean “experiment-driven” approach instead of diving in big.

Founder Vesting
Another common place for entrepreneurs to forget downside is at the founding of the company and how equity structures are put into place within the team, in particular, vesting. Many people think that they deserve ownership because they helped come up with an idea, but that’s bunk. The real work and real value is building a company. This is where vesting comes in. It says that if you leave the company too quickly (or deserve to be fired), you don’t get to keep your unvested shares. Usually vesting terms are 3 or 4 years, with a 1-year cliff. For example, for a 4-year schedule, you don’t get to keep any of your stock unless you stay for a full year, and then you get vest a monthly portion for the remaining 36 months. This is a very very good thing. Get a good startup lawyer to help you think through these structures.

Final Notes
In conclusion, dream big but don’t forget to protect yourself from the downside, not just in hunting for product-market fit, but in everything important. Remember that contracts exist in case the things that we DON’T want to happen actually happen. Sometimes they will.

Preparing for these kinds of problems isn’t being a debbie-downer. It’s good business.

I’ve written about financial modeling for startups on here a few times, and included a few sample models. More recently, I led an after-work class internal at Neo for those interested in improving their skills.

For those into lean, doing a thoughtful financial model from scratch is one of the best ways to spot hidden but critical assumptions, risks and dependencies.

To be effective, it really helps to know some key techniques within Excel, both in terms of formulas but also in terms of modeling best practices.

In case it is helpful, I just put the Excel workbook I created as a teaching / exercise tool for the class up on S3 for anyone to download.

Slack’s Success and Silos vs Teams

by Giff on May 3, 2015

(Note: I’m going to leave the original post as-is, but I don’t think I wrote it very well, so see the addendums to prevent misunderstandings. Maybe. This is the Internet after all.)

I read a blog post today that shocked me. A design agency taking credit for their client’s success. Which was surprising unto itself but what was more surprising was the content.

The suppostition that design was the key to Slack’s success.

Electric colors. Sassy copy. Is this what made the difference between success or failure?

No, it did not. I say this as a CEO of a company on Hipchat that switched his entire company to Slack, even though many employees complained that the improvements were incremental.

The big differences were these:

  1. A significantly better mobile app. Let’s face it, Slack understood the importance of mobile and invested in it far more than Hipchat, Flockdock and all the others
  2. Some very nuanced structural differences which enabled better “rooms” within the company, and entirely separate and secure experiences with clients, without a big UX headache
  3. The sense that Slack had momentum, vision, and creativity, and if we as a company had to bet on the partner for the future (and I’m serious about the phrase partner because as a distributed company, chat is mission critical), Slack was the company to go with. Some of this was tied to the founder — let’s face it, there are a lot of us that will try anything that Stuart or Caterina create — but the buzz, funding, and execution all came together.

Did I appreciate the copy? yes. The branding? yes. Did it make the decision? No.

Further, Slack has always understood, the way 37 Signals understood, that marketing is essential to success. Far too many startup people underestimate this and think everything banks on the product. I wrote on this before. Marketing isn’t a bad word. It is just the task of building indirect demand for your product.

I am not writing this note to throw a talented design agency under the bus. They did really great work. I am writing this note to remind all of us that silos don’t matter.

Design doesn’t save us. Strategy doesn’t save us. Engineering doesn’t save us. Marketing doesn’t save us. Customer support doesn’t save us.

No one gets to go on a pedestal.

Either it all works, or it doesn’t work.

It ain’t the electric colors, I hate to break it to MetaLab. It’s the whole picture. It’s the company that Butterfield has built and the way they as a team are executing. Product vision. Product execution. Company execution. Everyone.

One of my pet peeves right now is how design, which is finally getting its well-deserved moment in the sun, is getting a little too full of itself. Design is important, but the sun does not rise and fall on design. It takes a team.

Addendum 1:
I want to be fair to Andrew, the author of the original post, and share his tweet:

Addendum 2
I wrote the orignal post quite quickly, and probably both I and the author of the original post feel like certain misunderstandings have unfolded. A few clarifications:

1. if it’s not clear, I think design is extremely important, and that design *was* important to Slack’s success. Just not everything. When I shifted our company of 100 people over to Slack from Hipchat (not a universally popular move), it wasn’t solely because of the three design elements mentioned in the original article (although I appreciated those elements), but rather because of some nuanced UX differences and the belief that Slack was the company to back — that they were going to invest more and execute better than the other players.

2. I think that MetaLab does great work. While I am not privvy to how Slack and Metalab interacted, the results of that collaboration were great. I also don’t think that Andrew really meant to take credit for Slack’s success. I think I misread that, the way some have misread this post.

3. I don’t view design as just the visual layer. My definition of design is extremely broad, and not merely the purview of people with “designer” in their title. I was reacting to the three points in the original post.

4. My ultimate point is that I want people thinking holistically about startup success. It’s easy to look for a silver bullet, but in my experience things are never that neat. And while “if we build it, they will come” might work for indie software projects, I rarely does for ambitious startups. You have to get the entire system working well.

The challenge of a hedging model

April 23, 2015

A couple days ago, I wrote about entrepreneurship and some level of partial hedging. Actually solving that challenge is, of course, enormously difficult. So much so, that I think it might only really be doable when companies are just starting out, and the equity is worthless. I can see it working in a startup studio […]

Read the full article →

The Stupidity of Entrepreneurs

April 21, 2015

I was hanging out tonight with a bright young man who said, “A great entrepreneur always bets on themselves.” Context: we were talking about hedging. I asked the question: what if founders could hedge themselves against other startups so that if your company failed, you still had a chance for upside? He disagreed. He felt […]

Read the full article →

Why You Don’t Split Your Innovation Teams By Stage

February 17, 2015

(this post originally appeared on the Neo blog) Andy Weissman of Union Square Ventures wrote a piece the other day on chaos theory and startups. His conclusion was that making decisions, and deciding how you make decisions, is of the utmost importance. There are many approaches to making decisions. My current thinking can roughly be […]

Read the full article →

Do Market Sizing Early, Before You Jump Into “Lean”

February 11, 2015

Powerful new ideas often start with a spark insight: “Carpooling sucks! How can we fix it?” Or “Wow, these new smartphones might allow me to disrupt the entire taxi industry in a way never before possible!” Lean is great, but before you jump ahead with customer development, experiments and MVPs, it is worth taking two […]

Read the full article →

Custdev – Everyone Does It. Full Stop.

February 10, 2015

I see a lot of product teams try out customer development at the beginning of their product journey. But quickly the team gets so busy shipping features and they outsource customer learning to customer support, research or usability specialists, or the sales force. Those are all valuable touch points, but custdev is not a task […]

Read the full article →

The Value Behind Faster Horses

February 5, 2015

David Bland has a funny, and painful, graphic called the Product Death Cycle. It clearly illustrates one of the more dangerous parts of customer development: taking customer ideas literally. The famous line attributed to Henry Ford goes, “If I had asked my customers what they wanted, they would have asked for a faster horse.” Some […]

Read the full article →

Lean Startup Doesn’t Need Tools

January 29, 2015

In 2012, we were testing a bunch of new business ideas for Amex and I thought, “what if we had a tool that let us capture our assumptions, our experiments, and our progress?” So over a couple weeks, we hacked something out and tried it out on a few projects. It was a complete waste […]

Read the full article →