You can't ship software like you ship a cell phone tower
This is the first post in a series on how specific industries can modernize the way they build digital products. Our first focus is why digital product development is critical to industrial manufacturing companies.
The playbook that built these companies
For a multi-year period our co-founder Jeff Gothelf was engaged with Jio Telecom out of India. During that engagement, Jeff worked with the teams at Jio to build modern product management, design and development skills. It’s not that these teams didn’t know how to build software. They did. It’s just that it was treated like an industrial manufacturing project which the organization knew well. Continuous, modern software development is a different animal.
Industrial manufacturers are very good at a specific kind of work. You write the spec, design the part, test it to death, tool up the line, and ship. A mistake after release is expensive, so you get it right before release. That discipline is why the mobile phone tower collects and relays signal while distributing data loads across the network to minimize dead spots.
But adding software on top of these manufactured products requires a different approach. Connected sensors, monitoring dashboards, ordering portals, apps for the contractor on the job site are all examples of what’s required to operate these physical products now. Not to mention the consumer facing experiences used to sell and manage usage. The people asked to build all of it are often smart, rigorous engineers. They reach for the playbook that has always worked. It involves rigorous planning, upfront testing, heavy designing and a commitment to physical deployment in the (sometimes very literal) field.
Where it breaks
Software flips the economics of building products. Changing a software product after release is cheap. In fact, these products are never-ending (we call them “continuous”). Think about it for a second. When is Google done? When is Amazon done? Do the Netflix engineers walk in to the office one day and just turn off the lights saying “that’s it, that’s as good as it gets”?
They don’t because improving on a working solution is the core benefit of digital products and services. Building the wrong thing is the expensive part. And the customers, facilities managers, contractors, plant operators, usually can't tell you what they need until they've used something. This is where the risk amplifies for industrial manufacturing companies.
So the hardware playbook is put into use and ends up producing a familiar result. The team spends a year plus building to a detailed spec, hits every date, and ships every feature on the list. Then almost nobody uses it. Or the cost savings don’t come. Nobody did anything wrong. The process was built for a world where the spec and the risk is knowable up front, and with digital products it isn't.
If we reflect back on the cell phone tower example. The engineers at Jio know exactly what goes into every tower, what it will look like when done, what it needs to do when operational and how much all of that will cost. They also have a very high confidence level in what they expect people will do with the tower itself. In this type of low-risk, high-confidence environment the hardware development playbook works like a charm (as it always has).
Three shifts that help manufactures reduce the risk of building bad digital products
Start with the outcome, not the feature list. Before anyone writes a line of code, ask your team to define the problem they’re solving for the customer or user. Once they have a clear sense of exactly what they want to solve for, have them define what they want the customer to do differently once the problem is solved. Maybe it's calling the supplier less, or catching a problem before it becomes a shutdown. That behavior change is the goal. The features are the team’s best guesses about how to get there.
Learn before you build. Put a rough version in front of a real customer in the first few weeks, not the last. A sketch, a clickable mockup, or a manual version of the service will do. These lightweight prototypes start to give your teams real feedback from real users about whether the solution you chose to build will indeed solver their problem. You'll find out which guesses were wrong much earlier in the process and while they're still cheap to fix.
Check whether behavior changed. This one is key and where digital products development really deviates from physical product manufacturing. Shipping isn't the finish line. It’s the beginning of the conversation with your customers and users. Once your product is in market, look at whether customers did the thing you hoped they'd do. Measure overall behavior through the use of analytics to see if, at scale, your target audience is getting benefit and value from the digital service you built. If they didn't, that's information and it’s what your teams will need to build the next iteration of the product.
None of this asks hardware engineers to give up rigor. It asks them to point the same rigor at a different question: not "did we build to spec?" but "did we change something for the customer in a meaningful way for them?"
Where to start
Start small. Get some wins and scale from there. Don't retrain the whole company. Instead, pick one product team and one customer problem and let them work iteratively, learning and adapting for a quarter. At the end of that quarter, pause to reflect on how the process went, what you learned along the way and how you might expand this new way of working to another team or two.
At Sense & Respond Learning, we help product and engineering teams make this shift, from output to outcomes, with practical training in product discovery, Lean product management, and OKRs. If your organization is putting software inside things that used to be purely physical, we'd love to talk.