Scaling a Field-First Product Playbook

The Field-First Model: What Actually Worked

Let me start with what we got right, because it's easy to romanticize "being close to the customer" without understanding what that really means in practice.

Proximity Reveals the Real Problems

When you're on site every day, you stop hearing feature requests and start seeing systems. A customer doesn't just say "I need better reporting." You watch them manually consolidate data from four different sources, cross-reference it with a spreadsheet someone emailed yesterday, and then manually type everything into yet another system for compliance.

That's when you realize the problem isn't reporting. It's fragmentation.

We spent our first two weeks just watching. Not pitching, not demoing, just observing how work actually happened. Where did people get stuck? What workarounds had they invented? Which processes only existed because some system didn't talk to another?

The insights from those two weeks shaped the next three months of work. And none of it would have been visible from a conference room back at the office.

Speed Builds Trust Faster Than Perfection

Here's something nobody tells you about construction sites: they've seen a hundred vendors promise the world and deliver six months later with something that doesn't quite work the way they needed. So they're skeptical. Not hostile, just... experienced.

The only way to break through that skepticism is to show up with something they can actually use, and then make it better every single day based on their feedback.

We started with a simple observation tracking tool. Nothing fancy. But we deployed it in three days, and then we iterated on it daily. Sometimes twice a day. A site supervisor would mention something in the morning, we'd prototype a solution by lunch, and they'd be testing it before the end of their shift.

That velocity did something powerful: it proved we were listening. It showed we understood their world moved fast and our development cycle needed to match that pace. Within a month, they stopped treating us like outsiders who needed to be managed and started treating us like teammates who could be trusted with their real problems.

Customer Co-Creation Changes Everything

The breakthrough came when we stopped thinking about "users" and started thinking about partners.

One site engineer became our de facto product advisor. Not because we hired him, but because we gave him a reason to care. Every problem he brought us, we solved. Every idea he had, we prototyped. Every time he said "I wish this could do X," we made X happen within days.

He started coming to us proactively. Not with complaints, but with opportunities. "Hey, we just had an incident that exposed a gap in our process. Can we build something for this?"

That relationship changed how we worked. We weren't extracting requirements anymore. We were collaborating on solutions. He knew the domain intimately. We knew how to build quickly. Together, we could solve problems neither of us could crack alone.

And when you have someone inside the organization who genuinely believes in what you're building because they helped build it, adoption becomes inevitable. They become your champion, your translator, your distribution channel.

Scaling the Model: Making Field-First Repeatable

The question wasn't whether the field-first approach worked. It obviously did. The question was: how do you scale something that depends so heavily on proximity, speed, and customization?

We realized we needed three things.

1. Embed the Right People in the Right Roles

You can't have your entire product team living on construction sites. But you can't build great construction technology from an office either. So we created a model with three distinct roles:

The field expert lives on site. Not 100% of the time, but enough to maintain real relationships and spot real problems. They're the first point of contact for any customer need, and they're experts in how construction actually works. They can triage requests, provide immediate domain guidance, and identify when something is a quick fix versus a new opportunity.

The delivery lead owns the customer relationship and the technical solution. They spend up to 25% of their time on site—enough to stay connected, not so much that they can't focus on building. They make autonomous decisions about what to build and how to prioritize, with the field expert as their domain guide.

The opportunity hunter isn't embedded at all. They're out discovering new problems across multiple sites, validating opportunities, and—critically—stepping back once they hand something off to a delivery team. They're not gatekeepers; they're scouts. They find the next hill to climb and then get out of the way while others climb it.

This structure lets us maintain proximity where it matters (field experts embedded with customers) while keeping the delivery team focused on building.

2. Build Platform Primitives, Not Just Products

Here's what we learned from our integration success: the power wasn't in any single tool. It was in how easily they could connect to each other.

So instead of just building more tools faster, we started investing in the underlying platform capabilities that would make rapid, integrated development possible:

Custom objects you can create without engineering help. Workflows you can configure instead of code. Reports you can build by dragging and dropping. Integrations that happen automatically when you use the same underlying data model.

The goal is to reach a point where a field team can prototype a new solution directly on the platform, using existing building blocks, without waiting for the core engineering team to build something from scratch.

Think of it like this: in our early field success, a product manager used no-code tools to move quickly. But no-code tools create isolated solutions. What if the platform itself had those same rapid-development capabilities built in? What if anyone on the team could compose new solutions from platform primitives?

That's the unlock. Not everyone becoming a coder, but the platform becoming composable.

3. Harvest Patterns, Don't Force Them

This might be the most important lesson: don't try to generalize too early.

In our rush to scale, we could have tried to predict what all construction sites need and built a one-size-fits-all solution. That would have been faster in the short term and completely wrong.

Instead, we committed to building custom solutions for individual customers first, then looking for patterns only after we'd done it three or four times.

The first time you solve a problem, you're learning. The second time, you're validating. By the third time, you start to see what's universal and what's context-specific. That's when you can extract reusable components, create templates, and build platform capabilities that make the fourth implementation dramatically faster than the first.

But you have to earn that knowledge through delivery. You can't shortcut it with upfront analysis.

The Anti-Patterns: What Not to Scale

It's just as important to be clear about what we're deliberately not replicating.

Don't scale hero culture. Our early success came partly from one person working at an unsustainable pace, making decisions in real time, shipping multiple releases a day. That's not a model; that's burnout waiting to happen. The scaled version needs structure, process, and shared responsibility.

Don't scale the shortcuts. We used no-code tools to move fast. We deferred technical debt to ship sooner. We built outside our main platform because it was expedient. All of those shortcuts were the right call in that moment, but they're not things to replicate. Learn from them, then build the proper foundation.

Don't scale committee decision-making. The field team needs autonomy. The person closest to the problem should make the call. Scaling doesn't mean adding approval layers; it means giving more teams the authority to move quickly.

Don't scale before you solve. The temptation is always to think about reusability, scalability, and generalization from day one. Resist it. Build a great solution for one customer first. Make it work in production. Drive real adoption. Then figure out how to do it again.

What This Looks Like in Practice

So what does the scaled model actually look like day to day?

A customer request comes in. The field expert triages it. If it's a straightforward enhancement to an existing solution, they work with the delivery lead to knock it out in the next sprint. No approvals needed, no committee meetings, just autonomous execution by the people who understand both the problem and the solution.

If it's something bigger—a new opportunity or a significant expansion of scope—the field expert loops in the opportunity hunter to validate whether it's worth a formal investment. If it is, they get a commitment from the customer (usually in the form of a letter of intent), and then hand it back to a delivery team to build.

The delivery team works directly with the field expert to gather requirements. They don't wait for the opportunity hunter to write specs or create wireframes. They get just enough context to start building, and then they iterate based on real feedback from real users.

Throughout this process, the opportunity hunter stays informed but doesn't block progress. They're consulted on strategic decisions, but they're not gatekeeping every feature request or prioritization call.

And here's the key: this happens independently across multiple delivery teams. Each one is empowered to move fast for their customer. There's no central bottleneck, no shared roadmap that everyone has to align to, no monthly release train they're waiting for.

Speed comes from autonomy, not from moving faster through the same gates everyone else is stuck behind.

Measuring What Matters

You need different metrics when you're scaling this kind of model.

Obviously you track the usual stuff: time to production, customer satisfaction, adoption rates, revenue growth. Those matter.

But you also need to measure the things that made the original model work:

How quickly are you going from problem identification to validation? (We're targeting under two weeks.) How long from validation to production deployment? (Target: under eight weeks for a new opportunity.) How many releases are you shipping per sprint? (Continuous deployment is the goal, not quarterly releases.)

And critically: are you building for compounding value? How many integration points does each new solution create? Are you building more standalone tools, or are you building platform capabilities that make everything more valuable?

The Jafurah project went from 2 cameras and 300 connected workers to 25 cameras, 3,000 workers, and 6 integrated tools in three months. That's the benchmark. Not because every project needs to move that fast, but because it proves what's possible when you combine proximity, speed, and integration.

The Cultural Shift

None of this works if you're still operating with a traditional product development mindset.

You have to genuinely believe that the person on the site knows more about the problem than you do. That means giving up control. It means trusting field teams to make decisions you might not agree with. It means accepting that solutions will vary from customer to customer, at least initially, and that's okay.

You have to value speed over perfection. That doesn't mean shipping broken things; it means shipping working things and making them better every day based on real usage. It means being comfortable with iteration as the primary development mode.

And you have to resist the urge to generalize prematurely. Every time you catch yourself thinking "how will this scale to all customers," stop and ask: "does it work completely for this customer first?"

Solve one problem brilliantly before you try to solve ten problems adequately.

What We're Building Toward

The vision is this: a platform where any team can move with the speed and proximity that made our field-first approach successful, but with the leverage and integration that comes from building on shared primitives.

Where field experts can prototype solutions directly, without waiting for engineering sprints. Where delivery teams can compose new capabilities from reusable building blocks instead of starting from scratch each time. Where every new solution automatically inherits the integrations and intelligence of the platform it's built on.

We're not there yet. But we know it's possible because we've seen what happens when you get proximity, speed, and integration right. We've watched customers go from skeptical to dependent. We've seen solutions become so embedded in daily operations that the site couldn't function without them.

Now we're figuring out how to make that kind of impact repeatable. Not by standardizing the solutions, but by standardizing the approach. Not by building the same thing for everyone, but by giving every team the tools to build the right thing for their customer.

The field taught us what works. Now we're building the platform that lets everyone work that way.

If you're building for construction, or any industry where the real problems only become visible when you're embedded with your customer, I'd love to hear how you're thinking about this balance between customization and scale. The answer probably isn't the same for everyone, but I'm convinced the questions are universal.