An Introduction Product Strategy: Expansion
Part 1: Market Expansion
Note: this is part 1 of a product strategy series on Product Expansion. The introduction and outline can be found here. Part two on Segment Expansion can be found here.
In the early days, ZenPayroll offered only payroll. There were three general criteria for our target customers:
- Small and medium-sized businesses (SMBs) that need payroll, meaning at least one W-2 (not contractor) employee
- SMBs with a maximum of ± thirty employees
- SMBs located in California that had no employees outside of California
There were significant advantages to our narrowly bounded customer profile. Any product feature that fell outside of that small slice of potential customers was off the table. As you might know, product managers have a hard time saying “No.”, and, though the lines blurred at the edges—is this feature necessary for a 30 employee company or would they need 40+ people for this to matter?—it really did focus the product.
Solving a well-defined problem for a small, well-defined market is “better” (IN WHAT WAY) than a nice-to-have for a larger group.
By 2013 the product was “good enough” and we understood our existing customer profile “well enough” to feel comfortable expanding.
Before we move on to how and where we expanded, let's acknowledge those two unusably fuzzy measurements (demarked in quotations) ending in the similarly handwavy “comfortable”. You are not ZenPayroll in 2013, I presume, so now let's look at how you might reach your own definitions.
How good is “good enough”?
As always, It Depends™.
Your acquisition funnel, more specifically your CRM, is your friend. Make a point of documenting why potential sales fall through. If product features are not one of the primary reasons customers fail to convert then the marginal gain of developing new features can only do so much. “Primary” here could be “one of the top three most cited objections” or “the deal-breaking objection for >10% of deals.
For growth teams, “more features” is an easy and appealing out. Missing features are beyond the control of a salesperson. New features are a splashy launch for PR. Added functionality gives your marketing team more to work with.
But if your sales team isn't closing because they aren't connecting with the customer's pain points or your marketing team is targeting the wrong channels then your growth team has other issues.
How will you know?
a nested side note on rejection
Just ask.
Rejection of your product is not a rejection of you personally, so don't be afraid to ask for feedback. When earnestly asked for—when you admit how early you are and how helpful and impactful their feedback can be—people tend to be more than happy to give it. Don't underestimate the human desire to help others.
So go ahead and ask.
What's the worst that can happen? They don't buy your product? They're already not buying your product!
On the other hand, what's the best that can happen?
Vulnerability is not a sign of weakness. In fact, it is one core part of building trust. It is an admirable quality, in part because others recognize the small acts of bravery necessary to "put oneself out there".
It was not uncommon during those early ZenPayroll days that we were missing one feature or another. Payroll is perilously complex and a single missing feature, no matter how small, can write off the entire product. But when we asked for feedback and executed on it, when we pushed back on customers who we weren't actually in a position to support, we regulary came back and closed them once we were ready.
The fact that we were willing to admit our gaps—and even moreso that we valued their feedback enough to build what they were asking for—built trust. And when you're a payroll startup, trust is critical. Without it, very little else matters.
Now back to defining those fuzzy metrics.
How do you know when you understand your current customer profile “well enough”?
It Depends™.
Do you know why what is working is working?
The primary metric, of course, is “are people buying what I'm selling.” But people can buy what you're selling without you understanding why they're buying.
As with customers who reject you, you need to ask.
Customers—despite their belief to the contrary—are very rarely unique. (But don't tell them that.) There are others like them. It is your job to understand why your customer chose you, what they saw in you, and what they saw in them + you. Only then can you tell that story to others like them.
Are they representative?
This was a very real unknown at the beginning of ZenPayroll. As I mentioned before, many initial customers were from within the YC community. Those companies were willing to take a chance on us. They were also a very particular type of company.
Would other SMBs behave the same? It's reasonably possible that they would not. That there were some unknowns unknown to us and our product-market fit was with a narrower customer segment than we had thought.
(Thankfully that was not the case.)
Do they stick around?
Churn can happen for any number of reasons, but customers will put up with a lot if you're solving a deep problem that they have. (That's what product-market fit looks like.) Of course, don't push it and don't get comfortable with a product that's a pain to use.
If customers are churning, ask them why. The answer we care about here is that you're missing some feature that they need. You can fix that. When you have concrete answers, you are in a position to decide if what they're saying is in your expected or desired customer profile.
Some churn is inevitable and some of it will be customers who you aren't targeting right now. Break things off cordially. You never know, you might want them back as you expand your customer profile.
Do you know them well enough to teach others?
Every employee across the company must deeply understand your customer. A baked-in, compiled understanding is necessary, but it is not sufficient. If you can't articulate that understanding—if your expertise goes only so far as your gut—then you're not as far as you feel. Every new employee will need what you have and they can't relive your past. Nor, if they could, do you have the time.
Measure what you know by how well you can teach it.
How quickly can you onboard an experienced growth person? “Experienced” in that their primary blocker to independent contribution is an understanding of how your specific product serves your specific customer profile.
It's possible to grow quickly without understanding why, exactly, customers love what you're building…for a time. If you don't know where or why you fit with your customer, though, it's quite unlikely you can judge when it's time to expand elsewhere.
In line with the previous question, you can't know if you're product is “good enough” if you don't know what it's meant to be “good enough” at doing.
From strategy to tactics: choosing where to expand
With forty-nine unsupported states + DC, we had to choose which to support and in which order.
Here are some things we looked at:
- Market opportunity: how many additional SMBs in that region that we could support
- Market characteristics: our confidence that those potential customers fit our growth team. For example, we had no on-the-ground sales org.
- Product/engineering domain expertise: how much there is to know before we could start building
- Implementation complexity: how difficult it would be to support that state relative to another
To give examples, adding a state like Florida was comparatively easy: there are many small businesses of our employee size in Florida and no state income tax to implement. Adding a state like New York was more complicated — they do love their taxes. But the size of the market (442k SMBs) is worth the effort compared to, say, South Dakota (21k SMBs.)
Then all we had to do was pick one.
Ideally your expanded market looks, feels, and behaves as close to your current one as possible. For payroll this is broadly true. Running payroll is composed of:
- calculating compensation + taxes
- pulling that sum from the employer's bank account
- withholding taxes
- depositing paychecks into employees' bank accounts
- sending the taxes to the appropriate agencies
Simple stuff.
Well, not exactly, but at least it's stuff that, at a high level, is the same across the United States.
But the specifics of which taxes, how they're calculated, when/where/how/to whom to submit them, forms to be filed, information needed from businesses, etc., etc., etc…
Those are not at all the same.
What are you trying to prove?
To feel confident that we could deploy to fifty states plus DC, we needed to know that we could a) support more than one state and B) support a state with meaningful complexity.
And if you'd like one of each, you might as well choose the ones that get your growth team all riled up. Which is how we landed on Florida and New York.
From tactics to execution
Once we decided where to expand, we set about doing the work. The process went something like:
- Product managers research the tax requirements for a given state, what information we needed from users — new tax IDs, rates, some qualifying questions for filings, etc. — and spec out the flow for payroll admins to set up their company for that state.
- The design team mocks up the new flows and reworks designs for added complexity. For example, when there's only one set of tax details, it's easy to display and understand. What happens when there are five states and thirteen fields? Payroll can quickly tumble into unmanageble complexity. ZenPayroll's vision was to cut through the bad and reduce errors with thoughtful design.
- Engineers build both the one-time changes needed to migrate our backend from “calculate California taxes” to “calculate the taxes for each employee based on the state they’re in” and the abstractions for adding future states faster.
- The growth team prepared for targeting SMBs in other states. Since the product and customer size were mostly the same, this meant replicating California-specific content and tactics for new states.
- Salespeople needed to learn what new tax information was needed in case a customer asked if we supported it. Content specific to CA like “How to setup payroll in California” would be duplicated and repurposed for new states.
- Our support team got up to speed on the quirks and requirements for newly supported states.
As you can see, deciding where to expand first took work but was hardly the end of the planning. Executing—within teams, across teams, and across time—required a lot more than “Pack your javascript, we're going to Florida!”
Where this got us
Let’s look at the effects on the business:
- Our value proposition—delightful, modern payroll—remained the same.
- The profile of customers we could serve grew slightly, from “1–30 employee SMBs in CA” to “1–30 employee SMBs in CA/TX/FL/all of America”.
- The market opportunity associated with that expansion of our customer profiles—our “serviceable addressable market” or SAM, in MBA-speak—grew significantly, from the ~684,000 small businesses in California to (eventually) the ~5.7 million small businesses nationwide.
Here you can see the core of market expansion: what we built and why did not change. We weren't re-inventing the company, we were simply enabling it to serve more people. We weren't "innovating" the product, we were simply making it more inclusive.
Conclusion
Market expansion is the most common and tempting first step for young companies.
When you start with an MVP, you're limiting your product in exchange for faster execution and iteration. Your next step, naturally, is to build the things you had to cut. The possibilities are wide-open, which is simultaneously exciting and treacherous.
Market expansion allows you to focus on the same core problem you're solving for existing users, but be wary of the very real costs of implementation.
Deciding that we wanted to "support more states" was the easy part, and we could have easily gone from there to, “Pick the state with the most customers!” Those are neither strategies nor tactics of any meaningful depth. It's just as easy to dream and promise big as it is to run out of money.
If you don't fully understand and delibrately take into consideration the trade-offs between opportunity, time to market, implementation complexity, and whether your first steps make your next steps easier, then you're betting on being lucky. Sure, you might expand your addressable market fifty-fold, but if you run out of money because implementation took three times as long as your back-of-the-envelope calculation…well, I guess you'll know for your next company.
You don't want to be lucky.
You want to be good.
~
Up next, we'll cover segment expansion and how to capture larger deals.