Some product failures are execution failures. But the ones that frustrate me most are different: the technology worked, the business case closed, leadership was aligned, and customers still didn't buy it, didn't use it, didn't care. I've seen this pattern for decades, across Fortune 100 companies, startups, and enterprise teams. The cause is often the same: the company built what it could build and what leadership would fund. Nobody asked what they should build.

Three questions. Most companies only answer two.
‍Every product decision lives at the intersection of three questions: 

What CAN we do?
‍Capability: your technology, your talent, your infrastructure. 

What WILL we do?
‍Strategy: where leadership chooses to invest time and money. 

What SHOULD we do?
‍Customer need: the unmet problems, the latent desires, the things your market is desperate to solve. 

Most organizations are very good at the first two. The third one is harder to see, so they skip it. And that's where things go wrong. 

When CAN and WILL overlap without SHOULD, you're in what I call the Danger Zone.

It's where capable teams build the wrong things confidently. It's where feature lists grow because nobody had the discipline to say no. It's where products launch with impressive demos and disappear a year later. 

The Danger Zone isn't a failure of execution. It's a failure of discovery. 

What closing that gap actually looks like 

I worked with a workplace technology company that had saturated their core market and needed to find new ones. They had strong technology and leadership willing to invest. What they didn't have was a clear picture of where they actually fit in customers' lives outside their existing segment. 

We ran co-creation workshops with customers in target verticals, not to validate ideas leadership already had, but to discover problems worth solving. We mapped real workflows, surfaced real friction, and found opportunity areas the company hadn't considered. Those discoveries became their strategic roadmap. Years later, the moves they made trace back directly to what we learned in those sessions. 

In another engagement, our team served as the innovation arm for a large company trying to understand the well-being space. We used ethnography, going into people's homes, watching how they actually made decisions about health and happiness, to build a picture of customer motivation that no survey could capture. From that, we generated hundreds of ideas, narrowed to ten viable business models, and moved several into incubation.

In both cases, the SHOULD wasn't obvious. It had to be found. And finding it required methods most product teams don't use, not because the teams aren't talented, but because the methods aren't built into how most companies work. 

Why this is urgent right now 

AI is expanding what companies CAN do faster than most organizations know how to absorb. The barrier to building has never been lower. Code, content, design, prototypes, all of it moves faster now. That's genuinely exciting. 

It also means the Danger Zone is bigger than it's ever been. 

What's changed most in the last year: everyone is a builder now. Agentic tooling means designers, engineers, product managers, and individual contributors can push product to customers faster than any governance process was designed for. I see it on my own team and across the industry. Pet projects move through the pipeline. Sometimes people pause to ask whether they're solving the right problem. Often they don't. Speed without the SHOULD check isn't innovation. It's the Danger Zone, running at machine speed. 

AI is also changing how customers live and work, not just how companies build. The assumptions baked into existing products, about workflows, interfaces, how people make decisions, are being disrupted in real time. What customers needed two years ago may already be wrong. The companies that stay relevant are the ones studying now what customers will need next. Not validating what's already been decided. Actually discovering what comes next. 

This is what research excels at. Listening to customers before they can articulate what they need. Watching how work actually changes when new technology enters a team. Sensing latent needs that aren't asked for directly. That kind of understanding doesn't come from moving fast. It requires slowing down in exactly the right places. 

At Cisco, one of the clearest examples I've seen is in network operations. For years, operators were asking for the same thing: don't just surface the problem. Tell me what it is and how to fix it, in one place, at the speed the issue requires. They have been surrounded by data and still couldn't act fast enough. That persistent ask became the foundation for our AgenticOps work. Agents that sense degradation, diagnose root cause, validate a fix in a digital twin, and deploy. The SHOULD was there the whole time. Committing to it pointed directly to the hard work worth doing. 

The question for executives

Design and research functions are often brought in downstream. After the problem is defined. After the roadmap is set. There to make the solution look good. That's the wrong model, and it's an expensive one. You end up investing in craft without investing in direction. 

The question worth asking: does your design and research function have a seat at the table when problems are being framed? Are they operating alongside product and engineering, or after them? 

When anyone can build and ship, capability stops being the constraint. Judgment is. Knowing which problem is worth solving. Knowing when existing context is enough and when you need to go back to real people. Knowing how to slow the right things down without losing the speed that matters. That judgment doesn't emerge from an agentic pipeline. It has to be built into the people and process around it. 

Part of that judgment is protecting discovery. When everything is moving fast, discovery is the first thing that gets cut. A quick "validation session" replaces ethnography. A dashboard replaces a customer conversation. But discovery is where the SHOULD lives. Without it, you're not moving faster — you're just getting to the wrong answer sooner. 

This is work I'm focused on right now as a design leader, helping define what the SHOULD process looks like in an agentic world, and how design and research fit into it. Figuring out how the double diamond holds up when agents are doing parts of the work humans used to do. I don't have all the answers yet. But it's some of the most important work I'm doing, and I'll share more as it takes shape. 

Time AI frees up can go back into the discovery work that determines whether what you build matters. Less time spent on repetitive synthesis, documentation, formatting, handoffs. More time spent on meaningful outcomes. That's not overhead. That's strategy. 

The companies that consistently innovate have made understanding the SHOULD as visible and as funded as the CAN. 

The ones that haven't are building in the Danger Zone. And now they're doing it faster than ever.