The NBLM Deep Dive Podcast: Interested in a side of audio with your words? Listen to these fascinating AI-generated insights about this article.

Fortune smiled upon me in the most spectacular way

I recently received what every Product Manager dreams of: the ultimate gift of empathy, wrapped in AI brilliance. Through a LinkedIn automation twist of fate, I found myself in conversation with the CEO of BuildBetter.ai. Following an impressive demo, I was invited to explore their innovative platform, specifically designed for product managers. And thus I embarked on an exciting and revealing journey.

Like any passionate product professional (a special breed of optimistic masochists), I dove in headfirst. In my ongoing quest for AI tools to streamline my own product management, BuildBetter caught my attention with its focus on video chats, my personal favorite form of communication. Imagine a sophisticated fusion of Otter’s transcription prowess and ChatGPT’s intelligence, but evolved into something even more remarkable.

My initial week with the platform revealed the familiar growing pains of adopting new technology. The transition from sales to customer success was rocky and I encountered hurdles while introducing the platform to my team. Even those colleagues who ventured to try it faced considerable resistance in making it part of their workflow. While the platform excelled at video data collection, I found myself overwhelmed by the array of features and possibilities - ironically experiencing the same hesitation and confusion I regularly witness in my own users. This moment of vulnerability became a powerful mirror, reflecting insights about my own limitations I hadn’t expected to confront.

What emerged weren’t flaws to criticize, but valuable learning opportunities for both sides. Every piece of feedback I shared revealed improvements not just on their platform but on my own approach to product development. The BuildBetter’s team response was exemplary - they embraced each suggestion with genuine enthusiasm and gratitude, demonstrating exactly the kind of receptiveness users dream of encountering. Most impressively, as our discussion unfolded, other team members were already springing into action behind the scenes, working diligently to enhance the user experience.

Let’s be honest - every AI product today is basically trying to solve the “how do we make this not weird?” puzzle. While AI promises to revolutionize everything from rocket science to making toast, most professionals are stuck in that awkward phase where the AI is less “helpful assistant” and more “eager intern who keeps rearranging your desk.”

Looking at BoodleBox, my own digital offspring, I’ve had to admit that I’ve been guilty of allowing the “but what if we made it do everything?” syndrome when “do one thing well” was staring us in the face. I realized that even for someone deeply immersed in product development, we must all must “crawl before we run.”

This experience has led me to develop what I’m calling the “AI Adoption Straight Line“ theory - which is really just a fancy way of saying “keep it simple, stupid” with extra empathy and baby steps thrown in. Easy to preach, harder to practice, and even harder to admit when you’re not following your own sermon.

The Current Landscape

2024 marked a watershed moment in AI integration, with chat interfaces leading the charge. As we navigate through 2025 and beyond, we’re approaching a crucial turning point from “Look, it can finish my sentences!” to “Actually, we need this to pay the bills.” This transformation demands a complete reimagining of our approach to both AI-enhanced software development and user experience design.

The software industry is currently doing a rather impressive split between two worlds: the comfortable old realm of clicking buttons (ah, simpler times), and the brave new world of asking AI to do things in plain English. This dichotomy has led to an interesting phenomenon where both established companies and new ventures are retrofitting AI chat capabilities onto existing solutions, often redundantly solving previously addressed problems. Basically just strapping rocket engines to bicycles, convinced that’s what transportation needed all along.

Here’s the real head-scratcher for product leaders: how does one effectively communicate specific value when their tool’s capabilities are essentially boundless? The irony is the more possibilities we offer, the more users retreat to the comfort of basic features, rarely justify the substantial computational investment required.

The Straight Line Solution

To address this challenge, I propose a straight line approach - the radical notion that maybe, just maybe, we shouldn’t try to boil the ocean with AI. Revolutionary, I know.

Instead of overwhelming users with infinite possibilities, what if we focused on the stuff users actually need to do? You know, those mundane, everyday tasks that everyone does, all the time, without fail. The boring stuff. The stuff that actually keeps businesses running.

Here’s the groundbreaking formula:

• Find what 100% of users do 100% of the time

• Make that ridiculously good

• Don’t add a chatbot just because you can

This approach accomplishes three things:

1. Saves users from decision paralysis (because nobody needs 47 ways to send an email)

2. Ensures you’re not burning compute power to generate haikus about project management

3. Creates a solid foundation for future features that people might actually use

In other words: Let’s make AI boring again. But like, useful boring. The kind of boring that gets things done and doesn’t require a PhD in prompt engineering to use.

Building User Confidence Through Repetition

The secret sauce of AI adoption is boring, predictable success. Not exactly the stuff of sci-fi dreams, is it?

Think of it like teaching a teenager to drive. You don’t start with parallel parking on a steep San Francisco hill during rush hour. You start in an empty parking lot, doing the same mind-numbing circles until muscle memory kicks in. Then, and only then, does that teenager start asking, “Hey, what happens if I try...”

Turns out, users don’t fall in love with AI because of some flashy feature list or the theoretical possibility of achieving digital nirvana. They fall in love with it the same way you fell in love with your favorite pen - because it writes smoothly and never fails you when you need to jot something down.

The magic happens when users stop thinking “Will this work?” and start thinking “I wonder what else this can do?” It’s like watching a toddler go from wobbly first steps to running marathons. Except in this case, the toddler is your user, and the marathon is them finally figuring out how to use your AI for something you never even imagined.

Who knew that the path to revolutionary AI adoption would be paved with... consistency?

The Visionary’s Dilemma

Let’s be honest - telling a product visionary to limit their AI’s capabilities is like asking a kid in a candy store to only eat vegetables. I know it hurts.

Yes, you’ve got a technological Ferrari under the hood. Yes, it could probably write a dissertation on quantum physics while composing a symphony and debugging code. And yes, it’s absolutely killing you to watch people use it as a glorified calculator.

Think of it as strategic sandbagging - I’m not permanently condemning your AI to a life of mundane tasks, just making sure users don’t run screaming for the hills when they see everything it can do. It’s like dating - you don’t lead with “I’ve already planned our wedding and named our future children.” You start with coffee, or whatever AI-enabled virtual dating app the kids are using these days.

Looking Forward

Let’s cut to the chase: The AI Adoption Straight Line theory is basically the “teach a person to fish” philosophy, but for AI. Except instead of throwing them into the deep end with a nuclear-powered fishing submarine, maybe we start with a nice, simple rod and reel.

It’s not about showing off how many tricks your AI can do (sorry, data team). It’s about being the reliable friend who brings an extra phone charger, not the one who shows up with a portable generator and a complete backup power system when people just needed a quick battery boost.

To all you visionaries out there, clutching your models and muttering “but it can do so much more” - I hear you. I see you. I feel your pain. After all, even Iron Man started with a clunky Mark I suit before he got to the fancy nanotech version. And if Tony Stark can exercise patience, so can you.

The path to AI world domination - er, I mean, widespread adoption - isn’t a sprint. It’s more like teaching your grandmother to use a smartphone: start with calls, work up to texting, and before you know it, she’ll be creating autonomous AI assistants.

Baby steps, folks. Revolutionary, world-changing, AI-powered baby steps.

After having the pleasure of leading countless products, shepherding creative and technical minds of varying degrees of enthusiasm, I’ve learned that asking about effort estimates is like opening Pandora’s box – if Pandora’s box was filled with increasingly creative ways to say “it’s complicated.”

When I ask “what’s the effort?” I’m not plotting one’s demise or crafting an ironclad contract in blood. I’m simply trying to determine if this task falls into the ‘afternoon project’ or ‘we’ll-all-be-retired-by-then’ category.

You see, developers have this charming tendency to hear a simple request and immediately architect a solution that could probably also solve world hunger and achieve cold fusion. I say “add a button,” they hear “rebuild the entire backend from scratch.”

So despite my best attempts at clear communication and my repeated assurances that these estimates won’t be carved into stone tablets, I still find myself in the same daily ritual: Before I can finish explaining what is essentially ‘can we make this thing do a thing,’ I’m greeted with some version of these dreaded words: “That’s gonna be a big lift.”

Decoding the “Big Lift” Defense Mechanism

When someone declares something a “big lift”, they’re engaging in the ancient art of task inflation – a practice as old as the first estimate that it would take six months to center a div.

What they really mean is:

• “I haven’t thought about it yet, but I’m preemptively overwhelmed”

• “You didn’t use the exact technical jargon I would have used, response: 500 error“

• “You clearly don’t understand the butterfly effect this will have on my architecture”

• “I’m hoping if I make it sound scary enough, you’ll drop it”

• “I’ve been hurt by other PMs in the past and I don’t know if I can trust again”

The beautiful irony is that these “big lifts” often turn out to be more like “moderate inconveniences” once you actually dissect them. It’s akin to watching someone prepare for an Arctic expedition when they’re really just walking to the corner store.

The “big lift” declaration is essentially the corporate equivalent of your kid sighing dramatically when asked to take out the trash. It’s that moment when fear, procrastination, and imposter syndrome join forces to create a mountain out of what is, essentially, a moderately sized speed bump.

In the end, the phrase “big lift” has become less of a technical assessment and more of an automated response much like “we’ll see” (which we all know is just a parent’s way of saying “no” without starting an argument).

Breaking Down the Wall of Vagueness

For Product Managers dealing with the “big lift” phenomenon, here are some strategies to navigate task inflation:

Embrace Your Inner Pavlov

• When you hear “big lift,” immediately respond with “And what unit of measurement is that exactly? Is it metric or imperial big lifts?”

• Consider keeping a tiny violin in your desk drawer for these moments

• Bonus points for developing a facial tic that appears only when those words are uttered

Play “20 Questions: Developer Edition”

• Instead of accepting “big lift” as an answer, treat it like a murder mystery

• “What specifically makes this challenging?” often reveals that the original gut estimate may have been a scooch exaggerated.

• Watch as “impossible” transforms into “well, actually...” in real-time

The Great Task Striptease

• Slowly remove layers of complexity like you’re peeling an engineering onion

• “What’s the first thing we’d need to do?” usually reveals that it’s 3 small tasks and updating a config file, not reinventing electricity

• Suddenly that “big lift” looks more like a “slight bend at the knees”

And now, the moment of truth:

The problem is probably you, dear Product Manager. While you’ve been marinating in the “why” and “what” of your brilliant idea, crafting vision boards and user stories, your developers just heard about it 30 seconds ago between bites of their morning bagel.

You’re essentially asking someone to estimate the cost of building a house while they’re still trying to figure out if you mean a dollhouse or the Taj Mahal.

Embrace the friction. It’s like coffee – necessary and productive in the right amounts. Avoid fear. It’s like putting pineapple on pizza – controversial and potentially harmful to team morale.

Next time you hear “big lift,” resist the urge to roll your eyes so hard they get stuck. Instead, channel your inner therapist and help your developer work through their premature estimation anxiety. And if all else fails, try replacing “big lift” in the conversation with “scary monster under the bed.” It helps maintain perspective.

What does effort mean? Really.

Today the development world has somehow managed to compress all possible task complexities into a binary system that would make even the most zealous boolean enthusiasts cringe. It’s as if every task falls into one of two categories:

1. “No problem, I can do that in 5 minutes” (narrator’s voice: “it actually took three full days, two mental breakdowns, and a complete reevaluation of career choices”)

2. “That’s a big lift” (narrator’s voice: “it wasn’t”)

What our industry desperately needs is a more nuanced vocabulary for discussing effort that’s not t-shirt sizing or arbitrary points, something akin to a Richter scale for development tasks that assume actual time as represented on a clock, maybe something like:

• “Tiny Tap” (Minutes: The kind of task you could theoretically complete while sleepwalking)

• “Minor Hoist” (Hours: Just add coffee and an hour of focused work)

• “Medium Move” (Days: Requires engaging the brain, but won’t necessitate a complete system overhaul)

• “Substantial Shift” (Week: Time to dust off that documentation we’ve been avoiding)

• “Genuine Big Lift” (2-3 weeks: Better call AWS support and order several pizzas)

• “Complete Rebuild” (Ahh Crap: The perfect time to update those LinkedIn profiles and brush up the old resume).

This nuanced approach might just save us from the current situation where every task is either treated as trivial as breathing or as complex as explaining blockchain to your grandmother.

The Reality Check

The truth is, calling everything a “big lift” is like a teenager declaring everything “literally the worst thing ever.” It’s dramatic, it’s unhelpful, and it makes actual big lifts feel left out and underappreciated.

The next time you hear (or are about to say) “big lift,” pause. Replace it with specific concerns, actual time estimates, or even a simple “I need more information to properly assess this.” Your teammates will appreciate the clarity, and you might find that the lift isn’t as big as you imagined.

Even the most impressive structures are built one brick at a time. Sometimes what we need isn’t a bigger crane, but a better blueprint.

ALWAYS REMEMBER… A “Big Lift” is NOT a unit of measure!

I made these fun fashion reminders to help. Check em out