There’s a reason every car is designed the way it is. The windshield dominates your field of vision, while the rear view mirror is small and off to the side. Both matter—but they serve different purposes.

The rear view mirror gives you context. It lets you check what’s behind, notice patterns, or be aware of potential risks sneaking up on you. Without it, you’d drive blind to the lessons of the road. But it’s small for a reason: if you stared at it too long, you’d lose track of where you’re going.

The windshield, on the other hand, is massive. It stretches wide and tall, pulling your focus to what’s in front of you. It reminds us that forward is the primary direction. Yes, the past matters. But the future is what matters most.

This metaphor applies everywhere—at work, in leadership, in personal growth.

• In teams: We can’t keep measuring ourselves only by what we’ve already done. Post-mortems and lessons learned are valuable, but they’re just checkpoints. What matters more is setting our eyes on the road ahead and asking, Where are we going next?

• In careers: It’s tempting to replay past decisions—what you should have said, what you could have done differently. But careers are built on momentum. You only get there by looking through the windshield, not obsessing over the rear view.

• In life: Mistakes and regrets are like potholes you hit behind you. You can learn from them, but you can’t un-hit them. The bigger question is: how do you adjust your path moving forward?

I try to remind myself of this often. The rear view mirror is there to glance at, not to stare into. The windshield is bigger because what’s ahead of us deserves more attention than what’s behind us.

So maybe the real lesson is this: respect the past, but don’t get stuck in it. Your best days, your biggest growth, and your most important impact opportunities are still out in front of you.

It was supposed to be a clean launch.

Design hit their deadlines. Engineering got it out the door. GTM was prepped with messaging. But when the product shipped… crickets.

Low adoption. Confused users. Frustrated internal teams.

Sales pointed at Product: “We didn’t know the positioning.”

Engineering pointed at Sales: “They rushed features with no context.”

Leadership pointed at everyone: “Why wasn’t this flagged earlier?”

In moments like this, the reflex is to point the finger.

But great product managers?

They point the thumb.

The Thumb Principle

There’s a quiet kind of leadership in asking:

“What did I miss?”

Not as a scapegoat.

Not to absorb blame for others.

But because the best PMs understand a foundational truth:

If you own the outcome, you own the inputs.

That’s the thumb principle.

It’s not about taking blame—it’s about taking responsibility.

Responsibility for clarity. For alignment. For blind spots. For missed context.

Because no matter who “caused” the failure, the PM is uniquely positioned to prevent it.

Let’s take a few classic examples:

1. Engineering misses a deadline.

Finger: “They didn’t scope properly.”

Thumb: “Did I define the problem clearly? Did we de-risk the plan enough?”

2. Users are confused by a new feature.

Finger: “Design didn’t follow the brief.”

Thumb: “Did I validate the experience? Did I test assumptions early enough?”

3. Stakeholders override the roadmap.

Finger: “Leadership keeps changing priorities.”

Thumb: “Did I communicate tradeoffs clearly? Did I earn trust in the plan?”

It’s not about excusing others.

It’s about examining the system through your own lens of control—and leading the fix.

Why Pointing the Thumb Builds Influence

Ironically, the fastest way to earn respect is to own the hard parts.

When you point the thumb:

• Engineering sees you as someone who takes the heat, not just the credit.

• Leadership starts looping you in earlier because they trust your judgment.

• Cross-functional teams align faster—because you show, not just tell.

Radical ownership creates gravitational pull.

Thumb-First Habits of Great PMs

Here’s how top product managers embed this mindset daily:

• Start retros with: “Here’s where I could’ve been clearer.”

• In roadblocks, ask: “What signal did I miss?”

• Write postmortems that highlight your missteps before others’.

• Default to curiosity over criticism.

• When a feature succeeds, lift others. When it fails, start with you.

This doesn’t mean being a martyr.

It means being a multiplier.

Product isn’t a support function. It’s not about running standups, updating Jira, or cheerleading engineers from the sidelines.

I’ve done that. It’s safe. It’s comfortable. But it doesn’t move the needle.

The shift came when I stopped managing the process—and started owning the product.

As Marty Cagan said:

“The job is not about being a facilitator or cheerleader… It’s to work alongside design and engineering every day to solve problems for our customers in ways our customers love, yet work for the business.”

That starts with customer discovery.

Not surveys. Not guesses. Actual conversations.

You need to hear the friction in their voice. See the workarounds they’re hacking together. Sit in the pain long enough to feel what matters. Then you translate that into products that feel obvious in hindsight.

A product manager who’s not in discovery every week, maybe every day, isn’t doing product. They’re doing project coordination.

Every insight compounds. Every conversation sharpens judgment and reveals signals. And when you pair that with the speed of AI tooling—prototypes in minutes, in front of customers fast—you unlock something powerful:

You stop building what you think and hope will work. You start shipping what already does.

I’ve seen teams transform simply by getting closer to their customers. Less guessing. More conviction. Faster cycles. Better product.

If you’re not in the problem with the customer, you won’t be in the solution with the team.

This is the next phase of product. It belongs to the creators.

Not the spectators.

1. Speak to Lead, Not to Be Liked

• Drop uncertain phrases:

  • Stop using “I think…” → Be confident and say, “The best path forward is…”

  • Stop using “I feel like…” → Be confident and say, “Here’s the strategy…”

• Speak with clarity and conviction.

• Own your point of view—you’re in the room for a reason.

2. Remove Emotion, Show Composure

• Emotion clouds judgment and weakens trust.

• In tense moments:

  → Pause. Ask calm, clarifying questions.

  → Stay data- and logic-driven.

3. Communicate with Authority

• Know your purpose in every meeting or conversation.

• Don’t just “show up”—contribute meaningfully.

• Speak with intention:

  “My goal today is to align on X and address Y.”

4. Master Strategic Questions

• You don’t need all the answers—ask better questions:

  → “What’s the biggest challenge you’re facing?”

  → “What data supports this?”

  → “What would it take to prevent this from happening again?”

• Great leaders are great problem untanglers.

5. Stop Oversharing & Over explaining

• Over explaining = insecurity.

• Be concise. Make your point and land the plane.

• Confident communication looks like:

  → Clear statement

  → Graceful delivery

  → Full stop

6. Body Language & Voice

• Sit up straight. Shoulders back. Eye contact.

• Speak with volume—not a whisper.

• Use calm, controlled hand gestures.

7. Be Consistent and Disciplined

• Consistency builds credibility.

• Discipline ensures your tone, messaging, and presence stay aligned—even under pressure.

• Leadership isn’t about one moment—it’s about how you show up over time.

Confident leaders don’t need validation.

They speak to drive outcomes.

Managing software products can be chaos.

Your backlog’s overloaded. A feature’s broken. Customers are loud.

You can fix it all—or you can focus.

The best leaders do the latter.

They let fires burn.

Not out of laziness. Out of discipline.

Because when everything’s urgent, nothing is.

The Discipline of Strategic Neglect

Letting fires burn means choosing to solve the right problem, not every problem.

You’re not paid to keep everything neat.

You’re paid to ship outcomes that move the needle.

Instagram ignored Android. Stripe ignored the support queue.

Fires You Can Let Burn

• Process: Inefficient meetings? Let it ride.

• People: Internal friction? Not all of it needs a fix now.

• Tech: Legacy bugs? Unless it’s blocking users, it can wait.

What Makes a Fire Worth Fighting?

• Will it compound if we solve it?

• Does it unblock critical execution?

• Is it tied to a key business metric?

If not?

Let it burn.

The Real Job

You’re not a firefighter.

You’re a builder.

Your job is to ship the product that makes the fire station obsolete.

Let people get uncomfortable.

Let Slack freak out.

Let process be messy.

If you’re solving the right problem, you’re doing your job.

They focused on leverage, not noise.

“The best founders have a strong sense of which fires are okay to let burn.” — Light Speed Venture Partners

So do the best PMs.

Let it burn.

Build what matters.

Product strategy is one of the most debated — and misunderstood — topics in the world of product leadership. Recently, I’ve been reflecting on the ideas shared by several accomplished product leaders:

• Chandra Janakiraman (CPO at VRChat, ex-Headspace, Meta)

• Todd Olson (CEO of Pendo, author of The Product-Led Organization)

• Marty Cagan (Partner at SVPG, author of Inspired and Empowered)

• Melissa Perri (CEO of Produx Labs, author of Escaping the Build Trap)

Each leader brings a unique perspective on what product strategy is, how to create it, and how to align it with execution. Let’s dive into their viewpoints, compare them, and uncover actionable lessons for today’s product leaders.

1. What is Product Strategy?

Across the board, these leaders agree on one thing: product strategy is not a roadmap of features.

Chandra defines it crisply:

“Product strategy sits between mission & vision and the plan or roadmap. It forces choices about where to invest and what to ignore, so you can generate maximum impact.”

Melissa Perri expands this with her classic definition:

“Product strategy is a system of achievable goals and visions that work together to align the team around outcomes.”

For Melissa, the key word is outcomes, not outputs (features) or tasks. This is aligned with Marty Cagan’s mantra:

“Product leaders do the product strategy. Teams figure out the best way to solve those problems.”

In other words:

• Product leaders articulate the bets (the outcomes, the big problems).

• Product teams figure out the how (the best way to achieve those outcomes).

2. The Role of Leadership: Top-Down, Bottom-Up, or Both?

Here’s where it gets nuanced:

• Marty Cagan:
  Empowerment is not about teams picking what to work on; it’s about leaders making strategic choices, then empowering teams to figure out how to win. He sees this as the antidote to “feature factory” teams — ensuring teams are solving real problems, not just building what’s on the roadmap.

• Melissa Perri:
  She stresses the risk of the “build trap” — where teams become feature factories, cranking out outputs that don’t connect to a real strategy. Her solution? Clear product strategy that prioritizes outcomes over outputs. She says:
  
  “Good product strategy bridges the gap between business goals and customer needs.”

• Todd Olson:
  Adds the dimension of blending product-led growth (PLG) with human-led efforts. His view: product data should inform both self-service experiences and high-touch sales/support engagement.

• Chandra Janakiraman:
  Offers a clear operational approach to building alignment: a 8-12 week, five-phase process that incorporates leadership interviews, working group collaboration, and a final “rollout” phase to align all stakeholders.

Key insight:

While these leaders might use different words, they converge on one idea: strategy must come from the top, but it’s not a mandate for features — it’s a mandate for outcomes. And it must be deeply informed by bottom-up signals (data, customer insights, frontline experimentation).

3. A Repeatable Process: Chandra’s 5 Phases & Melissa’s Strategy Stack

Chandra’s 5-phase process (Preparation → Strategy Sprint → Design Sprint → Document Writing → Rollout) offers a tactical playbook.

Melissa Perri, in Escaping the Build Trap, lays out a complementary framework she calls the Strategy Stack:

1. Vision – The long-term, aspirational future state

2. Product Strategy – The approach to achieve that vision in the medium term

3. Product Initiatives – The big bets or themes (often aligned with Chandra’s “strategic pillars”)

4. Product Roadmap – The features and milestones that bring those initiatives to life

5. Execution – The day-to-day build/learn/iterate cycle

Melissa’s stack emphasizes that product strategy is not the roadmap — it’s the layer above the roadmap. This is a perfect match to Chandra’s insistence that strategy is about “what not to focus on” as much as what to invest in.

4. The Role of Data: Todd Olson’s Product-Led Expansion

Todd Olson’s insights highlight the power of data to inform and refine product strategy continuously. In his talk, he shares how:

• Product data identifies your “aha” moments for onboarding.

• Usage patterns can identify “happiness markers” for retention.

• Product-qualified leads (PQLs) can supercharge sales efforts.

• Trials and in-product engagement inform future bets.

Melissa Perri reinforces this idea. She argues that data is essential to avoid the build trap. As she puts it:

“Without good data, you’re just guessing. You’re not making strategic choices; you’re gambling.”

Together, these views underscore that the best product strategies are living documents. They evolve with continuous feedback from customers, usage analytics, and market shifts.

5. Small “s” vs. Big “S” Strategy: Present-Forward and Future-Backward

Chandra’s distinction between:

• Small “s” strategy – Near-term, problem-focused, 2-year horizon

• Big “S” strategy – Long-term, aspirational, 5-10 year horizon

… echoes Melissa’s “vision” vs. “product strategy” layers. She notes that many teams confuse the vision (the big inspiring future) with the near-term product strategy (the best bets for now). Both are crucial, but they serve different roles.

Marty, too, highlights that good product leaders must balance short-term execution with long-term vision — otherwise, they risk either stagnation or pie-in-the-sky thinking.

6. Bringing it All Together: The Unified View

Here’s the synthesis of these leaders’ perspectives:

7. Key Takeaways for Product Leaders

1. Product strategy is a set of choices — not a roadmap. It’s about where to focus (and where not to).

2. It must be informed by data, but driven by leadership. Bottom-up signals are crucial, but they don’t replace top-down strategic thinking.

3. Empowerment = leaders set the bets, teams figure out the how. This avoids feature factories and creates truly empowered teams.

4. Avoid the build trap. As Melissa says, “Focus on outcomes, not outputs.”

5. Blend human and product-led motions. As Todd emphasizes, even in PLG, humans play a key role.

6. Think in both short and long-term. Big “S” vision fuels ambition; small “s” strategy makes it real.

The Craft of Strategy

Building great products isn’t just about shipping features — it’s about making clear, data-informed, customer-centered choices. It’s about uniting the top-down and bottom-up to find the sweet spot of alignment.

As these leaders show us, there’s no one “perfect” way to craft product strategy — but there is a common thread:

Clarity. Alignment. Outcomes.

If we can get that right, we’re well on our way to escaping the build trap, driving real impact, and building products that matter.

Research inspired by:

How to create a winning product strategy | Melissa Perri

Marty Cagan, SVPG - Product Discovery, Product Strategy & Empowered Product Teams - Product Faculty

An operator’s guide to product strategy | Chandra Janakiraman (CPO at VRChat, ex-Meta, Headspace, Zynga)

In the rapidly evolving world of product development and engineering, new AI-powered tools like Cursor, Windsurf, Replit, and Lovable.dev are transforming how ideas become reality. These platforms aren’t just boosting productivity—they’re redefining how products are built, who can build them, and what it means to scale in the modern era. Their stories highlight both the promise and the challenges of the next wave of software creation.

Synthesis of Key Insights

Across these conversations, a few central themes stand out:

• Empowering Builders at All Levels
  
  Whether it’s Cursor refining how engineers interact with AI or Lovable.dev making it possible for anyone—regardless of coding skills—to build apps, these tools democratize the creation of software.
  

• Engineering Meets Product in Unexpected Ways
  
  As Anton from Lovable.dev observed:
  
  “Doing a bit of everything—being a generalist—is much more important than it used to be.”
  
  Success today requires hybrid skills that blend design, product intuition, and technical depth.
  

• Simplicity and Scale
  
  Each platform aims to make once-complex tasks simple. Cursor’s team described their goal as:
  
  “Making coding a conversation, not a battle.”
  
  Likewise, Replit’s intuitive environment shows how reducing friction opens doors for experimentation and rapid iteration.
  

• Battle-Tested in the Real World
  
  These aren’t just shiny demos. Replit has helped companies like Sears Home Services leapfrog from COBOL to AI-powered route optimization, while Windsurf emerged from real-world agent workflows.

Common Themes

Differences in Approach or Perspective

Standout Insights

Cursor

“Cursor is about turning coding into a conversation, making complex tasks feel like natural chat.”

Windsurf

“We didn’t start as a dev tool—we started by solving real-world agent workflow problems at scale.”

Replit

“Replit’s edge is empowering even non-technical teams to skip generations of legacy software.”

Lovable.dev

“We want to be the last piece of software anyone writes—removing the bottleneck of finding engineers.”

Comparative Analysis

A central tension runs through these conversations: empowering non-technical creators versus maintaining engineering rigor. Anton from Lovable.dev declared in this episode:

“We’re building for the 99% who don’t write code.”

That’s a bold vision—democratizing product creation in a way that resonates with Replit’s approach, where even Sears Home Services leapt from COBOL to Replit-based AI.

Yet, as Cursor’s founder noted in their episode:

“You want to balance the team so that the peaks of one are the valleys of another.”

This reveals the need for hybrid product and engineering cultures—pairing generalists with deep specialists to create balanced, high-impact teams.

Stories of Origin

What unites these platforms is their roots in scratching their own itches:

• Lovable.dev was born when Anton realized that LLMs could finally build products with near-human skill, unlocking opportunities for millions of non-coders.

• Cursor emerged from frustration with rigid IDE workflows—transforming them into conversational, AI-assisted experiences.

• Replit started as a way to bring coding to everyone—students, hobbyists, and even 100-year-old businesses.

• Windsurf didn’t even start as a dev tool at all; it was built to manage real-world agents in complex business scenarios.

Nuanced Examples

• Sears Home Services and Replit: Sears leapfrogged entire generations of software by moving from COBOL to AI-powered tools in Replit—showcasing how these tools empower non-technical teams to move fast and thrive.

• Anton’s Hiring Philosophy at Lovable.dev: He looks for those who “care a lot and have a superpower.” Their final interview is a work simulation—a powerful reminder that capability today is as much about attitude and curiosity as it is about code.

Actionable Recommendations

For product leaders and decision-makers, here’s what these insights mean:

Embrace AI as a Co-Builder

These tools show that AI isn’t a replacement for humans—it’s a powerful partner. Learn to articulate your product ideas clearly, and AI will help you build faster and better.

Prioritize Speed and Iteration

These platforms thrive on rapid experimentation. Product teams that launch fast and refine even faster will outpace those stuck in traditional roadmaps.

Hire for Product and Technical Hybrid Skills

As Anton suggests, “doing a bit of everything” is the new norm. Balance your team with people who can think like product managers, engineers, and designers all at once.

Test in Real-World Scenarios

Like Lovable.dev’s work simulation hiring approach, prioritize practical tests over resumes. See how candidates handle real, messy product-building challenges.

Stay Curious and Experiment Constantly

Anton’s final advice: spend a week with a new tool, build something end-to-end, and you’ll quickly jump into the top 1% of AI-enabled builders.

For more insights, listen to the full conversations:

🎧 Lovable.dev’s interview with Anton

🎧 Cursor’s story of turning coding into conversations

🎧 Replit’s story of skipping generations of software

🎧 Windsurf’s unique agent-based workflows

Cut Through the Noise

Every meeting, every deck, every pitch—someone’s tossing out AI jargon like it’s candy. “Transformer,” “RAG,” “RLHF,” “context window”—and half the room is nodding like they get it. But here’s the truth: most don’t. And that’s fine. This article is your no-BS guide to the 20 AI terms you need to understand to lead well, stay competitive, and make confident decisions.

No fluff. No techno wizardry. Just real talk from one builder to another.

The Foundation (Understand These First)

1. AI Model

Think of it like a brain. You feed it examples. It learns patterns. It gives you answers. That’s the core of every AI tool you use today.

2. Large Language Model (LLM)

These are the chatbots—like ChatGPT and Claude—that read and write like a human. Most are now “multimodal” (they handle images, voice, etc.).

3. Transformer

The reason AI got smart fast. Transformers let models “see” all the words in a sentence at once, like scanning a whole paragraph instantly instead of word-by-word.

How AI Learns (So You Can Build With It)

4. Training / Pre-Training

The model consumes massive amounts of data—text, books, websites—and learns to predict the next word. That’s how it builds its “understanding.”

5. Supervised vs. Self-Supervised Learning

• Supervised: Humans label the data (e.g., “this is spam”).

• Self-Supervised: The model learns by hiding words and then guessing them. Most LLMs use this.

6. Unsupervised Learning

The model explores unlabeled data and finds patterns. Useful for clustering, topic modeling, and anomaly detection.

Fine-Tuning and Aligning AI (What Makes AI Useful)

7. Fine-Tuning

After the big model is trained, you can specialize it for a job (like customer service or medical support) by feeding it domain-specific data.

8. Reinforcement Learning from Human Feedback (RLHF)

Humans rate answers → model learns what humans prefer → gets better at giving aligned, helpful responses. This is how ChatGPT got “polite.”

Using the Model (What Happens at Runtime)

9. Inference

When you type a prompt and get a reply? That’s inference. The model is “running.”

10. Prompt Engineering

The art of asking better questions.

• Conversational prompts: You asking ChatGPT.

• System prompts: Developers giving behind-the-scenes instructions.

11. Retrieval-Augmented Generation (RAG)

Gives models access to external information (such as your company’s documents or knowledge base). Think “open-book test” for AI.

Building With AI (Where It’s Going)

12. Model Context Protocol (MCP)

An open standard that enables models to perform tasks, such as booking meetings, updating Salesforce, or sending a Slack message. Game changer for tool integrations.

Recap & Framework for Product Leaders

Let’s simplify:

• Model: The brain that powers AI.

• LLM: Your text-savvy assistant.

• Transformer: What made AI actually work.

• Pre-training: General knowledge.

• Fine-tuning: Specialization.

• “RLHF": Human alignment.

• Prompt Engineering: User interface for AI.

• RAG: Gives the model context it wasn’t trained on.

• MCP: Connects AI to real tools.

• Inference: When the model actually runs.

Don’t Get Blinded by the Buzzwords

The future isn’t about sounding smart—it’s about leading with clarity. You don’t need a PhD in machine learning. But if you’re building software, leading teams, or making tech bets, you need to actually understand what’s happening behind the curtain.

When you understand the terms, you can:

• Make sharper investment calls.

• Ask better product questions.

• Call BS when someone’s trying to sell hype instead of substance.

Lead with confidence in a world where AI isn’t going away.

Stay sharp. Build well. Think 10X.

We’re at the dawn of a new era in software engineering and product development, one where artificial intelligence isn’t just a tool—it’s a collaborator, a co-pilot, and even a creative partner. Recent conversations with leaders from Anthropic and Cursor reveal a world where 90% of code is already AI-generated, where product strategies evolve in real-time alongside AI insights, and where the very idea of software engineering is being reinvented.

In this deep dive, we’ll synthesize key insights, highlight common themes, explore differences in perspective, and extract actionable lessons for product leaders, decision-makers, and professionals seeking to stay ahead in this rapidly shifting landscape. These insights are drawn from two rich podcast discussions:

• Overview 1: A conversation between Lenny and Mike Krieger, Chief Product Officer at Anthropic, on the future of AI-driven software development. Listen here.

• Overview 2: A roundtable between Lenny and the founders and engineers at Cursor, exploring how they’re using AI to build AI-first developer tools. Listen here.

Let’s start by surfacing the common ground and the unique vantage points that these two organizations bring to the conversation.

Key Insights:

Across both discussions, a few core insights shine through:

• AI as a Creative Collaborator: AI has evolved from a tool that simply assists with repetitive tasks to a collaborator that can generate novel ideas and challenge human assumptions. As Mike Krieger puts it, “Opus 4 really went out for a while and came back with a new angle that I hadn’t seen before.” Podcast Link.

• The Bottleneck Shifts: With AI generating the majority of code, the bottlenecks in product development have shifted. It’s no longer about writing the code—it’s about defining the right problems to solve and aligning teams around those solutions.

• Strategy Matters More Than Ever: As AI levels the playing field for code generation, what sets companies apart is strategic clarity and the ability to ask the right questions.

• Human Agency and Independent Thought: Both Anthropic and Cursor emphasize that while AI can do much of the heavy lifting, the spark of human curiosity, creativity, and critical thinking remains irreplaceable.

To bring these insights to life, here’s a narrative that emerged during the conversations:

Mike Krieger recounted a morning ritual with his six-year-old daughter. She insisted that coral is alive, and even when faced with Claude’s authoritative answer, she held her ground. “You can ask Claude, but I know I’m right,” she said. This simple breakfast-table exchange captures a profound truth: AI may know a lot, but independent thinking and curiosity are the engines of human progress. Podcast Link.

Table 1: Common Themes

Table 2: Differences in Approach

Table 3: Unique Insights

Comparative Analysis:

One of the most striking alignments across these conversations is the recognition that AI isn’t just a tool—it’s a new kind of collaborator. At Anthropic, Claude isn’t just producing code—it’s helping shape product strategy. Mike Krieger’s moment of epiphany came when Claude offered “a new angle that I hadn’t seen before,” marking a leap in AI’s capacity for independent thought. At Cursor, the same spirit of partnership drives their work. Their background agents—tiny autonomous coders—spin up pull requests in the background, suggesting changes and then letting human engineers take the wheel to finalize the work.

Yet, this partnership isn’t without friction. Cursor’s team described the challenge of verifying AI-generated code, especially in massive enterprise codebases where context and domain-specific knowledge matter. It’s not enough for AI to pass a test—it has to match the tacit understanding of a team’s coding culture. Anthropic sees a similar challenge: while Claude can propose novel strategies, aligning these with the human “why” and product vision remains essential.

This dance between human judgment and AI suggestion is where the most powerful insights lie. Anthropic’s narrative underscores the importance of independent thought, even for children growing up with AI as a constant companion. Cursor’s engineers echo this: despite AI’s transformative speed, the best engineers are those who can “tastefully” guide AI’s contributions, ensuring that the resulting code is not just correct, but elegant.

Surprising moments of convergence emerge when both organizations discuss taste. Anthropic’s CPO, a self-professed believer in the power of taste and UX, sees taste as a form of strategy—a way to decide “how we win and where we play.” Cursor’s engineers view taste as crucial in preventing AI from overwhelming the codebase with messy, hard-to-maintain solutions. In a world where anyone can write software, taste becomes the final frontier of differentiation.

Another surprising alignment: both Anthropic and Cursor are deeply invested in nurturing curiosity, especially for the next generation. Mike Krieger’s story of his daughter’s breakfast-table defiance is mirrored by Cursor’s belief that AI accelerates the learning loop, enabling junior engineers to build more and learn faster. Far from replacing curiosity, AI seems to amplify it—if we let it.

Conclusion and Actionable Recommendations:

As these conversations reveal, we’re entering a world where AI writes most of the code, but the soul of great products still comes from human judgment, taste, and strategy. Here’s what this means for you:

Embrace AI as a collaborator, not just a tool. Use AI to challenge your assumptions and generate new ideas. Let it take care of the repetitive work so you can focus on the “why” and “what next.”

Invest in taste and independent thinking. In a world where anyone can generate code, your ability to curate, refine, and align will set you apart.

Build AI into your workflows early. Like Anthropic’s PMs and Cursor’s engineers, don’t wait for perfection—experiment with how AI can accelerate ideation and prototyping today.

Design for verification and human alignment. Don’t just trust the AI’s output—ensure your processes allow for critical human judgment and alignment with your team’s values and vision.

Stay curious and teach curiosity. Whether you’re leading a team or raising the next generation, encourage the questioning mindset that can thrive alongside AI.

Look for differentiated opportunities. As both Anthropic and Cursor highlight, specialized knowledge, unique go-to-market strategies, and a deep understanding of your users’ needs are more defensible than ever in this new landscape.

Final Words:

AI is rewriting the script for how we build software—and how we build companies. But as these conversations show, the most powerful products will still be those that reflect a uniquely human vision. So ask better questions. Nurture your taste. And never lose sight of the quiet moments—the early morning conversations over breakfast, the late-night Slack debates, the subtle ways that software shapes our lives.

Because in the end, even in a world of infinite AI capabilities, it’s the human touch that will always make the difference.

AI tools are reshaping how we build products, but how far can they really go? As a product leader, I’ve been thinking a lot about whether AI-generated prototypes can seamlessly transition into production-ready features. Can PMs and designers really bypass engineers and push features live with AI? Let’s dig in.

AI Can Prototype, But Can It Ship?

AI-driven prototyping tools—like Lovable, Cursor, and Replit—are game changers for product managers and designers. They help visualize ideas, generate code, and even build functional MVPs. But can those outputs go straight into production? Not really.

1️⃣ How Transferable Is AI-Generated Code?

It depends. Some tools generate high-quality code, but it still requires engineering intervention to clean up, ensure scalability, and integrate properly. Think of AI as an accelerator, not a replacement—it gets you 50-80% of the way there, but devs still need to refine the rest.

For example, AI-generated UI components might not align with your design system, and backend logic might lack security and performance optimizations. If your goal is a working prototype, AI delivers. If you need production-grade software? Engineers are still essential.

2️⃣ Can PMs & Designers Prototype Without Engineers?

Yes—at least in the early stages. AI allows non-technical teams to build low-code/no-code prototypes, get user feedback, and validate ideas before committing engineering resources. That’s a massive advantage.

Imagine you’re a PM at a startup. You have an idea for a new feature. Instead of waiting weeks for a sprint to free up, you spin up an interactive prototype in Lovable or Replit and get user feedback immediately. No dev hours wasted.

But does that mean PMs can ship features without engineers? Not at scale. The moment you need custom logic, security, integrations, or performance optimizations, developers need to step in.

🚀 Where Are We Headed?

We’re moving towards a future where:

✅ PMs and designers can prototype and validate ideas faster than ever.

✅ AI speeds up development but still requires human oversight.

✅ Engineers focus more on complex, high-value work rather than basic scaffolding.

AI isn’t replacing developers—it’s shifting their role. Instead of writing every line from scratch, they’re reviewing, refining, and optimizing AI-generated outputs.

💡 My Takeaway

If you’re a PM or founder, AI tools can help you ship prototypes at lightning speed, test ideas with users, and make smarter product bets. But to build scalable, production-ready features, you’ll still need engineering expertise.

I even tried Lovable myself to build a simple game—and the results were pretty amazing. AI helped me get a working prototype in minutes, but turning it into a polished product? That still required iteration and refinement.

🔹 What do you think? Will AI replace traditional prototyping and dev work, or is it just a fancy shortcut? Drop a comment—I’d love to hear your thoughts!

Setting an Impactful Product Strategy for B2B SaaS

Building a great B2B SaaS product isn’t just about shipping features—it’s about delivering impact. A solid product strategy clarifies who we serve, where we won’t waste time, and what core initiatives drive real outcomes. Here’s how to approach it in a way that moves the needle.

1. Nail the Ideal Customer Profile (ICP)

If you’re building for everyone, you’re building for no one. An effective strategy starts with defining your ICP—not just by industry or company size, but by specific pain points and behaviors. Your best customers share common characteristics:

• Problem awareness – They actively feel the pain your product solves.

• Buying power – They have the budget and authority to make decisions.

• Adoption readiness – They are equipped to implement and integrate your solution.

By locking in on this group, you filter out distractions and focus your efforts on delivering maximum value where it matters most.

2. Be Clear on Where You Don’t Play

Just as important as knowing your ICP is knowing who you don’t serve. This is where discipline comes in.

• Are you chasing SMBs when your strength is mid-market and enterprise?

• Are you considering integrations that stretch your core value prop too thin?

• Are you letting a few loud customers pull you into niche features that don’t scale?

Great products die by a thousand cuts when they try to be everything to everyone. Draw your lines early and stay focused.

3. Define the Core Initiatives

Once your ICP is clear, you need a set of initiatives that drive impact for them. These initiatives should tie directly to customer outcomes and business goals. Typically, they fall into a few buckets:

• Simplify the experience – Reduce friction in workflows, improve UX, and remove bloat.

• Expand the core – Strengthen your primary offering with features that deepen engagement.

• Drive outcomes – Focus on capabilities that directly impact customer success metrics.

• Leverage AI & automation – Use AI to streamline admin work, enhance analytics, and drive insights at scale.

Each initiative should have a clear why behind it. If you can’t articulate the direct impact, it’s probably not worth pursuing.

4. Set Goals That Drive Impact, Not Just Features

Many teams fall into the trap of measuring progress by feature releases. Instead, set goals that focus on outcomes:

• Customer activation rates – How quickly are new users getting to value?

• Feature adoption – Are key features being used in a way that drives results?

• Retention & expansion – Is your product sticky enough that customers grow with it?

When teams know they’re responsible for impact—not just output—they make better decisions. Features become a means to an end, not the end itself.

Final Thoughts

A strong product strategy requires discipline. Define your ICP, be clear about what you won’t do, align around core initiatives, and set goals that drive real outcomes. Do this well, and your team will focus on what truly matters—creating impact, not just shipping software.

Leading a product team is one of the most rewarding challenges in business. Over the years, I’ve seen what makes teams thrive and what makes them freeze. The best product teams I’ve led had a few key ingredients: empowerment, access to data, a strategy that connects to company goals, clear ownership, and continuous communication. But beyond all of that, the most impactful teams thrived because of culture—a culture where there was no fear of messing up, where they could be themselves in front of any leader, and where they felt encouraged to keep pushing forward.

The worst experiences I’ve seen? When teams were stuck in fear. When every decision felt like a trap. When they were more worried about getting in trouble than about solving problems. Fear is a culture killer, and when fear runs a product team, progress stops. People stop taking risks. They start waiting for permission instead of taking initiative. They play defense instead of offense. And that’s when innovation dies.

So how do you build a product team that thrives instead of one that’s paralyzed by fear? Here’s what I’ve learned:

Empowerment: Let Them Own It

Great product teams need to feel like they own their work. They need the space to make decisions, take risks, and know that they won’t be punished for experimenting. The best teams I’ve led knew they had my trust. They didn’t need to ask for permission every step of the way. They knew the mission, and they had the freedom to execute.

Access to Data: Fuel for Better Decisions

Nothing slows a team down like flying blind. Product teams need real-time access to data so they can make informed decisions, test their hypotheses, and iterate quickly. I’ve seen teams transform simply by getting the right data in front of them. Suddenly, they aren’t guessing—they’re acting with confidence.

Strategy That Connects to Company Goals

A team without direction is a team that’s lost. The most successful teams understand exactly how their work connects to the broader company strategy. When they can see the bigger picture, their decisions become sharper, and their work becomes more meaningful. That connection to a larger purpose is a game-changer.

Clear Ownership: No Gray Areas

One of the most frustrating experiences for any product team is a lack of clarity around ownership. Who’s responsible for what? Where does one person’s work end and another’s begin? When ownership is clear, accountability is clear. When it’s not, everything slows down. The best teams I’ve led had well-defined roles, and because of that, they moved fast and worked well together.

Continuous Communication and Encouragement

Product work is a grind. Some days, it feels like pushing a boulder uphill. That’s why continuous communication and encouragement are essential. Regular check-ins, transparent conversations, and simple encouragement go a long way. The best teams I’ve worked with knew that I had their backs. They knew that even when things got tough, we’d figure it out together.

Culture: The Secret Weapon

At the end of the day, culture is what makes or breaks a product team. A culture where people feel safe to speak up, try new things, and fail without fear is a culture where innovation thrives. I’ve seen teams go from average to exceptional simply because the culture shifted. They stopped being afraid. They started trusting each other. And that’s when the magic happened.

If you’re leading a product team, ask yourself: Are they moving forward with confidence, or are they stuck in fear? Are they empowered, or are they waiting for permission? The most impactful way to lead product teams isn’t just about processes and frameworks—it’s about creating an environment where people can do their best work. When you get that right, the results take care of themselves.

I didn’t start with a roadmap. I wasn’t a product expert with years of experience. I was a 22-year-old college grad with an entrepreneurial mindset and a strong desire to solve problems. That mindset took me from an entry-level job at a startup, which was later sold for $110M. Then, I led product at a late-stage unicorn, driving growth with data. Now, I’m the Chief Product Officer at OnBoard, where I simplify governance software and use AI to build valuable features for boards and directors.

Every step in my journey has influenced how I build products. I have moved from startup chaos to enterprise discipline, then to late-stage scale. Here’s what I’ve learned along the way.

1. The First Break: One Email Changed Everything

At 22, I didn’t know what product management was. My only tech experience was building websites for small businesses. But I knew I wanted to be part of something new—something fast-moving and entrepreneurial.

I cold-emailed people in the industry, trying to break in. One email resulted in a lunch meeting, introducing me to an investor. Then, I received an offer to join Jobs2Web as the fourth employee.

That was my first lesson: opportunities don’t happen; you must create them.

2. Startup Hustle: Learning Product by Doing Everything

When I joined Jobs2Web, we didn’t have product-market fit yet. We were a job search engine, not a real platform. I had no set role, so I did it all. I worked on marketing, analytics, product, and customer support. I even built our first website.

We found our niche: helping companies like Best Buy and Microsoft attract and hire talent online. Once we hit product-market fit, growth exploded.

One of our co-founders once said: “This young guy figures things out and moves things forward.” That stuck with me. In the early stages of a company, your job is not about titles—it’s about solving problems and executing.

3. The $110M Acquisition and a Crash Course in Enterprise Software

By 2011, we had over 100 enterprise customers, and SuccessFactors acquired us for $110M. Weeks later, SAP bought SuccessFactors for $3.4B. In a few weeks, I was at one of the biggest software companies in the world.

At SAP, I learned the fundamentals of enterprise product management.

• Roadmaps matter. You can’t build features without careful planning; you need structured, multi-year plans.

• Enterprise customers demand scale. Every feature must integrate without any disruption to legacy systems.

• Execution beats vision. A great idea is worthless if you can’t operationalize it at scale.

One of my biggest mistakes at SAP? Not prioritizing integrations early enough. That mistake haunted us for years, reinforcing a core lesson: Do things right the first time. If something is foundational, don’t cut corners.

4. The Unicorn Stage: Leveraging Data to Drive Product Decisions

After SAP, I joined a late-stage unicorn, where I saw firsthand how data and metrics drive product at scale. This marked a change from my startup days. In those times, we often made decisions based on instinct vs. real data.

At scale, data became the most powerful tool for growth.

• Product Usage Metrics: We tracked user data in real-time. This helped us see which features were important. We used this info to improve adoption and optimize our product.

• Customer Segmentation: We identified key users and improved features to increase engagement and encourage repeat visits.

• AI and Predictive Analytics: We built intelligent product experiences, predicting user behavior and automating workflows.

This approach transformed how we built products. Instead of rolling out random features, we built based on what the data told us would move the needle.

5. Leading OnBoard: Simplicity, AI, and the Future of Governance Software

Now, as Chief Product Officer at OnBoard, I’m applying all these lessons to a private equity-backed company serving thousands of boards and directors worldwide.

6. Key Lessons for Founders and Product Leaders

Looking back, my journey wasn’t all about luck—it was about taking action, learning quickly, and driving execution. Here are the lessons that stand out:

1. Take Initiative—Opportunities Don’t Just Show Up

That first cold email changed my career. One introduction can open doors you never expected.

2. In Startups, Titles Don’t Matter—Execution Does

In early-stage companies, your job is to move things forward—whatever that takes.

3. Prioritize the Right Foundation—Don’t Cut Corners

Technical debt and poor integrations will slow you down later. Get it right from the start.

4. Leverage Data—Don’t Just Guess

Your gut is great for early-stage decisions, but at scale, data must drive product choices.

5. Looking Ahead: Building for the Next Era

My journey started with a cold email and led to creating products for global companies. This has strengthened one key belief:

Step up and try; then move things forward.

No matter if you’re new to product management, growing a company, or leading a big product team, the main point is clear: Take action. Learn fast. Solve real problems. And keep pushing forward.