So, most people reading this aren't looking for the marketing section. But I wanted to point something out I see all the time. Take a look at the roles under CMO at a 125 person company:
--
CMO (15)
Director, Product Marketing, plus 3 PMMs (4)
Director, Demand Gen, plus 3 marketers (4)
Director, Sales Enablement, plus 2 marketers (3)
Director, Brand Marketing (3)
PR & Analyst Relations (1-2)
Events/Community (1)
--
What I posit is that Product Marketing is useless as a position and should be eliminated most of the time.
The role ends up being:
- Jane Doe is the Product Marketer for product X. She's responsible for growing it as much as possible.
- She works with Anne X. in demand gen to make ads to promote the product to new customers.
- She works with Hillary Y. in email marketing to cross promote to existing customers
- She works with tech to do landing page/funnel testing.
However what I find is that the role just adds friction and useless tests to show value. Let the subject matter experts (in demand gen, email, website testing) create the plan for each product holistically. Product Marketers are dead weight 80% of the time.
I would only say this anonymously but its true. Source: I'm a marketing consultant that has worked with dozens of fast growing SaaS companies.
I see in your profile that you focus on Facebook and Google ads. If this is your context for product marketing, it’s totally understandable to see them as dead weight. If you’re meeting with B2B product marketers for paid display ads, you’re already dealing with a dysfunctional marketing org (perhaps part of why they brought you in as a consultant!).
In an ideal world, demand gen and content already have messaging guidance, target segments and titles and their pain points from product marketing (and field marketing for regional guidance), and can just run with it except for perhaps a once over from product marketing on some initial copy for accuracy or tone. Otherwise, product marketing has their hands full researching customers along side PMs, writing more specialized content that’s harder to outsource, or building and delivering sales enablement. Essentially, they’re making sure you’re targeting the right folks at the right time, prepping sales dev to receive those folks, and working with sales on scalable motions to close them. There’s no reason product marketing should be weighing in on the nuances of how demand gen is being executed.
Short version: there’s lots of facets to marketing, a good org keeps people focused where they’re needed based on their expertise.
So, I'm working in FAANG after time in strategy consulting, and I run a product ops and content dev team. I'm really interested in marketing and marketing 'strategy'. Any ideas on how to build knowledge and credibility in order to move into the space more directly?
All opinions of course, but based on a few years of working in GTM for businesses selling enterprise cloud infrastructure and developer solutions. YMMV if you’re shooting for B2C or even B2B2C, or anything else without a direct sales motion, as that’s not really my area of expertise. Also, “product ops and content dev” is an unusual combination - I’ve never seen that under one umbrella before.
Part 0: ask yourself if product marketing is actually what you want to do. It is (as you can see) a widely misunderstood role. There may be some other facet of marketing that’s more appealing - demand-gen is a challenging area on its own, as is partner GTM, or branding. If you’re looking for strategy, you may really be searching for a corp dev, product strategy, market research, or chief of staff role. No way to really know except to talk to folks in those roles and check out some job descriptions in your target industry (seriously, the only thing that really galls me when I get asked for career advice is when I inquire “consumer marketing or enterprise / B2B?” and the person shrugs…these are wildly different marketing roles and I wouldn’t dream of weighing in on a consumer marketing job search).
Assuming you’re still interested in B2B product marketing:
Part 1 is get as close to the customer as you can. The goal is to know the market (this includes competitors) and the customer as well as possible. Every single product marketer I know is sitting in on sales or customer success calls, doing research interviews with existing customers, investigating prospects we lost, and talking to people for whom the product is never even under consideration. If in a time crunch, sales people - particularly sales engineers and your top sellers - will do, but eventually you want to follow that up with more robust research designed with product management and demand-gen, as sales will only capture bottom of funnel info secondhand for you. In your role, it sounds like you can ask for 30 mins to talk to a sales leader or top seller under the guise of serving the customer better as part of product ops or content, and go from there.
Part 2 is build some content that demonstrates specialized knowledge. The goal here is to take that knowledge from Part 1 and demonstrate that you can actually turn it into something that can support other teams, at scale. The scale part is important - sales or content marketing can deliver content, too, but normally they’re looking to product marketing for anchor content to customize for a particular customer, or a webinar, or an article. No, creating this stuff is not ‘strategy’, but if you didn’t come from sales, you’re already fighting a credibility gap, and no one likes working with a product marketer who can’t make a deck, write a decently technical white paper or blog post, assemble a messaging document, or design and build a sales enablement curriculum. It’s best if you can demo your own product - and the less technical it is, the more you’ll be expected to do it. For example, analytics or productivity solutions would likely be within a non-technical product marketer’s capabilities, while something like a managed database or DevOps tools requiring integrations with a wide set of solutions means being able to work with a PM, technical marketing, or sales engineer. Check out a release blog or an overview video from a product you’re interested in doing marketing for to get an idea of what to expect.
The good news is if you have what I think is required of strategy consultants, you’re probably already a strong writer, good at boiling down market analyses down to the essentials depending on audience, and experienced with building and speaking to a good storytelling deck. Hiring managers will ask for work samples.
I'm sorry I think you've confused the Product Marketing role with something else.
PM's role is not to run campaigns, either brand or 'demand gen'.
That's regular operational marketing.
Product Marketing's job is to define the Product for the appropriate segments in terms of messaging, features, pricing. Then, outbound, they will provide the overall strategy for the various campaigns.
So part 1: They know the market well. Who uses it, why, what their needs are. They'll sit in on sales calls i.e. should be one of the primary conduits into the company from them. They'll do market research, understanding pricing trends. They'll generally do some kind of segmentation, even if crude.
Part 2: Direct product activities in this regard i.e. 'Each nation has different regulatory apparatus re: this feature so we need to break it down'. Or, even though our software has nothing to do with security, this specific issue is a problem and we need to have XYZ feature even if it's perfunctory.
Part 3: For everything outbound, they'll be setting the messaging and the strategy. 'What groups are we targeting' and 'What those groups need to hear'. Probably putting together the 'baseline copy' and materials.
The 'Marketing Ops' shouldn't be making a whole lot of those decisions on their own. They should be taking that from the PM and then deciding which channels to push their budget into.
There's quite a lot of overlap in terms of customer relationship and product features, as the Product Manager also does this, but I usually think of PM's as satisfying satisfying specific customer requests, having a broader vision for the architecture that goes beyond any segment needs.
The Product Marketing team is the one that says 'We'll be selling in 5 tranches with these features at this price'. The Product Manager cares less about that deliniation and more about the product as whole including internal architecture.
The line between product management and product marketing is definitely a gray zone and really depends on the organization, but rather than saying product managers are more focused in the architecture I think a fundamental difference is that they tend to be working much more closely with the engineers via a constant back-and-forth developing a shared understanding of what's possible, trade-offs, roadmap planning etc. Pricing is another one that in some organizations is product management led and in others product marketing.
Product marketing is an essential role for centralizing outbound go-to-market strategy, not only in terms of positioning for the outside world but also in terms of keeping sellers, marketers, and execs aligned.
I suspect these particular areas in which you feel they are at deadweight may be missing much of their focus or you've experienced an organization that is misusing this role.
There are some really great answers to my comment here! I'm delighted.
So here's the thing - I get the desired purpose of the role of centralizing GTM strategy. But in practice product managers are too far removed from the customer to be useful 80% of the time.
Basically I find that tactics that work for a given business should drive strategy more than vise-versa. This is a very unpopular opinion for sure.
In the end, messaging and positioning don't exist in a vacuum. The market responds to what it responds to. But because product marketers are too far removed from the stress of actually making messaging turn into revenue, they just don't have the skillset to be useful.
I wish product marketers could make positioning that actually works. But what happens is they make positioning that doesn't appeal to customers, and sales and demand gen pick up the slack and now have two jobs - to actually use messaging that gets results, and to make a middle manager happy with some data that helps them make useless reports upstream.
I don't know, it sounds like you've got a pretty myopic view of marketing if you think FB/PPC ads ('tactics that work') are what should drive strategy. Combine that with experience with PMMs who are too far removed from the customer (!) and I can see why you think product marketing is pointless.
From the other side of the B2B marketing fence, I see demand gen burning loads of cash on "high converting", highly "tested" ads that look great in reports, except that those leads never turn into customers, because the PPC marketers never track their revenue that far, and those lowest common denominator leads aren't a great fit for many B2B products anyway.
I suspect that if your argument is "Well, they should build the product that those leads want" I can see why (a) that view would indeed be unpopular, and (b) why you would be in conflict with product marketers who want leads that match the positioning, not positioning that matches the leads.
This is a good rough outline. As the author says, it's not meant to be a perfect target that fits every company. Adjust accordingly.
I like how he limits the number of C-level titles in the early stages to just a CEO and CTO. It's a common mistake for startup founders to hand out too many C-level titles to their cofounders and early hires. This causes problems when the company outgrows some (or most) of those people. If you need to bring in a more experienced CMO, CRO, CSO, or other C-level, your only options are to demote the existing C-level and replace them with a new boss or to arrange their exit from the company. Neither are good looks, and neither make people happy.
Much better to start with Director and VP level titles in the early days. You can either bring in a C-level above them when the time is right, or promote them to C-level if they grow into the role.
That said, most SaaS I've worked with would want more people on backend/devops at the earl stages. Having 3 people total handle combined devops and backend development is a big risk, especially if any of them want to go on vacation or leave for other jobs. Downtime and server outages are not a good look for a growing SaaS, so don't skimp on people who can keep it up and running.
I know it’s close to the truth, but it still feels weird that this hypothetical 50 FTE SaaS company has 2x the amount of sales/CSM folks vs technical profile. And that the whole product is in the hands of 6 devs (4x FE and 2x BE).
Yes, this is crazy to me. In a company of 50 people, six are working on the actual product!? What are all these directors of such-and-such doing all day?
It's often a much bigger lift to get people to adopt your product than it is to make the product itself, especially now when so many SaaS markets are either captured by large players or, conversely, hypercompetitive.
I used to think that as well, but sales doesnt scale like engineering, and their priorities provide a good counterbalance to engineering and even product priorities.
The thing that I thought was broken about it is the bread first strategy. I would think it would be better to focus on a segment of the market until they start getting momentum. Many products we see that are targeted at smaller companies are going to be wholly unacceptable to large enterprises.
* This feels way too hierarchical for the size -- there's significant distance from many employees and the CEO even at small sizes.
* Could not disagree more with putting HR and Ops under the CFO (even in a 50-person company). That's a surefire way to have a neglected HR/people function.
At 50 people everyone is still within 1 skip-level of the CEO. That doesn’t seem overly hierarchical to me.
What does seem a little surprising is how many “chiefs” the CEO has reporting to them. In my experience with companies around 50 people, things actually tend to not be sliced into so many pieces, but rather there are a few larger slices that are functionally heterogeneous.
I think the three machines approach works best for companies 0-100 people (depending on the company, for SaaS it makes sense).
Basically have someone own:
1. The product - CTO
2. The customer - (Could be a director or VP of marketing/sales/rev)
3. The company - CEO
Anything beyond those three execs at or around an A round is nuts to me.
I think a lot of people underestimate just how much you can outsource at that size. There almost no reason to have a COO when you’re less than 100 people. Same with a CFO. Either of those hires don’t become strategic until you’re doing $10+m in rev. Until then, use other SaaS services for payroll, book keeping, tax savings (MainStreet), etc. These take little effort use and can be setup by one of the founders in less than a day.
Ah, yeah when I say someone should own the customer, I mean you should have an exec dedicated to finding, closing, and keeping customers.
One slight contention here is who owns the keeping part. I’ve seen that under both sales and product, and don’t have strong convictions either way. I think it mostly depends on the type of product you’re selling.
Absolutely agree. It feels like the have a C level just to have it. Not only is that not going to be cost effective (C level titles expect C level comp) but it is setting you up for a lot of left hand/right hand issues even at a small size where that definitely should not be happening. Having worked in large orgs with 10+ levels it is a nightmare in the making.
I mean, _every_ C-level leader needs direct communication with HR to properly staff their organization. That's why it's a top-level function, not a subcategory of something else.
Why do the number of front end devs exceed the back end? Does anyone else see a problem here? Front end effort has always been a fraction of back end effort on the systems I've developed. If that's not the case, I can only hypothesize it's because front end toolchains have gotten overly complex for what they accomplish. Not only that, but I would posit that for most SaaS ventures, the back end is where the differentiation and value is delivered, so that is where the bulk of dev resources should be deployed.
The standard of polish that users expect has gone up a lot. The Front end is what users actually interact with, to them it might as well be your entire stack
Of the consumer/Enterprise SaaS companies I've worked with, many devs who say they are doing "backend" are just writing controllers and APIs specifically for front end/UI consumption.
A lot of places have combined that work into same stack/JS and call it "frontend".
I think that those figures are the kind of estimates that only make sense in aggregate: when it says 8 front-end developers, I just assume that it has a standard deviation of at least 4.
I've been a back-end dev at one of those places. When the front-end is comprised of Android, iOS, Web, and even Windows Phone, a senior and productive back-end team can easily serve multiple front-end teams.
In my case, a back-end team of 4 owned everything "non-app" while about 10 engineers owned the various front-ends.
at a startup with less than 50 people, the frontend engineers will typically manage "frontend services", which includes the backend that directly serves the frontend. basically full stack, which was't included.
yeah, as someone who has worked on both ends of the stack, that was confusing as hell. if you only need backend dev's on a 1:2 ratio with frontend, then your product ain't complex to begin with to warrant a separate frontend team.
but then having vc money contributes to decisions most of us, will never understand.
> There are plenty of independent SaaS businesses that make it past $200K ARR per person with teams of <10
Which is great for companies aiming to stay small and self-bootstrapped. There's nothing wrong with this model for founders who want to stay independent.
The VC alternative allows companies to grow faster than organic revenue growth might allow. It can take a long time for a 10-person company with $2mm ARR to grow to $2.2mm ARR so they can hire the next person they need. Alternatively, they can take VC money and hire the next 100 people they need without waiting for revenue to get there first.
One model isn't inherently better than the other. The important thing is for founders to decide which type of company they want to be and stick to it. A founder who wants to grow organically is going to have a bad time if they take money from investors who want growth. A founder who wants to grow as fast as possible is going to have a bad time if they're constantly stuck waiting for organic growth to let them make the next hire.
The other point to add is that while the organic business is waiting to get from $2mn to $3mn, their VC funded competitor can throw 100 people at the problem and eat the entire market.
The point is if you’re in a VC heavy space, you often have no choice but to dance along with the music.
This is what I understood it to mean: a startup grows marketshare rapidly with VC money infusion in an easy money environment. But when credit dries up like it did in 2008, the startup could be left hanging as VCs might not fund the next round of their previously star startups as they want to deploy resources to their absolutely top-rung startups. So, even good startups can be left stranded.
That's the feeling I have. Would like to know if my thinking is on the right track.
I like this comment. The archetype of the bootstrapped "lifestyle" software company is quite popular on HN, and for good reason, and venture capital often the subject of (often well-deserved!) criticism; but hey, the VC business model exists (and produces some spectacular successes) for a reason.
Well, when we consider that VC funding is usually trending towards a model of hyper growth, it becomes fairly straightforward to see that the model leans towards throwing people at the problem to make it grow faster. I do think it would be interesting to see a study comparing growth rates of companies comparing to number of employees as (educated guess here) operating with that many employees that quickly is going to result in a number of inefficiencies.
I wonder if "VC funding" lives in a space between old-style business development and hierarchy, vs. new-style revenue expectations. We get middle-heavy startups (backbiting optional) trying to cover zillion dollar AWS bills by perpetually pretending they're on the verge of a Google-up. This is why they need $50MM rather than 1/10th that.
Um....are you sure those numbers aren't MRR? I'm running a 2-person business with over $100K ARR, and we're not special as far as I can tell from talking to other more micro-style founders.
EDIT: Oh per person, I missed that part. Still though, that puts us at over $50k ARR per person at an org size of 2. However it also makes the comparison completely pointless.
This is silly. Of course I understand that because of scaling a 50-person org will have one "technical leader" who is, by definition, the CTO, and they might only have 12 reports.
But you don't now need to introduce additional abstractions when you go from 50 to 125. Why introduce a VP of engineering? Can the CTO not handle 3 extra director reports (4 if you add a "director" of QA with 2 reports?) Come on. Who is going to come on to be the "VP of engineering" for a startup, yet not have/want oversight for Security, Analytics, and Infrastructure?
Also in the 50 person startup, the product lead with 5 reports is a "Director" but a product lead with 11 reports is a "VP"? Get outta here, this is silly. It's the exact same role. It is NOT more scope or oversight.
There should be orders of magnitude size growths before you start overthinking the difference between a director and a VP, or introducing new layers.
"technical leader" for a 0-50 org is VERY different job than >100 org.
The CTO is probably very good at 0-1 type of start up work, and probably a cofounder and inexperienced eng leader.
But a experienced VP of eng is required to build teams and process later on. But usually those VP of eng are not good at building startups from the ground up.
So the solution here is either:
- fire the CTO co-founder and replace them with a VP of eng type of talents
- hire VP of eng and let the cofounder CTO focus on other works
- CTO is like a Chief Science Officer at a biotech or seniormost Principal/Fellow Engineer at a bigger tech co: ~No boss and ~no reports. The more boring the core tech & scale, the less important to have.
- VP.E might do more on internal people processes, like run overall technical recruiting, while CTO stays involved like helping close candidates & joins bigger sales calls, but is overall more peripheral to the people management. They are not fully removed -- they might focus more on say code culture due to being an experienced technologist & deeply familiar with the core code.
- Both VP.E & CTO might say fix little bugs to make sure code culture is sane and help add productivity tools to the stack, but CTO will more likely run major arch advances & new system prototypes, while VP.E will help trains run on time by seeing ahead around coordination issues. Both need to be leaders (consensus building, ...), but one leads the company's technology and reads deeply on technology, and the other, its technologists, and reads deeply on management.
Lacking a good VP.E. leads to inability to ship: cannot execute tactically. Lacking a good CTO leads to a stagnant technology org: cannot execute strategically.
I suspect this changes at bigger scales, where my cynical side suspects, at most orgs, corp dev (M&A) > Office of CTO for technical leadership :(
A 40 person Eng. Org. is not going to be led by one person with a bunch of direct reports.
IT and Eng. roles will probably be sub divided.
Instead of a VP it might be possible to have just a manager or director, but it depends on the seniority of the people you're bringing in.
The CTO's job is not just downward focus, they have strategic things to to.
A few titles could be mushed around but it's just about right.
For the VP product with only 11 reports - that's a staff position, it doesn't have to imply a lot of headcount.
You might have a Colonel in charge of an entire Regiment of Soldiers, but another Colonel in charge of a much smaller detachment of Medics, or Intel, Communications, or even just a Chief of Staff etc..
Aside from handing out VP roles to possibly people that are too young or inexperienced, the 'tree' itself is just about right.
The problem is the tree is imbalanced. The CTO has an org of 40, with 1 VP report, 3 director reports, and 2 IC's.
The VP has 28 - the vast majority of the org.
This role is redundant at this size, and wasteful.
Just have one technical leader who maanged SIX directors (and 4 IC's, and it is still a reasonable size team. What is the VP of Eng providing here that the CTO can't do?
BTW, arguably this is still true at the Series C 400-sized company. The technical org is 114, but the VP of Eng managed 92 of them.
I think the mistake you are doing is that these are primarily titles. It does not 100% correspond to what they actually do particularly at C level. If you are a CTO of a startup you frigging do everything for a long time. You want people to fully focus on the daily challenges of technical projects. You can call them VP of eng of whatever you want.
Nothing new will ever work for certain manager types that can only work the way they are used to workingm, aren't very introspective, and don't think about problems beyond the surface.
In my experience much of what gets discussed 1:1s should be discussed with the larger group during retro times. This can be setup for anonymous feedback if that makes people more comfortable(it also comes with benefits anyone involved so you can "read the room").
Coaching can work well with a rotating peer coaching setup.
Now you can get 20+ people with leads reporting to a single person who owns the employee relationships. Dump all the useless middle management.
For those of us who want to start an indie one-person SaaS, this is sobering - because it means that for a while, you’ll be doing all 50 of these jobs. And, paid far less than any of them.
No, you won't. Most of these jobs are consequences of scale, and exist to support it.
For example, you don't need any of the management jobs until you've hired enough people that you have to manage them. You don't need to do sales and customer management jobs when you have no sales and no customers. Etc.
Of the job titles that remain, these are all specializations. The projection of the work that you'll be doing onto any of the roles will be so small, that there's no point in even identifying it. E.g. you're not really doing "Dev Ops/Infra" if your project is running on a single server in whichever cloud you had the most free credits for.
For a indie one-person SaaS, this list is useful only as an identification of broad areas of concern. I wouldn't even try to read anything from relative number of any type of positions - jobs don't scale at the same rate. E.g. sales workload may grow faster than dev workload in B2C, the opposite in B2B.
Here's the good news: when it's just you, you don't need HR, because there are no interactions between employees, no hiring and no firing. Before you have any income, you barely need a CFO function, and so on and so forth.
Really, you only have about five roles:
- make the service
- run the service
- market the service
- accept money for the service
- support the service
I think there's room for (i.e. I think I'd read) an IndieHackers type site that focuses on one-man armies! Like IH has done in the past couple years you'd probably have to expand it, but even including <5ppl companies might still place a lot of success stories within arm's reach of OMA ambitions.
Yeah, the only way this chart makes sense to me is as "what's your target for using your series X money" rather than "where you should be when you get your series X money".
The terminology around seed vs a vs b is so skewed right now, but a 50 person series a startup, just estimating, is a 5 mil per year burn. Hard to say exactly the raise, but personally I’d be uncomfortable with less than 3 years runway, so let’s call it a 12mil raise. 12 mil raise for 25% of the company (again, totally back of the napkin here) puts us at basically 50mil valuation. 50 mil valuation on 1mil ARR seems way high to me, basically this all seems sort of shifted left on the headcount side (series b should be 50 people) and right on the revenue side.
I feel like 3 years of runway is actually quite a lot if you're gunning for extremely fast growth. I think you would have raised a Series B well within 3 years if you're growing as expected.
It's really interesting how AAR scales per employee. The larger you are, better the ratio -- this helps explain why large companies can afford to pay so much more for top-level employees than small ones.
I'm sure this seems obvious to some, but I'm not enough of a business/finance person to have really thought about this before. It helps crystallize some dynamics between, for example, my current employer and my immediately former employer; the former is able to pay dramatically more (around 150% on salary, plus equity) for essentially the same work, and gets more and higher quality talent as a result.
I wonder how a smaller org can escape this problem, if at all.
> my current employer and my immediately former employer; the former is able to pay dramatically more
This sentence was a little bit hard to parse because of conflicting meanings of the "former" (in sentence vs in your employment history). You meant that your new employer have you 150% salary and equity, and the previous one couldn't compete, right?
A growing company with investors happy to throw away large amounts of money for years in case they end up with a unicorn doesn't need to be profitable.
A growing company that was bootstrapped and is trying to make something actually worth selling in order to fund further growth is an entirely different situation.
There are plenty of other options. One that can work well if you have a relatively small organisation and every person really counts is to set up a profit-sharing scheme. That gives everyone a personal stake in the success of the business and it can work out well for everyone without the complexity and uncertainty of any scheme based on equity or options.
That might be true for startups, but my former employer is a 20+ year old established company with a specific niche. Growth is limited, but business is stable and profitable. It's a different mindset.
In that case it sounds like they have found product market fit and are mostly content with the way the business is growing and likely don’t need the kind of “top talent” that you offer. They’re ok with “mediocre talent” since talent isn’t enabling growth or survival.
The market is pretty brutal but I’ve seen many extremely talented folks work at mediocre organizations because of reasons other than financial. I guess everyone is happy with the arrangement.
You'd think and hope so. To be honest, I think they're trying to have their cake and eat it too - that's part of why I left. They wanted to grow and had all these strategies for doing so, but not nearly the resources to do it, and were unwilling to invest in getting more of them. We got a lot done with a little, but there were clear limitations.
It was an outlook I never quite understood. The core business was and is strong, reliably profitable and has made plenty of people quite wealthy and employed dozens more gainfully. Why mess with that success? What's in it for them? What's the point of (fake numbers) $100m in sales vs $50m when it comes to our 70-person company and small number of private, non-institutional owners?
But I am, of course, not the one who makes such decisions.
Series A feels top heavy to me. Having a director or VP of Product at that point feels like a mistake. I also think you could do more delegating under the CTO. 12 reports is too much.
Another way to think about this is ratios of budgets to departments, ratios of "core" vs "experimental" spend, and ratios of IC's to managers. If you map those constraints out for the system that you're building you can tailor things a little more to your business while making intelligent trade-offs.
The CEO seems to manage the CPO & CTO relationship in these models as well, which seems like a risk given a CEO's value is investor and market / key customer facing, and any time they spend on managing the peers in the CPO/CTO relationship is opportunity cost against that value.
It also means the CPO & CTO as peers will be jockying for the CEO's attention as a deciding factor, which seems like unnecessary friction. The CPO's key relationships are to the board and supporting the CEO activities and sales key accounts with strategic feature alignment that may include M&A.
The CTO's key relationships are outward with technology partners, suppliers, vendors, etc. and downward in the org. A CTO should be a partnership with a COO role, as they are solving scale and optimization problems together.
All that is to say, depending on org maturity, I don't think CTO/CPO should be peers under the CEO. IMO one of the CPO/CTO should report to the other, as otherwise you're going to get unproductive running battles between them that cost CEO time. If you have this model and are wondering why your staff aren't working well together, it's you.
This is why it can be useful to keep a founder around as a facilitator with convening power, provided they aren't too marginalized or a loose cannon. That said, I've only consulted to orgs like this and see it across them, and this is not the view of a CEO.
I actually don't disagree with you on this. Can absolutely see how this can create friction, but it's also one of those cases when dealing in absolutes is fraught with peril. A CTO is not a CPO and having strategies being defined - or steered by a singularly technically-minded person can work fine in a lot of scenarios, but for others, it's important to foster a certain level of autonomy for managing, growing and building the product, feature set and roadmap. Same thing in reverse.
There's definitely overlap between the two, but a collaborative approach works better in my opinion. As a disclaimer, I'm a CPO myself - and enjoy the working relationship and collaboration with the CTO, while reporting directly to the CEO and the board. Also, I guess that sometimes it really comes down to the types of personalities that are present in the management team - as well as the type of product being built.
I don't think I have anything particularly outstanding to share — for the most part, I believe common sense gets you really, really far. In fact, many choices I make go against the "common wisdom" and advice from the gurus, but I'm very happy with the results I'm getting.
There is only one fundamental truth: you need a good product that people are willing to pay for. Everything else is optional — you can get by and run a successful business without marketing, without mailings and mailing lists, without A/B testing, without AWS, without Kubernetes, but you cannot run a successful business without a good product that people are willing to pay for.
Anyway, the advice in the article might actually be good for large venture-funded SaaS businesses. I didn't mean to mock it, I just found it amusing how different my viewpoint is.
I always thought that in SAAS company at least 50% should be in the engineering, instead, out of 50, only 12 (25%) is in the engineering..
Not sure if this is the correct rule of thumb, but one day from Software Engineering I might want to move into management or have my own startup and this would help.
It depends on the product, but most SaaS companies in this space aren't doing a lot of breakthrough engineering. 9/10 of them have a shiny UI, basic CRUD on the backend (with large chunks outsourced to AWS and other managed infra services), and an army of marketing and sales people to push it onto large enterprises.
On the ML side you probably have more people working on data gathering/cleaning/client specific tweaks than actual modeling. (Practically, I’d say is 80%-20% at best in the projects we do at work).
It scares me to think that there's some capital-backed, likely nervous 20-something, reading this on their iPhone with shaky hands before screenshotting it and shipping it off to Glassdoor. Your company should be so much more than this, even an example that you find online for guidance.
Cargo-cult leadership might be the demise of the modern SaaS/VC workflow.
People that doesn’t understand what some position even are trust this kind of things and hire a lot of people for the sake of it.
Measuring growth in headcount is disfunctional and just bad. I’ve seen many of startups hiring tens on engineers because they can, and to show “growth” to the outside world, not because they added any value
I know this guy has a track record but not sure why you’d only have 12 engineers and 5 PMs in a 50 person company. Do you really need the Finance stuff? Why not just engineering and sales?
I don’t think you can ignore stuff like marketing at 50 person scale. But I assume you can wiggle some of the team sizes, especially if you outsource some roles that aren’t your core business.
Perhaps because I only work at companies where the data is the product but I have a hard time imagining a company without a Data Science Department reporting into the CEO
Understanding fully that this is meant to serve just as a reference, this type of article risks positioning hiring as an end — not as a means to an end.
Better to take external advice on typical team sizes / talent needed to achieve specific milestones specific to your business. Hire to get meaningful work done. Not based on a funding-centric "target" org chart.
very insightful, would like a version for before-round-A startups.
By the point when you got round-A, you have already passed the most difficult time for a startup: to survive from bootstrap or angel-fund to round-A.
the key is actually how to get angel-fund or bootstrap so you can reach to round-A, instead of being those 95% failed to launch ones and never saw the light.
Let's be generous and assume they outsource this -- which is a huge mistake. Your contracts are going to be an enormous pain, or if you use the paper from your customers you will be at a disadvantage.
Have a sharp general counsel _early_. If you want real (i.e. enterprise) customers you will get destroyed if you agree to their terms for SLAs and penalties.
I don't get this either, even with 50 you would have a someone with corporate law experience and 400 ?! What am I missing, is one of the top management people at the same time lawyer, or they are on case paid bases?
Can some explain to me what 25-50+ engineers do all day at these startups?
My experience is probably skewed, mostly working for SaaS companies providing enterprise B2B software, but the product and engineering team represents only 15-20% of the headcount - the customer success team is often 2-3x larger.
They will spend time overengineering things because they will get bored due to lack of meaningful work required from them, or have 7 hours per day of meetings
In my experience at SAAS companies, one or two teams alone are responsible for "This huge integration that's gonna change everything I swear! Trust us Yahoo JAPAN is BIG"
I've also usually noticed a lot of inefficiency on the dev-side too (bike-shedding, over-engineering, rewrites).
I fully expected this to be satire. Surely this is all subject to change based on the backgrounds of founders and early employees, industry, funding goals and sources, etc.
A less than 1:4 ratio of tech positions, 2 backend developers on a supposedly 50-employee SaaS company is ridiculous and shows how startups burnout tech employees.
I think this is stupid. Building a business shouldn’t be about hiring people to fit some platonic form of a company.
You should hire people based on a market need for that role. While I agree that this is the org chart that most often organically arises, it’s not because CEOs read this article on sub stack.
This is about as useful of information as telling me how to decorate my office space when I have a 50 person company.
Agreed. It feels very "one-size-fits-all" in a technical landscape that is constantly changing. Some products are exponentially more backend-focused (twilio), some exponentially more frontend-focused (salesforce?). I don't know enough about other departments to say for sure if these are universally valid numbers, but I doubt it.
Definitely worked for enough C-level people who said "We now need a 6-person data team in our startup because my friend Bob said so, and he's a big deal" or whatever the trend of the day was, to find such prescriptive templates questionable at best and dangerous at worst.
It's so funny when a CEO or a CTO or a VP has 20-50 people reporting to him/her :). This is barely getting outside of the "manager" rank in a proper corporation.
Yes. Not to mention that a director or a VP role has usually rather little to do with managing specific people directly, it's more about setting the culture, approving specific decisions and occasional big organizational re-wirings.
--
CMO (15)
Director, Product Marketing, plus 3 PMMs (4)
Director, Demand Gen, plus 3 marketers (4)
Director, Sales Enablement, plus 2 marketers (3)
Director, Brand Marketing (3)
PR & Analyst Relations (1-2)
Events/Community (1)
--
What I posit is that Product Marketing is useless as a position and should be eliminated most of the time.
The role ends up being: - Jane Doe is the Product Marketer for product X. She's responsible for growing it as much as possible. - She works with Anne X. in demand gen to make ads to promote the product to new customers. - She works with Hillary Y. in email marketing to cross promote to existing customers - She works with tech to do landing page/funnel testing.
However what I find is that the role just adds friction and useless tests to show value. Let the subject matter experts (in demand gen, email, website testing) create the plan for each product holistically. Product Marketers are dead weight 80% of the time.
I would only say this anonymously but its true. Source: I'm a marketing consultant that has worked with dozens of fast growing SaaS companies.