Why I Hired a VP of Sales Before Fixing My Onboarding Flow: A Cautionary Tale About Scaling Priorities

[maya_builds]

I need to share a story that still makes me uncomfortable to tell, but after reading the discussions on premature scaling and metrics, I realize this is exactly what this community needs to hear.

Why I hired a VP of Sales before fixing my onboarding flow: A cautionary tale about scaling priorities.

The Setup

Three design agency clients. $15k/month in revenue. Raised $500k seed round.

Felt this enormous pressure to “grow up” and act like a “real company” because we had investor money.

What I Did (Wrong)

The professionalization trap:

• Hired VP of Sales
• Hired Head of Marketing
• Hired Office Manager
• Got an expensive office in a trendy building
• Added Jira, Asana, Slack channels for everything
• Started having “leadership meetings”

Burn rate: $30k/month → $90k/month in 3 months
Runway: 18 months → 6 months

What I Should Have Done

Invested in making the product actually ready for scale:

• Automated onboarding flow (still completely manual)
• Customer success playbook (didn’t exist)
• Pricing research (we had one pricing tier based on gut feel)
• Documentation (everything was in my head)
• Repeatable sales process (every deal was custom)

The fundamental mistake: I optimized for looking successful instead of being successful.

Hired people who made us look like a Series A company. Spent on office space that felt “legitimate.” Created org chart that impressed investors.

Meanwhile, those 3 clients? We were delivering work late. Quality was declining. They were getting frustrated.

The Desperation Loop

Needed revenue to justify the team.
Team needed deals to justify their existence.
Product wasn’t ready to scale.

VP of Sales brought in enterprise leads that wanted features we didn’t have. Marketing created demand for a product that wasn’t polished. Office Manager was… managing an office nobody needed.

The Brutal Lesson

Premature professionalization is just another form of premature scaling.

Instead of obsessing over those 3 clients—making them deliriously happy, iterating on the product until they couldn’t live without us, documenting a repeatable delivery model—I tried to acquire 30 mediocre clients with a team that looked impressive but a product that wasn’t ready.

We died 8 months after raising that seed round.

The Psychology Question

After reading all your insights on scaling, I keep coming back to this:

Why is it psychologically easier to hire people than to deeply understand customers?

Hiring feels like progress. Customer development feels like stagnation. But it’s the opposite.

Building the team feels like taking action. Obsessing over product details feels like perfectionism.

But premature scaling—hiring before product-market fit, professionalizing before process maturity—is often just sophisticated procrastination from the hard work of building something people actually want.

My question: What’s the minimum viable team structure for your actual business stage, not your aspirational stage?

And how do you resist the pressure to “look the part” before you’ve earned it?

[eng_director_luis]

@maya_builds Thank you for this transparency. Your story resonates because I’''ve seen the engineering version of the same trap.

Technical professionalization trap:

Hiring architects, DevOps specialists, QA leads, platform engineers before engineering fundamentals are solid.

Counter-example I witnessed:

Company that stayed with 8 senior engineers until M ARR, then scaled intentionally.

Why it worked:

• Those 8 were excellent engineers who could operate autonomously
• They invested in tools, automation, documentation instead of headcount
• When they finally scaled to 25 engineers, onboarding took 2 weeks instead of 3 months because systems were in place

The “hire for gaps vs hire for scale” question:

Gaps need filling now (we can’'‘t ship because we don’''t have frontend expertise).

Scale needs systems first (we could hire 10 backend engineers, but our deploy process is manual and our architecture is a mess).

Framework I use: Don’''t hire a specialist until the generalist is drowning AND you understand the problem deeply.

Example: Don’'‘t hire a DevOps engineer because “we should have one.” Hire when your engineers are spending 20+ hours/week on infrastructure and you’''ve documented exactly what a DevOps person would own.

To your psychology question:

I think hiring feels like progress because it’''s visible. You can show the board an org chart.

Customer development is invisible. You can’''t put “had 47 customer interviews” on a slide and get the same reaction as “hired VP of Engineering.”

But the latter is theater. The former is how you actually build something valuable.

Question back: How do you resist the pressure to “build the org chart” vs “build the capability”? Especially when investors and advisors are pattern-matching to what “successful startups at your stage” look like?

[cto_michelle]

The hardest word in scaling is “not yet.”

@maya_builds your story about burning through runway by professionalizing prematurely—I see this from the other side as CTO, and it’''s just as painful.

Board/investor pressure creates org chart expectations:

“At M ARR you should have a VP of Engineering.”
“At 15 engineers you need an engineering manager.”
“You need a dedicated DevOps team.”

These are pattern-matches to what other companies did, not analysis of what your company needs.

Data that changed how I think about this:

Companies that maintained higher revenue-per-employee ratios longer had better long-term outcomes.

Example from our growth: Kept engineering team at 12 people from M to M ARR by investing in leverage:

• CI/CD automation (deploy time 45min → 8min)
• Testing infrastructure (manual QA → automated test suite)
• Documentation (tribal knowledge → written playbooks)
• Development environment (2-day setup → 2-hour setup)

The management layer timing question:

Added first engineering manager at 15 engineers, not at 8.

Why wait? Because at 8 engineers, adding a manager would have been overhead. Everyone could still communicate directly, see the full codebase, understand the product.

At 15 engineers, coordination costs were crushing velocity. That’''s when management became a force multiplier instead of bureaucracy.

Controversial take: “Flat org” dogma is premature scaling in disguise.

People interpret “flat org” as “no managers ever” when it should mean “no unnecessary management layers.”

But you DO need structure before you need headcount. Otherwise you get the chaos @maya_builds described—15 people with no decision-making framework.

Question for the thread: What organizational complexity are you avoiding today that will cost 10x more to fix in 6 months?

For me it was ownership boundaries. Should have defined them at 8 engineers. Waited until 20 engineers and spent 6 months untangling overlapping responsibilities.

[product_david]

The product version of Maya’''s mistake: scaling customer segments before nailing one.

That VP of Sales in your story brought big enterprise deals, right? And they destroyed your product focus.

Same trap I fell into:

Tried to serve SMB, mid-market, and enterprise simultaneously before dominating any single segment.

The cost:

• 3 different onboarding flows
• 2 pricing models (self-serve vs sales-led)
• Custom features for each segment
• Product roadmap became incoherent—everyone’''s top priority was different

Result: Good at nothing, mediocre at everything.

The customer segmentation trap is premature scaling too.

Not just team scaling, but go-to-market scaling. Market expansion before market dominance.

Framework shift: Sequencing strategy

Phase	Focus	Success Criteria
1	Dominate one segment	Top 3 player, NRR >120%, reference-able
2	Adjacent segment	Proven playbook, repeatable sales motion
3	Market expansion	Each segment has dedicated resources

We violated this completely. Went after all three segments at once because “TAM looks bigger to investors.”

To @maya_builds’'’ question about customer segment FOMO:

List every customer segment you’''re considering.
Pick the one where you have the most credibility, the shortest sales cycle, and the clearest path to 10 reference customers.
Say NO to everything else for 12 months.

The discipline question: What customer segment are you serving out of FOMO vs strategic advantage?

For us: We chased enterprise because deal sizes were bigger. Should have focused on mid-market where we had actual traction and product-market fit.

FOMO killed our focus.

[maya_builds]

Reading these responses, I’''m reflecting on what I would do differently if I could go back.

If I had 6 months to live over:

Focus only on making 10 design clients deliriously happy.

Specifically:

• Weekly customer development calls (“show me your workflow”)
• Obsessive iteration on core value delivery
• Documentation of repeatable processes
• Pricing research to understand willingness-to-pay
• Building a portfolio of case studies and testimonials

What I did instead:

Spent time on:

• Hiring (interviewing, onboarding, managing people I shouldn’''t have hired)
• Fundraising decks and investor updates
• Office logistics and “culture” initiatives
• Building features that sounded impressive but nobody used

The question this thread surfaces:

Why is it psychologically easier to hire people than to deeply understand customers?

My hypothesis: Hiring feels like progress, customer development feels like stagnation—but it’''s the opposite.

Customer development is uncomfortable. You hear criticism. You realize your product isn’''t as good as you thought. You confront gaps in your understanding.

Hiring is validating. You’'‘re growing. People want to work for you. You’''re building something real.

But one builds a company. The other builds an illusion.

Final reflection after reading this thread:

Premature scaling is often just sophisticated procrastination from hard product work.

It’'‘s easier to “play startup”—hire people, get an office, go to networking events, post on LinkedIn about your journey—than to sit with customers for hours watching them struggle with your product and fixing what’''s broken.

Question I’''m left with: What hard problem are you avoiding by focusing on scaling?

For me it was admitting that our core product experience was confusing and our pricing was wrong. Hiring a sales team felt like solving the growth problem. Actually, it was avoiding the product problem.