Category: Execution

The Fat Torso

~ avichal ~ Leave a comment

The Internet’s potential to enable new businesses by building for customers in the Long Tail is well-documented. However, for many Internet businesses, the Fat Torso is now more important.

As the Internet has scaled, we have seen the emergence of markets with Fat Torso and successful businesses that first target the Fat Torso of customers.

The Shape of Markets

Markets can have a big head, fat torso, or long tail. Offline businesses tend to have a fat head because there are real economies of scale. For example, the top five automotive manufacturers own about 50% of the global market and the top 15 own about 90% of the market. Internet businesses such as YouTube have both a fat head and a long tail uniquely enabled by the Internet.

As the Internet has matured, many markets have grown to also have “fat torsos.” These Fat Torso markets are often fantastic markets for startups to enter and the right entry point is through the Fat Torso.

What is the Torso?

Customers in the torso are between the head and the tail. They make decisions quickly and generate significant revenue or engagement per customer. Customers in the torso generate more value for your business (revenue or engagement) than tail customers, i.e. the area under the curve is larger. Unlike customers in the head who often make unreasonable demands because they are used to being catered to and having market dominance, torso companies will make feature requests that apply to many customers. Torso companies are hungry to compete with head companies and will try new solutions in order to gain an edge against their bigger competitors.

What is a Fat Torso?

Not all markets have “fat” torsos. If the torso is “fat,” there are many customers who meet the torso criteria (who spend lots of money and move quickly). Thus you can scale your business quickly: lots of customers * high revenue per customer (and they move quickly).

Go To Market: Torso First

The Fat Torso is the best place for startups to prove their business model. Often the go-to-market:

  1. Prove the model with the fat torso customers – torso customers move quickly, offer significant value to your business, are eager to scale their businesses, and do not have significant leverage over you to make unreasonable demands.
  2. Scale to support the head – now that you have some scale, you can negotiate with larger customers or partners. Your company has the runway to wait out the long time horizons that large customers require.
  3. Build self-service tools to serve the long tail – these customers offer significant revenue at scale but require a significant investment of self-service tools. They serve as a moat around your business if you can get them onboarded. Now that you have the customers they aspire to be (torso customers)

Examples

  • Online Ads — target sophisticated online advertisers such as game developers who scale ad spend quickly to $10 million+. Targeting smaller businesses in the tail requires hand-holding, self-service tools, and they will not scale ad spend over time. After you have the torso advertisers, convince large advertisers such as brand advertisers to use test budget and build out self-service tools for the tail.
  • SAAS — start by targeting companies large enough to give their employees autonomy to make purchasing decisions (say 100-1000 people). Avoid Fortune 1000 companies and avoid two-person startups. After you have many companies from 100-1000 people using your product, you can start moving up stream to enterprises and then build self-serve tools for startups.
  • E-Commerce Marketplace — find sellers who can use your platform as part of their existing full time business. At the same time, find buyers who will buy more frequently on your platform not just once per year. Etsy is a good example. It has many suppliers supplement their income substantially via Etsy and Etsy’s customer base appears to have a fat torso with 60% of customers buying only once per year. Over time you may be able to scale to head sellers like Nike or Dell. This is the path eBay took after scaling its core business by first working with sellers who made a living on the eBay platform.

The Torso First approach not the right fit for every market since not all markets have a Fat Torso. However, it is an increasingly common theme in businesses that scale to $100M+ in revenue, both because the markets that have Fat Torsos are great markets and because businesses that scale often use this strategy to scale quickly.

We discussed very similar ideas in some meetings at Facebook. I’m not sure who came up with these insights exactly, so thanks to everyone involved in helping form the ideas: Andrew “Boz” Bosworth, Alex Himel, Pratiti Raychoudhary, and Jon Lax.

Onboarding a New Product Manager

~ avichal ~ 3 Comments

Once a startup has 8-10 engineers a company often needs to bring on its first product manager. Below are some of the best practices I’ve learned over the years for ramping up a new PM.

Why is it hard to onboard a new PM?

Ramping up a new PM is challenging for two reasons:

  1. Product Context – to help a team make the right decisions, a PM has to help a team synthesize qualitative information, data, technical architecture, design decisions, go-to-market strategy, etc. This synthesis will take a long time.
  2. People Context – to ship products and features, a PM has to work with a wide variety of people inside a company, likely none of whom report to her.

How to Help: Product Context

  1. Set aside time at the end of every day for some fixed period of time (say two weeks) to answer any questions she has from that day.
  2. Give her access to all of the research, data, past product specs, presentations, sales material, blogs that she should read regularly, etc. and ask her to read as much of it as possible as quickly as possible. Let her know that she may have to read it two or three times in the first month to really understand it.
  3. Have her get as much context as quickly as possible on the other parts of the business — have her sit in on a budget meeting, go out to meet customers, sit in on sales calls. Whatever it takes to get a holistic understanding of how the business works outside of the product.
  4. Help her behind the scenes by helping her do the work without anybody knowing. For example, if the next deliverable is a spec, help her co-author it, edit it, and make it high-quality. Then when it goes to the engineering team she will establish credibility very quickly because it will come in a form that they expect and that a quality bar that they’ve come to expect from you. This will make her successful more quickly and in the long term create the least amount of pain for you because you’ll have landed her well with the team.
  5. Let her know what the ramp up will be very explicitly along with what the major milestones are for your involvement. For example a hypothetical timeline might be: for the first month you will help her edit the specs, can help her draft any emails or answer product questions for her 24/7, and will be in product team meetings. At the second month you will stop doing editing specs, she is expected to run meetings, and you will back out of those meetings. In the third month, she needs to be able to have enough context to make product decisions on her own and you will only get involved if the team is not hitting its ship dates or missing metrics targets. That way there’s no ambiguity about whether you are involved because she is not doing well, if you’re micromanaging, or if she is still in the ramp-up phase.

How to Help: People Context

  1. Let her shadow you for a few days to understand how you run meetings and what the various teams expect from a product manager. Ask other teams (engineering, design, sales, marketing, etc.) on her behalf if she can shadow them or sit in on their meetings to get up to speed.
  2. Give her a list of everyone she needs to have a great relationship with, explain what they do, what motivates them, and what they expect from her. Help her build good working relationships with everyone she needs to have good relationships with. In part this is innate, and in part it’s helping her understand who these people are, what motivates them, what they expect from their PM, what they don’t like, how best to build those relationships, etc.
  3. Help the team understand what she’s responsible for and what she’s not. They have come to expect certain things from you and she may not be able to give them all of that immediately, so they need to have expectations set appropriately up front too.
  4. Often as the former PM, new PM manager, or PM turned CEO of a startup, people will let you know in subtle ways if she is not delivering something the team expected. Help her interpret these signals and understand there is no ambiguity between what she expects and what the team expects. Reinforce this is not about micromanaging or a lack of trust between teammates. You simply have more context on the people to read subtle signals and are passing her this context based on your experience working with this team.

Be patient — often the new PM is stepping in for someone who lived and breathed the product for many years and who helped build out the team around them. These are big shoes to fill and becoming an effective PM takes an uncomfortably long time.

Investor updates

~ avichal ~ 5 Comments

Investor/advisor updates are an often under-utilized tool. Though there are many good reasons to do it, the real value is engaging your investors to help you solve problems.

High Level (TL;DR)

Do:

  • have a concrete ask in each update
  • keep it short, results focused, and on what matters to your audience, not to you
  • send the update regularly (at least quarterly, monthly is even better)
  • humanize the update with names and photos

Don’t:

  • deep dive in to metrics unless they teach something counter-intuitive (focus on synthesizing info, giving context)
  • hide bad news (own it, ask for help, or outline your plan to address the issue)
  • describe the activity/work (focus on results and impact)
  • spend more than 30 min a month (it should fast to synthesize this information if you are running your business efficiently)

Example

This is an amalgamation of the best updates I receive regularly. Shout out to the companies who most influenced this template: Color, Boom, and NoRedInk.

This update is for a hypothetical company, Banana Stand, that builds a mobile shopping app. If you delete all of my comments below, the update is short.

Your startup should track this information internally already so you should be able to update your template quickly. You can also share this internally as a simple way to keep everyone in the company up to speed as well.

Confidential – Banana Stand Investor Update – October 2016

Confidentiality – Please treat this and all company updates as strictly confidential. Do not share/forward any information. Do *not* forward to friends, colleagues or anyone else.

1. How you can help
//make your asks clear

  1. We need an intro to someone who works on Apple’s App Store by Nov 1.
  2. Please refer great sales people for:
    • role 1
    • role 2
  3. Email us if you can talk this week about best practices for eng hiring. We are going to revamp our eng interview process to hire more design/product oriented engineers.

2. Summary (TL;DR)
// 3 sentence summary with your ~3 topline metrics that matter

Monthly active users are slightly ahead of projections, revenue is behind projection because we pulled back ad spend, and we are on track with app launches. We are behind on hiring salespeople and could use your help. We expect revenue to return to projections once we resume ad spend to projections in Nov and Dec.

  • Shopper MAU: 5M (+25% m/m, +178% y/y)
  • Shopper Retention: 33% month over month
  • Seller MAU: 45k (+15% m/m, +300% y/y)
  • Revenue (monthly): $860k (+18% m/m, +150% y/y)

3. Goals
//high level goals, and how many you’re hitting
//this is a good way to track things internally too
// likely as the founder you want to have a list of key things to get done each month and hold yourself accountable
// just open up that list to your investors and ask for help hitting those goals

Goals for October: Hit 3/5
1. Grow to 4.9M MAU [hit]
2. Grow to $980k revenue [miss – details in financials]
3. Launch iOS v.2.3 [hit]
4. Hire three salespeople [miss – hired only 1]
5. Finish product roadmap and planning for Q1 2017 [hit]

Goals for November:
1. Grow to 6.3M MAU
2. Grow to $1.09M revenue
3. Launch Android v.2.3
4. Hire two salespeople – please help us with leads!
5. Identify and sign lease for office location for 2017-2019

4. Product
// Update on product roadmap, highlighting key launches and learnings backed by data.

  • Launched iOS v2.3 which is mostly bug fixes and performance updates
  • Planning to launch Android v2.3 this month
  • Q1 2017 Roadmap is locked. We will focus on driving more sellers in Q1 as we expect that side of our marketplace to have been underserved once we launch all of our buyer features through Q4.

5. People
//Quick summary on how big the company is, any surprises on hiring, and if there are new people, two sentences on who they are, where they are from, what they will do.
//Humans like looking at other humans’ faces. So put some faces in here. Humanizing your company is important! 

We are now 26 full-time people and 8 contractors/consultants. Recent hires:

  • Carla Stephenson: Carla was most recently Director of Sales managing eBay autos. She will be managing North American sales for us (3 salespeople). <LinkedIn profile> 

We are behind on hiring salespeople. We thought we would want less experienced people that we could train. However, after interviewing less experienced candidates, we realized we needed to get a manager in place first (Carla) and decided to focus entirely on hiring the manager before hiring two more junior salespeople. 

We also just sent off our class of awesome summer interns  (photo attached). They did all sorts of great work ranging from overhauling our logging infrastructure to revamping how we do customer support. Thanks interns!

team

We are still hiring for 3 roles (2 salespeople, 1 designer): <link to careers page>

6. Marketing & Press
// PR and Marketing wins here with links to press
// fine to have this just say “No Updates” because that’s still an update

No updates on press.

Our online marketing efforts have been 20% more expensive than projected, so we’ve had to spend more acquiring customers to maintain our revenue run rate. Details in the financials section.

7. Financials
// This section can get involved and complicated. Financials get more fleshed out as you get farther along. For a seed stage company, just calling out the cash balance, runway, and when you want to go raise again is great
// Even just showing a simple breakdown of the current revenue and expenses inspires a lot of confidence
// if something is not going well, own it and describe why. Call out if you don’t know why.

  • Cash Balance: $12.3M
  • Runway (forward looking, assuming no revenue growth): 12 months
  • Targeting next fundraise: Summer 2017

We missed on revenue projections for October because we pulled back on our ad spend to conserve marketing budget for Q4 holiday season. We under estimated cost-of-customer acquisition in Q3, and to hit our revenue numbers we had to spend more money than anticipated. To make up for this extra spend, we pulled back our ad spend in October. We will resume our ad spend in Nov and Dec for the holiday season as we saw a residual lift last year through January from our holiday ad spend. We expect our revenue in Nov and Dec to be on target.

bananastand

Table
//I literally copied and pasted this in 15 seconds from a fake Excel I threw together.

bananastandtable.png

Product Reviews

~ avichal ~ 1 Comment

I’ve been fortunate to work with exceptional product leaders at Google and Facebook. This distills some of the best practices I’ve learned around product reviews. 

Purpose: These thoughts are targeted at product managers (PMs), product leaders at larger companies, and CEOs of startups. This document outlines 1/the goals of a product review, 2/common mistakes, and 3/the logistics before, during, and after a review.

I use CEO or founder as a proxy for “decision maker.” For product-oriented companies under 500 people they are likely the same. At larger sizes, responsibilities often recurse down to a VP as the Decision Maker.

0. Why do product reviews?
Product reviews are a process through which a company can scale product development, and are useful for both teams and leaders. Product reviews allow teams to have ownership over product decisions and a clear, predictable way to move forward through strategic and operational roadblocks. They are a useful tool when a CEO can no longer be involved in parallel work streams in real-time. In my experience, this will happen around 20 employees — when it’s hard for one person to be both the full time PM for the product and the CEO at once — and are a staple process as a company grows from 20 to 20,000+ employees.

1. The Goal of a Product Review

There are three flavors of reviews:

  • I. Input/Discussion — The goal is to get input early in the ideation/development of a product. The questions on which you want input and the type of input you want should be clear. It is better to get the CEO/founder to weigh in rather than spend 3 months on something and then realize it is totally out of whack with her vision, that some other team is already doing it, that the company tried something similar before and the founder has context, etc. It’s good to get in front of her as soon as you have a good idea of what the team is trying to accomplish and get her input.
  • II. Unblocking a decision – The goal is to make a strategic decision. If multiple paths forward are plausible and reasonable people disagree about the right path, go to the CEO to make a call. In most companies, the CEO has more context than anyone else about what’s going on, more data intuition than anyone else at the company because of historically accumulated knowledge, and is phenomenal at asking the right questions. The CEO is the ultimate arbiter between teams and can unblock while optimizing for the company. Over time teams can build ways to formalize these decisions, but early on someone needs to make a call.
  • III. CEO priority – The goal is to build and ship a product with the CEO deeply involved in the process. This is a rare third form of review which is a bit more like a team scrum, with the CEO co-PMing with the product manager. This happens at every company. These are projects that are pre-launch, new products, or initiatives that are critical but struggling. The CEO will get involved because she has strong intuitions about what a team needs to build in a strategically critical area. She wants to understand what’s happening the same way any PM member would and help guide the team to build the right product. It’s not uncommon to go in every week to the CEO as the product gets built. After launch, the team should be on its own trajectory, and the team falls into the normal iteration cycle + product review cadence with review types I-II.

2. Common Mistakes

  • Reviews as updates – The most common mistake when asking for review time is to just offer an update. This is often conflated with a discussion style review (type I). Type I reviews have clear questions where the team needs input and will require the CEO to actively engage. Updates are information flowing from the team to the CEO and do not require active engagement. Teams should rarely burn a CEO’s time to do an update. Ten people in a room for thirty minutes = five hours wasted. Send updates over email and if the CEO has questions, get in a room to talk through it. This serves the dual purpose of forcing documentation that can be shared broadly.
  • Reviews as exposure/reward – Do not use reviews as an opportunity to give people exposure or as a reward. Teams should be 100% focused on winning and a review has a clear goal to unblock the team on its path to winning. For example, this may mean that a more senior product manager actually presents for the room or the most senior designer represents the entire design team’s work. Find other ways to give exposure and reward people.
  • Surprises during/after the review – everyone who will be impacted by the decision made should have context that this review is happening and has had a chance to weigh in with their perspective. This requires understanding not just the decision to be made but the implications/consequences of the decision. Not everyone has to agree with how to make the trade-off, but it is a big failure on the product manager if someone in the room is surprised with the content of the review or if someone who should have been involved in the decision is surprised when they hear the outcome.

3. Review Logistics
A. Before the review

  • An efficient approach is to have every team in the company have a standing block of time to go to the CEO during the week. This is efficient because a team knows they can go in every week if needed. If not, they give up the time a few days in advance so other teams who need extra time can use it.
  • Create a document or a deck with mocks, and send it the morning of the day before the review. So if you’re going in on Thursday afternoon, the CEO gets the document to read on Wednesday morning. The questions you want to discuss are called out clearly. The day before the review or the morning of the review, the CEO may respond with questions she’d like to talk through in the review. This gives the team time to get data or converge as a team on an opinion before the meeting.
  • Try to create standard formats/templates that are shared across teams. Uniformity across conversations makes it much easier for people to come up to speed on the content.
  • Anyone who has depth of information/context should be in the room – product managers, designers, analysts, marketing, user research, engineering, sales, marketing, legal, etc. The attendees will change depending on the decision to be made and should be determined and communicated in advance of the review so everyone can prepare for a successful review. Don’t have people who want to “stay in the loop” or “hear about it firsthand” in the room. If you’re not actively contributing to the discussion, you shouldn’t be in the room.
  • If you anticipate the meeting will take 30 min, block 45 min and shoot to be done at the 30 min mark. This also gives some buffer and prevents a domino effect since a CEO’s day is often back-to-back.

B. During the review

  • Everyone should have read the document beforehand and the meeting should start with a discussion on the open questions. Most of the time in a good review should be on productive discussion.
  • If you must present a deck, shoot for six slides per thirty minutes. Do not schedule content to fill the time and move through the presentation 3x faster than normal. If the CEO has a question or needs clarification, she will ask. The most productive use of time is to discuss and decide.
  • A great CEO focuses almost entirely on high level questions for most things that are brought to her. She wants to understand the goal and if the team is solving the right problem. This means she will look for a clear articulation of the problem you’re solving, data to back up that this is a real problem, a clear articulation of how to measure success, etc. Historical trust with her helps.
  • If there are known truisms inside the company, she will call them out if you violate them. For example, in many consumer apps, more information density means every metric will go up. So in areas where we want users to take some action and she sees a bunch of whitespace, that’s going to get called out. Another example is that certain design patterns may have become core to the product and often it’s better for the entire system to maintain these. So if you add too much complexity to the system by creating multiple ways to do something, a good CEO will ask why you are introducing new ways to solve this problem instead of using existing design patterns.
  • A good CEO avoids micromanaging (other than CEO-pri things). Likely if you’re getting micromanaged, it’s because the team is broken and the CEO will work through her directs to fix the team and perhaps move people between teams. After seeing this a couple of times, you realize that good CEOs aren’t interested in design specifics on most things because it’s not scalable. Hiring great people, having good processes, and giving people autonomy scales far better. A good CEO moves people and risks thrash to get the best people on the most important problems. She doesn’t care about who owns what, because it’s all one company, and all that matters is the company’s success. This is at odds with how many people think about their jobs and careers, and takes some adjustment.
  • She isn’t afraid to call out organizational issues. For example, if a design solution seems suboptimal, she may probe and then ask if we’re doing this because it’s too painful to work with some other team or if this is really the best way to do it. Good executives will back-channel information to their CEO as well so she has additional context and can make moves as necessary. It’s awesome to know a great CEO won’t hold back on organizational/political issues and wants the company to globally do the right thing.
  • She shares context across groups by calling out why she thinks something is the case, not just what she thinks is true. This is useful because she sees information across teams in a way no one else does.
  • Good CEOs are extremely logical and operates from first principles. This means that if you go in again in a week, she will give you the same answers as last week because the answers are derived. If there is no logical reason for something (she just has a strong intuition), she will make that explicit. This is unlike a lot of leaders who conflate what they believe emotionally with what they know rationally. It makes great CEOs very predictable, which allows the company to scale.
  • Other times, she will have very strong intuition about key pieces of product strategy. This is informed by historical information/experience that something will or won’t work. These are almost always strategic calls – for example, what the default privacy model of a social product should be – not something at the pixel level. In these situations it’s best to take the feedback and decide if you agree/disagree. Ultimately code and data win. If the team disagrees with her intuition, they should find a way to test the CEO’s intuition and the team’s intuition and validate (maybe a user study, maybe a small test, maybe confirming the historical data she has in mind).
  • If the CEO asks for something, you are on the hook to deliver a follow up, even if all it does is prove her wrong.
  • Great leaders are comfortable with silence. They will sit silently to think through something before articulating what they believe and why. This can feel like an eternity and be very uncomfortable for new people. A good CEO will take this time because she’s trying to think through why she believes something so she can articulate the principles, not just the intuition.
  • CEOs have to be good at demonstrating positivity when things are going well. Many CEOs’ and founders’ natural inclination is to be critical and point out what can be done better (e.g. the countless stories about Elon Musk or Steve Jobs). This leaves people feeling like they are constantly failing because they receive little positive reinforcement and makes it challenging to calibrate when things are truly not going well. If the team is not doing the right things, great CEOs do not hold back. She makes it clear what she thinks this is a mistake and why. She does not do this in a personal way and focuses on the outcome.
  • Curveballs happen (this should happen in < 10% of reviews) when the team is solving the wrong problem. This could be because of information asymmetry or it could be because of a communication breakdown. For example, the team thought the CEO wanted us to solve X but she was simply using X as an example and wanted us to think about the generalized version of X.

C. After the review:

  • CEOs rely on senior people to interpret for the team. After every review, the team should debrief without the CEO, and the senior people in the room should interpret what happened. For example, the PM and designer on the team incorrectly thought they were being asked to change the design of X (interpretation #1). The senior person in the debrief clarified that the decision maker was really saying that the team had introduced a new way to perform X in the app, when there was already another way to do X. While the new approach maybe good, two different ways to do the same action will erode the system over time, and the decision maker was calling out this principle. So the team should go think hard about whether a new way to do X is good, or if we should just do X the same way it’s done in the other part of the app (interpretation #2). Interpretation #1 and #2 are very different and would send the team in very different directions.
  • CEOs rely on their executives to make people shifts. For example, maybe an engineer is too junior for the problem they’re being asked to solve. The CEO shouldn’t throw this person under the bus in a meeting, but will work through the leadership for the group who is in the review, get the engineer additional support and if it doesn’t get the team where it needs to be, work through her management chain to get someone more experienced on the team. All of this will happen behind the scenes. A good CEO helps people save face in public because good junior people who trust their management chain eventually become great, loyal senior people.
  • CEOs rely most often on PMs to collect and synthesize notes from everyone and circulate them to everyone impacted by the discussion — the team, engineers, partner teams, marketing, sales, etc. Writing things down removes ambiguity, keeps everyone informed, and allows people who weren’t in the room to ask for clarification. These notes should be sent out the day of the review so the context is fresh in everyone’s heads and any ambiguity is resolved quickly.
  • CEOs rely on product managers to schedule more time for subsequent follow ups. CEOs tend to have great memories because they live and breathe their product. No PM wants to get an email four weeks later asking what happened with the open questions from the review last month. That reflects extremely poorly on the PM (and the team).

Many of these principles will scale to other, non-product types of reviews, but some of these observations may not carry to all cultures or types of companies.

Thanks to Dan Siroker, Yin Yin Wu, Andrew Bosworth, Zohar Yardeni, Alex Himel, Pratiti Raychoudry, and Hema Budaraju for their feedback.