What to build, and why.
Product judgment is learned. My training started in journalism, where accuracy and audience mattered most, against a deadline that never budged. Expanding into marketing, IT and then product was a natural transition. Audience became customers and stakeholders. Accuracy still reigns, along with quality and reliability. I work from a set of habits these experiences made automatic. They’re how I bridge the business and the technology, and how I make decisions as a product person and as an advocate for the customer.
Where I look
Actions in the product.
Customers, frontline associates who are themselves users, and UX research arriving as findings that need conversation. Direct evidence from product use, and where I start. I’m looking for unexpected behavior. What people do that we never designed for, and what they tell us about the experience. Those are data points to research and test against.
Impacts to the product.
Market and competitor signal, industry groups and trends. Ideas and insights from these sources usually arrive as a hypothesis with a point of view already attached. It’s the source that makes us look outside our business. We must consider what we could be, not just iterations of what we are. My work is to pressure-test the hypothesis and give it shape. I collaboratively define what the bet looks like in practice, what it takes to sell and support, what return we expect and by when.
Vantage points on the product.
Engineers, architects, and QA hold the clearest picture of what’s newly possible to creatively solve problems or differentiate through innovation. Solutions consultants and implementation teams sit with customers every day. They hear what they keep reaching for. Neither group is running analysis. They know what they know because of where they stand. Both groups get asked what to execute, not what they see. I make sure to ask.
How I decide
Default to action.
Something is broken, or somebody built a habit to work around it. Either way it’s costing them today. I take that away first. Relief doesn’t have to wait for the broader fix. When it can’t be taken away quickly, it stays visible. A workaround people live with is a tax on their trust in the product, and I’d rather account for it than forget it’s there.
Keep the long view.
I solve the immediate problem fast, then hold the fix loosely. It stopped the pain. It didn’t tell me what caused it. Repeated fixes in the same area are evidence, and I read them together. I find the design problem before the patches become the architecture.
Perfect is not a prerequisite.
There’s always a pull toward the most complete and elegant answer instead of the available one. The real fix, the refactor, the thing built to last. It’s usually fundamentally better. It’s also slower and more expensive. The customer waits while we build it.
That’s the tradeoff always in play. A more complete solution may reduce future cost, complexity, or risk for the business. The customer funds that big play with the time they spend waiting for it.