Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Part II: The failure points from $5M to $100M in ARR

tracy.posthaven.com

Post reply on HN
Print view View original

111–120 of 127 posts

Re: Part II: The failure points from $5M to $100M in ARR

#111

Post by forgingahead »

Great article and lots of salient advice in this post. It's so interesting to me that a company can get to $50 million ARR, and then feel strained because "there's enterprise competition". So what? I get that the pressure of VC-backed companies is go big or go home, but if the market that got them to 50 mill still loves and enjoys the product (which seems like it did), and churn is manageable, then one can probably truck along as a nice profitable business with some operational adjustments.

Again, I get that the VC-backed status doesn't allow this, but that's such an interesting distinction - this would be a successful $50mill ARR business if not VC-backed, but since it is, the panic button is pressed and that thus leads to decisions and scrambling that upend a lot of what was working.

Guess we all (as usual) need to make decisions about capital sources early and how we want to grow, as well as the real trade-offs between those choices.

Re: Part II: The failure points from $5M to $100M in ARR

#112

Post by carom »

donnythecroc wrote: post #61
manv1 wrote: post #58

A lot of the enterprise requirements he talked about add no actual value to the product; they're just checkboxes on an RFP that are required. Theoretically applying all of those requirements to your product might make your product more secure, scalable, or reliable. It'll also make your product harder to maintain, harder to test, and harder to improve. Many of those requirements are there because vendors put them the…

Interesting you assumed the female CEO writing this was male.

I've met both male and female people named Tracy.

Re: Part II: The failure points from $5M to $100M in ARR

#114

Post by candybar »

issa wrote: post #93
candybar wrote: post #67

On the whole, this is a fairly good write-up but this is just not right: > Being at a startup is hard in a way that is almost indescribable to anyone who hasn’t experienced it. Being at a startup as an employee isn't necessarily hard. You hear this type of "startup is so hard" because running companies well is hard and successful startups will often grow faster than their founders are able to grow their own ability t…

Startup work is much more chaotic than established companies. It is much closer to my creative experiences of directing a feature film and being in a touring band than it is to my time at big software companies. Instead of having clearly set requirements, you have to figure out the requirements as you go, and it's different and unique challenges every day.

One very easy way to disprove this is by looking at the experience of startup employees after acquisition. Now the product is no longer offered by a startup, but by a big company. Do things get easier now that they are at established companies? Do you now have clear requirements?

Of course not - in many cases, things get drastically more difficult. Instead of being able to pursue a clear vision, you often have to deal with tons of inter-organizational politics. You have all these extra stakeholders that are trying to influence you, some with good intent, others not so much. More processes need to be imposed, there's more pressure for standardization/integration both in terms of the product features, implementation, not to mention processes.

And this is about apples to apples it gets.

Another way to think about this is that there's a reason why startups are successful despite the massive advantages incumbents and larger companies enjoy. It's because certain things are harder at bigger companies. Then how could it be that being at a startup is uniformly harder? Startups exist in large part because they are more efficient or make things easier. If you flip that around, it means trying to do some of those same things at a big established company can be objectively harder.

Re: Part II: The failure points from $5M to $100M in ARR

#115

Post by paulsutter »

xenadu02 wrote: post #53

As employee #36 I lived through some of these things first hand and definitely agree with them (I think we were over 200 people when I left). It was painful going through the enterprise focus transition along with a nonsensical reorg imposed by the aforementioned Big Tech VP. One day we had focused platform-specific teams working on satisfying customers, the next we were moved to cross-functional feature teams and fo…

“Product Manager” is a double category error - the right title is customer analyst. This clarifies the actual function of the role, and eliminates most of the dysfunction

Re: Part II: The failure points from $5M to $100M in ARR

#116

Post by ebiester »

shuckles wrote: post #107
mdorazio wrote: post #83

Earlier quoted context omitted.

I think you’re getting bad answers here. It’s not just about talking to customers and understanding what they want, it’s about taking that and matching it against bigger business goals, budgets, and priorities plus making sure you’re not duplicating or messing up things other teams are planning plus prioritizing within all the features all the customers want. If you have time to do all that then why is the company pa…

If you’re doing all that, the company could be paying you staff engineer or senior manager salaries?

It's not about being able to do all of it -- it's about being able to do it in a sustainable number of hours a week. Otherwise, you just have someone with the programmer title but actually doing PM work, and not doing it as well as someone who is specialized in the role.

Re: Part II: The failure points from $5M to $100M in ARR

#117

Post by a_c »

LambdaComplex wrote: post #72
HatchedLake721 wrote: post #71

Earlier quoted context omitted.

Of course there is. If not for the PM, who will speak with the customers, gather, analyze and understand their needs and problems? There should be a person that drives the product in the right direction based on customer conversations. In the early stages founder is the product owner. But as the company grows, the role of the founder/CEO changes. You now build the people, and people build the business. Engineers or C…

> If not for the PM, who will speak with the customers, gather, analyze and understand their needs and problems? The engineers? i.e. the people who will actually be fixing those problems? > Engineers or CEOs building features no one asked for is IMHO one of the major reasons lots of tech startups fail. So why put another layer (the PM) in between the engineers and the customers? Sounds like an unnecessary game of tel…

You could, and probably should. The challenge is with the fad of scale. Every company wants to be the big guy hence bunch of hiring bunch of initiatives. It is common for people to subscribe to the ritual that a proper team should have some combination of PM, UI designer, UX designer, frontend, backend, devops (which is actually ops), QA, scrum master, customer success, support, data engineer, etc. Like graft different sticks together to call it a tree. OR you could grow a tree organically, naturally. Someone in your team is good at empathizing with customer? Good, do more talking with customer. Good with motivating colleagues? Good, do more motivating. It just doesn't quite fit the narrative of scale

Re: Part II: The failure points from $5M to $100M in ARR

#118

Post by bombolo »

HatchedLake721 wrote: post #81
LambdaComplex wrote: post #72

Earlier quoted context omitted.

> If not for the PM, who will speak with the customers, gather, analyze and understand their needs and problems? The engineers? i.e. the people who will actually be fixing those problems? > Engineers or CEOs building features no one asked for is IMHO one of the major reasons lots of tech startups fail. So why put another layer (the PM) in between the engineers and the customers? Sounds like an unnecessary game of tel…

The same reason when every year a new iPad comes out, you have a thread on Hacker News with engineers complaining they can’t run Kubernetes cluster on it even though it has the technical capability to do it. Engineers don’t understand iPad’s product positioning, that it’s not built for them and they’re not the target market. Want to get a portable Docker developer machine? MacBook Air is cheaper and lighter than a 12…

But docker works better on linux… if you want a docker machine a macbook air is not the best choice.

Re: Part II: The failure points from $5M to $100M in ARR

#119

Post by faangiq »

paulsutter wrote: post #115
xenadu02 wrote: post #53

As employee #36 I lived through some of these things first hand and definitely agree with them (I think we were over 200 people when I left). It was painful going through the enterprise focus transition along with a nonsensical reorg imposed by the aforementioned Big Tech VP. One day we had focused platform-specific teams working on satisfying customers, the next we were moved to cross-functional feature teams and fo…

“Product Manager” is a double category error - the right title is customer analyst. This clarifies the actual function of the role, and eliminates most of the dysfunction

Yep

Re: Part II: The failure points from $5M to $100M in ARR

#120

Post by faangiq »

ipaddr wrote: post #2

"And remember that A players can recruit other A players, but B players can only recruit C players" In point one they list this. In point 3 he mentions his biggest mistake was hiring someone with starpower from a public company who didn't work. Unless the founder is an A player in terms of recruiting everyone hired would be a C player or less. And in point 3 we learn he is not an A player. How do B players ever get h…

It’s a low IQ point of view popularized by VCs. You can hire A/B/C if you pay enough, within some competency band as well.
Post reply on HN