Barbell-Shaped Product Roles

Photo by VD Photography on Unsplash

I had yet another call last week with an AI engineer/cofounder who has built some very interesting software but gotten zero interest from his intended buyers. For 90 minutes, we ignored his beautiful tech, and dug into the product basics…
Target audience? Crisp problem statement? Compelling economic value message?
He had some hypotheses alongside a value story his intended users would find deeply insulting. He is trying to sell prospects on his concept of what they should need. I wish this were the exception.

We recapped my Code Isn’t Product post, why 10x Coding Speed Won’t 10x Revenue, and how the bottleneck is moving from raw code to honest discovery and commercial viability.

As AI accelerates core code development and reduces the detailed technical involvement of product managers, we still need to solve these two core product problems:

• Of the infinitely many things we could build, which ones are likely to drive revenue and business outcomes? (Note that this is not an engineering question.)

• How do we make more of our products successful in the marketplace? (Also not an engineering question.)

This has me drawing the AI-first product role as a barbell.

Classic Software Product Management (1971-2024)

During my decades doing this, we’ve spent the majority of our product time getting things built. Engineering created the software, UX created the experience, tech writers wrote the manuals, test engineers built the harnesses, but someone needed to drive clarity and adoption. Sondra Orozco describes it as “figuring out what their team should build with limited time and resources, and doing whatever it takes to make their product great.”

It looked vaguely like this:

Core development as product’s primary focus

The fuzzy front end is where we try to decide what we should build when faced with thousands of ideas and demands and suggestions and executive mandates. With severely limited resources. We wrestle with semi-quantitative insights, intuition, imponderables. We do open-ended discovery in the hopes of learning something. We try to validate problem statements (first) and then possible solutions (second) with our intended target customers. Define outcome metrics. We apply judgment, experience, common sense, war stories. Because most products fail here, before the first line of code is written, regardless of how fast engineering runs. Most products should never be built; most features should never be added.

We intend to put 20% of product effort here, but always short-change it... because every company believes that it can skip discovery just this one time on this one critical initiative. Our customers know exactly what they need. Our CEO is a visionary. Making software can’t be that hard. This one-off item won’t take much ongoing support. In spite of all evidence that most product work is wasted, our company is way above average.

The core development work (60-100%) is much more visible: SDLC, roadmaps, tickets, rituals, trade-offs, competing objectives, product narratives that don’t get read. We face the chaos... demands for ever-shorter schedules. Late-arriving requirements. Unexpected technical challenges. Sales escalations. Poached engineers. We satisfice and hope the next release will be easier.

Go-to-market readiness is everything that Sales & Marketing needs to start the money flowing: precise targeting/ICPs, messaging, pricing/packaging, ROI calculators, detailed-yet-unbounded use cases. Dazzling sales materials. Happy reference customers. Effortless onboarding. Bug-free software.

This gets 10-20% of an average product manager’s time, although it deserves much more. We may shift this to an under-appreciated product marketing or enablement group. Regardless, Sales & Marketing teams can’t succeed without these assets — they instinctively abandon products that don’t get immediate traction.

Product Management in AI-First Organizations (2027+)

Fast-forward to when we can deliver production-quality code 10x faster, measured from agreed features to full customer availability. (I don’t yet believe this, but will save that argument for another post.) That shifts the most valuable product work further to the ends — a barbell.

AI-first product effort moves to the ends

The Fuzzy Front End

We used to hide slow, uncertain discovery work behind an even slower development cycle. But now we’ll be building much faster than we can validate demand. The organizational pressure will be intense to skip the fuzzy steps and get right to coding.

Speed is our strategy! Users will experiment with everything we ship, and our instrumentation will tell us immediately what’s useful or valuable. Prospects will write our money stories for us. Selling will be faster and easier.

I don’t think so. Users/buyers are already overwhelmed, flooded with aspirational product pitches, trying to do their day jobs. 10x more features and tools and products will make it even harder to pick a winner.

And I don’t buy the “outsource our whole discovery process to AI” story. We need to put 40%+ of our time into evidence-based recommendations for a few big revenue bets. And convert those into money. Otherwise we’ll have the same uninspired, generic, AI-generated product plans as our competitors.

So instead, a few partial solutions for speeding up useful discovery:

Right Tools, Right Job

AI will speed up parts of discovery. Identifying users with similar support tickets, then scheduling calls with them. Daily analytics and trend identification. Scanning for competitor announcements. Suggesting money stories. Transcribing interviews and spotting themes. Reminding us to define success metrics before we ship. But we can’t automate judgment, context, or identifying the one really sparkling idea among the dreck.

I love Teresa Torres’ deep insight that humans need to do real interviews, yet AI coaches can help us be better interviewers.
And we don’t need to do discovery on everything. Let’s focus our attention on the big, risky, hard-to-reverse strategic bets. Muster the courage to discard the bottom 80% of our backlogs. And time-box decisions about smaller features, fixes, obvious improvements. See Büşra Coşkuner’s “When do you actually need Product Discovery?“

Putting 40%+ of our energy into serious discovery and market-sensing will let us get ahead of the daily anecdotal demand stream.

Core Development

Engineers do much more than build code. They understand systems, map out architectures, anticipate bottlenecks, apply hard-won learning around security and scalability and maintainability. They bring judgment, experience, talent, taste, intuition. I see that AI is dramatically accelerating the generation of code, but not convinced that we’re seeing 10x faster creation of commercially viable products. Some ways I think product folks can help more during core development:

• Keep teams focused on outcomes, customer value, market wins. Are we gold-plating that feature? Will users see the results of that optimization? Can we extract more market leverage from similar effort?

• Author whatever context files or product briefs or problem statements fit the new model. That still captures strategic intent.

• Humbly ask the bigger-than-code questions. Architecture, supportability, trade-offs. How do we know if our code still works when the underlying model changes every week? How will we track concept drift as users try new things and our corpus gets stale? What should we be worrying about?

Engineers get to decide how we build software, and choose their tools/processes/agents. Product folks try to keep our brilliant technologists focused on outcomes.

Go-To-Market Planning

If we can’t explain why someone should consider our product — in simple, user-friendly economic terms — then revenue doesn’t flow. Traditionally, product managers have passed this buck to product marketers or treated it as an afterthought. And we collectively had months (years) to draft go-to-market materials while products were built. Now that might be weeks.

Dirty secret: the best go-to-market intelligence comes directly from users and buyers, from the very same discovery calls we use for feature/function insights. Not from our own market-facing groups, not from industry analysts, not from the Board. But we often forget to ask.

Ways we could compress the GTM Planning cycle:

• Include product marketers (if they exist) in discovery calls. Ask the economic questions earlier: How would you describe the benefits? What else have you tried? How would you justify spending money on this? Who approves purchases? Sort out pricing, packaging, ROI metrics, and sales goals upfront.

• Use money stories to guesstimate future revenue for our big bets. And use those guesstimates to sidestep less valuable work.

• Identify Sales & Marketing capacity limits. If we can aggressively promote only two new products each quarter, propose the right ones.

• Ask the tough leadership question: which launches went well, and what does reasonable GTM preparation look like? Or consider the put-up-or-shut-up experiment, where some sales regions create their own messaging and packaging while others use what product/marketing supplies. Who is less unhappy?

Product Engineers?

My approach is in direct contrast to the product engineer trend. AI pushes product work to the ends and engineering work to the middle. I’ve met a few unicorns who are great at both. But this is mostly engineers doing hand-wavy product thinking on their way to shipping code. I’ve had to dig naïve CTOs out of this trap scores of times.

Exception: when AI engineers are building AI tools for other AI engineers, they are their own audience.

Sound Byte

The bar gets heavier at both ends: more judgment on what to build, more muscle on how to sell it. Engineering owns the middle.