Startups win by growing fast. As Paul Graham’s startup = growth essay explains, “A startup is a company designed to grow fast.”
VC-backed startups are designed to “eat capital and shit growth.” Growth expectations create a new definition of winning at each round of venture capital that your startup raises. Most businesses can’t scale rapidly based on large amounts of additional capital, which is why most businesses aren’t suitable for venture capital.
many people still don’t understand startup = ‘eats capital, shits growth.’ when you play with VC money, you play with fire. if a normal business grows revenues 50% per year, its great. startup seed-growth expectations are 10x that; 500% per year. can’t hit it, funding dries up.
— bradford cross (@bradfordcross) February 16, 2019
Modeling startup growth
Once you embrace that startups imply growth expectations, you can work backwards from growth expectations to outline a winning path. There are many simple rubrics out there for this, and one of my favorites came from Garry Tan’s reply to my tweet above; the T2D3 model.
Get to $2M ARR and then just triple, triple, double, double,double (T2D3) revenue every year
— Garry Tan 陈嘉兴 (@garrytan) February 16, 2019
The T2D3 model will generate a $1.44B company in 6 years assuming a 10X revenue multiplier as a standard valuation rubric.
| year | growth | revenue | Valuation ($Ms) at 10X revenue |
| 1 | $2 | $20 | |
| 2 | 3 | $6 | $60 |
| 3 | 3 | $18 | $180 |
| 4 | 2 | $36 | $360 |
| 5 | 2 | $72 | $720 |
| 6 | 2 | $144 | $1,440 |
This is just one model that works generally for SaaS and consumer startups, but you can poll the market of investors for your particular space to design a model that makes sense for your startup.
Polling the market for growth expectations
I tell founders to start working on their next fundraising as far in advance as possible via financial planning. Go out and poll the target VCs for your next raise, and ask them about their growth expectations based on the stage you’re at and the amount of capital you want.
Depending on your market and type of company (SaaS, consumer, deep tech, etc), you’ll find different expectations about growth milestones at each phase.
This also serves as a great screening mechanism for investors. The best investors know exactly what they’re looking for, will think independently, and make decisions from first principles. Others will operate purely on social proof and how hot a deal is. The latter group of investors won’t be able to tell you anything about growth expectations and won’t provide you any value after they invest. Polling the market to get a sense of expectations for your next raise is also a way of prefiltering those VC’s that you want to work with based on the value that they can probably add after they invest.
I would poll a full set of target investors and use it as an opportunity to get to know them and show your savvy. This could mean reaching out to up to 100 investors. You probably won’t get good data back from more than 10. Make sure to overweigh the data that comes from the people that seem most competent. You’ll be able to tell who’s done their research. They’ll have metrics, data, and expectations that are all backed by their existing portfolio.
Backing into your goals from growth expectations
Once you have a basic table of growth expectations like the T2D3 model, then you can create a goal tree that maps short term goals to their longer term goals counterparts with explicitly stated hypotheses about how the short term is going to influence the longer term; e.g. how are product updates, content marketing, or outbound email campaigns going to lead to more new customers.
Note that what matters here is always what matters to the market and *not* what the team feels internally. If tons of customers are churning and telling you they need specific functionality, that’s a strong market signal the functionality will help your growth. If everyone in your industry is crushing it with SEO and content marketing, that’s a strong market signal that trying more content marketing is a good idea. If a bunch of diesgners, engineers, or PMs have personal opinions about what will make the product better, or what customers want, and these opinions aren’t grounded in customer or market data, then these hypotheses should be subjected to heavy scrutiny. It’s very common that failure comes from setting the wrong fast moving goals because the team doesn’t have the right internal market instincts or focus. Founders need to be relentless about everything being based on market and customer inputs. This needs to be installed into the DNA of the team. It’s the only way to get people to stop arguing based on personal opinion and start focusing on how they can discover and support ideas that are grounded in the market.
Once you get everyone aligned on a strong set of hypotheses for fast moving goals that everyone believes will lead to achieving the slower moving growth expectations, you’re ready to execute and achieve your goals.
Cadence of accountability and check ins
Once you’ve locked in growth expectations and set your goals, it’s time to drive accountability with a cadence of regular check ins.
There are many ways to do this and you should find what works best for you and your team. For some teams this might mean daily standups with quarterly team syncs and for others it can mean weekly planning. What’s important is that there is some regular interval for accountability. My recommendation is meet as frequently as you can without going into overkill.
Sometimes people will say that certain goals don’t move fast enough to be worth talking about every week. This is a problem. You want to be really careful about setting your fast-moving goals. Make sure that they are things that can move every week. Without this, you’ll struggle to keep yourself and your team accountable and steadily progressing towards your longer-term growth expectations.
As I mentioned in the post linked above on goals, I’m a fan of weekly meetings that check in on fast-moving goals. The team needs to set all these fast moving goals themselves based on the longer term growth expectations, and the weekly meetings are the place to be accountable for the results — both whether we’re hitting these fast moving goals, and whether the fast moving goals, when hit, are influencing the longer term growth metrics the way we hypothesize. This applies natural and realistic pressure on the team.
Celebrating small wins
If you’re hitting your short-term goals and making steady progress towards achieving your longer term growth expectation, you’re in great shape. This is an awesome place to be and it’s important to do little things to acknowledge and celebrate these small wins along the way. Even though you want winning to be status quo, you don’t want it to *feel* status quo. For bigger milestones you might want to do team outings or swag, but even if it’s just a pause to reflect, high five, scream with excitement, to compliment everyone on what they did to achieve the goal — it all goes a long way.
Making the tough calls; changes to hypotheses and teams
When things aren’t going well you’re either failing to achieve your short-term goals or your short-term goals are failing to move the needle on your longer term growth expectations.
When you’re not meeting your short term goals you need to change the team, or how the team is being managed. If you need to change the team, it’s usually because you have some folks that you need to transition out, and this is never easy. The classic error here is to take too long to have clear accountability for the expected impact of each team member. It is especially important to identify a bad team member in the first four weeks during onboarding. It’s a lot harder to let someone go when they’ve been around for a bit. If you have the right team with the right managers, when you’re not hitting your short-term goals it’s a sign that you need to fix the process, set up systems, and remove blockers that are holding everyone back.
When you’re hitting your short-term goals but missing your longer-term growth expectations, your hypotheses are wrong. An example of this would be when you’re wrong on product ideas or go to market ideas. You thought that customers would love a product feature, a new marketing campaign would work, or that a new sales process would increase revenue, but instead the customers didn’t care, the marketing campaign flopped, and the sales process failed. You should expect this to happen. This is why it’s so important to separate out fast-moving short-term goals versus slow-moving long-term growth objectives. It’s never the case that your first ideas are just going to work, you’re always going to have to iterate an experiment to find your way to the short-term actions that are going to generate the longer-term results.
What company growth implies about personal growth
The best startups are the best run companies in the world. When they keep growing, they become companies like Amazon, which is just unfathomably well run for its scale.
Ask yourself — do you think you can become one of the best in the world at what you do? The answer should be yes. If you struggle with it too much, then startups might not be a good fit. You must be able to suspend disbelief and become a ‘true believer’ in this vision for yourself and for the startup.
You must be able to take an empirical scientific attitude. Question yourself every day and not be overconfident. Bias toward thinking you don’t know what you are doing rather than that you do, so that you can constantly learn and improve. Learning and improving really fast is one of the things that sets startup people and startups themselves apart from other people and other companies. Growing really fast as a company implies growing really fast personally, and that means messing up a lot, seeing it immediately, reflecting, seeking knowledge, and doing it really well very quickly.
If we want to be scientific thinkers and empirical about how we make decisions, then we need to also understand that means very high personal and company level growth expectations, which in turn means we must believe in ourselves to become the best in the world at something — both in our own personal skill sets, and in terms of our startups’ market positions.
What company growth implies about systems, delegation, and self-replicating leadership
Systems design
Systems design is #1 for scaling. If we look at engineering for example, there are interviews, code reviews, design reviews, architecture/system design, release process, quality eval process for models, the build process, etc. There is also clarity of roles and responsibilities, not having EM and TL roles clear, siloing of ML team rather than integration into engineering.
One of the reasons that I hate scrum so bad is that the Sutherland guy ripped everyone off to validate his scrum master certification class by posturing that this is the whole story to managing tech organizations. Scrum should be viewed as agile planning. Basic agile planning is good, but is literally 0.5% — that’s point five percent, not 5% — of the vast set of systems that must be in place for tech organizations to operate well. At one of my previous companies, we spent eons messing around with the agile planning, and hardly any time fixing the vast number of other missing or broken ‘systems of working’ in engineering and product.
I also notice that the team often talked about how there has been so much change and the change is at fault for the lack of growth–this is usually on teams where there has been about 1/10th the change that there should be. Let’s stop changing basic planning shit that should take 0.5% of our time, and let’s start changing very important things very fast. There’s almost never too much change too fast — it’s usually just that there is too much churn in the wrong areas.
If we look at sales, when we set and follow a solid system, we onboard new customers fastest. When we start to wing it, we slow down and risk failure.
Delegation
Delegation is key. You can’t scale if you can’t delegate, but you have to delegate the right stuff, and be aware of what is ‘special’ and what is not.
Some people think I don’t delegate because they see me in the weeds fixing stuff. I mostly delegate, but I’ve made the mistake of over-delegating too fast without calibration, and then needing to zoom in to fix things. For example, a common pattern among founders is delegating sales too fast and then needing to come back and reset things, setting up the foundation yourself and then gradually backing out.
Remember at startups we don’t have any time for make believe and overconfidence — we must generate the outsized growth results that everyone expects. One of the hardest parts of startups is you have to balance suspending self-doubt with a razor sharp self-awareness. We need to be explicit about people trying to take things on, failing at it, and it’s OK. What is not OK is when we take something on, we are failing at it, and we avoid looking in the mirror in order to protect our ego. Delegation always has to come with short term results — there isn’t time and space in startups for ‘just go away and trust me’ forms of delegation.
Self-replicating leadership
A startup’s culture and momentum dies if the team is unable to grow with it and the startup needs to keep shedding the old team and replacing it with a new one for the next phase. A solid percentage of folks need to ‘grow with the business’ — that means if the startup is growing 3X per year in revenue and headcount, you need to grow 3X per year to keep up. This means that you must rapidly master what you are doing today, and be able to teach someone else to do it tomorrow.
Self-replicating leadership is not just about ‘emerging stars’ who can grow as fast as the company for several years, it is about the feedback loop of learning -> doing -> systematizing -> teaching; people constantly pass through some skill or role, making the systems/process better each time. Rotating people through code leaves it better than component-level code ownership. The rotation of engineers through on call duty makes the production culture of the team improve dramatically. The whole team rotating through code reviews ensures that we break down context silos and have strong system level context across the team. When we constantly learn, do, document systems, and teach others, we are setting the team up to be able to scale as fast as possible.