Building a product team from scratch: lessons from Mercury and Square

Executive overview

Most founders resist hiring product managers until bottlenecks force the issue. At Mercury, 400 employees — including ~200 engineers — operated without a single PM title before the org finally formalised the role.

The core tension: someone always does the PM work. When engineers and designers absorb it, they stop doing their actual jobs. The question isn't whether you need product thinking — it's who carries it and when to make it official.

The right time to hire PMs is when founders can no longer scale themselves across decisions, cross-functional coordination, and adjacent product bets.

When to hire your first PM

• Founders are the original PMs — don't hire until they genuinely cannot do the job anymore
• Bottlenecks signal readiness: decisions stall waiting for founders, engineers/designers absorb PM work and drop their core responsibilities
• Complexity triggers: compliance, legal, risk, cross-functional coordination all compound the load
• Adjacent markets demand it: when you target a new customer segment, you need someone close to that customer
• Mercury's mistake — promoted "business leads" to PM titles without PM training; strategic planning, roadmapping, and prioritisation suffered

Building the PM discipline

• Start by defining expectations in writing: career ladder, values, skills required at each level
• Mercury anchored the ladder on two vectors: products customers genuinely love, and measurable business impact
• Table-stakes skills: product sense, customer obsession, analytical thinking, system-level strategy
• Interview process should mirror the career ladder — test for the same signals you reward in performance reviews
• A written interview component surfaces depth, care, and communication quality — often missed in PM hiring
• "Well stolen is half done" — borrow from strong existing ladders, then customise to your culture

The pioneer, settler, city planner framework

• Pioneer: zero-to-one PM; creates from nothing, works without infrastructure, takes raw material and builds
• Town settler: growth-stage PM; builds on early foundations, experiments, adds structure while still flexible
• City planner: mature-product PM; drives efficiency at scale; every change touches millions of customers immediately
• Match the PM type to the product stage — not just to the resume
• Founders who dislike PMs are usually picturing city planners when they need pioneers
• Probe interview candidates on which mode they thrive in and what they want next — "the resume without the receipt is just a piece of paper"

Attracting great product talent

• Understand the candidate's S-curve: y-axis = ambiguity, x-axis = scale; know where they are and what their next step looks like
• Senior PMs want scope (big, meaty problem) and challenge (will this make me better?)
• People want to play tennis with better players — signal who they'll work alongside, not just what they'll work on
• Candidates judge companies by interview quality — a well-designed process signals that you understand the role
• Be transparent about the good, bad, and ugly; don't over-promise, but do sell the genuine opportunity

Investing in quality and craft

• There is a false dichotomy between quant-heavy experimentation and design-heavy artistry — you need both
• In boring industries (fintech, procurement), precision and intentionality breed the trust customers need to move their money
• Small details — like Mercury's BillPay invoice zoom feature — won't move a single metric but generate the strongest customer reactions
• Compounding effect: many intentional incremental improvements build a moat and become a competitive advantage
• Quality has second-order effects: it attracts talent who want to be proud of their work, and it deepens customer loyalty
• Quality as differentiator requires top-down cultural commitment — it cannot be driven bottom-up alone

Going multi-product: org structure

• New product seedlings placed too close to mature products get crowded out — their roadmaps are always trumped by maintenance and core priorities
• Create a structurally separate expansion org with dedicated headcount; Mercury's expansion team exists for exactly this reason
• Treat new product lines like angel investments: quarterly check-ins, concrete milestones, but flexibility for pivots and learnings
• Seed teams run two-week sprints vs. monthly cycles used by mature product orgs — stay nimble, learn fast
• Full cross-functional squads (eng, design, PM, data science) with leveraged support from central ops, risk, CS

Going multi-product: product and go-to-market strategy

• De-risk new bets by looking for baby signals already in the existing product (Mercury's "payment requests" URL presaged invoicing)
• Prioritise adjacencies where you already have distribution advantage — don't require a full go-to-market effort to test demand
• Evaluate new bets on TAM, existing advantage, and friction to escape velocity
• Each subsequent Mercury launch took less time than the previous — execution compounds as the team learns the pattern
• Don't rush from launch to revenue optimisation; give new products away free first to validate usage, engagement, and retention
• Focus on building products people love; revenue follows as a by-product — not the reverse

Customer obsession done right

• Aim for one or more customer conversations per week per PM; discovery-mode teams run 20–25 calls
• Enter calls as a documentarian, not a validator — remove bias, observe context, find patterns, then test them
• Customers are polite on calls; what they say and what they need are often different
• Customer obsession must be anchored to business viability — what customers want for free can't always be what you build
• Triangulate: qualitative research + quantitative data + willingness-to-pay work before pricing decisions
• Leverage every touchpoint: CS calls, RM/sales calls, surveys, social media, off-boarding messages in Slack