Insights — Case Study

A remote operations platform for smart access and facilities management — deployed across commercial properties in around the world — giving operators the ability to monitor, act on, and resolve device issues without sending someone on-site.

The central lesson from this project: internal demand does not always reflect customer value. The direction only became clear through customer discovery — by setting aside what internal teams wanted and asking a harder question: what are customers actually willing to pay for?

Problem

Managing smart access devices across multiple sites is operationally expensive. Faults require on-site technician visits, response times suffer when issues cannot be diagnosed remotely, and operators have limited visibility into what is happening across their estate.

The initial assumption was that monitoring — real-time status, alerts, and dashboards — would be the primary value driver. But early customer conversations revealed a different pattern. Customers had already made significant upfront investments in installation, and monitoring was viewed as a baseline capability — expected as part of the solution, not something they would pay for as a standalone recurring product.

At the same time, internal teams had strong operational demand for maintenance workflows and service planning tools.

This created a genuine tension:

Monitoring → aligned with the initial vision, but limited monetisation potential
Maintenance → high operational value internally, but value remained internal to the organisation
Remote operations → emerging area, underemphasised early on

The core question became:

What is the primary value this product delivers — and what are customers willing to pay for?

Core Insight

Two insights emerged through customer validation.

1. Visibility alone does not drive monetisation

Monitoring answers: “What is happening?”

But customers place higher value on: “Can I resolve this quickly and remotely?”

The most compelling use case was remote restart — it resolved common operational issues without escalation, eliminated unnecessary on-site visits, and improved response time in a way that was immediate and measurable. This reframed the product from passive visibility to active operational control.

2. Internal demand and external value are not the same thing

Not all valuable capabilities are suitable as the core of a customer-facing product.

Maintenance workflows were operationally important and strongly requested internally. But similar capabilities were already being explored in enterprise tooling. The value remained inside the organisation, not in the hands of the customer.

Proposed Direction

Reposition the product as a remote operations platform, with monitoring and maintenance as supporting layers — not the core.

Remote operations → primary value (action-oriented, efficiency-driven, monetisable)
Monitoring → supporting layer (provides context for decisions)
Maintenance → complementary workflow (supports operational teams and partners)

Key Product Decisions

Engineering owned the technical architecture and infrastructure. My role was in shaping product scope, the product model, and the prioritisation decisions below.

1. Shift from monitoring to action

The emphasis moved away from standalone monitoring dashboards toward capabilities that enable direct intervention — remote restart and remote control actions. The product is not about seeing more. It is about doing more without being on-site.

2. Focus on high-impact use cases

Not all features contributed equally to customer value. Monitoring was treated as an expected baseline. Maintenance delivered internal efficiency but not external impact. Remote restart, by contrast, created immediate operational impact for both customers and service partners — and became the primary lens through which features were prioritised.

3. Reframe value around efficiency

The product narrative shifted from increased visibility to fewer on-site interventions, faster issue resolution, and measurable improvement in operational efficiency. That reframe made the commercial case significantly clearer.

4. Balance internal and external needs

Internal teams had legitimate operational needs around maintenance workflows. The approach was to support these where relevant — while ensuring they did not define the core product positioning.

Internal demand was acknowledged, not dismissed. But it did not anchor the product.

5. Use customer value as the primary decision filter

A consistent principle emerged across every prioritisation decision:

Prioritise capabilities that create clear, external value for customers.

This became the tiebreaker when stakeholder perspectives diverged.

Constraints & Risks

Ambiguity in product positioning (Critical)

At the early stage, there was no clear consensus on whether the product should focus on monitoring, maintenance, or operations. Multiple iterations of problem framing were required before the direction stabilised — and that ambiguity created real risk of building confidently in the wrong direction.

Diverging stakeholder perspectives

Customers emphasised operational outcomes. Internal teams emphasised workflow efficiency. Balancing these perspectives required deliberate prioritisation — and a clear principle to return to when the conversation drifted.

Overlapping capability areas

Monitoring, operations, and maintenance are closely related. When the underlying capabilities share infrastructure and overlap in use, clear product boundaries are harder to maintain — and positioning requires ongoing discipline to hold.

What Changed in My Thinking

The biggest shift:

From “monitoring is a strong standalone value proposition”
→
“monitoring is expected, but not sufficient on its own”

That shift happened because customer conversations consistently deprioritised visibility as a purchase driver, the remote restart use case kept surfacing unprompted as high-value, and maintenance workflows — though operationally important — did not translate to external monetisation.

The next assumption — that maintenance could anchor the product — also needed revision:

Internal efficiency does not necessarily translate to external value.

What finally clarified the direction was a single reframing question:

What are customers willing to pay for?

Once that became the primary lens, decision-making became significantly cleaner.

Why This Matters

The core challenge in this project was not feature selection. It was defining the right problem. Not all useful features are monetisable. Internal demand does not always reflect customer value. And early positioning decisions shape long-term product direction in ways that are hard to reverse.

The product is defined not by everything it can do, but by the value customers are willing to pay for. In this case: monitoring informs, maintenance supports — but remote operations delivers.

Open Questions

How do you maintain clear product positioning as the platform expands to cover more use cases?
At what point does supporting internal workflows start to dilute the external value narrative?
What is the right sequencing between remote operations depth and monitoring breadth?

Reflection

What initially appeared to be a straightforward monitoring product required multiple iterations to clarify its true value.

The most important shift was not in the features — it was in the framing. From visibility to action. From internal demand to external value. From feature set to product positioning.

The strongest lesson from this project is that effective product decisions often come from reframing the problem, not just refining the solution. The answer was there in the customer conversations early. The harder work was being willing to set aside the original assumption to hear it.

What changed?

v2

Softened opening to reflect that the strategic direction emerged through discovery rather than implying solo authorship. Added explicit ownership boundary sentence in Key Product Decisions separating PO scope from engineering architecture and infrastructure.

v1

— skip —

Why it changed?

v2

Claim safety review against the dormakaba portfolio validation process identified two minor overclaiming risks: the original opening implied Kenny unilaterally asked the hard question, and the Key Product Decisions section did not clearly separate PO ownership from engineering ownership. Both fixes preserve the core narrative while making the case more defensible.

v1