Product Development and AI Readiness: From Widgets to Intelligence

I was introducing the idea of information as a product feature to one of our business units – about $150M in total revenue, making a relatively small but critical component for high-performance systems operating in harsh environments. The engineering and product development teams were open to brainstorming, but this was new territory for them. They hadn’t given it serious thought until I showed up with a framework and some questions. Their core product had always been a physical thing – well-engineered, reliable, built to spec. The idea that data could become part of what they sell was interesting but abstract.

So I switched the conversation to revenue. “How much would something like this be worth?” The team knew their market cold, and they got into it fast. The play would be using sensor data to quantify product quality, guarantee performance, and reduce the customer’s maintenance time considerably. Predictive maintenance instead of preventative maintenance – knowing when a component actually needs service rather than replacing it on a schedule. Someone said, “we’ll definitely gain share, no problem.”

My opening. “So, how much share gain are we talking about?”

“Could double it.” Hmmm. “What’s the current market size?” $500M. “And our market share?” 10%. “And we could double it?” 20%. “And that’s annual?” Yes. “So if we solve this problem, we’re talking about an additional $50M per year in revenue?”

Silence. You could see the whites of their eyes get a wee bit bigger, as the math worked out the numbers. Their numbers. Their opportunity. And the conversation picked up a bit after that.

A few weeks later – reality check. Too many other priorities in a fast-growing business. Projects already in the strategic plan with a much clearer line of sight to success. Not a problem, not unusual. But the point had been made: the product team could see, in concrete terms, what information-enabled products might be worth. That’s the conversation that product development AI readiness starts with. Not “how do we use AI to design things faster?” but “how does AI change what we sell?”

From Widgets to Intelligence

The phrase I keep coming back to is “widgets to digits” – the shift from making and shipping physical stuff to providing and supporting data-enabled stuff. It’s been happening for years, starting with sensors and connected products, and AI is accelerating it dramatically.

For most of the history of manufacturing and industrial products, the value was in the physical thing. You engineered it, you built it, you shipped it. The product’s intelligence lived in the design – materials, tolerances, performance specifications. If a customer needed to know how the product was performing, they inspected it. If they needed to predict when it would fail, they followed a maintenance schedule based on averages and experience. The data, to the extent it existed, was an afterthought.

That equation has been flipping for a while now. Products generate data. Machines report their own status. Components with embedded sensors can tell you what’s happening in real time, and with enough historical data, they can predict what’s going to happen next. AI takes this further – products that don’t just report but adapt, that learn from usage patterns, that improve their own performance over time. The physical thing is still important, but the intelligence layer is increasingly where the value lives.

And that shift changes the economics of product development in ways that most product teams haven’t fully absorbed yet. When the value was entirely in the physical thing, the development cycle had a clear endpoint – you designed it, tested it, manufactured it, shipped it. Done. Revenue came from selling units. But when the intelligence layer becomes a significant part of the value, the product is never really done. The data it generates needs to be collected, analyzed, and fed back into the product’s behavior. The algorithms need to be updated as conditions change. The customer relationship shifts from transactional (buy the thing, use the thing) to ongoing (the thing keeps getting smarter, and that ongoing intelligence is worth paying for). For a product team that’s spent decades optimizing a design-build-ship cycle, this is a fundamental reorientation – not just of what they build, but of how they think about what “finished” means.

Here’s why this matters for AI readiness: product development is the only team in your organization that can lead this conversation. IT can build the infrastructure. Operations can deploy the sensors. Data science can build the models. But none of them can answer the fundamental question: what should AI do for our customers? That requires understanding the product, the market, the customer’s workflow, and where information creates value that the customer will actually pay for. The product team lives in that intersection. Nobody else does.

And the phrase I heard in almost every conversation – “we’re a [thing] company, not a software company” – isn’t resistance. It’s a refreshing signal of self-knowledge, and an opportunity to start a strategic conversation about how the definition of “thing” is changing.

Design Thinking Meets AI

Product development teams have spent decades getting good at something that AI desperately needs: design thinking. Not design thinking as a buzzword – the actual discipline of understanding how people interact with complex systems and making those interactions intuitive, useful, and elegant.

Consider how many legacy internal systems and processes are blessed with legendary difficulty. People love to complain about how tough it is to enter customer data, transact orders, or ship product. And it’s not limited to technology – even the smallest companies come up with strangely archaic processes that are insensitive to the user. Now layer AI on top of that. If the underlying process is confusing, adding AI doesn’t simplify it – it adds another layer of mystery. The recommendation appears, and nobody trusts it because nobody understands where it came from or how it connects to the process they’re already struggling with.

Product development knows how to fix this. They know how to take a complex capability and make it accessible – not by dumbing it down, but by designing the interaction so that the complexity serves the user rather than overwhelming them. That’s what good product design has always been: making powerful things usable.

There’s a parallel here with information design. We’ve all labored through illegible spreadsheets printed in the tiniest font because someone insisted the report should fit on a single page. We’ve all sat through presentations with nothing but bullet points and poorly justified text, showing ideas that could have been communicated with a single picture. Visualizing the insights trapped in data is genuinely difficult – and your product development team, the people who spend their careers communicating complexity through design, can lead the way on making AI outputs understandable and actionable.

This applies both to customer-facing AI features (how does the customer interact with the intelligence in your product?) and to internal AI tools (how do your own people interact with AI-powered workflows?). Think about the last time someone on your team tried to use an AI-generated demand forecast. The model produced a number. Maybe it came with a confidence interval, maybe not. There was no context about which inputs drove the prediction, which historical patterns it weighted most heavily, or what would have to change for the forecast to be materially different. The planner looked at it, shrugged, and went back to the spreadsheet – not because the model was wrong, but because the experience of using it gave them nothing to work with. A product designer would approach this completely differently. They’d start with the planner’s actual decision process – what do they look at first, what makes them trust or distrust a number, what contextual information do they need to act? Then they’d design the AI output to fit that workflow, not replace it. The forecast might show up alongside the planner’s own historical estimates, with the key drivers highlighted and the areas of disagreement flagged for human review. Same model, same math – but now the experience is designed for the person using it. That’s the difference between AI that gets used and AI that gets ignored, and your product development team is the one that knows how to close that gap.

Be Your Own First Customer

Here’s an idea that came out of conversations between R&D and operations teams, and it’s one of the more practical contributions product development can make to AI readiness: use your own organization as the first beta customer for AI-enabled product ideas.

Your operations team has been experimenting with sensors and smart devices for years – monitoring machines, tracking material handling, optimizing warehouse flows. Meanwhile, your product development team is exploring how to embed those same kinds of capabilities into the products you sell. So why not bring these two groups together and try out the information-enabled ideas internally first?

The logic is straightforward. Your own operations are a controlled environment where you understand the processes, you have access to the data, and you can iterate quickly. When a predictive maintenance model doesn’t work the way the product team expected, you learn from it and adjust – and the learning event impacts internal operations, not an external customer’s production line. Engineers get hands-on experience with the technology, which demystifies it and makes it digestible for the broader organization. And operations gets early access to capabilities that might genuinely improve how they work.

I had a conversation that brought this idea to life. An engineering team was trying to figure out how to put sensors into a component that operates in a brutally hostile environment – think extreme pressures, caustic materials, conditions that would destroy most electronics. The problem seemed unsolvable, until a patent attorney pulled out a filing that showed someone had already figured out half of it. A few weeks later, at a conference session on a completely different topic, engineers in the room were describing sensors that measured exactly the kind of environmental data we needed, in similar conditions. The solution wasn’t invented from scratch – it was assembled by connecting knowledge from adjacent spaces.

That’s what happens when product development treats AI innovation the way it treats any other engineering challenge – not as a technology problem to be solved in isolation, but as a design problem that draws on diverse knowledge sources. And testing those solutions internally before launching them externally is the kind of disciplined innovation that actually works.

The Revenue Question Nobody’s Asking

Most AI conversations in most organizations are about cost reduction. Efficiency. Automation. Doing more with less. That’s important, but it’s only half the story – and frankly, it’s the less interesting half.

Product development is the team that can flip the conversation from cost to revenue. What does AI make possible in your product line that wasn’t possible before? What would customers pay for if you could offer predictive capabilities, performance guarantees backed by data, usage-based maintenance recommendations? What subscription models open up when your product generates a continuous stream of useful information?

That $50M revenue opportunity I described in the opening – that came from a single business unit, a single product line, exploring a single use case. Multiply that across a diversified manufacturer with dozens of product lines, and the potential is enormous. But it requires a product team that can envision the opportunity, an engineering team that can prototype it, and a business plan template that accounts for how digital revenue actually works – different ramp patterns than physical products, different cost structures, different metrics for go/no-go decisions.

Those differences are real and they trip people up. Physical product revenue is familiar – you book orders, ship units, recognize revenue. The ramp follows a pattern every finance team understands: slow start as the sales force gets up to speed, acceleration as the market adopts, plateau as you saturate your addressable segments. Digital and data-enabled revenue doesn’t follow that curve. It often starts with a service or subscription component that ramps more slowly but compounds over time – small per-unit data fees that look underwhelming in year one but become a significant revenue stream by year three as the installed base grows and the data gets richer. The cost structure is different too: the marginal cost of delivering intelligence to an additional customer is nearly zero, which means margins improve as the base scales in ways that physical products never can. But the upfront investment in data infrastructure, model development, and integration is substantial and hard to tie to a specific revenue line on the P&L. Product teams that understand this can build business cases that survive the CFO’s scrutiny. Product teams that don’t will pitch exciting ideas that die in the budgeting process because they can’t explain why the return shows up in year three instead of quarter two.

This is where Product Development’s contribution to AI readiness connects back to Finance’s contribution from earlier in this series. Finance understands how to build business cases under uncertainty. Product Development understands what the customer would value. Together, they can build the case for AI-enabled products that neither could build alone. Without Product Development’s input, the business case is theoretical. Without Finance’s discipline, the product vision is a science project.

The organizations that treat AI purely as a cost-reduction tool will save money. The organizations that let product development lead the revenue conversation will create it.

Every other article in this series focuses on what a functional area contributes to how your organization uses AI internally. Product Development is different. This is the team that looks outward – at what AI means for what you sell, how you compete, and where your next revenue stream comes from. That’s not a secondary contribution to AI readiness. For many companies, it’s the one that matters most.

In the first article of this series, we argued that AI readiness is built from the contributions of every functional area. Finance speaks in facts. Sales and Marketing brings the customer voice. Product Development brings the vision – the ability to see AI not as a tool to optimize the present, but as a capability that redefines what you offer. Next up: Operations, and the discipline that keeps all of this grounded in reality.

If you’re exploring how product development and other functional areas contribute to AI readiness – or just want practical ideas for leading digital transformation – join our mailing list and we’ll keep the conversation going.

Related Articles

• From Concept to Market: How AI Can Accelerate Physical Product Innovation – Deloitte Insights on how AI is transforming the physical product development lifecycle, from ideation through manufacturing
• How Can Smart Connected Products Change the Way Manufacturers Operate? – EY’s exploration of how connected products create new revenue streams and cost efficiencies for industrial manufacturers
• Unlocking Gen AI in B2B Sales – McKinsey on how gen AI processes unstructured data to generate competitive intelligence and product insights

Recommended Books

• Don’t Think So Much by Jim MacLennan – A practical guide to digital transformation that connects operations, customers, products, data, and teams into a framework that works
• Competing in the Age of AI by Marco Iansiti and Karim R. Lakhani – Harvard Business School research on how AI transforms operating models and creates new competitive advantages through data-driven products and services
• The Design Thinking Playbook by Michael Lewrick, Patrick Link, and Larry Leifer – Practical frameworks for applying human-centered design to complex technology challenges, directly relevant to making AI usable