When good products reach the end of their chapter

When a product feels naturally Meraki

I was genuinely sad to see Cisco Meraki Systems Manager and MT Sensors reach end-of-sale.

Both products carried a quality I always associated with Meraki: taking something technically complex and making it easier to operate from a familiar dashboard. SM brought endpoint management closer to the network. MT used Meraki infrastructure to support environmental monitoring across use cases such as temperature, water leaks, air quality, doors, and power. Neither felt like a random addition to the portfolio. They made sense alongside the platform.

What SM taught me personally

As a Meraki Support Engineer, I loved what SM could do. Managing devices, applications, security policies, certificates, and network access from one place was powerful.

I also found SM challenging to troubleshoot. My background was heavily rooted in enterprise networking. Routing, switching, wireless, and SD-WAN followed mental models I had spent years building. SM required me to think across operating systems, enrollment methods, device permissions, certificates, application behavior, and changes made by third-party platforms.

That was not a weakness in the product. It was a reminder that two products can share a dashboard without sharing the same troubleshooting motion or technical skill set. Supporting an adjacent product may require new expertise, documentation, escalation paths, and readiness across the teams responsible for the customer experience.

Technical adjacency is only one kind of fit

MT created a similarly interesting extension of the platform. Existing Meraki access points and cameras could act as gateways for sensors, reducing the need for separate infrastructure. The technical story was compelling. The buying story could be more complicated.

The networking team might understand the value, while the budget or operational responsibility belonged to facilities, workplace operations, or another business group. A product can therefore be close to the existing architecture while being further away from the existing buyer.

That distinction matters. A familiar dashboard can make adoption easier, but it may not be enough to create a new budget, change an established workflow, or replace a specialist solution.

What end-of-sale does and does not mean

Cisco cited limited growth when announcing the end-of-sale of both product lines. For SM, Cisco also referenced the ongoing operational costs of remaining in the mobile-device-management market.

I do not interpret that as proof that the products were unsuccessful in every sense. They served customers, solved real problems, and created useful capabilities.

It does suggest that their growth was not strong enough to justify continued investment relative to other opportunities. That is one of the harder realities of product management. A product can be valuable and still not be the right place for a company to keep concentrating its people, time, and resources.

What I carry forward

This experience leaves me with a few practical questions I would ask before taking a product into a nearby market. Are we solving an important problem for people who already buy from us? Will our sales and support teams feel ready to explain it and troubleshoot it?

I would also look beyond the launch. Is being part of the same platform a strong enough reason for customers to choose it? Can we keep improving and supporting it for years? Is there enough room for it to grow?

SM and MT may have reached the end of their product chapters, but the ideas behind them still matter. For me, their story is not about failure. It is about how difficult it is to turn a technically natural extension into a sustainable product, and how much thoughtful work happens before, during, and after a launch.

This is a personal reflection based on my experience and Cisco's public end-of-sale information, not an internal account of either decision.