Being AI-native isn’t about speed. It’s about direction.

Speed was never the bottleneck. Direction was. AI made shipping cheap, and the real bottleneck became obvious: most teams now ship the wrong things, faster.

Two years ago I wrote a guide on structuring product and growth teams. The principles held up. The ratios broke. The PM role compressed around the one thing AI can’t do for you: alignment.

Here’s the refresh.

The cast

Two roles do most of the work in a product-led team:

Product Manager (PM). Owns what the team builds and why. They connect what gets shipped to the business: the business case, the altitude map (a cascade of metrics from company outcomes down to the team’s daily work), qualitative and quantitative research, and the go-to-market plan. The PM is the person who answers: is this worth building, and how will we know?

Engineering Manager (EM). Owns how the team ships. They lead the engineers technically and as people: hiring, coaching, sprint cadence, technical health, removing blockers. Throughout this piece I mean the internal EM, the one who sits inside the team alongside the engineers, not one managing from outside across multiple teams. The EM is the person who answers: are we building this well, and can we sustain the pace?

Those two, plus 2-3 engineers and sometimes a designer, are the team. Everything that follows is about how their scope and ratios changed.

1. Smaller. EMs smaller still.

I used to recommend product teams of fewer than seven people. That’s now too big.

The new shape: 4-5 people total, including the PM. Three to four engineers, one PM, sometimes a designer. That’s the unit. Operators and investors looking at AI-first companies are landing on the same number.

The engineering manager scope dropped harder. I used to say an internal EM could handle 3-4 engineers. The new working number is 1-2, with rare exceptions at 3. Above that, the EM regresses into pure people management and loses the technical context they need to balance tech debt against product urgency.

The whole point of embedding the EM in the team was to keep that balance live. You can’t keep it live across 5 engineers.

Why:

• Specialist profiles got more senior. Fewer people, each doing higher-leverage work.

• Shipping more means reiterating more. Tight teams iterate faster than wide ones. The loop between ship and learn matters more than the act of shipping itself.

Bigger teams don’t fix this anymore. They amplify it.

2. PM ratios split by measurability.

I used to recommend one PM per team. That’s now too dense for some teams and not dense enough for others.

The split depends on one question: how easy is it to measure whether the team’s output is good?

For commercial product work, UI features, conversion flows, anything where you can run an A/B test and read the result, one PM can cover roughly eight engineers across two teams. Quality is verifiable. Metrics close the loop. The PM is needed for direction, not babysitting.

For core AI behavior, model outputs, prompts, agent reliability, anything where “is this good?” doesn’t compress into a single number, you need one PM or TPM (technical product manager, a PM with deep engineering fluency) per two engineers. Quality is the work. You cannot offload it to a dashboard.

The harder it is to measure quality, the more PM bandwidth per engineer you need.

One exception. A junior PM can sit dedicated to a single team while a principal or staff PM spans both teams as their coach. Treat it as a time-bound training overlay, not the steady state. The thesis here is concentration, not headcount.

3. Prototypes replace specs. PMs compress around alignment.

The product requirements document (PRD) used to be how a PM communicated the build to engineers. PMs wrote PRDs, engineers turned them into code. The handoff was the artifact.

That’s over. Prototypes replaced specs, and they’re built collaboratively now, in two phases:

1. The PM prototypes the idea first, with the team. A visualization of what came out of customer conversations, or what customers reacted positively to. Rough, fast, throwaway-grade. AI prototyping tools let a PM build the first version without needing an engineer to start.

2. Engineers deepen it. They add functionality, surface technical implications, push it to where the team can see what’s actually being committed to.

These are primary focuses, not silos. Separating meaning from team members is dangerous. A PM who doesn’t know what’s technically possible will prototype things that can’t ship. Engineers cut off from the why will build the wrong thing, faster. The whole reason teams got smaller is to make this kind of separation harder.

The exercise has way less overhead than the PRD-to-code handoff. Two artifacts collapsed into one collaborative thing.

But prototypes only solve the spec part of the PM job. They don’t solve alignment: the prior question of which thing to build, which trade-offs the team will live with, which metric defines success, which users we’re choosing to disappoint. A prototype shows the what. It doesn’t tell you why this and not something else.

So the PM role compresses around alignment. Less time writing specs. More time talking to customers, sitting with executives to surface the real strategic question, running experiments that resolve the ambiguity. The deliverable changes from documents to decisions.

But the alignment that matters most isn’t even up-down to leadership. It’s sideways. Across marketing, sales, growth, and product. Without a PM actively connecting those functions into one story, they only talk to each other when they need something.

Marketing pulls product in only when they need a feature for a launch. Sales pings product only when a deal is on the line. The story fragments and guess who feels it: the customer.

This is where good commercial PMs earn their seat. They hold the whole arc. From how the thing gets discovered (marketing), to how users adopt it (growth), to how it gets sold (sales), to how it gets built. They walk the org sideways before the org realizes it needs to.

This is the part AI cannot do for you. Not because AI is bad at it. Because alignment is about reconciling competing humans, and AI doesn’t have skin in the game.

4. PM comp matches engineer comp.

Pay your PMs like you pay your engineers. Same bands, same levels.

Why: the role got harder, not easier. With fewer PMs covering more surface, each one needs to be unusually strong. Vision. Qualitative judgment. Quantitative literacy. The instinct to know when to be data-informed (data shapes the decision but doesn’t make it) and when to be data-driven (the data dictates the call). Most PMs do one or the other badly. The new bar is doing both fluently.

Keep PM bands a tier below engineering and you signal that PM is supporting work. It isn’t anymore. The PM determines whether the team builds the right thing.

The bottleneck moved from shipping to direction. Pay the people who own direction like the bottleneck they are.

5. Growth profile is mandatory now, for PMs and engineers.

I only hire PMs and engineers with a growth profile now. That used to be optional. It isn’t anymore.

A growth profile means the person owns four things, in addition to whatever their nominal job is.

This doesn’t mean engineers become marketers or PMs become salespeople. The bar is intuitive understanding, enough to ask the right questions when something matters. Specialists still exist; they just can’t be the only ones thinking about these things:

• Marketability. Can the thing we’re building actually be sold? Does it have a hook the marketing team can use, a story the sales team can tell? Building a beautiful product nobody can communicate is a way to lose quietly. Growth-profile engineers don’t just ask “does this work?” They ask “is there a story here?”

• Distribution-awareness. Distribution is no longer a problem you hand off. It’s an input to what you build. If a feature has no path to reach the user who needs it, building it is a waste. Growth-profile PMs scope ideas with the distribution channel in view from day one. They kill features that only work if marketing performs heroics.

• Optimal friction. Especially with AI in the mix. The question used to be “do you want this tool?” Now it’s “do you want a tool that fits into your existing workflow with this much friction?” Optimal friction means the lowest possible cost of adoption inside the customer’s actual environment. Most products lose here without realizing it.

• Attention budget. Inside any product, multiple teams compete for the same finite resource: the customer’s attention. UX research wants to recruit them for an interview. One team wants to send an NPS survey. Another wants to onboard them into a new feature. Marketing wants to push a release. Each is locally rational. Stacked together, they’re death by a thousand cuts. Marketers don’t own the total attention demand. PMs traditionally don’t either. Growth-profile people do. They notice when the org is collectively shouting at the customer and step in to coordinate.

Without a growth profile in the room, the team optimizes for what it can measure (shipped features) and ignores what it can’t (the customer’s experience as a whole).

6. What stayed.

Most of the 2024 framework held up. The principles below are unchanged:

• Internal EM, embedded in the team. Engineering managers should still sit inside the team, owning hiring, coaching, technical health, and delivery cadence. The scope dropped (1-2 engineers, not 3-4), but the principle is the same.

• Insourced specialists. Data scientists, UX researchers, and other specialists shouldn’t sit in a separate service team. Pull them into the product team for the duration of a project, return them to a central pool. Outsourcing this kind of skill creates the service center mentality: specialists with no business context, PMs explaining from scratch, endless back-and-forth that costs more than just hiring in.

• Business casing inside the team. PMs own the case for what they’re building. Not the CEO. Not strategy. If a PM can’t connect their feature to revenue, they shouldn’t be building it.

• Altitude maps. Cascading metrics from company outcomes down to team-level work. Still the cleanest way to translate between leadership language and team language.

• GTM planning by PMs. Product teams own how the thing gets sold. They don’t outsource that question to whoever happens to be in marketing.

• Kill the service center mentality. The spine of the 2024 guide. Still right. Outsourcing a function that should sit in the team always costs more than it saves.

AI-native teams don’t ship more. They ship the right things, with less wasted attention.

That’s harder, not easier. Fewer people, more senior, costs more per head.

If you’re racing to ship faster with AI, you’re optimizing yesterday’s bottleneck. The new one is direction. Build the team for that.

I wrote the original framework two years ago. The principles in it still hold; the ratios in this piece are the update. Read the 2024 guide.

Thank you and credit goes to Mike Pilawski for reflections and feedback on Eval focussed teams.

Broad software indices down ~25% from 12-month highs. The median public SaaS valuation multiple: 18.6× revenue in 2021, 5.1× at the end of 2025. That’s 73% compression, while most of the underlying b…

Read more

A PM presented a report showing a significant traffic spike in a specific period. The numbers were pulled correctly. The charts looked clean. The analysis was thorough.

I asked one question: did you check whether that date range includes the weeks we had a bot network scraping our sites?

They h…

Read more

I was seven. Maybe eight.

My dad had a Commodore 64, where I occasionally played games on, and a book about QBasic, a computer language, on the shelf.
I don’t know why he had that book, and I’ll never get to ask him anymore, but I did pick it up one day.

And typed the first line in the book and hit…

Read more

My take was simple: no. LLMs match semantic patterns. They don’t simulate intent. …

Read more

Anyways…

The title of the paper is:

“LLMs Reproduce Human Purchase Intent via Semantic Similarity Elicitation of Likert Ratings”

or, in simpler words, including an AI em …

Read more

Do you, a B2B SaaS product, want to sponsor this spot so it’s free forever and get your message out? Drop us a line for the Mediakit: sponsoring@productea.io

One of the hardest concepts as a product manager is to step out of this notion to ship products and to be “commercial” or more “strategic”.

I heard this phrase directed to me as well a couple of times, and I never really knew what it meant or how to achieve these expectations from my higher-ups.

I’ve developed over the years my own methods in how to deal with it and use this framework more or less the same in coaching and when I set expectations towards my product managers and their teams.

The first step is to get a grip on your roadmap. It’s the one document that is your business card towards managing up, sideways, and down. It’s your master plan for what matters going forward.

It needs to be simple to communicate, easy to understand, honest, and as reliable as possible.

It may feel that most managers will push you in your career towards committing to things that are insane just to satisfy their own higher-ups. More often than not, this dynamic is caused by a frustration from management that they can’t rely on promises from the product, and because they are measured on what a PM delivers (in terms of business impact), they have only one option:

• Micromanagement or building pressure to ship something because missed deadlines never make money, but shipping something might.

A good roadmap is a critical tool to build the trust with leadership that you have your area under control and that when you say “this is not going to work,” they believe you, instead of challenging you.

That’s easier said than done and an exercise that takes time. The first step, though, is to understand two key components of communicating any plan to management:

• Reliability always beats Optimism.

• Being proactive vs. reactive creates reliability over time.

Let’s map out what the three areas are that you have to cover, and some general tips on how to combine and communicate them.

The roadmap of a commercial PM

1. The table stakes - What’s the minimum to participate in a market?

   1. How to identify table stakes

   2. What metrics do they typically move

2. The differentiators - What’s helping to stand out and sell?

   1. How to identify differentiators

   2. What metrics do they typically move

3. The focus - What keeps us from shipping on time?

   1. Accountability for past commitments

   2. Debt - Accept or pay back?

4. An opinionated, high-level roadmap

   1. Communicating in ranges

   2. Honesty vs. optimism

   3. Simplicity in complex topics

Let’s look at each one in more detail:

1. Table stakes

Table stakes are things that the market expects of your product to be present to be considered as a bare minimum. I highly recommend that you think of table stakes not in the context of today, but whether those hold up in the next couple of years.

Remember that what we build needs to sell in future markets for some time to be commercially viable, not just today.

It’s important to understand the difference between table stakes and differentiators. Table stakes do NOT make us buy a product. Table stakes are simply what define a product inside a category.

A table stake for a car, for instance, is that it has four wheels, can drive, and is compliant with the regulations of the country in which it is released. None of these factors gets a customer excited to buy it; it’s simply necessary to recognize it as a car.

Things that used to be exciting for people become table stakes with time, as everyone else is copying them. We see this right now because of AI that a lot of functionality is simply expected to be present (AI summarization or some kind of LLM integration), whereas 2 years ago, the same features were the reason why customers bought your product over another one. (Which would be a differentiator)

In general, try to remember that table stakes are not something that we use to wow our customers; they are simply an expectation, therefore, the commercial impact of them is limited when it comes to acquiring new customers.

There’s an important exception to this: If the core functionality of your product is in an extremely bad shape and you’re not fulfilling your table stakes at all, you will influence new customer acquisition.

In other words, your company lost or never had product market fit, this only happens in earlier start ups or established companies that fall prey to the red queen effect (a continous deterioration of market conditions)
If that is the case, your roadmap should ONLY contain tablestake items until they are sorted out.

Commonly, you positively influence the following metrics by ensuring table stakes are in order:

• Any 30day+ retention

• LTV (Lifetime Value)

• Support tickets

• Overall customer sentiment

• Churn

Three questions to table stakes:

To answer this question, you should have a hypothesis on what you believe is stable and what’s changing in the market where your product is sitting. Zoom out for this one, trends can be in quarterly reports of competitors, your company strategy, market reports, or by simply developing a sense from talking to ICPs (Ideal Customer Profiles) outside of your product. Make sure you validate your views here with leadership.

We’re looking here for macro trends that have or could have a broader impact on the market.

For instance, if you believe that PDFs are getting replaced by a different document format (for your ICPs), why are you building out complex functionality for a bulk importer that is compatible with PDFs?

A common mistake here is to focus too much on your company, existing customers, and product. Trends are shaped in the market, not your existing customer base. Talk also to people who are not your customers but fit your Ideal Customer Profile. If leadership has a bet on future trends, ask questions until you understand why they believe them.

This is the very foundation of everything that follows. A commercial PM has high conviction and understanding of how the market looks and bases all assumptions on that, nothing else.

Now, we do an honest positioning of our product. Where are we today?

Since we developed an understanding of where the market is going or staying, we can highlight the gap between where we are and where the market is going.

Now we can list critical table stakes that need work to be ready or that are simply missing based on this difference.

Make sure that you’re not overfocusing on features here that are easy to communicate. This can also be on softer factors like reliability which are harder to identify.

As markets stabilize, customers expect more reliable services. In the early days of AI, it was expected and accepted that LLMs hallucinate. Depending on what you offer, this might not be the case anymore in one or two years.

For instance, if we see the volume of frustrated ICPs (internal support tickets, general sentiment in calls, public reviews) increase when it comes to how well core functionality works, then this hints at a table stake we have to be ready for.

I also recommend aligning what you find with leadership first before you communicate a finalized roadmap.

I cannot stand it when PMs approach me with lists of opportunities and table stakes that are not stackranked. Sorting everything we have to do in “High,” “Medium,” and “Low” is not good enough.

Have an opinion on why you believe that every item is more important than the next. Yes, we can often develop things in parallel, but even then, I’d like to know what’s at the absolute top of your list.

Anything we develop is a combination of two things:

• The opportunity it presents

• The cost (time and money) it incurs to develop and ship it

The combination of those two should already dictate what gets to the top of your list. For instance, a lot of PMs believe that only things that require a lot of work (High Cost) are worth being mentioned to leadership.

This leads to products that can’t get their basics sorted out (being easy to use, reliable etc.) while stuck in developing only complex stuff.

This happens because often, low-cost, high-impact things to do are hard to quantify and less sexy to communicate.

I generally try to visualize anything we do on a 2 x 2 with the above in mind to remind people what we look for when we talk about table stakes:

You might be wondering why I prioritize low-cost / low-impact over high-impact / high-cost ideas for table stakes.

This has to do with the fact that we commonly underestimate high-cost items in terms of time and money, which delays their impact as a consequence. A lot of PM careers were cut short because of ideas that spiraled out of control over multiple quarters and took up their entire attention, neglecting other, more basic things.

If you have a strong conviction for a high-cost / high-impact table stake that you want to develop, find a way to reduce the cost as much as possible. This is commonly done by introducing measurable milestones (splitting the opportunity up) that serve as checkpoints to determine whether we should abort or continue spending resources on something.
(As in, having multiple smaller throws that make up the big one in total)

In summary, there are two conditions under which you take care of high-cost / high-impact table stakes:

• You have exhausted all other low-cost opportunities

• The market forces you to take care of them (see Red Queen article above) because otherwise you won’t survive long term

Commonly, table stakes tend to be relatively stable, and you should be fine revisiting them once a year (or whenever a new company strategy is formed).

The trap of being data-driven and table stakes

The most challenging aspect of addressing table-stakes problems is that forming a business case for them in hard numbers is often seemingly impossible and unappealing. That’s why we spend a lot of time getting alignment on the trends and the current state of our product first.

For instance, we might agree with leadership that our interface looks like absolute crap and customers expect more from us compared to what others are getting done. To express that problem in hard numbers is almost impossible.

The underlying buy-in can only come from a shared conviction that this is more important than other flashy things on the road map, based on trends and customer sentiment.

Having said that, this is not a free pass to do everything without any data. If you cannot find a single customer who has a serious issue with what you’re saying is the problem, then you probably are not solving something worthwhile (see more details in the next chapter in how to create a business case)

2. Differentiators

People and companies do not buy new services for problems that are only marginally better than what they already have as a workaround or solution.

A differentiator is an opinionated specialization that you do better than anyone else to create this margin. It allows your company to move upmarket and charge more money per customer.

If a prospect is looking for a solution to a problem they encounter, they start weighing different solutions against each other on a comparison sheet.

In order to get on that mental comparison sheet, we need to fulfill the table stakes.

In order to be selected over the other options a customer considers, we need to have them experience relevant differentiators.

We commonly talk about this in Jobs theory as an underserved need.

A “need” is defined by table stakes: “I need to get from A to B (with a car)” (this would be a table stake)

Underserved means the current solution is not good enough in solving this need in some way, and could be anything:

• “My current car is too expensive.”

• “My current car is too loud on long drives.”

• “My current car is not spacious enough when I pack my things.”

• etc. etc.

Your job is to find out which one of these underserved needs is relevant enough in high enough numbers for your ICPs so they are worth addressing in the next years and where you are positioned today in relation to them.

Read more

Often, the learnings are not as groundbreaking as they used to be. The concept of Growth or Produ…

Read more

This way of "let's define values about how people should behave by writing them out on sticky notes" and then telling HR to hammer them into people's heads always felt artificial to me, especially while the management/leadership culture was at the same time completely dysfunctional.

It's no surprise that I keep get…

Read more

Do you, a B2B SaaS product, want to sponsor this spot so it’s free forever and get your message out? Drop us a line for the Mediakit: sponsoring@productea.io

"Let's fire everyone who's junior and midlevel. We have AI now!", is AI really boosting everyone's productivity to the wazoo, or is it shifting bottlenecks?

Everyone who actually does the work knows that while AI gains are impressive across the board, they are not as crazy as we might think.

The other day, I watched a video titled “Does AI actually boost developer Productivity?” by Stanford, conducted on 100,000 developers.

It attempts to ground the real numbers in terms of productivity gains, specifically for developers. There are a lot of parallels, though, to other jobs as well, including product and growth teams.

I joined Smallpdf back in 2019 when we were some of the best at throwing things at the wall to see what stuck. We were about 20 highly talented people with a strong engineering and shipping focus.

It made the company successful and grow at a breakneck speed. I also remember what my CEO, Dennis Just, told me on the first day of work:

“We’re really good at throwing spaghetti at the wall and seeing what sticks, but we need to grow out from that; it’s become unmanageable, and growth will eventually stall.”

How right he was.

Let’s look first at some brief numbers from the study and then at the parallels to what it means for companies and their products, and why the term “shipping” is misunderstood.

"As codebase size increases, productivity gain from AI decreases"

This is also true for other jobs. The meaningless, "simple" busywork can be massively improved with AI but complex work still suffers from being something an AI cannot comprehend.

We're looking at a range from simple, 60% to complex, 5 % more efficiency:

These numbers are in a field (engineering) that is “relatively” measurable. The worry I have is the usual lemmingesque behaviour of CEO’s not understanding any of it and translating numbers they hear on podcasts from “massive increases” to “I think we can fire half of our staff”.

“Using AI in software engineering increases rework”

You're delivering more and shipping more. Not all of it is useful; not only is that stuff also requiring rework. It usually requires rework that AI can’t solve by itself.

This is especially the case when we talk about complex system integration, where you have to make various systems work with each other.

The spaghetti effect and “shipping”

The relative position you inhabit in a market is, to a large degree, influenced by your competition’s capabilities. And in 2019, Smallpdf was well ahead of its competition. We dominated our distribution (SEO) and were shipping things multiple times a day.

Throwing spaghetti on the wall to see what stuck and reiterating on it led us to success with impressive numbers, hypergrowth at a scale that most companies and funds dream of.

At its height, we had 50,000,000 monthly active users using our services to play around (worked on by about 10 teams, product & growth). This traffic was divided into the few dozen tools we had, which was impressive by any standard.

And while this was by far the biggest data stack I’ve worked on at that time, I still ran into problems at scale:

• The bottleneck of the team was waiting for statistical significance for most of our experiments, despite all the traffic we had.

• Shipping a lot of small crap without validating it is the same as polishing a turd. The product constantly changes, but not necessarily for the better.

• The company was struggling to come up with big, good swings that were worth building. Should we add editing of a PDF into the product, or make all tools collaborative? Should we ship less so there’s less disruption to the service? Should we rework the legacy code that has not been touched in 4 years for most tools?

Especially the first point was amazing to me. If we changed a copy of our main website or most prominent tools, the experiments were statistically significant within hours.

A more complex down the funnel change for higher value customers? Weeks, sometimes months.

Ugh.

If we had access to AI improvements and faster devs, none of that would have changed. You can ship reiterations faster, but I remember specifically that my planning was constrained by how many tries I had to improve things with the team per given week.

If you haven’t yet, you will run into the same problem. Regardless of how many people you reach.

The term “shipping”

“Just ship it” was the go-to phrase of a manager I used to have over 20 years ago. It annoyed me to no end. He constantly said it because he felt that everyone was slow and not keeping up with his great ideas.

While I developed some sympathy for why he said it (he was convinced that he had the best ideas), it highlights a typical management problem. Managers (especially sales-led ones) don’t understand what “shipping” means and usually forget about a key part of it:

• Ideation: There’s an idea

• Development: You build the idea

• Validation: You validate whether what you think the idea does is actually happening

Yes, vibe coding tools like Lovable et al. help you to ship things faster, but only as long as these ideas struggle with the “development” part and don’t need Ideation and Validation:

• AI doesn’t help you come up with better ideas, except for the most obvious ones. It can help you with processing feedback somewhat though.

• AI can’t help you to validate anything at scale faster. Validation depends on how many users you have to test on, not how fast you “read” the results.

Now, you might be a manager who rightfully points out:

That’s true, only for the smallest companies, if you have a lot of obvious things left to build and improve.
As you scale, this does not work anymore because a good idea might give you a lift of only 5% which is undetectable in a typical sales pipeline.

You have one product, and we know that 75% of ideas, despite their best intentions, do not deliver any meaningful impact. Even worse, they might negatively impact the overall product and customer experience.

By skipping the validation step, you might ship yourself literally out of business.

Conclusion

If AI improves the facilitation of smaller changes, then these will not be a bottleneck anymore.

What’s left will be complex problems and validation. Problems that AI can help with very little.

Building a tech and software product that is commercially viable will always be hard and more of an issue of Ideas that matter and how you distribute them.

If it wasn’t, it would be copied, and you would drown in commoditized offerings, and you can’t charge money anymore for it.

Yes, you should absolutely think about how to integrate AI into your workflows if anything, and enable your organization to work with it, but chill on your budget because of it.

It’s great, but not that crazy to just forget about everything else.

Talking to customers and building the “right” thing for the correct market is still king. So far, AI has not substantially improved or made any of it obsolete.

Video Source:

Vincent Pierri, Public speaking coach and LinkedIn’s "PowerPoint ninja" with 25K+ followers, dismantles stage fright myths and reveals how to craft unforgettable talks. He shares practical frameworks like the "3Ps" (Pain Point-Problem-Promise) and the "ingredient spectrum" for engaging content.

Perfect for founders and leaders tired of boring presentations, this episode is full with actionable tweaks.

Timestamped Segments

1. 00:02:54 - 00:05:10
   "The Pastor’s Secret: Non-Tech Origins"
   Vince reveals his background as a full-time pastor—weekly sermons forged his speaking chops and frameworks.

2. 00:08:00 - 00:09:16
   "Stage Fright? Nope, You Just Suck at Prep"
   Vince argues 90% of "nerves" stem from poor talk-writing, not fear. Key fix: Structure talks for memorability.

3. 00:15:00 - 00:17:09
   "Talk Ingredients: Why Ideas Alone Bomb"
   Breaks down the content spectrum (ideas → stories → tactics) and the "2-min rule" for pacing engagement.

4. 00:39:00 - 00:42:58
   "Open Strong: The 3Ps Hook Framework"
   Vince’s Pain Point → Problem → Promise method hooks audiences fast. Leah adds mnemonics for sticky concepts.

Hot Takes

1. “Stage Fright is a Cop-Out—Your Prep is the Real Problem”
   Vince insists most “nerves” vanish when talks are well-structured, pretested, and packed with analogies (not just ideas).

2. “Polished Performance is Overrated—Be a Lawyer, Not an Actor”
   Ditching theatrics for persuasion (e.g., “argue like you’re in court”) beats forced energy shifts for early-stage speakers.

Share

Audio:

Youtube:

Connect

Follow:

Vincent’s Linkedin: https://www.linkedin.com/in/vincent-angelo-coach/

Follow Leah Tharin:

• LinkedIn: Leah Tharin

Season 4 of the Product Tea

We spill the tea on how to go to Market through Product-led Sales and Product-led Growth in B2B and the realities of senior leadership.

Check out the other Episodes

Anna Karina Schmitt, a world-record free diver and former tech executive, shares her journey managing multiple sclerosis through lifestyle changes, mindfulness, and freediving. She talks about reclaiming control by prioritizing self-responsibility, structured habits, and mental resilience. Her approach blends practical health strategies with lessons from extreme sports, insights for founders and leaders overwhelmed by burnout.

Timestamped Segments

1. 00:01:04 - 00:02:06
   "From Burnout to World Records"
   Anna’s background as a freediving athlete, multiple sclerosis survivor, and mentor to athletes and executives.

2. 00:02:54 - 00:05:10
   "Diagnosis & Denial: Early MS Struggles"
   Anna recounts her initial diagnosis at 20, early denial, and how MS symptoms worsened before she adopted lifestyle changes.

3. 00:08:00 - 00:09:16
   "The Turning Point: 2013 Crisis & Recovery"
   Anna Describes her health crisis, the realization of needing drastic changes, and how freediving became a tool for mental clarity.

4. 00:15:00 - 00:17:09
   "Practical Tools: Breathing, Boundaries, and Structure"
   Shares actionable strategies: 8-8-8 breathwork, daily habit structuring, and balancing work/rest priorities.

5. 00:39:00 - 00:42:58
   "Mental Mastery: Freediving Lessons for Leadership"
   Explains how freediving’s mental discipline (e.g., managing panic, trusting training) applies to high-pressure work environments.

🧘‍♂️ Breathwork — One Minute Breath

We use this simple breath meditation to calm the mind, warm up the respiratory system, and train our CO₂ tolerance. Inspired by Kundalini yoga, it’s a powerful tool to slow down and reset — without stress or breath-holding.

How it works (example):

Inhale (nose) – 8 sec

Hold – 8 sec

Exhale (nose) – 8 sec

Keep your inhale and exhale speeds steady. Avoid fast inhales during the first third of your breath—this may mean your interval is too long. Check in with your body: is your forehead, shoulders, and belly relaxed? Start with a comfortable breath length, around 8–11 seconds, but adjust to what feels natural without any urge to breathe. Sit or lie down—whatever helps you relax. Over time, we work toward a 20–20–20 rhythm = 1 breath per minute.

Why we practice:

Improves lung capacity

Strengthens breath control

Lowers heart rate

Builds CO₂ tolerance

Supports recovery + mental clarity

📱 Breathe+ Meditation Timer: Try using this app to support your practice. https://apps.apple.com/ch/app/breathe-meditation-timer/id1087354227?l=en-GB

📚 If you want to know more about the principle of reducing breath / accumulating more CO2, “The Oxygen Advantage” by Patrick McKeown is a great read.

Hot Takes

1. "Hustle Culture is a Lie – Your Body Knows Better"
   Anna critiques the "16-hour workday" myth, arguing that burnout stems from ignoring physical/mental limits. True productivity requires self-awareness and rest.

2. "Accountability ≠ Shame – It’s About Self-Compassion"
   Challenges the stigma around seeking help. Success isn’t about perfection but consistent, kind adjustments to habits and mindset.

Share

Audio:

Youtube:

Connect

Follow:

• Annas Linkedin

• https://www.annakarinaschmitt.ch/

Follow Leah Tharin:

• LinkedIn: Leah Tharin

Season 4 of the Product Tea

We spill the tea on how to go to Market through Product-led Sales and Product-led Growth in B2B and the realities of senior leadership.

Check out the other Episodes

The art of crafting a compelling two-sentence company description. Anthony Pierri dismantles common marketing myths, revealing why product functionality matters more than vague outcomes, and introduces his "positioning anchors" framework. We dive into real-world examples, differentiation strategies, and why founders often sabotage their own messaging.

Timestamps

1. 00:01:38 - 00:07:00
   The elevator pitch crisis: Why outcomes aren’t enough.

2. 00:07:00 - 00:14:00
   Positioning anchors: Primary vs. secondary frameworks.

3. 00:14:00 - 00:25:00
   Differentiation: Linking problems to anchors.

4. 00:25:00 - 00:41:17
   Positioning pitfalls and real-world applications.

Hot Takes

🔥 "Product demos are the highest-value part of sales—not outcomes."
Anthony cites a study showing that for companies over $50M revenue, the product demo outweighed outcome-focused pitches.

🔥 "Most elevator pitches fail because they’re stacked secondary anchors."
Leading with outcomes like "we save time" without explaining what you actually do leaves listeners confused.

Share

Audio:

Youtube:

Connect

Follow:

• Anthony’s Linkedin

Follow Leah Tharin:

• LinkedIn: Leah Tharin

Season 4 of the Product Tea

We spill the tea on how to go to Market through Product-led Sales and Product-led Growth in B2B and the realities of senior leadership.

Check out the other Episodes

Join my next cohort on Product-led Growth in B2B running from July 15 - Aug 5, 2025

The short summary of what’s happening right now in SaaS:

SaaS companies above >$1M ARR in the US,

• 2020: ~5,000 (Pre-pandemic, pre-AI) (48% of those with PLG)

• 2025: ~15,000 (Post AI, PLG Efficiency) (72% of those with PLG)

Or if you want to have it even more condensed:

There’s more and more SaaS companies trying to get money of the same cake and there are no signs of that slowing down.

The ones that do become profitable also tend to grow much faster than before. More companies, more jobs, and faster growth…

The structure of most SaaS / PLG businesses is that ~70% or more of all costs are staff-related.

People like you and me.

This hasn’t changed much despite AI now being overall a bigger cost centre. Most SaaS companies are still run by humans.

But the founders and investors in those companies are also humans. And they try to control these new companies with somewhat old methods, which are leading to some problems that have plagued our industry for decades.

Understanding those methods can help you understand why it’s so important to think commercially to secure your job.

Share

The “phone call”

The investors who own these companies are facing a somewhat changed reality from previous years in that most of these companies are now dominant with product-led growth as a distribution model.

One main difference from PLG dominant companies is that they are less transparent and harder to control. While you do have more data in a lot of aspects (due to having a freemium, trial), the control tools that we have to scale such motions from the balance sheet are awkward at best.

I teach most of my PLG material for B2B companies with two important mechanisms:

• We separate value creation (your product metrics) from value capture (conversion metrics into $) to align our product and growth development with the customer. This leads to better onboarding and longer-term retention as the customer experiences more likely early on what they expect longer term.

  • For instance, instead of measuring how many visitors we convert into paid ones, we focus on how we bring visitors as fast as possible to the “AHA” moment with our product, which is before payment.

• We will always prioritize revenue over internal processes, even if that means that we lose a bit of oversight.

  • For instance, B2B buyers do not want to give us their email anymore just to read our content. In order to maximize the number of eyes we generate on our inbound material, we remove gated content even if it means less tracking. We also need to take into account the fact that buyers do not follow linear paths anymore.
    It’s possible someone calls sales, three months later goes into a freemium, and then closes self-served. We might not be able to correctly attribute this, but we have to build our growth funnels for that possibility.

Both of these mechanisms help you differentiate and beat your competition, but they also make the company harder to control.
A typical Sales-led company can be steered with simpler predictability over its sales headcount due to the linearity of a sales pipeline:

• Customer clicks “Call Sales” → Call happens → Demo is given → Lead is generated, etc., etc.

Letting go 50% of your sales people means probably a similar reduction in new revenue almost instantly.

Whereas if you let 50% of your product and growth people know, no one knows exactly what that will do and how fast.

If you want to read more about the inner workings of PLG, read my free guide on the subject, or join me in my upcoming Maven cohort, mid-July 2025:

Investors have since then come up with new metrics to roughly measure company efficiency, and one of the KPI’s they came up with is the amount of revenue a company makes per employee.

This is not a terribly new thing, but it’s often a blind spot for even more senior product and growth people since they never learned the commercial side of any business.

It matters because at some point, Investors will pick up the phone after looking at the balance sheets and talk to your CEO with a variation of the following phrase:

Investor:
“We need to talk about your Q2 numbers. Your ARR per employee is at $150k – decent, but Canva’s at $310k using AI-driven support teams. The market’s punishing anyone below $250k now. Look what happened to HubSpot’s stock after their metrics dipped last month.”

CEO:
“We really shouldn’t lay off people right now, morale is already quite low….”

Investor:
“Morale doesn’t move multiples. Try the Autodesk Playbook: Cut 9%, blame ‘cloud transformation,’ hire 20 AI specialists. Bamm! Or do what Shopify did, freeze hires and let attrition do the work quietly”

Whatever you pick, announce it before our next board meeting. Oh, and if you need cover, cite the EU’s new AI liability laws as a ‘strategic pivot’.

CEO:
”What about our Q3 Product roadmap?”

Investor:
Delay it. Right now, we cares about two things: your burn rate and how many FTE equivalents you’ve automated. Did you see CrowdStrike’s report? They replaced 40% of L1 support with AI and got upgraded by Goldman. Be that story.

This fictional call is one that the CEO is getting if your numbers are not too great in the minds of your investors, but you will also get it if you are insanely profitable and have revenue way above whatever the ideal revenue per employee is in your investor’s head.

Then the call will go a bit differently in that your CEO will be interrogated as to why they are not investing the additional money to aggressively capture more of the market. This will lead to aggressive overinvestment practices, which will land you in the same cycle sooner or later again.

This happens because companies in SaaS are being sold based on their outlook and expected performance in the coming years, not just their existing money in the bank.(Read up on “DCF [Discounted Cash Flow] Evaluation” for more info on this.”)

In either case, it’s a reflection and reminder of the purpose of a company: to generate value for shareholders, ergo dollars. Not to employ people.

Hate the player, not the game

We can shake our fists and be angry about the fact that we are being treated as exchangeable resources, or we can try to understand the game better and act within its rules. Whether you are a normal product manager or a product leader:

It doesn’t hurt to think commercially and try to put yourself into a position where any investor (and by extension, your CEO) would think it’s a bad idea to cut your job:

Create a lot of money with as little investment as possible. Don’t just ship things. That’s the best way to protect your job and the ones from your team members:

• Don’t just ask as a reflex for more people and resources because it looks good on your CV, be comfortable abandoning ideas because they simply don’t pay enough.

• Billion-dollar improvements that never ship because they are stuck in research create zero revenue. Set yourself stringent limits on how long you are willing to research before you either kill or ship a project.

• Do good things and talk about them. If you’re creating a lot of uplift with your team, don’t forget to highlight the commercial side of things when presenting it.
  It’s cool that you “vastly improved onboarding” and now have an AI agent called “Toby” to help support. But don’t forget to put it into a memorable quote that the CEO can remember by mentioning revenue.

• Money will always beat vanity. Balancing your backlog with things that have a material effect on the business is your responsibility. You might think that you can’t sleep until you update a section of your internal wiki page of the company because you promised your CEO 1 year ago.
  My experience is that good, solid business cases for new stuff are the best weapons to kill old vanity promises that seemed important at the time.

More in-depth reading on the topic of being a commercial PM:

I consider myself to be a pragmatist when it comes to these things, and I do recognize that there are probably some regulations overdue (notice periods, etc.) for a long time in our industry, but focus on what is within your control.

Or, if you are a bootstrapped founder with no investors, be nice to the people you work with, even if it costs a little bit more.

Maybe not everyone should be reduced to a number.

Join my next cohort on Product-led Growth in B2B running from July 15 - Aug 5, 2025

Scott Brinker, HubSpot's VP of Platform Ecosystems and "Godfather of MarTech," unpacks the chaos of marketing tools, why AI won’t replace human strategy, and how vertical solutions beat bloated platforms. He reveals why marketers must balance brand-building with data myopia and why usage-based pricing is the future.

Timestamps & Segments

• 00:03:36 – 00:07:00 | MarTech’s Explosion (And Why It’s Harder Than Ever)
  Scott explains why marketing has never been more complex despite tech advancements, citing fragmented channels and operational overload.

• 00:10:16 – 00:13:00 | Attribution’s Illusion & Brand Marketing’s Comeback
  Why “data-informed” beats “data-driven,” and why brand-building trumps funnel obsession.

• 00:18:43 – 00:22:00 | Platform Wars: HubSpot vs. Salesforce vs. AI
  Debating centralized platforms vs. micro-tool constellations—and why vertical solutions will dominate.

• 00:34:21 – 00:38:00 | Pricing Shakeup: From Seats to Outcomes
  Scott predicts the death of seat-based SaaS pricing and the rise of usage/outcome models.

Hot Takes
🔥 “AI is a sparring partner, not a CEO—if you let it make decisions, you’ve already lost.”
🔥 “Vertical market tools will eat horizontal platforms alive. Specialized domain expertise is the only moat left.”

Share

Audio:

Youtube:

Connect

Follow:

• Scott Brinker’s LinkedIn
  

Follow Leah Tharin:

• LinkedIn: Leah Tharin

Season 4 of the Product Tea

We spill the tea on how to go to Market through Product-led Sales and Product-led Growth in B2B and the realities of senior leadership.

Check out the other Episodes

Larry Robinson, CPO of Bright Plan and Salesforce veteran, unpacks how to balance data with gut instinct in product leadership. From hiring dilemmas to prototyping emotional reactions, he reveals why sometimes the "soft" skills of intuition and storytelling outpace spreadsheets. Hot takes on why your next MVP should prioritize passion over precision.

Timestamps & Segments

• 00:00:00-00:07:00 | Data vs. Gut: The Product Leader’s Tightrope
  Larry’s framework for blending analytics with instinct in high-stakes decisions.

• 00:07:55-00:16:00 | Hiring Hack: Why 5-Minute Gut Checks Beat 9 Interviews
  How to spot A-players faster using presentation-based interviews and thin-slicing.

• 00:22:00-00:30:00 | Prototypes ≠ MVPs: Build to Spark Emotion, Not Just Data
  Why showing two excited customers beats a perfect metrics dashboard.

• 00:35:00-00:44:00 | Innovation Fuel: How to Sell Leadership (Not Features)
  Positioning products as category-defining tools instead of incremental updates.

• 00:44:00-00:54:00 | Budgeting Rebellion: Why Simplicity Trumps Spreadsheets
  Larry’s contrarian approach to financial planning that pissed off tinkerers (but worked).

Hot Takes
🔥 “If your prototype doesn’t make someone’s eyes light up in 5 minutes, kill it.”
🔥 “Hiring processes with more than three interviews are just cowardice in spreadsheet form.”

Share

Audio:

Youtube:

Connect

Follow:

• Larry Robinson LinkedIn
  

Follow Leah Tharin:

• LinkedIn: Leah Tharin

Season 4 of the Product Tea

We spill the tea on how to go to Market through Product-led Sales and Product-led Growth in B2B and the realities of senior leadership.

Check out the other Episodes

Sponsored by Attio, the CRM for the AI era.
Sync your email and watch Attio build a powerful CRM - with every interaction you’ve ever had, totally enriched and organized.

👉 Start your free trial today.

I wrote an article on the topic of why Alignment is at the heart of every great leader; it was one of my most-read articles to date:

Leadership, to me, is about leading people in a given direction, not necessarily managing them. At the heart of it is the art of creating alignment and inspiring people to move.

While I think that every manager is, to some degree, a leader, not every leader has direct reports, and IC Leadership (leading without managing people) has been a huge unlock in my career to understand that you lead more people than you manage.

In this 5 part series, I’ll dive into each one of these critical components:

1. Great Storytelling

2. Thorough Market Knowledge

3. Communicating often

4. Growing in front of your employees

5. Experimentation culture (this article)

Share

Share

Part 5: Experimentation Culture

If you’ve stuck with me through storytelling, market knowledge, frequent communication, and personal growth, you’ve already got the foundation for strong leadership. But now it’s time to take it to the next level: a good experimentation culture.

This is where things get tricky. Most leaders know they should experiment, but few build a culture where failure is not just tolerated but embraced. After all, we are all hired to make changes, not to simply maintain the status quo.

Success is never the direct goal of an experiment or change. Learning is, in order to maximize our chance of success over time.

Does your team see it that way, too? They’re probably not convinced. It’s your job to show them (and not just say it) that failure in the name of learning is the real win.

So let’s get into it - how to define success, why it’s crucial to set expectations early, and how to balance moonshots with more achievable wins. This is how you turn an experimentation mindset into a superpower for your team.

Experimentation ≠ Guesswork

Fostering a culture of learning over winning

I’ve saved this for last because it’s the hardest to pull off and the one that most people struggle with – creating a culture of experimentation where failure is okay and encouraged when done in the service of learning.

In short, success is not the goal. Failure is how we learn, and learning is the goal. By learning, we succeed in the long run.

And even though you might know that, your employees almost definitely don’t or see it as a glossy marketing phrase.

As with so much else in this guide, the root issue that we’re solving for here is that we, as leaders, grossly underestimate how clear we’re being with our team.

You may think that, of course, running an experiment to improve your onboarding flows is not just about success or failure and mostly about what you learn through the process, but your team members/employees, whom you are responsible for, probably don’t.

So, being the rational upstarts they are, they’re going to assume that the only way to succeed is for an experiment or change to work. If it shows a positive ROI, they’re doing great. If not, everyone will look down on them.

Which is a perfectly logical thing to think! It’s also the safe thing to think, and the thing that we’ve all been taught is true in the workplace our entire lives - results matter, so if you mess up, you’re screwed.

Define success clearly, explicitly, and early

This is why it’s essential to define the goals and the success state of our experiments before they happen. I make sure to communicate this to my team along three main criteria:

1. Explicit - Is the success state clear and explicit?

2. Early - Is it shared before the experiments themselves?

3. Expectations - Are the expectations well-defined?
   

Explicit

Are you being clear and explicit about what success looks like for this particular project or initiative? Or do you think you’re being clear but your direct reports have no idea what you’re talking about?

A quick way to make sure here is to ask them back. “What does success look like for us in your words?” You’ll be surprised at how often people are not yet aligned with your vision or simple goals for changes you want to drive.

“We are testing X. Success means we learn Y, even if the outcome is Z”

Early

Have you shared your expectations ahead of time, or are you telling people after the fact that it’s actually no big deal that the thing you tried didn’t work? By then, it’s too late.
They’ve already got a story in their heads about failing and will see your statements as trying to make them feel better. This’ll make them lose trust in you and themselves.

A good practice is to celebrate well-prepared initiatives and experiments when they are launched (especially if you feel the preparation and execution were exceptional), and don’t necessarily wait till the results are in.

Expectations

In a classic B2B SaaS organization, the majority (>60%) of all experiments are going to fail. That’s okay. It’s the nature of things, and in bigger companies it’s even lower.

So why do we try things? Because of the outsized impact the successes will have. Those things compound. But your team has to understand this. How? By telling good stories that inspire them and make them feel safe and part of the team. We take risks when we feel safe to do so.

It is your job as the leader to create a sense of safety for the team, so that it’s not about the flat number of times we win and the individual changes, but the big picture.

If you want a deeper dive into the overall maths behind it, consider reading my deep dive:

Balance - Managing Risk without Killing Ambition

It’s easy to overindex on moonshots that are destined to fail. Some leaders are exceptionally visionary and always dream big. Others are too scared to try out big stuff.

Balance here is key – as a leader, you want to give your team the right challenges. It’s tempting to push for those lofty goals, but if you constantly hand out five tasks that are all long shots, you risk burning your team out when they fail over and over again.

Yes, we want to celebrate the learnings from failure, but it’s essential to strike a balance. Your team also needs smaller optimizations or easier wins to stay motivated. Successes, even smaller ones, build momentum. Without that, it’s just frustration on repeat.

As a leader, it’s your responsibility to watch for this frustration and step in before someone feels like they’re going to give up entirely. If your team is always failing - no matter how many times you tell them it's okay - they’re going to start losing their drive. They’ll stop going to the gym, so to speak.

Instead, give them a healthy mix of challenges. Celebrate the big things that land on slides for management, but also make sure to provide enough attainable goals to keep morale high. Success compounds, but so does failure, and it's up to you to find that balance.

My former mentor, Stephanie Schoss, summarized this brilliantly:

You’re not just their leader - you’re their coach and trainer. You’re there to help them to grow stronger and more capable over time. But just like any good trainer, you can’t throw them under a 200kg squat rack and expect them to do anything but break their back.

They need the right mix of big goals and achievable wins to stay motivated. It’s your job to guide them through both, to push them when necessary, but also to provide the realistic support they need to keep moving forward.

Only then will they hit their stride and start gaining real momentum.

A good mental model to balance is: 70% safe bets, 20% incremental, 10% moonshots.

“How do I know if it’s working?”

You will feel an energy of trust and a willingness to make mistakes that is shared by everyone on the team.

So what do you do when it’s not there?

Ask.

Just as you would with ICP customers or prospects, you need to have honest conversations with your team and understand what’s gotten in the way.

Nine times out of ten, it will be because of something discussed in this guide - expectations aren’t clear, they don’t think you have credibility, miscommunication, or simply past experiences that make them suspicious about “why should it be different now?” etc.

This is where learning in public and being okay with your own failures are so important. By modeling to everyone that you are okay with not being right, you show (not tell) them the same.

Without this show and living it out yourself, it’s hard to demand the same from your team.

Why you shouldn’t focus on success directly

I know there’s a Gary the Sales Guy inside you (he lives in all of us) that’s asking, “uhhhh, why not just focus on success? Isn’t that a faster way to, ya know, succeed?”

In our current market dynamics, the simple, high-reward, predictable tasks are already taken. The system rewards those who crack the code, leaving fewer low-risk, high-return options for the rest of us.

We must take big risks, and with big risks comes a higher likelihood of failure.

But the question is: have you accounted for this in your organization? If you treat big, ambitious bets the same as smaller, safer ones, you’re setting yourself up for disappointment.

Do you expect the same success rate from moonshot ideas as from incremental optimizations? If you do, you’re not giving your team room to breathe. You need to allow—and even encourage—your team to take bigger swings, with the understanding that they’re going to miss more often.

At Smallpdf, we made a point of being transparent about this. We attached success rates to our big initiatives when we presented them, often as low as 10-20%. It sparked the obvious question: "Why bother if we're likely to fail?" The answer is simple - the potential payoff makes it worth the risk.

But not everyone sees it that way. Conversations about risk and reward need to happen regularly. You can’t expect your team to suddenly embrace big swings if they’ve spent the entire year focused on precise, validated optimization.

You need to teach them how to think about risk, about failing often, and about how that’s okay, especially when the stakes are high.

Including failure scenarios to manage risk:

Have a mental decision flowchart on when to:

• Pivot

• Persist

• Or kill a project

Formulate those when you work out a plan with your team for every bigger initiative by adding threshhold metrics: “If we can’t validate this initiative after 3 sprints, we will kill it.”

Best practice processes

“Failure is okay” is, at this point, probably an overused phrase; we need to back it up by showing how to fail in our processes (for instance, your post-mortems), keep those always:

• Blameless

• Data-Focussed

• Action oriented

A playful way is also to have recurring fail nights where your team can share their most spectacular failed experiments.

Learning repositories

Sooner or later, you want to organize the learnings for your teams so they can have them accessible in the future.

At Microsoft, we followed this simple structure for documenting our experiments when they failed:

1. Hypothesis tested

2. Why it mattered

3. Failure root cause

4. One actionable insight

Try following these core principles when organizing them in a repository:

• Single source of truth: Consolidate all knowledge (docs, videos, presentations) into one searchable hub. Bonus if you can put an LLM on top that has access to it. While it’s easy to discuss experiments in your internal chat tool like Slack, make sure that there is a recurring process that these insights don’t just rot away there.

• Taxonomy: Manual or good AI - autotagging helps others to browse through learnings, even if they might not specifically know what they are looking for. We used a simple notion table at Smallpdf to organize our hundreds of experiments, and it did us good service.

• Sunset ancient history: Everything around us changes with time. I try to occasionally just do spring cleaning by deleting or archiving stuff that has become irrelevant.

  • By time: Older than 12 months

  • Usage: Unused assets (never viewed in months)

Keeping a repository like this simple honors the limited bandwidth of your team and, in my mind, is a key responsibility for leaders because it usually falls through the cracks otherwise.

Summary

• Empower your team to take calculated risks as long as they align on the upside

• Impact is more important than win rate

• Simple and accessible repositories make learning from failures easier

• Celebrate insights from failures in recurring processes

If there’s one thing to remember from this part, it’s that failure isn’t the enemy. It’s part of the process. And as a leader, you have to foster an environment where your team feels safe enough to fail—and smart enough to learn from it.

What’s next?

Check out the other parts of this guide if you haven’t:

1. Great Storytelling

2. Thorough Market Knowledge

3. Communicating often

4. Growing in front of your employees

5. Experimentation culture (this article)

Sponsored by Attio, the CRM for the AI era.
Sync your email and watch Attio build a powerful CRM - with every interaction you’ve ever had, totally enriched and organized.

👉 Start your free trial today.

Etie Hertz, CEO of Loris.AI, breaks down how AI isn’t replacing humans - it’s unlocking superpowers for customer service teams. From analyzing 100% of customer conversations to predicting emerging issues before they blow up, he reveals how enterprises can turn empathy into a scalable strategy. Plus, why chatbots are headed for commoditization and the real value lies in the intelligence layer above.

Timestamps & Segments

1. 00:02:00 – From Lawyer to AI Disruptor
   Etie’s journey from predicting the 2008 crash to building AI that tackles agent burnout.

2. 00:09:00 – AI’s Hidden Superpower
   Why and how analyzing every customer conversation (not just samples) transforms decision-making.

3. 00:20:00 – Data Sanity vs. Stale Insights
   How Loris.AI keeps models dynamically updated—no more “cup of water in the ocean” bias.

4. 00:31:00 – The Chatbot Commoditization Trap
   Frontend bots are racing to the bottom; the real gold is in routing intelligence.

5. 00:38:00 – Enterprise AI’s Dirty Secret
   Why 2025 will force consolidation—and how CX leaders are becoming the new data powerbrokers.

Hot Takes
🔥 “AI agents using the same LLMs will have identical outputs within 2 years—it’s a race to the bottom.”
🔥 “If your AI isn’t making CX leaders the loudest voice in the boardroom, you’re doing it wrong.”

Share

Audio:

Youtube:

Connect

Follow:

• LinkedIn: Etie Hertz

• Loris.ai
  

Follow Leah Tharin:

• LinkedIn: Leah Tharin

Season 4 of the Product Tea

We spill the tea on how to go to Market through Product-led Sales and Product-led Growth in B2B and the realities of senior leadership.

Check out the other Episodes