I do not begin with a backlog. I begin by watching where work breaks.
People reveal product opportunities through the extra steps they have accepted as normal: the spreadsheet beside the official system, the person everybody asks before changing a setting, the support explanation copied for the hundredth time, the decision postponed because nobody trusts the available data. Those workarounds are evidence. They show where the current product ends and the real job continues.
Telzio began that way. I needed a capable business phone system for another project and could not find one that combined the features, flexibility, and accessibility I needed. So I built the missing tool. At first it was code solving my own problem. Then I needed to change behavior without editing the code each time, so I built an interface around it. That interface forced the logic to become explicit. The personal tool started becoming a product.
Useful innovation is not the same as invention
Invention can be impressive without being useful. Innovation closes a gap somebody actually experiences. That distinction matters because technical teams are naturally attracted to what is newly possible. A new capability can make us search for a problem generous enough to justify it.
I prefer the sequence in the other direction: understand the unmet need, identify why existing approaches fail, and then decide what must be invented. Sometimes the answer is advanced technology. Sometimes it is a better default, one fewer handoff, or a rule that the system can apply consistently.
The point is not to avoid ambition. It is to concentrate ambition on the part of the problem that matters.
Build the smallest complete system
A thin prototype can be useful, but “thin” is often confused with “visual.” A clickable screen may test language and flow while avoiding every difficult question about data, permissions, timing, failure, or operations. It can make an idea feel validated before its central risk has been touched.
I try to build the smallest complete system instead: enough interface, logic, data, and real operation to test the dangerous assumption. If the product depends on making a reliable decision, test the decision. If it depends on integrating fragmented channels, connect two real channels. If it depends on an expert trusting automation, put it in front of the expert with a clear way to inspect and reverse what happened.
This approach can look slower during the first week because it does not optimize for the appearance of progress. It is much faster by the tenth week because it exposes the truth early.
Direct support is product research with consequences
During Telzio’s early years, I was not only building the product. I was also handling support and customer service. That created an unusually short feedback loop: I could hear the problem, inspect the system, fix it, and then see whether the fix worked.
Customers do not always ask for what they need. They describe the point where their current understanding failed. If several people ask how to recover from the same state, the opportunity may not be better documentation. The workflow may need a safer default, a preview, a warning at the moment it matters, or a system that prevents the state entirely.
Support volume is therefore not just an operating cost. It is a map of product debt. Every repeated explanation is knowledge that the interface has failed to carry.
Product leadership is translation without information loss
Product work crosses several languages. Customers describe outcomes and frustrations. Designers describe attention and behavior. Engineers describe constraints and failure modes. Operations describes exceptions. Leadership describes risk, timing, and return.
A product leader has to translate among those groups without flattening what each one knows. “The customer wants this feature” is usually too shallow. Why do they want it? What work are they trying to complete? What happens if the system is wrong? Is the need common, or is one customer exposing a deeper model that many others share?
Technical depth helps me make that translation. It lets me challenge an artificial constraint, recognize when a seemingly small feature creates a dangerous new state, and separate expensive work from merely unfamiliar work. Creative experience helps too. Producing a record teaches you to preserve the intent while dozens of detailed decisions threaten to obscure it.
Turn founder knowledge into product capability
The earliest version of a product often works because the founder is standing beside it. They know which customers are a fit, how to configure the complicated parts, when to make an exception, and how to recover when something goes wrong. That knowledge can create a strong service, but it is not yet a scalable product.
Productization means transferring that judgment into the system without pretending every situation is identical. Good defaults cover the common path. Progressive disclosure preserves expert capability. Automation handles repeated decisions. Observability shows what the automation did. Escalation protects the cases where context still matters.
This is one reason I think about the back office as part of the product. If the customer experience depends on employees assembling context across five systems, the product is not finished. The hidden workflow will eventually define the speed, reliability, and cost of the visible one.
Launch is when the evidence gets better
Before launch, product work is mostly prediction. After launch, people show you what the product actually is. They skip the feature you considered central. They combine capabilities in a way you did not expect. They hit a boundary that looked unimportant in a workshop and matters every day in practice.
The right response is neither to obey every request nor defend the original plan. It is to improve the model. Which users are getting durable value? What behavior predicts success? Where does trust break? Which exception is a one-off, and which reveals that the product has misunderstood the job?
That is the work I enjoy most: moving between the idea and the evidence until the product stops feeling like a collection of features and starts feeling like the natural way to do the job.
Further listening
This thinking also appears in my conversations on What is Innovation? and Cloud Realities, where we discuss unmet needs, direct customer feedback, and how an internal tool became a communications product.