An Introduction Product Strategy: Expansion

Part 2: Segment Expansion

Note: this is part 2 of a series on strategic Product Expansion. The introduction and outline can be found here. The previous section on Market Expansion can be found here.

Part three on Solutions Expansion can be found here.

Segment expansion is building product features to capture higher value deals while solving the same general problem.

For ZenPayroll, segment expansion was moving from 1–30 employee SMBs to businesses with 50+ or 70+ or 100+ employees. The product offers the same functional solution: payroll for businesses. What changes is the size of the deal.

Because ZenPayroll was priced per employee per month, the customers served by these features paid more on a per-customer basis. If it took roughly the same amount of sales/marketing to onboard a customer with fifty employees as to onboard one with thirty then we made more money. (Yay.)

Frequently, early-stage investment pitchs involve a slide around segment expansion. Of course you would prefer $600 per month to $30 per month. Most B2B SaaS companies chart the inexorable march towards enterprise, subscription media companies towards a wealthier readership that commands higher ad rates, consumer companies towards a higher margin pro-sumer customer (or even a jump into professional products/services/packages), etc., etc., etc.

Challenges

But feature development aside, there are sales constraints to moving up-market.

Maturity and social proof

In the beginning, ZenPayroll had a customer base primarily comprised of SMBs from 1–12 employees and a small contingent of 12–20 employee companies. Even if we built the necessary features, we could not sell to a company with 70 employees.

They would ask, quite reasonably, about our experience with companies of their size. They would ask for a few customer references. You can see the problem: our experience was zero and we had no customers like them to reference.

From the perspective of their HR team, the risk of botching the entire company's payroll raises a high barrier to entry. In the case that our product was not as good as advertised—if we mispaid taxes or locked employees out of their accounts or hadn’t built the right features for larger customers because we didn’t have any current customers for user research and development—then the HR person’s boss could rightly say, “Why did you adopt this system that literally no one of our size has used before?”

There's a reason you hear the phrase, “no one ever got fired for buying IBM.” The product could be worse or more expensive, but it shifts accountability. What else could you have done?

Addressing concerns

There are ways to address these concerns, some of which don't require new product features.

Setting the terms

If you go back and read press releases or listened in on sales/support calls from ZenPayroll in 2013/2014, we rarely mentioned metrics like average employee size or number of customers.

This was an explicit company policy. These numbers are private financial information, so this isn't atypical or nefarious. We just weren't trying to announce the revenue of a one-year-old company, especially a number that changed so rapidly.

The more strategic reason for not disclosing these numbers is that they didn't address our customers' concerns around product maturity and social proof. In fact, the true numbers would probably hurt our case. Hearing we had fifty customers or that our average customer had twelve employees isn't comforting for something as serious as payroll.

But we didn't not share numbers. There was one in particular we talked a lot about: payroll processed. We would say things like, “we process millions of dollars in payroll per year.” It sounds like a lot! And it's not not a lot of money, but it's not as much as it seems.

For example, take a company with twelve employees paying each employee an average salary of $90,000. (Note that we served almost entirely tech companies, so average salaries were considerably higher than the American mean.) Now ask yourself which is more impressive:

“We run payroll for one twelve person company.”

or

“We are processing over one million dollars per year.”

Right?

Right.

When potential customers asked how many businesses we served or the size of our largest customer, what they were really asking was if they could trust us. We chose to answer that question instead of the one that they had literally asked.

Social proof by proxy

ZenPayroll's early investors were primarily angels. Many were CEOs of well-known companies: Jeremy Stoppelman of Yelp, Aaron Levie of Box, Drew Houston of Dropbox, Patrick Collison of Stripe, Jared Leto of…Jared Leto.

Endorsements from successful people lend an air of credibility, even when the endorser has no experience in or insight into the field. You might wonder who gives a cares about what Jared Leto thinks about small business payroll, but people don't not.

Walking up market

If we approached a company with twenty-five employees, however, our experience with twenty employee businesses was relevant enough. If we could handle customers with twenty employees, there’s a reasonable assumption we could handle one with twenty-five. Once we had a dozen twenty-five employee customers, selling to thirty employee SMBs wasn’t so bad. And on and on. The more you win, the more you win.

Your customer base is itself an asset when selling new customers. There will be, of course, points where that asset is not enough; when segment expansion became less like a steady incline and requires concerted product development or redesigns to jump forward. But don’t underestimate the value of proven execution; of answering the “can you handle us?” question as well as possible before expanding upwards.

But what about the product?

Unfortunately, the product changes necessary to move up market are highly business- and product-specific. For us in those days, there were general design and usability improvements like pagination, performance improvements for our payroll engine, and billing and pricing (e.g. bulk discounts more common for larger deals.) There were features like supporting sub-organizations within companies.

One larger effort was integrations with other software. There is an inflection point where onboarding new employees, tracking time and attendence, and managing teams becomes a drag on HR. (Much more on integrations later.)

Where to end

For Gusto, the segment expansion has mostly capped out in the 100-ish employee companies. Strategically, you might decide to cap segment expansion when:

  • the marginal costs of product implementation don't match the expected value of new customers
  • the marginal cost/benefit of segment expansion is less compelling than other types of expansion
  • you're hitting product walls with customers already in your customer profile

The question of where to stop yourself is beyond the purview of this piece (It Depends™.) For companies generally a few factors include: prioritizing focus over breadth, finite product bandwidth and expertise, costs of moving up-market (in people or capital, though the former can be somewhat a function of the latter), the mission and ambition of the company, etc. etc. etc.

Conclusion

As you've seen, segment expansion can have as much to do with building for the story you tell as it does with building the features to support larger ACV deals. Those features are dependent on the business, of course, but be careful not to lose the MVP attitude when venturing out. It's okay to start with a small segment of customers you can support with minimal effort, then expand from there.

Up next, we'll cover solutions expansion and deepening your relationship within existing an customer profile.