Why Focus Still Wins: Hubert Palan on Product Strategy in an AI-Driven Market

On a recent episode of Untrapping Product Teams, host David Pereira sat down with Hubert Palan, founder and CEO of Productboard, to talk about product strategy in the age of AI. The episode opened with a clip claiming AI already killed product managers and software engineers. Palan doesn't buy it.

Eleven years into building Productboard, his argument runs in the opposite direction. The tools have changed, but what separates the companies that win from the ones that don't hasn't.

Three themes stood out for product leaders deciding where to focus their teams:

• The discipline of choosing a narrow market before expanding.
• Why context is what actually makes AI tools useful, more than raw technology.
• And how specs are replacing code as the place where the real product work happens.

The Enterprise Pivot: Why Focus Beats Trying to Serve Everyone

Palan traced Productboard's strategy back to a hard call made during the 2022 downturn. As funding dried up and interest rates climbed, the company's smaller customers started struggling financially. Productboard had built a strong base in the SMB market, but the team made a deliberate choice to accelerate its move toward larger enterprise accounts.

That shift came with tradeoffs. Enterprise customers carry more weight, and that weight brings pressure. They ask for one-off integrations, custom workflows, features built for a single account instead of the broader roadmap.

Palan had to build the discipline required to say no. Some of those customers left. Palan argued the alternative would have been worse—spreading resources across too many customer specials until nothing was differentiated enough to matter.

He pointed to a pattern beyond Productboard. Uber started with high-end limo service before expanding down-market. Tesla and Superhuman followed a similar path, starting with a narrow, well-served segment before expanding into breadth.

The lesson is about sequencing. Focus first, then expand once the market is understood well enough to do it right. For product leaders, this reframes a familiar tension: serving every account looks like growth, but it often dilutes the roadmap until nothing is sharp enough to differentiate.

Why Context Matters More Than Technology

Most people assume the best AI products come from teams with the most advanced technology. Palan disagrees. He used coding tools as the example. Cursor succeeds in a crowded field because its founding team are developers building for developers, with a deep, specific understanding of what that user needs. The technology underneath isn't what sets it apart.

That principle carries directly into how Productboard is building its own AI capabilities. Palan compared asking a general-purpose tool to do competitive research against using a specialized agent built for that exact job—one that knows which industry databases to query, how to read a 10-K, which release notes actually matter. The difference in output quality isn't marginal.

He extended this to scale. A single product manager doesn't need a shared product knowledge system. An organization with 20,000 people across R&D does. The harder challenge is making sure that context, and the decisions built on it, gets shared across teams so people aren't relearning the same lessons in isolation. Generating one good output is the easy part.

This is the case Palan makes for Productboard Spark. It's built around the context a product team accumulates over time (customer feedback, competitor moves, internal roadmap history), so its recommendations stay grounded instead of generic.

Spec-Driven Development: Why the Spec Is Becoming the Product

The third theme addressed a shift already underway in how product teams work with engineering. Palan referenced a trend he calls spec-driven development. If AI agents are writing the code, the spec is what tells them what to build. Get the spec wrong, and the output is wrong no matter how capable the coding tool is.

He shared a concrete example from inside Productboard. He and his co-founder spent a day working through the full flow from product discovery to delivery, using AI coding tools alongside their own product knowledge. Work that used to take a product manager weeks, writing a spec, handing it to engineering, waiting for a return trip through the codebase to surface edge cases, compressed into a matter of hours.

Speed doesn't remove the need for judgment. Complex products still carry dependencies, and hallucination still shows up once a spec moves into delivery. The efficiency gain shows up earlier in the process, in how fast a team reaches a clear, well-scoped spec. It doesn't replace the need for a human who understands the product deeply enough to write one.

What This Means for Product Leaders

Underneath the three sections is one conclusion—depth of market and customer understanding is still the deciding factor, and focus, context, and specs are just the three places that depth gets tested right now.

Productboard's enterprise pivot exhibits the demand for focus: to build something well, you have to narrow your lens and, at times, turn away business that deviates from the strategy. For product leaders, that's the difference between solving customers' problems in the moment and solving them for the long term.

The context argument exhibits the case for shared systems: an AI tool only performs as well as the understanding behind it, so leveling every PM to the same base of knowledge raises the team's output more than any single tool upgrade would. As product leaders take on more responsibility for how their teams use AI, choosing tools that raise the whole team's floor is going to matter as much as choosing capable tools at all.

The spec argument exhibits how the EPD relationship is evolving: the value isn't just in shipping faster, it's in a new expectation for deep product and user understanding, one that now cuts across roles and shows up directly in the thinking behind a spec. That gives product leaders a real opening to reshape the relationship with engineering and raise the quality of product thinking across the team.

Palan's final thought returned to domain knowledge. Everything in the conversation points back to it: domain knowledge, not AI fluency, is the deepest source of competitive advantage. AI can move a team faster through research, synthesis, and delivery. It can't replace the judgment of deciding what's worth building in the first place.

Frequently Asked Questions

Should product leaders worry that AI is replacing their teams?

No. AI changes how fast a team moves through research, synthesis, and delivery. It doesn't change who's accountable for deciding what's worth building. That judgment call, and the responsibility for it, still sits with product leadership.

How should a product leader evaluate which AI tools to bring into their team's workflow?

Judge a tool by how much of your team's own history it can actually draw on, not by how impressive its output looks in a demo. A generic tool can write a decent-sounding summary of a customer feedback thread. It won't know your team already tried and shelved a similar feature two quarters ago. A tool built around your team's own product history catches that automatically; a generic one won't even know to check.

How does the right approach to AI tooling change as a team scales?

A five-person team can keep most of what it knows in a few people's heads. A company running dozens of squads across regions can't. At that size, the risk isn't that any one squad uses AI badly, it's that two teams on opposite sides of the org independently solve the same customer complaint without ever finding out the other already did the work. Scaling AI well means catching that kind of overlap, not just making each team's individual assistant smarter.

What does spec-driven development change about the relationship between product and engineering?

It shifts where the real work happens. As AI compresses the time it takes to go from spec to shipped code, the spec itself becomes the place where product thinking gets tested. That's an opportunity for leaders to raise the bar on how deeply a team understands the problem before writing starts, not just how fast it ships once writing is done.