In 2019, a Fortune 100 retailer spent $340M building a ‘smart warehouse’ that reduced efficiency by 18%. The problem wasn’t the technology - it was that digital product leaders designed it without understanding physical operations, and operations leaders implemented it without understanding digital product principles. I’ve seen this movie 47 times.

Section 1: Defining Phygital Beyond the Buzzword

The Phygital Product Definition:

A system where:

1. Physical assets generate value through digital intelligence

2. Digital systems require physical execution to deliver outcomes

3. The value loop CANNOT be completed in either domain alone

4. Customer experience spans both domains seamlessly & is often multi-modal

Critical Distinction Framework:

• NOT phygital: Mobile app for a restaurant (digital layer on physical service)

• NOT phygital: Manufacturing equipment with monitoring sensors (instrumentation)

• IS phygital: Autonomous vehicle fleet (physical execution + digital orchestration + continuous feedback)

• IS phygital: Smart building systems (physical environment responds to digital optimization in real-time)

• IS phygital: Smart Robotic Fulfilment Centers (robotic pick systems integrated with digital ordering systems).

The Three Types of Phygital Products:

1. Instrumented Physical - Assets with sensors feeding optimization systems (predictive maintenance, fleet management)

2. Digitally-Actuated Physical - Systems where software controls physical outcomes (robotics, automated facilities, smart manufacturing)

3. Experience-Bridging - Seamless customer journeys across atoms and bits (omnichannel retail, telehealth, hybrid work platforms)

Section 2: The Three Fatal Mistakes

Fatal Mistake #1: The “Sensors + Dashboard” Trap

• Most teams stop at data collection and visualization

• Real phygital products create closed-loop control systems

• The value is in automated action, not insights

• Framework: The Phygital Value Ladder

  • Level 1: Monitoring (commodity, ~$2-5/asset/month value creation)

  • Level 2: Diagnostics (baseline, ~$10-20/asset/month value creation)

  • Level 3: Prediction (differentiator, ~$30-50/asset/month value creation)

  • Level 4: Prescription (premium, ~$75-150/asset/month value creation)

  • Level 5: Automation (market leader, ~$200-500/asset/month value creation)

Fatal Mistake #2: The Deployment Blindspot

• Digital PMs think installation = app store download

• Reality: Physical deployment requires field ops, installation QA, site-specific calibration

• Cost structures are different: SaaS margin 80-90% vs Phygital 40-60% at scale

• Framework: The Deployment Complexity Matrix

  • Environment variability (low/medium/high)

  • Installation complexity (plug-and-play/guided setup/custom integration)

  • Ongoing maintenance requirements (self-healing/scheduled/reactive)

  • Optimal business model varies by quadrant

Fatal Mistake #3: The “Hardware First” or “Software First” False Choice

• Hardware-led teams build over-engineered physical products with weak software

• Software-led teams build beautiful apps that can’t survive real-world physical constraints

• Framework: The Phygital Development Cycle

  • Must oscillate between physical and digital development

  • 3-sprint cycles: Physical prototype → Digital integration → Deployed testing → Iterate

  • Cannot waterfall hardware then layer software

  • Cannot build software then retrofit hardware

Section 3: Why Traditional Product Leaders Fail at Phygital

The Digital PM Failure Modes:

• Underestimate latency/connectivity constraints in physical environments

• Miss the “white glove service” economics of deployment

• Design for controlled environments, not for factories/warehouses/outdoors

• Think “version 1.0 then iterate” works (it doesn’t when hardware is involved)

The Operations Leader Failure Modes:

• Optimize for operational efficiency, miss platform/ecosystem opportunities

• Build point solutions, not scalable architectures

• Underinvest in software quality and developer experience

• Think “it just needs to work” is sufficient (it’s not for competitive moats)

The Winning Profile:

To succeed in this new era, Phygital Product Executives will require

1. Systems thinking across physical and digital domains

2. Unit economics fluency (physical COGS + digital hosting + field ops)

3. Supply chain + software development lifecycle integration

4. Team leadership across hardware engineers, software developers, field ops, data scientists

5. Customer empathy for both end-users AND operational implementers

Conclusion: Your Phygital Action Plan

For Digital Product Leaders:

1. Find a physical operations mentor inside your company - spend a week shadowing

2. Take ownership of one deployment/installation problem

3. Build fluency in hardware development cycles and supply chain

For Operations/Physical Product Leaders:

1. Take a software architecture course - understand APIs, cloud platforms, data pipelines

2. Partner with a strong software product leader on one initiative

3. Study platform business models and ecosystem thinking

For All Product Leaders:

• The next 5 years will separate “product leaders” from “phygital product leaders”

• Companies are creating dedicated phygital P&Ls and product organizations

• Compensation, scope, and career trajectory divergence is already happening

The Imperative: Master this now, or be managed by someone who did.

You’re six months into your PM role at a company undergoing a “digital transformation” and with “operational complexity.” Maybe it’s logistics, healthcare, financial services, government, or PropTech. You’ve shipped three features. Each one solved a real problem. Stakeholders are happy. Your sprint velocity looks great.

And yet... something feels off.

The same complaints keep surfacing in different forms. The integration work never ends. Every new feature requires touching five systems. Your “quick wins” are starting to feel like whack-a-mole.

Here’s the uncomfortable truth: you’re not solving problems—you’re treating symptoms.

I spent 20 years learning this lesson the hard way. I built countless point solutions. I celebrated the shipped features. And I watched organizations slowly drown in the complexity of their own “solutions.”

Eventually, I figured out a different approach. I call it the Complexity-to-Product Transformation Model (C2P) ©. It’s not another framework to hang on your wall. It’s a systematic way to see the hidden patterns in operational chaos—and turn them into your biggest competitive advantage. So, if you are a Product Manager or a Digital Transformation Leader or whatever designation attached to you but tasked with transforming the organization from its operational chaos, this is an end-to-end framework for you.

The Point Solution Trap

Before we get into the model, let’s talk about why smart PMs keep falling into the same trap.

In operationally complex organizations, there’s always a backlog full of urgent problems. Stakeholders have real pain. The pressure to ship is intense. So you do what good PMs do: you prioritize, you build, you deliver.

The problem? Each solution creates its own gravity. It needs maintenance. It needs integration. It needs documentation, training, and support. And because it solved that specific problem for that specific team, it didn’t help the three other teams with similar-but-not-identical problems.

Fast forward two years. You’ve got 47 point solutions. Seven of them overlap. Four are abandoned. The integration layer looks like spaghetti. And the original problems? Still there—they just wear different masks now.

I call this “solution sprawl,” and it’s the silent killer of digital transformation.

The Insight That Changed Everything

The breakthrough came when I stopped looking at problems and started looking at patterns.

At Amazon in our custom & collectibles product marketplace, we had 47 documented pains across seller onboarding, catalog management, and marketplace operations. Forty-seven. That’s a lot of backlog items.

But when we traced each pain to its root cause—really traced it, not just one level deep—we discovered something remarkable: 31 of those 47 pains (66%) shared a single root cause. No unified catalog architecture across marketplaces for easy listing of custom products.

We weren’t looking at 47 problems. We were looking at one problem wearing 31 different costumes.

This is the core insight of the C2P Model:

Pains that cluster share root causes.

Address the root cause, and you solve the cluster.

This isn’t just efficient—it’s transformational. Because once you solve for root causes, you’re not building point solutions anymore. You’re building capabilities. And capabilities compound.

The Four Phases of C2P Model

The Complexity-to-Platform Transformation Model has four phases. Each builds on the last. Skip one, and the whole thing falls apart.

Phase 1: DECOMPOSE — Map the Chaos

Before you can find patterns, you need data. Lots of it.

Most PMs stop at 10-15 pain points. That’s not enough. In complex organizations, you need 50-200 documented pains to see the real patterns emerge. This feels excessive until you realize you’re not building a backlog—you’re building a diagnostic dataset.

How to do it: Interview everyone - folks running shadow operations, shadow IT teams developing their own solutions. Read every support ticket. Attend cross-functional meetings. Listen for the signal phrases & classify them into one of the four buckets.

Pro tip: Don’t filter or prioritize yet. That’s the trap. Capture everything. The patterns won’t emerge until you have enough data points.

Phase 2: CORRELATE — Find the Clusters

This is where the magic happens. Take your pain inventory and start asking “why” for each one. Not once—five times. The “5 Whys” technique sounds simple, but it’s brutally effective at exposing root causes hiding behind symptoms.

Example:

• Pain: “Sellers complain about inconsistent product listings across marketplaces”

• Why? Different teams manage different marketplaces

• Why? Each marketplace has its own catalog system

• Why? We built marketplace-specific solutions over time

• Why? No unified catalog architecture exists

• Root cause: Missing unified product identity layer

Now do this for every high-impact pain. You’ll start seeing clusters form—multiple pains tracing back to the same root cause.

Score each cluster using this formula:

C2P Score = (Pain Density × 0.3) + (Impact Magnitude × 0.5) + (Solvability × 0.2)

The highest-scoring clusters are your platform candidates. These are the root causes worth building capabilities around.

Phase 3: ARCHITECT — Design Capabilities, Not Features

Here’s where most product-led transformations go wrong: they jump straight from problems to products.

The C2P Model inserts a crucial layer in between: platform capabilities.

A capability is a reusable service that addresses a root cause. A product is a user-facing solution that consumes capabilities to solve specific pains.

This distinction matters enormously:

• Capabilities are stable, reusable, and consumed through APIs

• Products are focused, user-facing, and rapidly evolving

When you mix these concerns—when a platform tries to solve problems directly—it becomes bloated. When a product tries to be a platform, it becomes unfocused.

The Separation Test: Before calling something a “platform capability,” ask these five questions:

1. Could 2+ products consume this independently?

2. Is it stable (changes less than annually)?

3. Can you define a clear API contract?

4. Would it reduce, not add, overall complexity?

5. Does single-team ownership clarity exist?

5/5 = Strong platform capability. ≤3/5 = Probably a product feature. Don’t force it.

Phase 4: ACTIVATE — Ship Products, Not Platforms

Here’s the counterintuitive part: you don’t ship platforms. You ship products.

Platforms are invisible infrastructure. Products are what users see, touch, and love (or hate). Your job in Phase 4 is to build focused products that consume platform capabilities to solve specific pain clusters.

Before building any feature, run it through the Bloat Detector:

1. Does this address a documented pain from our inventory?

2. Does it consume (not duplicate) an existing capability?

3. Can we deliver this without new integration points?

4. Will this remain relevant in 2 years?

5. Does one persona clearly own this?

6. Can we measure success with existing metrics?

6 Yes = Build it. 4-5 = Proceed with caution. ≤3 = Stop. You’re about to create bloat.

Four Traps to Avoid

I’ve also seen the C2P approach fail. Usually, it’s one of these:

1. Platform Theater

Calling something a “platform” without building true capabilities. Usually a monolith with an API bolted on. If one team owns everything, it’s not a platform.

2. Boiling the Ocean

Trying to platform everything at once. If your roadmap extends beyond 18 months before first value, you’re boiling the ocean. Start with the highest-scoring cluster. Ship a product. Learn. Expand.

3. The God Product

One product that tries to solve every pain. Feature count grows faster than adoption. Onboarding takes weeks. Focused products beat feature-stuffed monsters every time.

4. Platform Island

A platform that requires “rip and replace” instead of incremental adoption. Change management becomes impossible. Great platforms coexist with legacy systems—they don’t demand wholesale replacement.

How to Start Tomorrow

You don’t need executive buy-in to start. You don’t need a transformation budget. You just need to change how you look at problems.

Week 1: Start your pain inventory. Create a spreadsheet. Every time you hear a complaint, see a workaround, or notice friction—write it down. Aim for 50 pains minimum.

Week 2-3: Run the 5 Whys. Take your top 20 pains by severity. Trace each to its root cause. Look for clusters.

Week 4: Map your first cluster. Pick the cluster with the highest correlation score. Document which pains it contains, what the root cause is, and what a capability addressing it might look like.

Then: Make the case. Show leadership you’ve traced 15 backlog items to one root cause. Propose building a capability instead of 15 features. The math speaks for itself.

The Bigger Picture

Here’s what I’ve learned after two decades of this work:

Operational complexity isn’t a bug—it’s a feature. It’s a moat. Your competitors have it too, and most of them are drowning in point solutions just like you were. The organizations that win aren’t the ones that eliminate complexity. They’re the ones that convert complexity into capability. They find the patterns others miss. They build platforms where others build features. They compound where others sprawl.

That’s the promise of product-led transformation in complex organizations. Not simplicity—leverage.

Stop solving the same problems over and over. Start building platforms that make those problems impossible.

That’s the C2P way.

I was wrong.

A decade at Amazon, I learned that this distinction is not just false; it’s actively harmful. The companies that win at scale don’t separate product from operations. They treat Operations AS Product.

This insight shaped everything I’ve done since. Here’s what I learned.

The Amazon Paradox

Amazon is famous for operational excellence. The fulfillment centers. The delivery network. The relentless efficiency.

But here’s what most people miss: Amazon’s operational excellence isn’t the result of better processes. It’s the result of better product thinking applied to operations.

Jeff Bezos didn’t build a logistics company that happened to have a website. He built a product company that realized the logistics network itself was the product.

This sounds like semantics. It’s not. The distinction changes everything about how you make decisions.

When you think of operations as “execution,” you optimize for efficiency. You ask: How do we do this faster and cheaper?

When you think of operations as product, you optimize for customer value. You ask: What experience are we actually delivering, and how do we make it better?

The second question leads to fundamentally different outcomes.

Principle 1: Customer Backwards, Not Capability Forward

At Amazon, we had a forcing mechanism called “Working Backwards.” Before building anything, you wrote the press release announcing it. Not the technical spec. Not the project plan. The press release.

This sounds like a writing exercise. It’s actually a thinking exercise.

When took over the Same-Day Delivery product, the team was focused on operational metrics: delivery density, route optimization, driver utilization, selection count. All important. All wrong as starting points.

The Working Backwards question was different: What does the customer actually want to feel when they choose Same-Day?

The answer wasn’t “delivery in 24 hours.” It was certainty. Customers wanted to know— with complete confidence — that their package would arrive when promised. The speed was secondary to the reliability.

This reframing changed our entire roadmap. Instead of optimizing for faster average delivery times, we optimized for tighter delivery windows and higher on-time rates. We hit 99.5% on-time performance across 13 countries.

The operational metrics improved too. But they improved because we were solving the right problem, not because we were solving the wrong problem more efficiently.

Principle 2: The Product IS the Process

Here’s a question that changed how I think about building: Where does your product end and your operations begin?

At Amazon, the answer is: there is no line.

When a seller lists a product on Amazon Marketplace, they’re using a product. When that listing goes through our catalog system, that’s also a product. When a customer searches for it, finds it, buys it, and receives it—every single touchpoint is a product decision.

During my time with the Marketplace team, we launched four new marketplaces generating $1B+ in annual revenue. The key insight wasn’t about market selection or pricing. It was about treating the seller onboarding process as a product.

Most marketplace companies treat seller onboarding as operations: paperwork, verification, compliance. A necessary evil before sellers can start selling.

We treated it as a product experience. We asked: What if onboarding was so good that sellers told other sellers about it?

We built a catalog platform that automated the painful parts of listing products. We created tools that let sellers see exactly where they were in the process and what they needed to do next. We designed the experience to feel like using a consumer app, not filing taxes.

The result: 15,000+ new SMB accounts from targeted outreach, while raising seller fees 4% (because sellers were willing to pay for a better experience).

The product was the process. The process was the product.

Principle 3: Measure What Customers Feel, Not What You Do

Amazon is obsessive about metrics. But the metrics that matter most aren’t operational metrics—they’re experience metrics.

Here’s an example. In logistics, everyone measures “on-time delivery rate.” It’s a standard operational metric. But at Amazon, we also measured something called “delivery quality score”—which included factors like package condition, whether the driver followed delivery instructions, and whether the customer had to contact support after delivery.

On-time delivery rate tells you what you did. Delivery quality score tells you what customers felt.

When I was scaling Same-Day Delivery, we found that our on-time rate and delivery quality score sometimes moved in opposite directions. We could hit our on-time targets by rushing drivers, but rushing drivers led to packages left in the rain, missed delivery instructions, and more customer contacts.

The operational metric said we were winning. The experience metric said we were losing.

We restructured incentives around the experience metric. On-time performance improved to 99.5%, and we increased Prime customer lifetime value by 7%. Not despite optimizing for experience, but because of it.

Beyond Amazon: Applying Product-Led Operations

When I left Amazon to lead product at JLL, I brought these principles with me.

JLL provides software for commercial real estate—building management, facilities operations, space planning. The industry traditionally thinks of this as “enterprise software,” which means long implementations, complex workflows, and training manuals nobody reads.

I asked the Amazon question: What if we treated the building operations workflow as a product experience?

We launched an IoT analytics platform that automated facility decision-making. But the real innovation wasn’t the analytics—it was treating the facility manager’s daily routine as a product to be designed.

Instead of dashboards full of data, we built a system that told facility managers: “Here’s the one thing you should do right now, and here’s why.” The product was the process of running a building.

Customer acquisition increased 40%. Operating costs dropped 20%. Not because we had better analytics, but because we had better product thinking about how analytics should fit into someone’s workday.

The Framework: Three Questions for Product-Led Operations

If you want to apply product-led operations thinking in your organization, start with three questions:

1. What does the customer actually want to feel? Not what feature they requested. Not what your capability allows. What emotional outcome are they seeking?

2. Where does your product end? Map every touchpoint from first awareness to long-term retention. If there’s a handoff to “operations,” that’s a product opportunity you’re missing.

3. What would you measure if you could only measure one thing? Find the metric that best captures customer experience, even if it’s harder to track than operational metrics. Then optimize ruthlessly for that.

Why This Matters Now

We’re entering an era where AI will automate most operational tasks. Route optimization, inventory management, demand forecasting—all of this will become commodity capability.

What won’t become commodity is the ability to design experiences that customers love. The ability to see operations not as execution, but as product. The ability to ask “what should customers feel?” before asking “how do we do this efficiently?”

Amazon taught me that the companies that win aren’t the ones with the best operations. They’re the ones that realize operations and product are the same thing.

That’s the lesson. That’s the advantage. And it’s available to anyone willing to think differently about what they’re actually building.

What’s one operational process in your company that could be reimagined as a product experience? I’d love to hear your examples in the comments.

I was unprepared for what I found.

The department served 2.5 million citizens across 72 different benefit programs. Each program had its own application process, its own eligibility rules, its own technology system. A family in crisis might need to apply separately for food assistance, healthcare, childcare subsidies, and housing support—filling out essentially the same information four different times, on four different systems, interacting with four different case workers.

The technology wasn’t the problem. Each system, individually, worked. The problem was that nobody had ever asked: What should this experience feel like for a citizen?

That question—the product question—changed everything.

The IT Mindset That Holds Government Back

Government technology organizations are, typically, IT organizations. This distinction matters more than it might seem.

IT organizations implement systems. They translate requirements into technology. They maintain infrastructure, ensure uptime, manage security. These are essential functions.

But IT organizations don’t own outcomes. They own inputs: systems delivered, tickets closed, uptime maintained. The outcomes—whether citizens actually receive the help they need, whether services are accessible and dignified—belong to someone else.

This creates a fundamental misalignment. When you’re measured on system delivery, you optimize for system delivery. You build what was specified, on schedule, within budget. Whether the specification was right in the first place is someone else’s problem.

The result is government technology that works perfectly—and serves citizens terribly.

I saw this pattern everywhere. Systems that met every technical requirement but required citizens to enter the same information seven times. Portals that passed every accessibility audit but were abandoned by 60% of users before completion. Applications that functioned exactly as designed but took 45 minutes to fill out.

The systems weren’t broken. The thinking was broken.

What Product Thinking Means in Government

Product thinking starts with a different question. Not “what system should we build?” but “what outcome are we trying to create?”

For government services, the outcome isn’t a system. It’s a citizen’s life getting better. A family receiving food assistance. A child getting healthcare. A senior accessing housing support.

When you start with outcomes, everything changes.

Instead of asking “how do we build an eligibility determination system?”, you ask “how do we help a family in crisis get all the help they qualify for, as quickly as possible, with as little friction as possible?”

The first question leads to a system. The second question leads to a service.

This might sound like semantics. It’s not. Watch what happens to decision-making when you shift from systems to services.

System question: Should we add a field for spouse income? Service question: Is there a way to get this information without making the citizen enter it?

System question: How do we ensure data accuracy? Service question: How do we reduce errors while respecting citizens’ time?

System question: How do we meet the requirement by the deadline? Service question: How do we measure whether citizens are actually being helped?

The system mindset optimizes for the organization. The service mindset optimizes for the citizen.

Case Study: Integrating 72 Benefit Systems

When I arrived, the state’s Health & Human Services Agencies operated 72 distinct benefit programs. Each had evolved independently over decades. Each had its own application, its own technology, its own rules.

A citizen applying for multiple benefits might interact with a dozen different systems. The experience was fragmented, frustrating, and often resulted in eligible citizens giving up before receiving help.

The IT approach would be: Modernize each system. Build APIs between them. Create a portal that accesses all 72.

We took a product approach instead: Design the experience a citizen should have, then figure out how to create it.

We started with citizen research. We shadowed families through the application process. We documented every form field, every handoff, every wait time. We mapped the emotional journey alongside the process journey.

The insight that emerged: Citizens didn’t care about programs. They cared about problems. They didn’t want “SNAP benefits”—they wanted to feed their children. They didn’t want “Medicaid”—they wanted their kids to see a doctor.

So we built a unified intake experience. One application. One set of questions. One case worker who could navigate across programs.

Behind the scenes, the 72 systems still existed. But the citizen-facing experience was unified. The system complexity was hidden. The product experience was simple.

The results: Processing time decreased 60% in pilots. Citizen satisfaction scores increased.

We didn’t modernize 72 systems. We built one product.

AI in Government: The Opportunity and the Risk

We were one of the first government organizations to deploy GenAI tools for case workers. The decision was controversial. Government AI deployments have been criticized for bias, opacity, and harm. Why take the risk?

The answer came from understanding what case workers actually do.

A case worker might handle 150 active cases. Each case involves reviewing documents, understanding complex eligibility rules, communicating with citizens, and documenting decisions. The cognitive load is enormous. The consequence of errors—families losing benefits they need—is severe.

When we observed case workers, we found that they spent 60% of their time on documentation and information retrieval, and only 40% on actual case work—understanding situations, making judgments, helping families.

GenAI could shift that ratio.

We deployed AI tools that could: summarize case histories, identify relevant eligibility rules, draft communication templates, and flag potential issues for review. The AI never made decisions. It made case workers more effective at making decisions.

The results: Case worker productivity increased. Average call wait times decreased. Case workers reported higher job satisfaction because they spent more time on meaningful work.

But we were vigilant about risks. Every AI output was reviewed by humans before action. We monitored for disparate impacts across demographic groups. We maintained explainability—case workers could see why the AI made every suggestion.

AI in government can be transformative. It can also be harmful. The difference is whether you’re using AI to replace human judgment or to enhance it.

A Framework for Government Product Leaders

If you’re leading technology in government, here are five shifts that enable product thinking:

1. From requirements to outcomes

Stop asking stakeholders what system they want. Start asking what outcomes they’re trying to achieve. Then work backwards to what technology might help.

Requirements capture what people think they need. Outcomes capture what actually matters.

2. From projects to products

Government technology is typically managed as projects: defined scope, defined timeline, defined completion. But citizen needs don’t end when a project ends.

Build permanent product teams that own citizen experiences over time. Give them authority to iterate, improve, and evolve based on feedback and data.

3. From procurement to partnership

Government procurement is designed to prevent corruption. It also prevents innovation. The rigidity that ensures fairness also ensures that what you buy is exactly what you specified—even when what you specified was wrong.

Where possible, build internal product capability. Where external vendors are necessary, structure relationships as partnerships with shared outcomes, not contracts with fixed deliverables.

4. From uptime to outcomes

IT is measured on system metrics: uptime, response time, tickets resolved. Product should be measured on outcome metrics: citizens served, time to resolution, satisfaction scores.

What you measure shapes what you build. Measure what matters to citizens.

5. From government-centric to citizen-centric design

Every government process was designed around government needs: what information do we need to make a decision? How do we ensure compliance? How do we audit?

Product thinking flips this: what experience should a citizen have? How do we make the process respectful of their time and dignity? How do we meet government needs without burdening citizens?

The Opportunity and the Obligation

Here’s what keeps me up at night: Government services are the last interaction with technology that hasn’t been transformed by product thinking.

Banking has been transformed. Retail has been transformed. Healthcare is being transformed. But applying for government benefits still feels like 1995.

This isn’t just an inconvenience. For citizens in crisis—families facing food insecurity, individuals dealing with health emergencies, children in need of care—government services are a lifeline. Every friction point, every abandoned application, every week of delay has real consequences for real people.

We have an obligation to bring the same product thinking that transformed every other industry to the services that matter most.

At WA state, we integrated 72 systems into one experience. We deployed AI that enhanced human judgment. We proved that government can deliver services that are not just functional, but genuinely good.

This is possible everywhere. The barrier isn’t technology. It isn’t budget. It isn’t even politics.

The barrier is how we think about the problem. Move from IT to product thinking, and everything changes.

I’ve seen the dashboard graveyard. As the Head of Product at JLL Technologies, I visited hundreds of buildings equipped with sophisticated sensors, energy management systems, and analytics platforms. In most of them, facility managers had reverted to the same routine they used before the technology arrived: walk the building, check the equipment, respond to complaints.

The technology wasn’t broken. It was irrelevant.

This is about to change. Not because sensors are getting cheaper (they are) or because buildings are getting more complex (they are). It’s changing because AI is finally capable of doing what dashboards never could: making decisions.

Here’s what I learned about building for this future—and why the next three years will determine who wins the $65B building automation market.

The Dashboard Graveyard

Let me describe a typical “smart building” in 2023.

The building has sensors everywhere: temperature sensors, occupancy sensors, air quality monitors, energy meters, equipment monitors. These sensors feed data into a building management system (BMS), which aggregates it into dashboards.

The dashboards are beautiful. Real-time energy consumption. Floor-by-floor occupancy heat maps. Equipment performance trends. A facility manager could spend hours exploring the data.

None of them do.

Here’s why: The data doesn’t tell them what to do. It tells them what’s happening—but translating “what’s happening” into “what I should do about it” requires expertise, time, and mental energy that facility managers don’t have.

A typical commercial building has 15-20 major systems: HVAC, lighting, elevators, security, fire safety, water, waste, and more. Each system has its own data. A facility manager responsible for a 500,000 square foot building might receive 1,000+ alerts per day across these systems.

No human can process this. So they don’t. They develop heuristics: check the important stuff in the morning, respond to complaints, handle emergencies. The dashboards become decoration.

When we surveyed facility managers at JLL, we found that the average “smart building” dashboard was accessed less than twice per week. The median time spent per session was under three minutes.

Millions of dollars in sensors. Minutes of attention.

The Insight That Changed Everything

The breakthrough came from a simple observation: Facility managers don’t want data. They want recommendations.

Not “your HVAC system in Zone 3 is running 15% above baseline.” That’s data.

They want: “Adjust the Zone 3 setpoint by 2 degrees. This will save $340/month with no impact on occupant comfort. Here’s why.”

The difference seems subtle. It’s not. The first requires the facility manager to interpret data, evaluate options, assess tradeoffs, and make a decision. The second requires them to say yes or no.

This is what AI enables. Not better dashboards—fewer dashboards. Not more data—more decisions.

At JLL, we rebuilt our IoT analytics platform around this principle. Instead of presenting data and hoping operators would act on it, we built an AI layer that analyzed the data and generated specific, actionable recommendations.

The results were dramatic. Customer acquisition increased 40%. Not because the underlying sensors were better—they were the same sensors competitors used. The difference was that our platform reduced cognitive load instead of adding to it.

Three AI Applications That Actually Matter

Based on my experience, three AI applications in smart buildings deliver genuine ROI. Everything else is either premature or overhyped.

1. Predictive Maintenance That Pays for Itself

Every building has equipment that’s going to fail. The traditional approach is reactive: wait for failure, then fix it. The “advanced” approach is preventive: replace equipment on a schedule regardless of condition.

Both are expensive. Reactive maintenance leads to emergency repairs, tenant complaints, and secondary damage. Preventive maintenance replaces equipment that still has useful life.

Predictive maintenance uses AI to analyze equipment behavior and predict failures before they happen. But here’s the key: the prediction alone isn’t valuable. The value is in the recommendation.

A useful predictive maintenance system doesn’t just say “this motor will fail in 30 days.” It says: “Schedule maintenance for this motor during the building’s low-occupancy window next Tuesday. Here’s the work order. The estimated savings vs. reactive repair is $4,200.”

That’s a decision, not data.

As we are building Synovai, we are implementing this at scale across our client’s managed portfolio. The buildings that adopted AI-driven predictive maintenance saw 25% reduction in emergency repairs and 15% reduction in overall maintenance costs.

2. Occupancy Optimization Beyond Simple Counting

Most occupancy sensors count people. How many are in the building? How many on each floor? This data feeds into dashboards that facilities teams never look at.

AI-enabled occupancy optimization does something different. It asks: Given current and predicted occupancy, how should the building behave?

If a floor is 20% occupied, should you condition the entire floor? Or can you dynamically adjust HVAC zones to serve only the occupied areas? If occupancy patterns predict heavy use of the east wing in the afternoon, should you pre-condition that space?

These decisions require real-time data, predictive modeling, and integration with building systems. A human can’t make them at the speed and granularity required. AI can.

We saw buildings reduce HVAC energy consumption by 18-22% through AI-driven dynamic zoning—without any reduction in occupant comfort. The savings paid for the technology in under 12 months.

3. Energy Management That Adapts

Energy management used to mean scheduling. Lights on at 7am, off at 8pm. HVAC starts an hour before occupancy.

AI-enabled energy management is adaptive. It responds to weather forecasts, utility rate changes, occupancy patterns, and equipment status in real-time.

Here’s a concrete example: Grid operators increasingly offer demand response programs that pay buildings to reduce consumption during peak periods. But capturing this value requires rapid response—sometimes within 15 minutes of a request.

An AI system can evaluate a demand response request, identify which loads can be curtailed with minimal occupant impact, execute the changes, and document the response for billing—all automatically. A facility manager would need hours to do the same analysis.

We saw buildings generate $50,000-$150,000 annually in demand response revenue that they’d previously been unable to capture, simply because the decision-making was too slow.

Why Most PropTech AI Fails

If AI is so valuable, why aren’t all buildings using it? Three reasons.

The Integration Problem

A typical commercial building has 50+ distinct systems, most of which were installed at different times by different vendors and don’t communicate with each other. The HVAC system doesn’t know what the occupancy sensors see. The lighting system doesn’t know what the energy meters measure.

AI needs data. Fragmented systems produce fragmented data. Before AI can deliver value, someone has to solve the integration problem—which is expensive, time-consuming, and often requires replacing legacy equipment.

At JLL, we spent significant resources on integration middleware. It’s not glamorous work, but without it, the AI layer has nothing to work with.

The Trust Problem

Facility managers have been burned by technology before. They’ve seen the dashboard graveyard. They’ve experienced systems that generated alerts but no value.

When AI starts making recommendations, their first reaction is skepticism. Why should I change my setpoint? How do I know this won’t cause problems?

Building trust requires explainability. Every recommendation needs to come with reasoning that a facility manager can understand and verify. “Adjust setpoint by 2 degrees because current outdoor conditions and predicted occupancy suggest comfort can be maintained at this level, based on similar conditions last month when no complaints were received.”

AI systems that deliver recommendations without explanations don’t get adopted. We learned this the hard way and redesigned our interface to lead with reasoning, not just results.

The ROI Problem

AI requires investment before it delivers returns. Sensors, integration, software, training—all cost money. The returns come later, in reduced energy consumption, lower maintenance costs, better tenant satisfaction.

CFOs want payback calculations. But building performance is noisy—influenced by weather, occupancy, tenant mix, and dozens of other variables. Isolating the impact of AI is genuinely difficult.

We developed measurement frameworks that tracked savings against weather-normalized baselines and comparable buildings. Proving ROI isn’t optional; it’s a prerequisite for scale.

The 2026-2029 Window

I believe the next three years represent a critical window for PropTech companies.

Three trends are converging:

First, AI capabilities have crossed a threshold. Large language models can now interpret building data and generate natural-language recommendations that facility managers actually understand. Computer vision can analyze building conditions from images and video. The technology is ready.

Second, sustainability mandates are creating urgency. The EU’s Energy Performance of Buildings Directive, New York’s Local Law 97, and similar regulations worldwide require buildings to dramatically reduce carbon emissions. Compliance requires technology that most buildings don’t have.

Third, post-pandemic uncertainty about office usage is forcing building owners to rethink their operations. Fixed schedules don’t work when occupancy is unpredictable. Dynamic, AI-driven building management is no longer a luxury; it’s a necessity.

The companies that capture this moment—by solving the integration problem, building operator trust, and demonstrating clear ROI—will define the smart building category for the next decade.

Those that don’t will join the dashboard graveyard.

I spent years building AI-driven products for commercial real estate. I’d love to hear from others in the PropTech space: What’s working? What isn’t? And what are facility managers actually willing to adopt?

Meanwhile, VC’s are chasing AI unicorns while countless $50M–$200M opportunities — the ones that create jobs and local prosperity — are, for the most part, ignored.

That’s why we built Foundry Innovations: a Public Benefit startup factory that turns students into founders and job seekers into job creators.

How Foundry works

Think: Incubator + Operator Guild + Seed Fund under one roof.

• Student venture teams (“Sparks”) form, validate ideas, ship MVPs, and win paying customers.

• Foundry centralizes non-core ops & tech so Sparks focus on product, sales, and customers.

• Our model is efficiency-first: tiny teams (~10) scaling durable, profitable companies toward $100M revenue with only ~$1M outside capital.

Proof it works Our first cohort with South Puget Sound Community College (#SPSCC) launched Sound Gen Financials in January, only six months after a group of ten students came together and met each other for the first time. They already have secured customers and pulled their first seed cheque.

So we decided to keep going! This year, four new Sparks are launching – each with their own ideas and a new batch of students.

Why this matters now

• Skills to work: Students graduate with revenue, leadership experience, and a portfolio — not just a résumé. AND a job!

• Access & equity: Brilliant talent exists everywhere. Opportunity doesn’t. We widen the on-ramp.

• Real jobs, real economy: Mid-market problems create steady jobs and resilient cash flows without financial sugar highs.

Join the movement

• Colleges & Universities → Bring practical entrepreneurship to your campus.

• Angels → Back Sparks solving overlooked $100M+ problems.

• Philanthropists & Grantmakers → Fund access, scholarships, and durable job creation.

• Mentors & Advisors → Guide students toward product-market fit and lighthouse customers.

If this resonates, connect with us. Comment “SPARK,” DM us, or share with someone who should be part of the journey.

Let’s graduate employers, not just employees — and prove disciplined, mission-driven companies can build wealth, dignity, and opportunity at scale.

Soumam Debgupta Omey Nandyal Samir Mehta Tom Willard, MBA

#Foundry #StudentFounders #FutureOfWork #WorkforceDevelopment #HigherEd #Entrepreneurship #EdTech #EconomicMobility #ImpactInvesting #AngelInvesting #MidMarket #ProfitableGrowth #JobCreation #OperatorLed #PublicBenefit

Physical assets globally generate 41 Gigaton of CO₂e emissions and 84 Zettabytes of data annually. Gartner estimates 68% of the asset data remains unused resulting in three key challenges:

1. Information loss every time there is asset transition, financial or operational

2. Information asymmetry between various stakeholders interacting with the asset

3. Opportunity cost of not optimizing asset value over its lifecycle

Over 10K companies directly or indirectly compete in this space, yet the problem is unsolved because:

1. The marginal cost & time to acquire and mine the asset’s dark data is high

2. They optimize either operational or financial or emission objectives individually, not in aggregate & simultaneously

3. Network effects are not considered & recommendations are moment-in-time v/s lifecycle based

The Opportunity

We estimate US companies are spending upwards of $35 billion annually to create visibility for this asset’s dark data but without clear RoI as a result of the following factors.

1. Fragmented Ecosystem: An average enterprise deploys an average of 130+ applications each targeting a specific aspect of the asset’s operational or financial performance.

2. With Connected Decisions: Users need to make decisions about an asset with data residing in multiple applications, that are interdependent but are not yet connected.

3. But Siloed Solutions: SaaS solutions are moment in time, most require structured data, don’t go across the asset lifecycle and optimize on one of the financial, operational or emission parameters.

4. Creating Linkage Burden: Enterprises build huge data teams or hire systems integrators to link, govern, centralize and visualize data for users to help decision making.

Current Solutions

There are four primary options for clients today that don’t scale and have their own limitations:

1. System Integrators to bring all the varied data sets together, but results in a custom solution with high ongoing maintenance costs

2. In-house data teams to build proprietary solutions for the enterprise that are very prescriptive and required long-term investment commitment from executives

3. SaaS point solutions focused on specific objectives and works great for that use case but don’t work well with other applications and optimize locally v/s achieving a global maxima

4. Building a fully functioning Digital Twin for each asset which takes time, has a hard ontology definition with high latency which prevents deployment in true critical environments

I am taking on the challenge of building an Agentic Asset Intelligence Platform that collects, organizes and acts all physical asset data securely to increase the life & value of the assets. My hunch is that the sweet spot on the marginal cost is <$15 cents per GB of dark data mined, where the ROI is higher than the cost.

Why is it the right time?

There is an increasingly growing share of connected & smart assets on a $430 trillion global physical assets balance sheet. By 2050 there will be over 100 billion IoT assets in the physical world generating over 230 exabytes of data everyday. I require four fundamental capabilities that have only coexisted recently.

• Inference time reasoning on multi-modal GPT models to consume & contextualize unstructured data

• A hands-free form factor that is extremely portable, and can run low latency AR applications with the combined power of computer vision

• True agentic systems that can do multi-step reasoning for complex asset optimization objective functions

• Immutable decentralized data ownership contracts that can help protect the data access based on individual users at scale

The cost of these technologies have dropped over 500% since launch with Moore’s scaling laws still applicable making them financially viable for a solution. Coupled with the growing size of the problem, makes this a perfect opportunity window.

Subscribe now

AI and Robotics: Not Job Takers, but Job Makers

The narrative of AI and robotics as job destroyers overlooks their potential as catalysts for new industries and novel occupations. As AI automates routine tasks ², human labor will shift towards roles demanding creativity, critical thinking, and complex problem-solving ³. This transition will be facilitated by personalized education and lifelong learning programs ³, empowering workers to adapt and thrive in a dynamic environment. AI is not simply automating existing tasks; it is also creating entirely new ones. The increasing need for machine learning engineers, data scientists, and AI ethicists exemplifies this trend ².

Moreover, AI and robotics will drive productivity gains, leading to economic growth and increased demand for labor in non-automated sectors ⁴. This echoes historical trends where technological advancements ultimately created more jobs than they displaced ⁴. In addition to boosting productivity, AI has the potential to improve workplace quality by reducing mundane tasks, improving access to the workplace for different types of workers, and helping to improve workplace health and safety ⁴.

Macroeconomic Trends: Navigating a Shifting Landscape

Macroeconomic forces, such as globalization and demographic shifts, will further shape labor participation in 2050. Declining birth rates in many developed countries ⁵ coupled with increasing life expectancy, influenced by advancements in healthcare and automation ³, will necessitate policy responses to maintain a vibrant workforce. These may include increased labor force participation among older workers ⁶, policies that support parents ⁵, and potentially, immigration. This will lead to a more diverse workforce, requiring inclusive policies and adaptable workplaces ⁷.

Furthermore, the rise of non-standard employment ⁶ and remote work ³ will necessitate new regulatory frameworks and social safety nets to ensure worker well-being and economic security. One potential solution is the "self-employed" designation proposed by Harris and Krueger, which offers a framework for regulating non-standard employment while protecting workers' rights ³. However, it is important to acknowledge the potential for increased economic inequality arising from these trends, as AI and automation may disproportionately impact low-skill and low-wage jobs ¹.

Space Exploration: Expanding the Frontiers of Labor

Space exploration, once a realm of science fiction, is rapidly becoming a reality with significant implications for labor in 2050. As space-based industries emerge, such as asteroid mining and space-based solar power ⁸, new opportunities for specialized labor will arise. These ventures will demand expertise in fields like robotics, engineering, and space logistics ⁹, creating a new generation of "space workers." Space exploration is not just about reaching new destinations; it is also about driving innovation and technological advancements with spillover effects on the broader economy ¹⁰.

Furthermore, space-based agriculture could initially support lunar mining colonies or factories but may quickly turn out novelty products for sale on Earth, such as space-grown coffee ⁸. This illustrates the diverse economic opportunities and potential labor demands associated with space exploration.

Societal Norms: Redefining the Value of Work

Evolving societal norms will redefine the very concept of "work" in 2050. With AI shouldering more of the burden of traditional labor, individuals will have greater freedom to pursue passions and engage in meaningful activities. This shift towards purpose-driven work will be accompanied by a growing emphasis on work-life balance and well-being ⁴. This trend aligns with a broader societal shift away from consumerism and towards a greater emphasis on purpose and personal fulfillment ¹¹.

Labor 2050: A Synthesis

By 2050, labor participation will be characterized by:

• Increased specialization: Workers will possess niche skills and expertise, particularly in STEM fields and emerging space-related industries.

• Lifelong learning: Continuous adaptation and upskilling will be essential for navigating a dynamic labor market.

• Technological collaboration: Humans and AI will work synergistically, leveraging each other's strengths.

• Purpose-driven work: Individuals will seek fulfillment and meaning in their labor, beyond traditional economic incentives.

• Greater flexibility: Non-standard employment and remote work will become increasingly prevalent.

This optimistic vision of labor in 2050 requires proactive policy interventions and societal adaptations. Investing in education, fostering innovation, and promoting inclusivity will be crucial for harnessing the transformative potential of these converging trends and ensuring a future where human labor not only survives, but thrives in collaboration with technology and expands into new frontiers.

Share your views about the future of labor by participating in this poll.

Works cited

1. Effects of Artificial Intelligence and Robotics on Human Labour: A Systematic Review | Legal Information Management | Cambridge Core, accessed February 25, 2025, https://www.cambridge.org/core/journals/legal-information-management/article/effects-of-artificial-intelligence-and-robotics-on-human-labour-a-systematic-review/7E13446EDCF143BD3048765A55BD90AA

2. The Labor Market Impact of Artificial Intelligence: Evidence from US Regions - IMF eLibrary, accessed February 25, 2025, https://www.elibrary.imf.org/downloadpdf/view/journals/001/2024/199/001.2024.issue-199-en.pdf

3. Future of work in 2050: thinking beyond the COVID-19 pandemic - PMC - PubMed Central, accessed February 25, 2025, https://pmc.ncbi.nlm.nih.gov/articles/PMC9736711/

4. The Impact of AI on the Labour Market - Tony Blair Institute, accessed February 25, 2025, https://institute.global/insights/economic-prosperity/the-impact-of-ai-on-the-labour-market

5. The Lancet: Dramatic declines in global fertility rates set to transform global population patterns by 2100, accessed February 25, 2025, https://www.healthdata.org/news-events/newsroom/news-releases/lancet-dramatic-declines-global-fertility-rates-set-transform

6. A new look at long-term labor force projections to 2050, accessed February 25, 2025, https://www.bls.gov/opub/mlr/2006/11/art3full.pdf

7. A century of change: the US labor force, 1950-2050 - ResearchGate, accessed February 25, 2025, https://www.researchgate.net/publication/298877868_A_century_of_change_the_US_labor_force_1950-2050

8. What Might Space Look Like in 2050? - RAND, accessed February 25, 2025, https://www.rand.org/pubs/articles/2023/what-might-space-look-like-in-2050.html

9. 2050 Vision for In-Space Transportation and Logistics, accessed February 25, 2025, https://ntrs.nasa.gov/api/citations/20230015702/downloads/Logistics_Dankanich_Final_NoVids.pdf

10. A US space strategy for 2050: shaping a domain on the cusp - Atlantic Council, accessed February 25, 2025, https://www.atlanticcouncil.org/wp-content/uploads/2021/11/056_Massa_USstrategy_sep21_DES.pdf

11. A New Look at Long-Term Labor Force Projections to 2050 - ResearchGate, accessed February 25, 2025, https://www.researchgate.net/publication/237244202_A_New_Look_at_Long-Term_Labor_Force_Projections_to_2050

Subscribe now