Building for Scale: Product Lessons from Minnesota’s Fastest-Growing Tech Companies
When people think about tech scaling, they usually picture Silicon Valley startups burning cash to chase hypergrowth. But that’s not how we do things in Minnesota. Out here, we build differently. We build to last.
Working as a Product Manager in the Twin Cities, I’ve watched Minnesota tech companies grow from regional players into global powerhouses—and I’ve noticed they scale with a philosophy that feels distinctly Midwestern. It’s not flashy. It’s not about moving fast and breaking things. It’s about building systems that actually work, talking to your customers, and making deliberate choices about growth.
This essay shares what I’ve learned from companies like Jamf, Digi International, SPS Commerce, and C.H. Robinson—and what their scaling approach can teach any product team about sustainable growth.
Why Minnesota’s Tech Scaling Philosophy Matters
Minnesota’s tech ecosystem isn’t new. We’ve had major enterprise software companies here for decades. Control Data Corporation (CDC) pioneered supercomputing. Honeywell built automation at scale. Best Buy scaled retail technology nationally. This history matters because it shaped how modern Minnesota tech companies think about growth.
There’s a particular strain of pragmatism in Minnesota business culture. We’re not trying to disrupt; we’re trying to solve real problems for real customers. We’re not chasing venture capital at any cost; we’re building profitable businesses. And when we scale, we do it deliberately.
I first noticed this distinction when I joined Veeam. The company has massive global growth, but the approach feels different from what I’d read about in Valley-centric tech media. We’re obsessed with product quality. We listen to customers relentlessly. We build features that solve actual pain points, not ones that look good in pitch decks. That’s not unique to Veeam—it’s baked into Minnesota tech DNA.
Lesson 1: Know Your Customer Before You Scale
The Minnesota Approach: Depth Over Speed
Jamf’s growth story is instructive here. The company started by solving a real problem: Apple device management in enterprise environments. They didn’t guess at what enterprises needed. They talked to IT directors, systems administrators, and security teams—over and over. That deep customer understanding informed every feature, every product decision, and ultimately every scaling decision.
When Jamf went public in 2020, they had a clear, defensible market position because they’d spent years understanding their segment. They weren’t trying to be everything to everyone. They were exceptionally good at one thing for a specific customer.
This is very different from the move-fast-and-iterate mentality. In Minnesota, we tend to ask more questions before we build. We run pilots with actual customers before we invest in scaling infrastructure. We watch how people actually use our products, not just how we think they should use them.
At Veeam, I’ve seen this play out constantly. Before we scale a feature to our entire user base, we test with real backup administrators in real data centers. We don’t assume we understand their workflows—we go watch them work. That takes time, but it prevents us from scaling the wrong solution.
Practical Steps for Customer-Centric Scaling
- Conduct customer research before scaling: Talk to 20-30 customers using your product at their actual scale. What’s breaking? What’s working? What’s missing?
- Segment your customer base: Different customers have different scaling challenges. Jamf understands that a 500-person company’s device management needs differ from a 50,000-person enterprise’s needs.
- Create customer advisory boards: SPS Commerce does this exceptionally well. They bring together customers across different segments and industries to discuss product direction. It’s not focus groups—it’s deep partnership.
- Build feedback loops into your scaling roadmap: When you decide to scale a feature or service, plan how you’ll get feedback during the scaling process, not after.
Lesson 2: Infrastructure Isn’t Glamorous, But It Matters
The Reality of Scaling Beyond Your Current Database
Let me be direct: scaling is often not about adding flashy new features. It’s about making sure your systems don’t fall over when you have 10x more customers.
Digi International, a Minnesota-based company specializing in embedded systems and IoT connectivity, has grown internationally while maintaining extreme reliability requirements. Their customers include mission-critical infrastructure operators. You don’t get there by ignoring infrastructure.
When I talk to product managers at other Minnesota companies, I hear the same theme: infrastructure decisions made early matter enormously later. C.H. Robinson, one of the largest logistics software companies in the world, built their systems to handle tens of thousands of concurrent users—not because they needed to on day one, but because they knew that’s what the market would eventually demand.
This requires a specific mindset: you have to care about things that users never see. Database architecture. API response times. System monitoring. Disaster recovery. These aren’t product features. They’re the foundation everything else sits on.
I spent weeks recently working with our infrastructure team at Veeam to understand our scaling constraints. It’s not exciting work. But understanding where your systems actually break, and planning for it, is central to serving customers well as you grow.
The Infrastructure Scaling Checklist
- Map your critical paths: Which operations must complete in under 100ms? Which can take longer? Which are background processes? Build infrastructure that respects these requirements.
- Plan for data growth: How big will your database be in two years? Five years? What query patterns will break? Start solving these problems now, not when you’re down.
- Design for observability: You can’t fix what you can’t see. Build monitoring, alerting, and logging into your product from the start. This costs time upfront but saves months of debugging later.
- Build resilience into your design: Assume parts of your system will fail. Design so failures don’t cascade. Test those failures regularly.
- Document your limits: Know the maximum number of concurrent users your system can handle. Know the maximum data size. Know the maximum request rate. Share these limits with your team and with customers.
Lesson 3: Hire Slowly, Build Culture Early
Minnesota’s Approach to Team Scaling
I’ve noticed something consistent about Minnesota tech companies: they tend to grow their teams more deliberately than what you see in hyper-growth Valley startups. There’s less of a “hire 50 engineers in six months” mentality and more of a “hire the right 10 people” mentality.
This isn’t just financial conservatism (though it is that too). It’s a belief that team culture—how you work together, how you make decisions, how you treat customers—is easier to protect if you’re thoughtful about who joins.
Jamf scaled from dozens to thousands of employees, but they did it in waves. Each wave was intentional. There are stories in the company about when they brought on their first salespeople, their first customer success people, their first marketing people. These decisions weren’t made lightly.
I’ve experienced this at Veeam too. We’re a much larger company now, but you can still feel the original engineering-first culture. That doesn’t happen by accident—it happens because leaders made deliberate choices about hiring and culture as the company grew.
This has a direct impact on product management. When your team grows thoughtfully, you retain the ability to move fast and be flexible. When you hire quickly just to add headcount, you often end up with coordination problems that slow you down further.
Principles for Scaling Your Team
- Hire senior people into new areas: When you’re expanding into a new function (like customer success, or international sales), hire someone experienced who has done it before. They’ll scale that function much better than a junior person will.
- Document your decision-making culture: As you grow, write down how decisions actually get made. What requires consensus? What requires executive sign-off? What can individual teams decide? Make this explicit before you’re large enough that it becomes chaotic.
- Create onboarding that actually teaches the culture: New employees learn your values from what you do, not from what you say. Make sure your onboarding shows what you actually care about.
- Measure team health as carefully as you measure product metrics: Track retention. Track velocity. Track how long decisions take. If any of these deteriorate, slow hiring until you’ve fixed the underlying issue.
- Build cross-functional relationships early: Engineers, product, customer success, sales—these teams need to trust each other. Create opportunities for them to work together before you have 500 people and silos are already baked in.
Lesson 4: Scalability Isn’t Binary—Design for Levels
Understanding Different Scaling Phases
One mistake I see is treating scalability as a single problem: either your product scales or it doesn’t. But real scaling happens in phases, each with different constraints and priorities.
SPS Commerce, which provides supply chain management software, handles scaling across multiple dimensions simultaneously. They serve retailers, distributors, and suppliers—each with different volumes, different data requirements, and different performance needs. Their scaling strategy isn’t one-size-fits-all.
When I think about Veeam’s scaling challenges, I think about it phase by phase:
- Phase 1: One backup administrator, one data center, terabyte-scale data. The product needs to work reliably for this person.
- Phase 2: Multiple administrators at the same organization, petabyte-scale data, distributed data centers. The product needs to coordinate across administrators and data stores.
- Phase 3: Global enterprises, multiple geographical regions, hybrid and cloud environments, multi-tenant scenarios. Now we’re solving completely different problems.
Each phase requires different architectural thinking. Phase 1 is about reliability and correctness. Phase 2 is about consistency and coordination. Phase 3 is about isolation and performance under load.
If you design for Phase 1, Phase 3 is impossible. If you design for Phase 3 from the start, Phase 1 is bloated and you’ll never get to Phase 3 customers because the product is too complicated to use. You have to design deliberately for the phase you’re in while keeping an eye on what comes next.
Design Patterns for Phased Scaling
- Define your scaling tiers: What does a small customer look like? A medium customer? A large customer? What are the different constraints and problems each faces?
- Accept that early versions won’t scale to everything: Your first version of the product might only work for small customers. That’s okay. Accept it, design for it, and plan when you’ll move to the next tier.
- Build abstraction layers that let you swap implementations: A single-server database works great for Phase 1. A distributed database works for Phase 3. Don’t hardcode either—build an abstraction that lets you swap the implementation.
- Test at each tier: Create test suites that verify your product works for Phase 1 customers, Phase 2 customers, and Phase 3 customers. As you add new tiers, add new test suites.
- Communicate your tier to customers: Be explicit about what scale your product supports. Customers appreciate honesty. A customer who knows your product maxes out at 1 million records can plan accordingly. A customer who discovers this after buying is angry.
Lesson 5: Solve for Your Geography, Then Expand
Regional Dominance as a Scaling Strategy
Minnesota tech companies often start as regional businesses that expand nationally, then internationally. That’s different from companies that try to be global from day one.
There’s something valuable about this approach. You become extremely good at serving a specific region’s needs. You build deep relationships with customers in that region. You understand the local market deeply. Then you expand deliberately.
C.H. Robinson, headquartered in Eden Prairie, is a great example. They started as a regional freight broker serving the Upper Midwest. They got extremely good at logistics in this region. Then they expanded to the rest of North America. Then internationally. Each expansion was deliberate.
The product advantage of this approach is real. When you deeply understand your region’s needs, you can build products that are precisely tailored to solving that region’s problems. Those products often work surprisingly well in other regions too—but you’ve built them for something real, not for some imagined global market.
For companies like Digi International that need global presence, I see a similar principle: establish a strong base in one region first. Prove the business model. Understand the product deeply. Then expand with confidence rather than hope.
Geographic Scaling Strategy
- Define your initial geographic market: Where are your first 100 customers? Why are they there? What specific problems are you solving for them?
- Become the local expert: Understand local regulations, local business practices, local customer preferences. Build products that account for these factors.
- Build local partnerships: Find resellers, implementation partners, and advocates in your region. Their credibility will matter when you expand.
- Create case studies from your region: “We helped X company in Minnesota solve Y problem” is more credible than generic marketing. Use these stories when you expand.
- Plan for regional differences when you expand: When you move to a new geography, don’t assume your existing product is perfect for it. Talk to customers in the new region. You might need to adjust.
Lesson 6: Build Profitability Into Your Scaling Plan
The Minnesota Tech Mentality: Revenue Matters
Here’s something I’ve noticed about Minnesota companies: profitability isn’t a dirty word. It’s a feature.
This is probably tied to Minnesota’s historical reliance on established industries (retail, logistics, healthcare) where profitability was always expected. But I think it also reflects a deeper pragmatism: a business that isn’t profitable eventually fails, regardless of how many users it has.
I’m not saying Minnesota companies don’t take venture capital or that they’re opposed to spending money on growth. Jamf has taken massive venture funding. But even with that funding, there’s this underlying belief that the business needs to make financial sense.
This affects product decisions. When you’re building a scalable product, you have to think about the economics of serving each customer. What does it cost to support them? What’s your gross margin? Can you make money at their scale?
At Veeam, this is baked into how we think about scaling. We can’t just add customers infinitely—each additional customer has a cost. As we scale, we need to either improve our cost structure or improve our pricing. Ideally both.
This forces better product thinking. It pushes you to build elegant solutions that don’t require proportional infrastructure increases for each customer. It pushes you to automate support. It pushes you to build products that customers can largely self-serve.
Building Economics Into Your Scaling Plan
- Understand your unit economics: How much revenue does a customer generate? What’s the cost of acquiring that customer? What’s the cost of serving that customer? What’s your gross margin? If your unit economics don’t work at your planned scale, fix them now.
- Model how costs change with scale: As you get 10x more customers, what needs to scale? What stays roughly the same? If infrastructure costs scale proportionally with customers, you have a problem—improve automation or change your pricing model.
- Plan for efficiency improvements as part of scaling: Don’t just assume you’ll maintain the same cost structure at 10x scale. Plan which costs will improve through automation, better processes, or better tools.
- Build variable costs, not just fixed costs: Fixed costs are dangerous when you scale. Try to structure your business so costs scale roughly with revenue. This gives you flexibility.
- Price to support scaling: If scaling requires investment, make sure
