Not long ago, I took a shot that went very differently from what I initially planned. The original idea for the hole was gone. Walking towards the ball, it occurred to me how familiar this situation is. Golf and product ownership both involve looking beyond the next move. A plan gives you direction, but things change and you need to understand the conditions, weigh your options and adjust as you go.
A roadmap gives you direction, not certainty
In golf, you plan the hole, but where the ball lands shapes your next shot.
A product roadmap needs the same flexibility.
I work as Product Owner on the IoT platform that provides the connectivity for domestic appliances people use every day. It brings embedded firmware, cloud services and mobile integrations into one ecosystem.
Our ongoing work on AI capabilities is a good example when the idea sounds simple: an appliance learns from everyday routines and adjusts how it operates. On a slide, that looks like one feature, but it requires several parts of the platform to work together.
When a feature is complex, instead of treating it as one large delivery, we see if we can break it into blocks that could be delivered in phases.
Workshops with the client, help us explore and decide what is feasible and useful to users now and what can wait.
This helps the client set priorities and split the scope into phases, rather than spend months perfecting everything at once.
We also look beyond the first product. Building a reusable core makes it easier to bring the capability to similar appliances and adapt it where needed.
That way, each release supports both the user’s needs today and the products we plan to build tomorrow.
Ownership is not just producing requirements
In golf, a long shot only matters if it leaves you in a good position for the next one.
In a product ownership, every decision sets up the one after it.
Architects and developers bring the technical depth. Ownership connects their findings with priorities, dependencies and release plans, so the client can see the consequences of different options.
At Ignit, challenging a requirement also means exploring an alternative if there is risk, potential high costs, or maybe a better way to create value for the user.
On a platform serving around one million users, these choices matter.
Small inefficiencies become real operational costs. Small quality issues become support cases.
Feature that works perfectly for ten thousand devices may look very different when scaled many times over.
If a device suddenly changes its behavior without explanation, even a technically correct implementation can feel like a bug to a user.
When working on autonomous AI features, it is tempting to focus only on making the algorithm work, but that would be like focusing on one great shot while forgetting the rest of the round.
The real product outcome also depends on reliability, user experience and, perhaps most importantly, user trust to continuously use it.
The product cannot just be intelligent, it also needs to be transparent to the user.
Every technical decision contributes to an experience people can trust.
We are users too
In golf, a course map tells you what to expect. Playing the course shows you what the map could not.
It's the same with products: a specification describes how something should work, everyday use shows how it fits into people's lives.
We use the connected appliances we help to build. We notice friction hopefully before users.
In other words, we are platform developers, but sometimes we are also the customer.
Using and understanding the products gives context that is difficult to get from a requirements document alone.
You start asking practical questions:
- Why does the user need to do this?
- What happens if connectivity disappears at this moment?
- Would I understand this notification if I received it at home?
- Would I trust the appliance if it changed its behavior automatically?
- Is this feature actually useful, or are we implementing it because it sounds good on a slide?
This experience helps us ask better questions about how the whole product works for the person using it.
Play from where you are
In golf, you are not trying to win every individual shot. You are trying to protect the score for the whole round.
The same is true in product ownership: you are not trying to win a sprint, you are protecting the whole product.
After one bad shot, it is very easy to rush and take an unnecessary risk or try to compensate for what you just lost.
A dependency is late. A technical limitation appears. A release does not go according to plan.
After something unexpected happens, the quality of the next decision matters more than defending the previous plan.
We bring the right people together to understand the new constraints and decide what gives the best overall outcome.
We always try to understand the situation first:
- What exactly happened?
- What is the impact?
- What options do we have?
- And most importantly: how do we prevent one problem from creating three more?
That loop never changes, whether the surprise happens on the course or on project:
