Propel Software: Building the Agentic PLM Platform That Thinks While You Work

Company Profile

Propel Software is a cloud-native PLM and product value management platform built natively on Salesforce. Founded in 2015 and led since 2022 by CEO Ross Meyercord, Propel targets midmarket and growth-stage manufacturers who need a PLM system that works with their commercial operations — not in a separate silo.

The company's leadership team brings a specific combination of pedigree: Meyercord spent years at Accenture implementing PLM systems for large manufacturers, then moved to Salesforce where he ran internal systems at scale. CTO Kishore Subramanian was at Agile Software when it was building the original web client, then spent nearly a decade at Google. Both bring lived experience with what breaks in enterprise software — and those lessons shaped what Propel set out to fix.

Propel's differentiation is structural: by living on Salesforce, it shares a data model with the CRM, quoting, and commercial operations systems that most manufacturers already run. When an engineer updates a product spec or initiates a change order, the sales team sees it. When a customer reports a quality issue through CRM, the engineering team can trace it directly to the affected BOM revision. That connection doesn't require a custom integration — it's native.

---

The Challenge: PLM as an Island

Traditional PLM implementations solve a documentation problem: they store the authoritative product record, manage revisions, and control change. What they don't do well is make that record visible to everyone who depends on it. Sales teams quote from stale specs. Quality teams document issues in systems disconnected from the engineering record. Supply chain teams discover design changes days or weeks after they affect procurement decisions.

Meyercord saw this pattern repeatedly during his years implementing PLM at Accenture. The problem wasn't that PLM systems were bad at managing product data. It was that they were optimized for engineering teams and hostile to everyone else. The data existed — it just didn't flow.

The second structural problem: legacy PLM implementation timelines. A major enterprise PLM deployment can run 18 to 36 months before a company gets to productive use. For a company with 50 to 200 engineers, that timeline is a dealbreaker. By the time the system is live, the product architecture it was configured for has evolved twice.

Propel's hypothesis: if you build PLM on top of Salesforce, you inherit a platform that non-engineering teams already use, already understand, and already trust. You collapse the integration problem. And you deploy in weeks, not years.

---

What Propel Built

The Unified Data Model

Propel's core architecture puts all product-related data — BOMs, revisions, change orders, quality records, supplier information — on the same Salesforce platform instance that stores customer accounts, sales opportunities, and service cases. This isn't an integration. It's a shared schema.

The practical effect: when a product manager in Propel initiates a change order, the account executive for the customers who bought that product can see it. When a quality nonconformance is reported by a customer through the service portal, the engineering team can pull the product record, the BOM revision in production at the time, and the change history — all without leaving the platform or opening a ticket with a different team.

Subramanian's framing, drawn from his Agile Software experience, is that every previous PLM generation made a wrong bet on the client layer. The Java client became the Windows client; the Windows client became the web client; the web client became the mobile-accessible cloud app. The pattern: the last architectural choice always seemed permanent until it wasn't. Propel's bet is that the platform layer — the Salesforce data model and workflow engine — is durable in a way that any particular client technology isn't.

Agentic AI on Top of Structured Data

By 2025, Propel was building the AI layer. Subramanian had watched AI development closely since his Google years, where Larry Page mandated that every developer take a machine learning course in the 2014–2015 timeframe. When ChatGPT launched, his read was clear: "The accessibility changed the game. Even Google was caught off guard."

Propel's approach to AI in PLM follows a layered model the company frames as a spectrum from advice to assist to automate:

• Advice: AI surfaces patterns, flags anomalies, and presents data the human needs to make a good decision. No system changes.
• Assist: AI proposes a specific action. The human approves before execution.
• Automate: AI executes a workflow end-to-end. Human oversight is structural (audit trail) rather than real-time.

The platform's change order workflow is the clearest example of AI value. Change orders have historically been the highest-overhead activity in PLM — every stakeholder from engineering to manufacturing to procurement needs to understand the change, assess its impact, and sign off. In legacy PLM, "understanding the change" means manual digging: comparing BOMs, reading change descriptions, correlating with similar past changes. A thorough review can take days.

In Propel's AI-augmented change order flow, the system pre-populates the review with: what changed (automatically compared to prior revision), who owns each affected component, whether similar changes have been made before and what was learned, and which customers or contracts reference the affected product. The reviewer doesn't start from a blank slate — they start from a brief. The goal is to make a thoughtful review take 15 minutes instead of a day, without pushing humans out of the loop.

Autonomous Data Management

Agentic systems — AI agents that can take actions, not just surface information — are the next layer. Propel is building toward agents that can autonomously manage specific PLM tasks: keeping supplier records current, flagging when a BOM component goes end-of-life before it becomes an engineering crisis, reconciling duplicate part numbers, and escalating quality issues that match patterns associated with field failures.

These are exactly the tasks that make PLM systems expensive to maintain: they require someone who understands the data well enough to know when something is wrong, but the work itself is pattern-matching, not judgment. AI handles that class of task well.

---

Results and Business Impact

Propel's customer outcomes reflect what happens when the PLM-to-commercial-data gap closes:

Faster change order cycles. When the pre-work for change order review is automated, teams that previously took 5–10 business days to close a major change are doing it in 2–3 days. The bottleneck shifts from information gathering to actual decision-making — which is where it should be.

Reduced integration costs. Customers running Propel on Salesforce report near-zero integration cost to connect PLM to their CRM, CPQ (configure-price-quote), and service platforms. That connection, typically a $200K–$400K integration project on legacy PLM, is included in the platform license.

Time-to-productivity. Propel customers are typically in production use within 4–12 weeks. Enterprise PLM implementations on the same scale run 12–36 months. For a 100-person hardware company in a competitive market, that 12-month head start matters.

Commercial visibility. Sales teams at Propel customers can see real-time product availability, revision status, and change history while working with customers. This eliminates a category of sales mistake that most manufacturers accept as unavoidable: quoting an obsolete configuration or promising a feature that engineering has already changed.

---

Lessons Learned

1. The platform bet matters more than the feature list. Propel's Salesforce foundation is not a shortcut. It is the architectural decision that makes everything else possible — shared data, no integrations, inherited enterprise security, and a user base that already knows the tool.

2. Build for the reviewer, not the recorder. Legacy PLM is optimized for the person entering data. Propel is optimized for the person making a decision based on that data. That shift in design orientation changes what the system surfaces and when.

3. The AI value is in pre-work, not replacement. Change order review, quality triage, supplier qualification — these are all activities where the majority of time is spent gathering context. AI handles context assembly better than humans. Humans handle judgment calls better than AI. Design the workflow accordingly.

4. Agentic doesn't mean unmonitored. Every Propel AI agent action is logged, auditable, and reversible. Manufacturers live in a regulated world where traceability is a compliance requirement, not a preference. The agentic layer earns trust by being transparent.

---

Implementation Advice

If you are a midmarket manufacturer — roughly 50 to 500 employees, cloud-native preference, already running Salesforce or seriously considering it — Propel's architecture is built for your situation. The unified data model pays off fastest when your sales, engineering, and quality teams are already supposed to be coordinating but aren't, because the data lives in three different systems.

If you are evaluating Propel against a legacy PLM platform, the right comparison is not feature count. It is total time to productive use plus total integration cost over three years. On those dimensions, Propel wins in almost every midmarket scenario.

If you are running a company larger than 1,000 engineers with highly complex BOM structures, variant management requirements, or deep CAD integration needs — evaluate carefully. Propel's strength is coordination and data unification, not deep CAD-native configuration management.

---

About the Source

This case study is drawn from AI Across the Product Lifecycle Episode 10, a podcast conversation with Ross Meyercord (CEO, Propel Software) and Kishore Subramanian (CTO, Propel Software). See also: [[Propel Software Spotlight]], [[Cloud PLM vs Enterprise PLM]], [[Change Order Management]], [[PLM Comparison Guide]].