My co-author, Alistair Croll and I have been jamming on this too. He’s thinking way further ahead than me (as is always the case!) but we’re seeing the same things: the cost of building has collapsed, models drift under your feet, and your “users” might not be human at all.

The short version: the core Lean Analytics frameworks survive. Many of the specific metrics you were taught to obsess over need a rewrite. Some have been replaced entirely.

This post is about how to tell them apart. Fair warning, it’s a long one. We’re going to cover what still works (fast), what’s changing at the product metric level (in detail), what’s changing at the business model level (where some of the real damage is happening), and what’s coming next (more speculative, but important).

Subscribe now

A quick primer, in case you haven’t read Lean Analytics (the book)

If you’ve read Lean Analytics, skip this section (or skim it). You can probably ask ChatGPT or Claude for a synopsis. You can always get the book, too. 😉

Here’s enough to follow along.

Lean Analytics has four ideas worth anchoring on:

1. Know your stage

In Lean Analytics, we proposed 5 stages that all businesses go through: Empathy → Stickiness → Virality → Revenue → Scale.

Here are a couple primers:

• From Empathy to Scale: What Stage Are You Really At?

• You Don’t Have Product-Market Fit (and that’s OK)

At each stage there are key metrics to track. A lot of founders lie to themselves about the stage they’re at, eager to hit hockey stick growth before laying down a solid foundation. That’s very true in today’s rush to build the next AI darling.

2. Know your business model

We defined six archetypes: SaaS, e-commerce, two-sided marketplace, user-generated content/community, mobile app, and media. These are outdated, but the principle of knowing how your business works is critical.

When you’ve mapped your business it helps determine which metrics to track. Here’s a classic example from the book:

You can dig into the concept of mapping your business (and the business model) through a few posts:

• Deconstructing & Mapping B2B SaaS Business Models

• The Importance of Business Models to Building Great Products

• Your Startup is a System You Can Map to Identify Problems, Align the Team & Win

3. Pick the One Metric That Matters (OMTM)

At any stage, for any business model, there’s a single metric you should be focused on. This is the concept of the One Metric That Matters.

You can’t fix everything at the same time. The OMTM helps you identify what to work on and the right way to measure it.

Here are some relevant posts:

• OMTM vs. NSM: Why You Need Both to Drive Startup Growth

• Build, Measure, Learn: The Expanded Edition

4. Use lines in the sand

Benchmarks tell you when you’ve earned the right to move on. We called them “lines in the sand” because they’re not writ in stone. Thankfully there’s a lot of data out there on targets for specific metrics, although with AI and agentic products, the metrics and targets are moving quickly.

Here’s a post with more information on benchmarks: 4 Steps to Building Super Stick Products Leveraging Your Best Users

None of these principles change in an AI era

Although Lean Analytics was written in 2013, the core principles are sound. But the businesses being built today are significantly different. AI changes user interfaces, pricing models, profit margins, and much more. AI-first and agentic products are used differently. Expectations for value creation change. Connectivity between platforms changes.

Example: The five stages don’t disappear. They get a question mark attached to each one.

We need to integrate new metrics in with old ones to define each Lean Analytics stage. We need new metrics to help evaluate whether our business model is working. We still need to measure what’s going on, but we’re changing what and how.

Let’s start with product metrics.

Product metrics: six shifts that matter

Shift 1: Time to value collapses

Traditional SaaS had straightforward onboarding flows. Users signed up, went through a few steps, saw value and hopefully returned. It was rarely immediate, and Time to Value (TTV) wasn’t even a priority for many companies.

In 2024 I ran a study on TTV and the results were fascinating. Here’s one example:

How should you think about TTV value for AI products?

My experience: People are willing to try but fickle.

As people get more comfortable with AI, there’s a recognition that things are a touch experimental. They’re willing to test things out, but to an extent.

If they’re not convinced that the output quality is high enough they’ll move on. Fast. And the expectation bar is going up; people are aware of the hype so they expect your AI product to blow them away.

This isn’t just about chat products. A user drops in a messy document and expects a polished proposal back. Uploads a spreadsheet and expects clean analysis. Sketches a wireframe and expects a working UI. Hands over a contract and expects an instant review. The input method varies. The expectation is constant: fast, high-quality output, first try (or very shortly thereafter).

There’s a flip side that’s interesting. Time to competency has collapsed too. Non-technical users can now generate expert-level outputs without the training curve that used to gate them. Your activation curve used to be a learning curve. Now it’s an interaction or two.

That’s a real Lean Analytics shift. What used to be a multi-week journey to competency is now a single input away. The instrumentation has to change to match.

Shrinking time to competency is a good thing. But it may have a negative impact on business models (which I’ll focus on later). If one person can now do the work of three because AI fills in the expertise gap, you don’t need to onboard everyone in the company. That hits your seat counts, your expansion revenue, and your ACV curves. Happy users, fewer seats. That tension starts right here in Shift 1, and it ripples through everything downstream.

What to measure: time to first useful output, and the percentage of users who get a useful result on attempt #1, regardless of whether attempt #1 is a prompt, an upload, or a sketch.

Share

Shift 2: Activation isn’t deterministic anymore

In traditional SaaS, activation was a deterministic event. If the user completed a set of steps (connect your data, invite a teammate, create a project), they hit a predictable output. You could instrument the funnel because A + B + C reliably produced D. I wrote about this with Ben Williams, in the context of early PLG metrics, and most of those metrics assumed that deterministic relationship.

AI breaks that assumption.

In an AI product, a user can complete every step of your activation funnel and still get a mediocre output. They set up their account. Connect their data. Upload the document. Hit run. And the result is... meh. Your dashboard shows them as activated. They are not.

Activation isn’t a binary gate anymore. It’s a quality-weighted event.

This matters because everything in product is a loop. Nir Eyal’s Hooked gave us the dominant mental model for how product habits form: trigger, action, variable reward, investment. Every trip around the loop deepens the habit. That framework still applies in an AI era, but with one critical caveat that breaks a lot of the math underneath it.

In the classic Hooked model, the “action” is deterministic. User takes the action, a reward follows (variable in magnitude, but reliably present). AI loops introduce variance on both sides of the action. Users will stretch and test the edges of what you’ve scoped, prompting or asking for things you never designed the product to do. The outputs will range in quality. Two sources of variance in a single loop is a genuinely harder thing to instrument, and the old retention math wasn’t built for it.

This doesn’t mean activation has to collapse to a single prompt. Compound multi-step activation can still work beautifully in AI products, and often works better than one-shot activation when the setup actually improves outputs. Connecting context, uploading reference material, configuring templates, training the tool on your voice. More setup can equal higher first-run quality, which is exactly what you want. The shift isn’t “activation got shorter.” The shift is that completing the steps doesn’t guarantee the user got value.

What to measure: the old funnel-completion metrics still apply (for now), but pair them with the attempt #1 quality signal from Shift 1. The funnel tells you the user finished the steps. The quality signal tells you whether finishing the steps actually produced value. You need both, and your activation dashboard has to show them side by side.

Shift 3: Engagement is directional (and the axis isn’t product type)

Traditional product wisdom: more time in product = good. Longer sessions. Higher DAU. Deeper feature usage. Session length went on every investor deck.

AI flips the question. The right frame isn’t whether engagement is going up or down. The right frame is more fundamental: what is the user’s time being spent on?

• Time spent struggling (regenerating, re-prompting, tweaking inputs to try to get a useful output) = bad engagement, every single time. High regenerate rate, long sessions with no copy or ship event, users abandoning mid-flow. This is failure dressed up as engagement, and it will flatter your dashboard while your product is silently dying.

• Time spent with AI doing the work on users’ behalf (spreadsheet being manipulated, proposal being generated, document being reviewed, emails being drafted) = good engagement, potentially very high. The minutes represent AI labor, not user friction. A user whose spreadsheet is being restructured by AI for 20 minutes is getting real value. That engagement number is a feature, not a problem.

• Time spent exploring or creating (brainstorming, ideating, iterating on a design or draft) = good engagement. Traditional intuition holds here.

• Zero user time, task completed = ideal for agent and automation products. The best outcome is invisible.

Stop asking “is engagement up or down?” Start asking “what is the time being used for?” That’s the PM question now, and most dashboards aren’t set up to answer it.

GitHub Copilot reports percentage of suggestions accepted as a core metric, hovering around 27-30% industry-wide according to published research. That’s a KPI that literally didn’t exist in traditional SaaS. It’s a direct measure of “was the AI’s work useful?” rather than “did the user stick around?” Huge difference.

Shift 4: Stickiness becomes about flow, not walls

Traditional stickiness was a frequency game: DAU/MAU, return visits, habit loops. Andrew Chen wrote a well-known piece years ago about where DAU/MAU breaks down: episodic-but-high-value products, weekly-rhythm tools, anything that doesn’t fit a daily habit pattern. AI doesn’t kill DAU/MAU. It amplifies the limits Andrew was already calling out.

Two things are happening at once.

First, users expect to do more diverse tasks with an AI product than they did with the linear SaaS tool it replaced. “Surely I can do more with this AI than the single-function tool, right?” is becoming the default customer mindset. That’s a real opportunity. PMs should be actively mining what users are prompting, uploading, and asking for beyond the current scope of the product. Task diversity per user is a growth vector that didn’t exist before, and the signal for where to expand your product is sitting in your prompt logs and your interaction data right now.

Second, sticky AI products are less about walls that keep users in and more about being in the flow of their work. Trace Cohen recently wrote a piece called “Moats are dead. Long live canals.” that captures this well. He wrote: “moats scale through exclusion, canals scale through throughput.”

Stickiness in an AI era looks a lot more like canal thinking. You’re indispensable because of throughput and embeddedness, not captive because of switching cost. “Routes,” as Trace puts it, “tend to outlast empires.”

What to measure: DAU/MAU still matters as a baseline (especially while humans are in the loop), but pair it with metrics that actually capture flow:

• Task diversity per user. Are users stretching your product into use cases you didn’t originally scope?

• Integration depth. How many of the user’s tools and data sources are connected to your product? Each connection is a canal.

• Trigger diversity. What brings users back? One trigger or many? Multiple entry points means you’re plugged into multiple parts of their workflow.

• Workflow chaining. Does your product hand off to other tools, or receive handoffs from them? Being a node in a multi-step process is the literal definition of being “in the flow.”

When humans stop becoming the primary user, classic DAU/MAU will become problematic.

Don’t be a tiny canal

Stickiness as flow has a failure mode. Being “in the flow” can mean being a small canal between two big rivers, useful today but vulnerable to being widened, narrowed, or rerouted by whoever owns either bank. Today you’re indispensable. Tomorrow the tool upstream ships an AI feature and absorbs your slice.

The defensive move is to eat more of the chain. Legacy moat software is fat, slow, expensive, and not AI-native. The opportunity isn’t to fit neatly between two of those tools. It’s to replace them.

Claude Code didn't just sit alongside your IDE. It replaced enough of the editor, enough of Stack Overflow, and enough of the actual work that developers used to do by hand to become a different shape of product. That's the model.

So add one more metric to the four above: replacement breadth. How many adjacent tools, subscriptions, or manual processes did your customer drop when they adopted you? If the answer is zero, you’re still a tiny canal that can be rerouted around. If the answer is meaningful, you’re becoming the route everything else flows through.

Subscribe now

Shift 5: Quality is a first-class metric now

We’re circling back. Shift 2 (activation is a quality-weighted event) and this shift share a root cause: AI outputs are probabilistic, not deterministic. That single change cascades through every metric you inherited from the SaaS playbook. Activation is one place it shows up. Ongoing product quality is the other, and that’s what this shift is about.

Traditional: the feature works, or it doesn’t. You ship it. You instrument it. You move on.

AI reality: outputs are a distribution, not a property.

An 80%-good product and a 95%-good product feel like completely different products to users. That gap matters more than any other gap in your funnel. Quality isn’t something you ship once. It’s something you watch like retention.

Klarna is the cautionary tale. They went big on AI-only customer support in 2024, claiming the AI did the work of 700 agents. By mid-2025 the CEO publicly walked it back and started hiring humans again.

There’s a second piece most teams aren’t tracking well enough: brittleness. Your quality depends on models you don’t own, integrations you barely control, and prompts that can silently regress when an upstream provider updates something. Quality can drop without anyone on your team touching the code. That’s a new risk category, and it doesn’t fit anywhere on a traditional dashboard.

The defense is to measure models against each other on your actual prompts. If you’re using more than one model across your product (and most teams are, or will be), each one has its own quality distribution and each can shift independently. Run the same evals across every model you touch and watch the gaps. When one provider regresses, you’ll see it. When another improves, you’ll see that too. Your model is now a vendor you have to actively manage, not a dependency you can set and forget.

What to measure starts with the basics: thumbs-up rate and regenerate rate as your core signals. Regenerate rate showed up in Shift 3 as a struggle indicator. Here it’s the inverse: same number, different question being asked.

Layer on top of that: eval harness scores tracked over time, the way you’d track retention. Run those evals across every model you use, not just one, so you can spot regressions and improvements as they happen.

And finally: quality distribution by cohort. New users experience a different product than power users do. They don’t know how to engage yet. The tool is worse for them by default, and most teams aren’t measuring that gap.

Sidebar: Alistair on why evals are the new MVP

My Lean Analytics co-author Alistair Croll recently wrote a piece I think every PM should read: “The feedback loop is the product.”

His core argument lines up exactly with this shift. In the Lean Startup era, the MVP was the smallest experiment that tested your riskiest assumption. In an AI era, your riskiest assumption is no longer “can the model do this?” (it can). It’s “does our system behave correctly in the situations that matter most to our users?”

He writes: “The eval suite IS the MVP: the smallest set of behaviors whose improvement you can automate and measure.”

If you’re building AI products and you don’t have an eval harness, you don’t have a product. You have vibes. Go read the post. It’s the clearest explanation of evals-as-management-tool I’ve seen.

Shift 6: Trust and comfort with AI are leading indicators

This wasn’t in the Lean Analytics book, because it didn’t need to be. Tech savviness has always mattered, but it’s never had the range it has now. With a traditional SaaS tool, if a user can click buttons and read labels, they can use the product. With AI, comfort with the technology itself is a variable, and it shapes every downstream metric you care about.

The macro picture is clear. Gallup’s February 2026 study of 23,717 US employees found that what separates AI adopters from holdouts isn’t access to the tools. It’s whether employees see AI as useful, ethical, and a fit for their workflow. Non-users tend to question whether AI is relevant to their role at all. Infrequent users see some potential value but get held back by practical concerns and risk.

Stanford’s 2026 AI Index Report shows global adoption at 58% of employees but the US trailing at 28.3%, far behind Singapore at 61% and the UAE at 54%. The same product can sit on top of dramatically different user populations, and most teams aren’t measuring that.

In a B2B context, my hypothesis is you’ll see meaningfully different activation, stickiness, and task diversity curves between AI-native users and AI-hesitant ones. Same product, same plan, same role, different behavior. The AI-native user stretches the tool, prompts it in ways you didn’t design for, and gets more value per session. The AI-hesitant user is cautious, underuses the tool, and quietly concludes that “this isn’t for me” even when the product is working correctly. If you measure them as one cohort, your averages will hide the real story.

In a B2C context, the stakes get more intimate. Products for companionship, mental health support, friendship, and emotional wellness are now a real category. Stanford’s data shows 52% of respondents globally are excited about AI for companionship, with that number climbing past 80% in places like Singapore and Indonesia. Comfort with an AI in those contexts is the core product question. Value creation is literally measured through the user’s willingness to keep showing up, keep talking, and keep engaging emotionally with something that isn’t human. That’s a very different measurement frame than “did they complete the task?”

Trust also isn’t one thing. It’s at least four things, and they move independently:

1. Trust in the output: Is this correct? Is this useful?

2. Trust in data handling: Where does my prompt go? Who sees it?

3. Trust in security: Can this be exploited or leaked?

4. Trust in reliability: Will this embarrass me if I rely on it?

I don’t know of teams doing rigorous AI-comfort cohort segmentation in their own product analytics yet. But the variance exists, the tools to measure it exist, and it make sense to do. A single onboarding question (”How often do you use AI in your daily work?”) plus behavioral signals you’re likely already capturing (prompt complexity, regenerate rate, time-to-advanced-feature-use) is enough to build a working cohort view. Run your existing activation, retention, and trust metrics through that lens and you’ll likely see gaps that aggregate dashboards are hiding.

What to measure:

• Adoption and activation curves segmented by AI-comfort cohort, not just role or plan.

• Accept rate, which we saw in Shift 3 as a measure of “was the AI’s work useful?”, becomes especially revealing when sliced by AI-comfort cohort. How quickly does trust build for AI-native users versus AI-hesitant ones? The slope of the curve, more than the absolute number, tells you whether your product is earning trust or losing it.

• Override rate, meaning how often the user rewrites, edits, or redoes the AI’s output. A falling override rate is a rising trust signal.

• For emotionally intimate B2C products: session depth, return rate to sensitive features, qualitative tone of interactions.

• Signals of data/security concern: feature opt-outs, support tickets asking “where does this go?”, usage that avoids sensitive inputs.

Trust and comfort with AI aren’t soft, squishy, unmeasurable things. They leave real signals in your data. Instrument them the same way you’d instrument retention, because in an AI era they effectively are retention.

Share

Business model metrics: three key shifts

Product metrics change. The bigger shock is what AI is doing to business models.

Picture the scene. Your AI feature launches. Engagement is 10x any other feature in your product. Your CEO is ecstatic. You’re in every all-hands slide for a month.

Six months later, finance review: gross margin has collapsed, your power users cost more than they pay, and your best engagement metric is the one strangling your P&L.

This is happening quietly in products everywhere.

Shift 1: Cost-per-successful-task is your new CAC math

Traditional SaaS: CAC, LTV, and gross margin were relatively stable per customer. Scale made things cheaper, not more expensive. Marginal cost of adding a user was close to zero.

AI reality: your power users literally cost you money.

Tokens are variable cost. Flat-rate subscription plus a heavy user equals negative margin per account. SaaS LTV curves don’t hold. The more someone uses your product, the worse your unit economics get, which is the exact inverse of what you want.

What to measure:

• Gross margin per active user. Not per paying user. Per active user. Big difference.

• Cost-per-successful-task

• Model cost as % of revenue

• Marginal cost of power users vs. marginal revenue from them

Intercom’s Fin is a great example of getting this right. They didn’t price per seat. They priced at $0.99 per successful resolution. You only pay when Fin actually solves the issue. That’s outcome-based pricing, and it’s mathematically honest about what AI products actually cost to run. ElevenLabs went usage-based from day one. Anthropic and OpenAI have both publicly wrestled with consumer subscription economics.

If your pricing and metrics don’t reflect variable compute cost, you’re flying blind.

(I wrote more about how business models shape which metrics matter a while back. The core argument holds, the cost structure is what’s new.)

Shift 2: Pricing is a product decision now

Usage-based and outcome-based pricing are still early. Hybrid models (low monthly fee plus usage, with overage) are probably where most AI products eventually land.

Here’s what matters for PMs: pricing decisions are product decisions now, not just finance decisions. The pricing model tells the user what success looks like. It has to match the unit economics underneath. Get that wrong and you’ll either burn margin or cap your growth. Sometimes both.

Think about the difference between “unlimited AI queries for $20/month” and “$0.99 per successful outcome.” Those aren’t just two pricing models. They’re two completely different products from the user’s perspective. The first says “experiment freely, we’ll eat the cost of your learning.” The second says “we only win when you win, and you have to think about what winning means.” Both can work. Neither is neutral.

This is a real shift, because most PMs haven’t had to think deeply about pricing. It was finance’s problem, or the CEO’s problem, or the “we’ll figure it out when we need to” problem. That’s changing fast, and AI-native PMs need to treat pricing as a core part of product design.

Side note: As I build AI tools for Highline Beta (we’re releasing things soon!) I’ve spent a lot of time instrumenting the tools to track AI usage and calculate cost. I’m sure there are tools that do this for you, but I wanted to understand how to do it: learning through building.

It’s interesting to see what actions (features) drive cost, and then determine if they drive commensurate value, and then figure out how to price everything.

You may have AI features in your product that are expensive but don’t create a ton of user value, which can easily kill everything for you. Adding SaaS features was typically cheap (i.e., new features don’t cost a ton to run), which simply isn’t true for AI features.

Subscribe now

Shift 3: Experimentation isn’t a vanity metric anymore

Experiment count used to feel like a vanity metric. In an AI era, I think it’s mission critical. And it’s earned that promotion through a specific mechanic that didn’t exist before.

AI-enabled product building lets you release way more, way faster. The cost of shipping a feature has collapsed. That sounds like an unambiguous win, and it isn’t.

If you’re shipping faster but not running real experiments, you’re vibe-stuffing your product (as far as I know, I just invented this term!)

You’re adding features because you can, not because you have evidence they’ll create value. Most of those features won’t. Some will be ignored. Some will be used in ways you didn’t anticipate and couldn’t measure. The product gets bloated, the codebase gets bloated, the cognitive load on users goes up.

On top of that, every AI-powered feature you ship has a cost attached to its use. Not a one-time build cost, an ongoing per-call cost. Inference isn’t free. So the bloat from vibe-stuffing isn’t just clutter, it’s a tax that compounds with usage. You’re paying tokens every time someone touches a feature you didn’t have evidence for. The more it gets used, the more it costs, and you don’t even know if it’s creating value.

That’s a uniquely bad outcome. Slow, expensive, and unproven, all at once. Pre-AI product bloat was annoying. AI-era product bloat is a margin killer.

Strong experimentation is the only defense, and Lean Analytics goes up in value here, not down. The discipline of picking a metric, writing a hypothesis, pressure-testing it, and deciding what to do next is the difference between a team that’s learning and a team that’s just shipping. The Lean Analytics Cycle was built for exactly this, and it has never been more relevant.

A useful filter: for every experiment, write down the hypothesis and the decision criteria before you ship. If you can’t do that, you’re not running an experiment. You’re running a release. Both have their place, but don’t confuse them.

What to measure: experiments-per-quarter as a real metric, not a vanity one. Hypotheses written down before launch. Features sunset based on data, not just features added. And cost-per-feature in production, because the AI-era product audit isn’t just “is this used?”, it’s “is this used enough to justify what it costs us to keep running?”

Tying all of this together: value density

A note before we leave business models. There’s a principle running underneath all three shifts above, and it’s worth naming.

Ben Murray, the SaaS CFO, said it cleanly: “If SaaS is about margin efficiency, AI is about value density. You’re optimising for how much output, productivity, or labor you replace per dollar of compute.”

That’s the new unit economics question, and it’s measurable. The numbers are already showing up in the data. ICONIQ’s January 2026 State of AI report puts inference at 23% of revenue for scaling-stage AI B2B companies. That same report shows AI gross margins averaging 52% in 2026, up from 41% in 2024 but still well below the 70-90% that mature SaaS companies hit. Bessemer pegs AI-first companies at 50-60% gross margins. Jason Lemkin’s framing: “as you grow, you need ever more inference. You can’t cut it without degrading the product.”

So how do you actually measure value density? It’s not one ratio. It’s three, and they move independently.

• Cost-to-deliver per task. What does it cost you, in tokens and compute, to produce a successful output? This is the bottom of your funnel. If you can’t answer this, you can’t answer anything else.

• Revenue captured per dollar of compute. Are you charging enough to cover variable cost plus margin? A flat-rate plan with a power user can mean negative revenue per dollar of compute on that account.

• Value delivered to the user per dollar of compute. This is the one most teams skip. Did the user get something worth what you spent? A team can be strong on the first two ratios and still build a product nobody wants to pay more for. A team can be strong on the third and have terrible economics. The diagnostic only works if you measure all three.

The future: humans receding from the loop

Business models are getting way more complex. But products still have to drive them. That’s a Lean Analytics principle that hasn’t moved an inch.

What has moved is what a “product” even is, and who (or what) is using it. The thread running through everything below is the same shift viewed at four different distances. The human is receding from the loop. Still building. Still using. Still paying. But increasingly through, behind, or alongside agents that decide what actually happens.

Build-too-much is the new overfitting

Building is so easy now that the risk is shipping more than users can absorb, or more than your data can tell you is actually right. Every feature has a cost (cognitive, operational, and literal), but when the cost of adding one drops to nearly zero, the urge to ship everything is hard to resist.

Alistair wrote about this exact problem from the engineering side:

Fallbacks and the deletion problem

In “Fallbacks will be the death of us,” Alistair argues that AI removes the friction that used to force deletion. Old code stayed because rewriting was expensive. Old features stayed because building was costly. Friction was the garbage collector.

Now that building is cheap, nothing gets pruned. Fallbacks pile up into “invisible load-bearing walls.” Tests become dishonest (AI-generated tests often optimize to pass themselves rather than to validate the desired behavior). The whole system bloats silently.

He wrote, “deletion feels riskier than retention, and without friction, things stay.”

PMs need to own this. If nobody on your team is saying “this has to go,” you’re accumulating debt that’s hidden from your own metrics. Worse, as Alistair notes, you can’t trust your regression suite either, because the AI wrote the tests and the AI is grading the tests. Go read it.

The PMs who resist build-too-much and learn to measure deletion as carefully as they measure addition will win.

Agents as users

When a Claude agent uses your product on behalf of a human who never sees your UI, who is the user? What does “activation” even mean? What’s session length? What counts as engagement when the thing using your product has no attention, no fatigue, and no churn risk?

I don’t fully know. I’m not sure anyone else does yet either.

What I do know: if you’re not instrumenting agent traffic as a separate cohort today, you’ll miss the shift when it happens. And it’s going to happen.

The practical move is to start capturing user-agent strings, API patterns, and anything else that helps you distinguish “human driving the UI” from “agent hitting the API.” Track them as separate funnels. The behavior is different, the success criteria are different, and mixing them into one metric is going to give you the wrong answer on both.

Sidebar: Rob May on why HX replaces UX

Rob May recently wrote a piece worth reading: “The End of The Funnel: Why HX Is The Next Big Design and Investment Frontier.”

His argument: thirty years of UX has been about getting humans to click the right button. Conversion funnels. Onboarding flows. A/B tests on button color. When an autonomous agent books your flight, it skips all of that. It hits an API and returns a result.

His line: “The funnel isn’t just broken. It’s irrelevant.”

What replaces it is what Rob calls HX, or Harness Experience. The metaphor is deliberate. You don’t operate a harness, you wear one. It distributes load, keeps you tied to something powerful, and lets you stay in control without doing all the work yourself. HX is the design layer for a human who is steering, trusting, and auditing a fleet of agents working on their behalf. The user becomes a director, not a driver, and the metrics shift accordingly. You stop measuring clicks and conversions. You start measuring outcomes, oversight, and intervention.

If you want a sharper mental model for what “agents as users” actually means in practice, Rob’s piece is the best one I’ve read on it.

Discoverability and reuse

Two problems, one root cause: an AI that isn’t yours decides whether your product gets used.

Discoverability is the obvious one. A user opens ChatGPT and says “help me plan a trip to Mexico.” ChatGPT decides whether to invoke Expedia, Booking, Kayak, a niche specialist, or none of the above. The user never picked a tool. The AI did. For thirty years, distribution was about getting a human to find and choose you. In an agentic world, the human delegates the choice, and you’re competing for the AI’s selection logic, not the human’s attention.

Reuse is the one most teams haven’t grappled with yet, and it’s the more unsettling of the two. A user signs up and pays for Canva. They have the Canva ChatGPT app installed. Then they ask ChatGPT to help design something. ChatGPT still decides whether to invoke Canva. The user already chose. The user already paid. The AI gets to override that choice every single time the user goes through the AI to get work done, unless the user explicitly asks.

Same dynamic with Claude skills. You install a skill, you can be explicit about when to use it, or Claude decides. As more work routes through AI assistants, the AI becomes the gatekeeper not just for acquisition but for reuse of tools you already own. Owning the customer doesn’t mean owning the moments where the customer actually gets value. That’s a new kind of platform risk, and most teams haven’t priced it in yet.

What to start tracking: the gap between “users who own or pay for the product” and “users where the AI actually invoked it when it could have.” A paying subscriber whose AI hasn’t invoked them in 30 days is more at risk than a subscriber who hasn’t logged in directly. The first one might never log in directly again. They might just talk to ChatGPT. And the AI may have quietly stopped picking you.

Agent-to-agent products

When your product is a network of agents collaborating with other people’s agents, what’s the OMTM? What’s stickiness? What’s churn?

We don’t fully know. But the PMs thinking hard about these questions in 2026 will write the next version of the book.

If you remember Shift 2 for product metrics, I leaned on Nir Eyal’s Hooked as the dominant mental model for product loops. Trigger, action, reward, investment. Every single phase of the classic Hook Model has to be reconsidered when humans are receding from the loop.

The four phases are still there. Each one now has a question on it that didn’t exist five years ago. What does a trigger mean when the AI is doing the triggering? What’s an action when the AI takes it? How do you reward something that doesn’t experience reward? Does investment apply to a system that has no memory of previous loops, or has perfect memory of every loop it’s ever been part of?

The PMs that figure this out will lead the way. They’ll build new products and experiences for AI-”users” and simultaneously figure out what to measure to learn if they’re heading in the right direction.

What to actually start doing today

The Lean Analytics frameworks still work. Know your stage. Know your model. Pick the one metric that matters. Draw a line in the sand.

The specific metrics you inherited from the SaaS playbook need a rewrite. Time-to-value collapsed. Engagement is directional. Stickiness is trust. Quality is a cohort, not a property. Your power users might be your biggest unit-economic hole.

Here’s what I’d do, concretely, starting today:

1. Audit your engagement metrics. Stop asking "is engagement up or down?" and start asking "what is the user's time being spent on?" Time spent struggling is failure dressed as engagement. Time spent with the AI doing the work on the user's behalf is real value. The number on the dashboard is the same in both cases: your job is to know which one you're looking at. Get this wrong and you'll spend the next quarter optimizing for failure.

2. Add a quality-by-cohort view. Measure output quality for new users separately from power users. The gap might be bigger than you expect, and it tells you exactly where onboarding has to get better.

3. Look at gross margin per active user. Not per paying user. Per active user. Your best users are either your best asset or your biggest liability, and your current dashboard probably doesn’t tell you which.

4. Start instrumenting agent traffic separately. Even if it’s 2% today. It won’t be for long, and you’ll want the baseline before the shape of your traffic changes.

5. Build an eval harness. Alistair is right. If you can’t systematically evaluate whether your AI is doing the thing you want it to do, you don’t have a product. You have vibes.

6. Evaluate how you build features. Are you running tight experiments, or vibe-stuffing your product to death? How efficient and effective are your teams?

The book still holds up. The lens has shifted.

How are you handling the shifts in product, business models and metrics being created by AI?

14 years ago I wrote a blog post that was extremely personal. It was about my brother who died on April 22nd, 1986. That blog doesn’t exist anymore, but I need the content to live on.

If you’re not interested in a long, super-personal post about my life, don’t read on. Totally cool. This one is for me.

Today, April 22nd, marks the 40th anniversary of my brother's death.

He died in 1986 at the age of 8 from leukemia. I was 10 at the time. He was my only sibling.

Strangely enough, he and I share a birthday. He was born two years after me. I don't know the odds of that happening, but they’re small.

April 22nd, the day Jacob died, is also one my aunt's birthdays. She was (and is) our closest aunt, dearly loved by Jacob (and me).

Jacob was diagnosed with cancer when he was 6. He suffered, off and on, for two years. There was the occasional bout of remission, but it never lasted long. Most of the time he was shuttling back and forth between Guelph (where we lived) and Toronto's Hospital for Sick Children. He spent a lot of time at that hospital. So did my parents. I visited Jacob there, but never stayed for long periods of time. I was still going to school, and I think my parents wanted to shield me from what was going on. So I stayed with family friends, often for weeks at a time, and tried to lead a "normal life."

I miss my brother.

I often wonder what it would be like had he survived. In that fantasy world, we're best friends, close enough in age to have shared many milestones together: turning 30, getting married, having kids. Who knows...

I often wonder what he'd be like. He and I were very different. I was always more serious, he was always sillier and more fun. He liked tuxedo costumes, I couldn't care less what I wore (still sort of true.) He put a lot of effort into holidays and parties, I didn't. Even when he was sick, he had a jovial personality and enjoyed himself as much as he could, although as you might expect, there were occasions when he was so sick and in so much pain (made worse by the chemotherapy) that even his bright personality could not shine through. I really don't know what he would be like, but I have a feeling he'd be a fun guy to hang out with. And caring. Ridiculously caring.

My memory of my childhood is very spotty. My memory overall is bad, but it's amazing how little I remember of my brother's illness. Maybe I blocked it out to get through the situation, I don't know. But there are some things I remember.

I remember we both enjoyed LEGO (I still do!) We used to build Transformers and Thundercats out of LEGO, playing in our bedroom (which we shared with bunk beds) for hours.

I remember eating a lot of hospital food (don't do that), including ham and cheese sandwiches on white bread. I'm pretty sure I ate as a coping mechanism.

I remember throwing things at each other from our bunk beds and joking around while we were supposed to be sleeping.

I remember going on vacation to Cape Cod, near the end of his life. My parents already knew it was over, but I didn't. We had a great time buying a ton of gear at an Army surplus store and playing G.I. Joe. Did he ever love G.I. Joe.

I remember the day he died, when family friends came to pick me up at school. I was called out of class and I walked to the top of a set of stairs. Looking down the stairs I saw our family friends and knew instantly my brother had died. One of them said, "It's time." I went back into the class, collected my things and they took me home. It must have been a 20-30 minute car ride at least, but I have no clue what we talked about or said during that time. I also don't remember the last time I saw Jacob alive. I wasn't at home the night he died, my parents knew it was coming to an end, so I was staying with family friends.

The world is a shitty, brutal place. It's absurd how much suffering there is. And when people say "life is short," are they ever right. Most people don't really know what that means. Some definitely do.

It's difficult to say how my brother's death changed me. I don't know what I would be like had it not happened. While I feel like I grew up more quickly than my peers (at the time), I also never outgrew a lot of "kid" stuff. I still love cartoons, comic books and toys. So do a lot of people, but for me, "capturing a bit of my childhood" is so much more than nostalgia. It's a way of remembering my brother.

Reflecting on yourself is hard. I look back on my life and the experience with Jacob, and wonder why it didn't propel me more in terms of career choice (although I always wanted to be a doctor, I couldn't handle the years of school), or why I don't donate more money to research and charity. I don't know if my experience made me a better person. Somehow personal selfishness and laziness overruled my desire to help. I don’t think I'm a bad person, but I look at what some people do in the world—how they devote themselves to making a difference in huge ways—and I marvel at their desire and ability to do so.

People are incredibly resilient, more than they realize. Few people are ever pushed to their absolute limit. My grandparents on my father's side survived the Holocaust. They spent years in ghettos and concentration camps. Talk about pushing past one's limits. People survive horrible tragedies and experiences every single day. And most persevere. You've gotta believe in the human spirit and will to live. They're almost insurmountable. Having said that, I'm not an optimist when it comes to the human race. I'm not really a pessimist either. I'm ... neutral. It's not where I want to be, it's just where I am. We (collectively) do some fantastic things, but we're also so easily capable of evil that it's impossible for me to believe we get it all right "in the end." Life is just too complicated for that.

People are also insanely stubborn and irrational. We know right from wrong, and still go down the wrong path a lot. I’ve just started eating better and exercising. I finally committed to it. I always knew I should take care of myself and never did. I think it was my way of saying, “Fuck you” to the world (and death). But I’m 50 and running out of time. It’s something I’ve written about (if you want more sad, personal stories). Recently, my mom got very sick and that was it, I decided enough is enough…

Of course something will get me someday. As long as it's not cancer; you've already taken enough from me.

While stubbornness and irrationality can be bad qualities, they're also good. I don't think I would have achieved much of anything in life if I wasn't stubborn and irrational. I would have just turned over and given up.

I haven't mentioned my parents much here. I can't begin to imagine what they went through (even though I was there), and the pain they felt burying their son. We all suffer loss in our lives—that's part of life itself—but losing a child is unimaginable, even for me. It's something I have to force myself not to think about, given that I have two boys of my own.

My parents and I have our differences, just like any family. But I love and respect them dearly for the people they are and what they've gone through in life. They gave me a happy, good childhood.

For my kids, I'm saddened by the fact that they'll never get to know my brother. I think Jacob would have been an awesome uncle. They’re both now adults, but I used to be so scared every time they got sick. I hid it, but on the inside I was mess. Jacob's leukemia started with flu-like symptoms. That's it. From "having a cold" to a "rare form of leukemia" is a hell of a jump. But sometimes, that’s how it happens. Most parents don't think the same way that I do (although parents are universally and constantly afraid for their kids), because a cold is 99.99% of the time just a cold.

I think about Jacob a lot. Not on a daily basis, but he's never too far from my thoughts. I think about him in good and bad times. I think about him when I'm going to do something hard, and remember what he went through. I get a sense of strength from him that helps me. More than I probably realize. It's still hard though—forty years later—to think about him. Our time together was just too short, and the pain is still there.

My goal with this post was to share a part of me that's never really been shared. I'm sharing with myself and for myself, and sharing for my brother and with him. For my kids too. I would never presume to preach to you, I don't know what you've been through. The truth is, you can't really know someone until you know everything they've been through. But I can tell you this: whatever it is, I bet you can get through it. It's in our very core to fight (in a good way, and unfortunately in a bad way too) and survive. You can make it.

One thing Jacob taught me for sure, was to be happy.

It's a cliche, but genuinely important. Unfortunately, most of us never really get there. And while I admire the few people that can drop everything and do exactly as they please all the time, I'm not wired that way. But I do seek happiness. And I think I've done a pretty good job charting my own path (with the occasional hiccup along the way), always in an attempt to be and stay happy. If you can achieve even a little bit more happiness in your life—through anything—you owe it to yourself to at least try.

In Jacob's short life he touched a lot of people. Even today, people still visit his grave, evidenced by the small stones or pebbles they leave on his headstone (which is a Jewish tradition.) One of his childhood friends still leaves small toys on the headstone; a tiny connection to the friendship they shared. Just before my brother died, he asked my mother to take care of his friends. To the end, Jacob was thinking about others he cared about.

He was an awesome kid. He was an awesome brother. And I love him.

That’s what pre-seed investing feels like right now.

And if you’re thinking: didn’t Gandalf show up at Helm’s Deep and save the day? Sure. But that’s Lord of the Rings. This is real life. VCs love to think of themselves as Gandalf-level awesome. They’re not. Nobody’s riding in at dawn with the Rohirrim to save your startup. You’re going to have to break through those walls yourself.

The barrier to starting a company has never been lower. AI coding tools, AI GTM tools, AI everything tools means you can get from idea to functional product in days. So founders are launching. Lots and lots of founders. Throwing their startups at the wall to see what breaks through.

Cannon fodder.

• To be clear: I’m not being dismissive. I’ve written before: we need more founders. More entrepreneurs, not fewer. Small businesses employ nearly half the private sector workforce and generate enormous amounts of economic value. More startups means more shots on goal, and some of those shots will matter enormously.

• On the investor side, I’ve also argued that we need more angel investors to fund the next generation of founders. Someone has to take the earliest bet…

So yes. More startups. More investors. More entrepreneurship. 💪

But there’s a signal-to-noise problem right now that I’ve never seen before. If you’re trying to invest at the pre-seed or angel stage, you feel it constantly.

Here’s how I’m thinking through these challenges…

Subscribe now

1. The “Why” Matters More Than Ever

The ease of starting a company means founders don’t always have a great reason for doing so. They see opportunity. They think they’ll win fast. They’ve read the stories about AI companies hitting millions in ARR within months of launching and they want some of that. It feels a bit like the dot com era.

I’ve argued for a while that the most important question a founder can answer is why. Why are you building this? What happened to you, or what did you see, or what do you uniquely know that made this feel necessary?

Of all the things you could be doing with your life, why this?

That question matters more in a cannon fodder environment. Founders building because it’s cool, or because the timing seems right, or because they’ve spotted a gap from the outside, are the ones getting mowed down. Founders with a genuine insight, born out of lived experience or deep domain expertise, have a different quality of conviction. Conviction is what carries you through the grind.

Ed Sim from Boldstart, who’s been investing at the inception stage (his preferred term for pre-seed) for many years, describes the founders he backs as being on a mission. They can’t stop thinking about it when they wake up in the middle of the night. That’s the bar.

Founders: Using AI Aggressively is a Requirement

The use of AI tools to build and operate your startup is now table stakes. Not a differentiator. Table stakes.

Ed frames this as a direct question he now asks every founder: how much of your code was written by agents? His expectation for a software company is close to 100%. But it doesn’t stop at code. It’s product marketing, GTM, research, operations. The entire company needs to be agent-native.

What I’m looking for beyond the basics is creativity in how founders are using AI to innovate on startup creation itself. Not just building the product faster, but reimagining how they go to market, how they serve customers, how they operate. Founders who treat AI as a weapon rather than a utility.

Speed of execution matters more than ever because differentiation is compressing fast. But speed alone doesn’t win anymore either. Necessary condition, not sufficient.

Share

A quick aside, because this isn’t only about VC

One of the things I genuinely love about where AI is taking us: it’s opening the door for all types of entrepreneurs to build all types of things. Not just VC-scale swings with giant exit ambitions. Side hustles. Lifestyle businesses. The person who wants 50 paying customers a month to generate $5K in recurring revenue and buy back some freedom. That’s legitimate. That’s valuable. AI has made it more achievable than ever.

But if you think a lower bar is easier, you’re in for a world of hurt.

Getting 50 customers consistently is hard. Keeping them is hard. Distribution is hard regardless of your revenue target. Traction at any scale requires repetition, discipline, and more iteration than most people expect before they’re in it. The rules of building a real business don’t soften just because you’re not chasing a Series A.

Please: build the side hustle. Build the lifestyle business. Not everything has to be a moonshot, and frankly the failure rate on moonshots is brutal. But go into it with open eyes. “I don’t need to raise capital” is a feature, not a shortcut.

The Moat Problem

People are panicking because the moats they once held dear are drying up.

Network effects? Sometimes. Data advantages? Possible, but hard to prove early. Technical differentiation? Compresses in days, weeks, months. Ed Sim put it bluntly: what used to take 12 to 18 months to replicate in software now takes a fraction of that time.

Let’s not forget, moats (or ditches and walls) in medieval times weren’t perfect either.

The siege of Château Gaillard in 1203–1204 is a classic example. Built by Richard the Lionheart, it was considered nearly impregnable, yet it still fell to Philip II of France. After months of conventional siegework, French troops ultimately exploited an unguarded latrine shaft leading into the chapel and climbed through, opening the way for the castle’s capture. When someone is determined enough, they find a way. Moats and walls bought time. That’s it.

I came across an approach from Patrick Salyer, Partner at Mayfield, that’s worth sharing:

“There’s a simple filter I’m starting to use when evaluating AI agent startups: single-player or multiplayer?

Single-player AI apps are most at risk. They handle discrete tasks with limited complexity, exactly what Claude is designed to do incredibly well today.

Multiplayer apps require collaboration across multiple stakeholders to complete complex workflows. They need human-in-the-loop engagement, governance, and security around who can access what. Multiplayer is the moat.”

That maps to something Ed talks about too: the investments that hold up have domain complexity that can’t be collapsed into a single skill or replaced with the next model release.

Rob May, who writes Investing in AI (which you should read) argues that “weird stuff wins.” His take: the only durable opportunities might be genuinely low-probability and out-of-distribution. Ideas that don’t show up in training data patterns. Things that require real information asymmetry to even recognize as opportunities. As AI makes marginal innovation obvious and replicable, the success distribution shifts toward the weird ideas. It’s a provocative take, but there’s something real in it.

Which brings me back to what I think might be the last genuine moat: what does the founder know that nobody else does?

A proprietary insight developed through years in an industry, or a specific pain they’ve lived through, that gives them an unfair head start. That’s the question I come back to most in early-stage meetings.

Go narrow first, then scale

There’s endless debate: start in a niche or go for a platform play immediately?

My vote, most of time: start narrow

Insights come from going narrower. Finding complex problems comes from going narrower. The deeper and more specific you go into a market, the higher the likelihood of finding something that actually matters. You may uncover some boring problem that 10,000 other startups aren’t already chasing.

Subscribe now

Founders: Please Don’t Pitch at the Pre-seed Stage with Only a Deck

If you can ship an MVP in days using AI coding tools, and generate early demand signals using AI GTM tools, then showing up with just a pitch deck sends one clear message: you haven’t done the things you could have already done.

Pre-seed and angel investors want to see a functioning product. An early waitlist. Some proof that someone out there cares. That doesn’t have to be hyper-growth. But you need to demonstrate two things: (1) that you’re creating real value; and, (2) that you know how to reach your market.

The bar on traction has gone up, because the bar on building has dropped. Those two things are connected.

It’s Still a Bet on People. Maybe More Than Ever.

Remember the old adage of the ideal founding team? A hacker, a hustler and a hipster. Otherwise known as the builder, the seller and the designer.

First coined by Rei Inamoto of AKQA, the idea was that you needed at least three different people with complementary skills to build a company.

That framework made sense when each role required years of specialized skill to be competent.

It’s not quite the same world anymore.

AI has dramatically lowered the floor on all three. A solo founder can now hack (build a product with AI coding tools), hustle (run outreach and GTM with AI), and design (ship a polished product experience without formal training). I wrote recently about how the skills bar has expanded for everyone. The T-shaped model is under real pressure. The horizontal bar is becoming load-bearing. And what’s true for knowledge workers in general is especially true for founders.

The expectations on a founding team have changed. Hacker, hustler, and hipster skills still matter. But I don’t want to hear that you need to hire a CTO before you can start building. Or that you need to bring in a designer before you can ship. The solo founder is increasingly viable.

What I’m really betting on is whether a founder can figure things out. All kinds of things, in all directions, under pressure, with imperfect information. That’s always been the pre-seed bet. It’s just more nakedly true now.

Ed Sim calls it the “art of the possible.” He knows 9,999 things can go wrong when you invest early. But if one thing goes right, really right, how big can it be? That question drives everything.

Founders should build authority before jumping in

One signal I’m paying more attention to: has the founder already invested in building authority in the space they’re entering? Not just reading about it. Actually writing about it, building a following, becoming a known voice, knowing the players.

I’ve started to think: if I was building a new startup today, I’d spend 6 to 12 months doing exactly that before launching anything. Build the community first. Build the audience first. That work unlocks real problems, surfaces real insights, and gives you pre-built distribution before you’ve shipped a single line of code.

Founders who’ve done this aren’t a guaranteed bet. Authority isn’t a substitute for execution. But it’s a meaningful signal that someone has invested deeply in a space rather than parachuting in because the opportunity looked good from the outside.

Quick Reference: What I’m Looking At

For founders and investors both, here’s how I’d summarize the framework I’m working from.

If you’re a pre-seed/angel investor:

If you’re a founder pitching at pre-seed:

The medieval siege analogy feels right to me because it captures the brutality in an honest way. Most things don’t make it. The casualties are real, even if the walls are metaphorical.

But the founders who have something real, who are genuinely on a mission, who understand their problem better than anyone can still break through.

The job, as a pre-seed or angel investor, is identifying them early and having the courage to make a bet.

The moment that crystallized it: Figma’s Config 2023. Brian Chesky told a crowd of designers Airbnb had “gotten rid of the classic product management function.” The audience cheered. One tweet on the topic got six million views. Designers celebrated. PMs panicked.

Chesky later clarified he’d merged product management with product marketing. But the sentiment had spread. The broader critique wasn’t entirely wrong. A lot of PMs had spent years becoming backlog administrators and Jira ticket managers. That’s project management, not product management, and people could see it.

Then AI piled on. If everyone can build, why does a specialized role exist to manage the process?

The “PM is dead” crowd must feel pretty vindicated right now.

Except they’ve gotten it almost completely backwards. AI isn’t killing the need for product management. It’s making product management a skill everyone needs.

Subscribe now

Building Got Easier. The Hard Parts Didn’t.

Yes, AI has compressed the time and complexity of actually making things. A solo founder can build a working web app in a weekend. A marketer can spin up a prototype without filing a ticket. Anyone with an idea and some patience can ship something real.

I’ve been living this myself. I’m building stuff like crazy and it’s genuinely fun. Over the past few months I’ve built an LLM/SEO optimizer, an innovation toolkit, an applicant tracking system, an investor portal, a venture studio readiness tool, and a pile of automations. I’m a product person, not a developer. The line is getting blurry in ways I didn’t expect.

So yes. Building got easier.

But figuring out what to build? Still incredibly hard. Getting it into the hands of the right people and making them actually care? Harder than ever.

The cost of building wrong hasn’t gone down just because building got cheaper. If anything, it’s gone up. Because now everyone is building. The market is flooding with products, which raises the bar for everyone. Differentiation is harder. Getting your message out is harder.

And you know who else is building, or at least thinking about it? Your customer. If they look at your product and think, “I can just build that myself,” you’re in trouble Even if they can’t, the perception is powerful enough to kill a sale.

You’re Already Doing Product Management. You Just Don’t Know It.

If you’ve written a single prompt into an AI tool to build something you’re doing product management.

• Every time you decide what to build next, you’re doing product management.

• Every time you talk to a user (or skip talking to a user), you’re doing product management.

• Every time you choose which features to include, which to cut, and what success actually looks like, you’re doing product management.

• Every time you think about how someone is going to find what you built, you’re doing product management.

You’re doing it whether you have the title or not. Whether you’ve read a book or blog post about it, or listened to a podcast.

The question is whether you’re doing it well.

What I find fascinating is that product management skills are the very skills you need to use AI effectively to build something.

You need to think clearly about problems. Articulate what you want with precision. Break complex work into pieces that can be delegated. Synthesize messy, incomplete information into a decision. Catch when AI is confidently wrong and know how to course correct.

That’s not just AI literacy. That’s product management.

The moment everyone can build, the skills that were supposedly obsolete become the skills that determine whether you build something worth using.

Share

So What Are These Skills, Actually?

Product management confuses people because everyone has a different definition. The core is simple: find a real problem worth solving, build the right-sized thing that solves it, get it into the hands of the people who need it, and learn constantly throughout. It’s not easy, but it always felt pretty clear to me.

Here’s what it looks like in practice:

Know whose problem you’re solving. Not who you think has the problem. Who actually has it, how badly, and what they’re doing about it today. If you can’t answer those questions specifically, you’re building on assumptions. Assumptions that feel true are still assumptions.

Define success before you build, not after. What specific behavior change in users tells you this is working? What does the number look like in 90 days if you’re right? Set it before you write a single prompt. Otherwise you’ll rationalize whatever you ship as working, because you want it to be working.

Scope is a decision, not a default. AI makes it trivial to add features. That’s a trap. Lenny Rachitsky defines the job as “delivering business impact by marshaling your team to identify and solve the most impactful customer problems.” Not shipping everything you can think of. The best products do fewer things exceptionally well.

Distribution isn’t someone else’s job. Figuring out what to build is hard. Getting people to use it is equally hard. Product managers aren’t growth bystanders. Neither are you. If you’re building without thinking about how someone discovers, tries, and keeps using what you made, you’re building in a vacuum.

Your product needs to feel right, not just work. Use your own product obsessively. Feel the friction as a genuine first-time user. Notice what people don’t say in feedback sessions but reveal in their behavior. The judgment you build from this, over time, is what makes the difference between something that’s functional and something people actually want.

None of this is revolutionary. All of it gets skipped by people who just want to build.

Learn It By Doing. Not By Outsourcing It.

AI has a way of tempting us into being…brain dead. It’s so easy to agree with everything it outputs and stop reading and thinking.

AI can do a remarkable amount of PM work. It can synthesize user research, spot patterns in feedback, draft requirements, flag edge cases, simulate user reactions. That capability is real and improving fast.

But if you’ve never done these things yourself, you can’t tell when AI is wrong.

The judgment required to evaluate what AI gives you has to come from somewhere. It comes from talking to users, watching them use your product, shipping things that fail, understanding why they failed, and trying again. From the customer call where the data said one thing and the room said another, and knowing which one to trust. That instinct doesn’t come from reading about it. It doesn’t come from prompting your way through it. It comes from doing it.

Shreyas Doshi puts it plainly: “The only real long-term career moat for product people is how you can improve on the already-brilliant, already-comprehensive inputs and outputs that AI will provide for you.”

You can’t improve on something you’ve never tried to do yourself.

So if you’re new to building, here’s where to actually start:

Talk to five people before you write a single prompt. Not friends. Find five strangers who actually have the problem you think you’re solving. Understand how they solve it today, what it costs them, whether they’d change their behavior for your solution. If you can’t find five people with the problem, you probably don’t have a product yet.

Write your first product requirements by hand. Type it out. No AI help on this one. Describe what you’re building, who it’s for, what problem it solves, what success looks like, and what the riskiest assumption is. Then ask AI to evaluate it. You’ll learn more from writing it yourself than from anything AI could produce for you.

Launch smoke tests to validate the value proposition and your ability to get anyone to the front door. A smoke test is a way to see if you can attract users, but there’s nothing real yet. You might have a landing page with a few ads. Maybe you share some things on social media. You’re trying to test interest, perhaps a bit of conversion (e.g., through email signups). A lot of people skip this because they build and launch. When it doesn’t work, they’re not sure why, and there’s been little learning.

Build the smallest thing that tests your core assumption. Not the full vision. The one feature or flow that proves whether your hypothesis is true. Everything else is scope creep. AI will make adding more feel painless. It’s not. Don’t know what your core assumption is? Stop. Go back. That’s the first thing to figure out.

Use your own product as a stranger every week. Pretend you’ve never seen it. Where are you confused? What’s missing? What feels broken? This is not optional and it never gets easier, because your familiarity with your own product degrades your ability to see it clearly.

Expect to be wrong in important ways. Not about everything. But about the things that matter most. That’s how this works. The goal of a first version isn’t to nail it. It’s to learn what you got wrong fast enough to fix it before you’ve built too much on top of it.

The faster you can build, the more important it is to have done the thinking first.

Subscribe now

One Warning About AI and Product Skills

There’s a growing category of AI tools specifically designed to accelerate product management work. Frameworks, prompt libraries, agentic workflows that cover everything from discovery to strategy to go-to-market. A good example is pm-skills on GitHub, built by Pawel Haruyn: 100+ agentic skills replicating PM workflows end to end, nearly 9,000 stars. It’s genuinely impressive work and worth knowing about.

I use tools like this myself, including ones we’ve built at Highline Beta. In the hands of someone who knows what they’re doing, they’re a real accelerant.

That last part is the key.

These tools do a lot of things quickly, but without the product management fundamentals in your back pocket and an instinct for what’s good or bad, you’re following blindly.

This is the same failure mode PMs fell into before AI, just wearing different clothes. Before, it was mistaking status checks and coordination for product work. Now it’s running AI workflows and mistaking output for thinking.

The skills aren’t in the tool. The tool accelerates the skills. You have to build those skills first, or the acceleration is just moving faster in the wrong direction. (To be clear, I’m not referring to Claude Skills in this paragraph. 😆)

Product Management Isn’t Dead. It Became Everyone’s Job.

The irony of the “PM is dead” moment is that it was half right. The version of product management that died deserved to die: the backlog-managing, sprint-facilitating, paper-pushing version that confused coordination with creation.

It was never about that. It was always about judgment. About figuring out what’s worth building, for whom, and why. About caring enough about the user to understand them, and caring enough about the business to connect those two things.

That work doesn’t go away because building got easier. If anything, it matters more. When everyone can build, the products that win are the ones built by people who understand what they’re actually trying to do.

You’re going to build something with AI. You probably already are.

Guess what? You’re a product manager now. The only question is what kind.

What’s the hardest part of building with AI that no one prepared you for? Drop it in the comments.

These resources may help you get started:

• Test First, Build Later: A Guide to Validating Your Ideas With Stimulus & Prototypes

• How to Apply the Scientific Method to Startups Without Being a Zealot

• What Comes Before Zero to One?

• Build, Measure, Learn: The Expanded Edition

• Product Management is Communication

• Using Product Requirement Docs for Scoping Features & Uncovering Unknowns

You’ve probably heard the term, “a T-shaped person.” It’s been floating around business and tech for 40+ years, and there’s a reason it stuck.

The concept traces back to the 1980s, when McKinsey & Company started using it internally to describe the ideal consultant profile. It made its way into mainstream business conversation when David Guest coined the term publicly in 1991. By 2001, Harvard Business Review had put a formal frame around it in an influential article about T-shaped managers and knowledge sharing. Then Tim Brown, CEO of IDEO, brought it to an even wider audience in a 2010 interview that became the most-cited articulation of the model.

The model spread fast. It got baked into agile methodology, talent acquisition, career development frameworks, and performance management systems.

McKinsey still uses it. A 2023 CompTIA study of HR and L&D professionals across the US and UK found companies still actively use the T-shaped model to guide talent management and training. Forty-plus years after it was coined, it remains the dominant mental model for what a great hire looks like.

Subscribe now

The visual is simple, which is part of why it works:

• The vertical bar of the T = deep expertise in one domain. Your specialty. The thing people hire you for.

• The horizontal bar = enough breadth to collaborate across disciplines. The ability to sit in a room with people from other functions and actually contribute to the conversation.

Research backed it up. Studies on agile teams consistently showed T-shaped members outperformed specialist-only groups on complex, ambiguous problems.

The concept got refined over time: Pi-shaped (two verticals), comb-shaped (many verticals), and more. Consultants, futurists, and HR practitioners kept iterating on the model.

But the core idea held for decades: be great at one thing, and be collaborative enough to work well with people who are great at other things.

That model is no longer enough.

What the T Got Right (And What AI Just Unlocked)

The original definition was more nuanced than most people remember.

Tim Brown, who popularized the model at IDEO, described the horizontal bar this way:

It’s the disposition for collaboration across disciplines, built from two things. First, empathy. The ability to stand in someone else’s shoes and understand a problem from their perspective. Second, enthusiasm for other disciplines, “to the point that they may actually start to practice them.”

That second part is the key phrase. And it’s the one AI just supercharged.

In the pre-AI world, enthusiasm for other disciplines had a ceiling. You could be genuinely curious about how engineers think, or how data analysts work, or how a marketer approaches positioning. You could follow that curiosity into books, courses, or conversations. But converting that curiosity into actual capability took years. Apprenticeship. Formal training. Time you often didn’t have.

So for most people, in most roles, the horizontal bar stayed at “collaborative and empathetic.” Genuinely valuable. But not execution-level.

AI removes that ceiling.

If you have the enthusiasm and the natural inclination to figure things out on your own, you can now actually do it. Not perfectly. Not at the level of a specialist with a decade of practice. But well enough to build something real, do or ship something useful, and keep learning from doing.

The curiosity was always the unlock. AI just made it exponentially more powerful.

What I’m Seeing From My Own Work

I’ve been building a lot lately.

• An LLM/SEO Optimizer (if you’re interested, let me know!)

• An innovation toolkit using Highline Beta’s best practices.

• An applicant tracking system for Highline Beta and a few of our portfolio companies.

• A web app for evaluating corporate venture studio readiness.

• A ton of different automations for interlinking blog posts, adding LLM-specialized content to my web site, naming screenshots, removing backgrounds on images, and more.

These are all things I would have never touched even a year ago, because (a) I didn’t think they were my job; and (b) I didn’t have the capabilities.

I’m a product person. Not a developer. But the line is getting blurry in ways I didn’t expect.

Every week I’m posting on LinkedIn about new things I’m building or figuring out with AI. It’s not a flex. It’s just freaking cool what’s possible. Meanwhile, the tools keep improving, the things you can do keep expanding, and the skills I’m acquiring — even imperfectly — are changing how I think about my own work.

That’s when Tim Brown’s original framing really clicked for me.

I always had the enthusiasm for adjacent disciplines. I was always curious about how developers think, what good system design looks like, what separates a working product from a fragile one. I’ve been building software for 30 years, so I have a solid base of knowledge and experience, but now it’s growing exponentially.

AI is unlocking things I never thought possible. I’m not just collaborating with developers anymore. I’m doing development. At a certain level, in a certain context. Not at the level of a senior engineer building sophisticated systems. But building real things that work and deliver real value.

The curiosity was always there. AI just let me follow it all the way through to execution.

Share

What AI Is Actually Doing to the T-Shaped Model

For most people, in most roles, the horizontal bar was decoration.

Not useless decoration. But you weren’t expected to ship code, or build an analysis, or run an ad campaign. You were expected to understand it well enough to direct someone else to do it or provide other experts with the information they needed to do their jobs.

That’s changing across every function, and fast.

Marketers are doing data analysis. Designers are shipping code. Operations people are building automations that used to require an entire engineering sprint. Finance folks are generating their own reporting without waiting two weeks for a data team. Product managers are building the things they used to only spec out.

Beyond that, marketers are now building products. Product managers are doing growth (which, in my opinion, should have always been their job), developers are doing design and so on.

This isn’t theoretical. This is happening right now, at companies of all sizes, across industries.

The horizontal bar is no longer about perspective. It’s about capability. Real, functional capability. Not “I can have a conversation with the engineer about this.” It’s now, “I can build a version of this myself and iterate on it.”

That’s a different standard. And it’s coming whether or not people are ready for it.

Wealthsimple Jumped In With Both Feet

Recently, Wealthsimple launched an AI Builders program. Pay attention to how they describe what they’re looking for:

“We’re looking for people who look at a broken process and can’t help but imagine what it should be. Who move fast in ambiguity, own problems end-to-end, and think carefully about where AI should — and should not — take responsibility. Your story tells us where you’ve been. Your build tells us where you’re going.”

Dig in a bit more and you’ll find the key signal: they explicitly say that your CV isn’t everything. Degrees and experience aren’t the gating criteria. What you can build is.

This is a major Canadian fintech with hundreds of thousands of customers, not a scrappy four-person startup, saying: the old signals of competence don’t automatically apply anymore.

They’re not alone. They’re just one of the first bigger companies to say it out loud.

The T-shaped model was built on the assumption that your vertical is your primary value, and your horizontal is a nice bonus. What Wealthsimple and others are signalling is: we need the horizontal to be real. Not soft skills. Actual functional capability across multiple domains.

So What Does the New Shape Look Like?

I’ve thought a lot about this, and I don’t think a new letter captures it.

Pi-shaped. Comb-shaped. These add more verticals, which misses the point. The problem isn’t that people need two specialties instead of one.

The problem is that the horizontal bar has to become load-bearing. It has to represent actual capabilities, not just social ones.

Maybe we should just turn the T upside down…

In the old model:

• Horizontal = breadth of perspective, mostly soft skills

• Vertical = where you actually deliver value

In the new model:

• Horizontal = real functional capability across multiple domains, powered by and through AI

• Vertical = still important, but increasingly table stakes rather than your primary differentiator

It kind of looks like Thor’s hammer. Not everyone is worthy…

Your specialty doesn’t disappear. But it’s no longer enough on its own, and the breadth piece is no longer optional.

Subscribe now

AI Empowers Learning. It Doesn’t Replace It.

Before anyone gets the wrong idea: using AI doesn’t make you an expert in everything. Let’s not be silly.

I can build a working web app with Lovable or Claude Code, but I’m not a developer. I know enough to be useful. I know enough to ship something that works. I don’t know enough to architect systems at scale or debug deeply weird infrastructure problems. It’s easy to get caught in the hype and think that you can vibe code your way through anything. You can’t. You need enough foundational understanding to know when the AI is steering you wrong. And at some point, you need to bring in the experts.

AI compresses the time it takes to become functionally capable in something new. It doesn’t automatically install expertise.

What it does do is dramatically lower the activation energy.

That domain you always said was “not your area”? You can explore it now. And not just theoretically. You can build something in it. Fail at something in it. Learn from the failure. Iterate. That loop used to take years of apprenticeship or formal education. Now it can take weeks of deliberate experimentation.

That’s not magic. But it changes the math on what’s possible for any given person to develop.

The Skills That Actually Need to Be in the Horizontal Bar

If the horizontal bar is becoming load-bearing, what actually needs to go in it? I’m not talking about specific tools — those change too fast. I mean the underlying capabilities.

1. Comfort with ambiguity

People who need clear instructions before starting anything will struggle. AI-augmented work is exploratory by nature. You often don’t know exactly what you’re doing until you go through the process a couple times. If you freeze without a detailed spec, or you require a lot of handholding, that’s a problem.

2. Speed of experimentation

The willingness to try something, watch it fail, understand why, and try again. Not as a formal process. As a reflex. The people posting weekly about what they’re learning and building aren’t more talented than everyone else. They’re running more experiments and learning faster because of it.

Learn by doing. Please. I’m borderline begging you, because otherwise you’ll be obsolete.

3. Judgment about AI outputs

AI will confidently give you wrong answers (although it’s getting better). It will build things that work in demos and break in production. Knowing when to trust it and when to push back is a skill you develop through use, not through reading about it. You have to get your hands dirty to build that judgment. And as the Wealthsimple Builders program suggests, that judgment is going to become a critical skill for hiring.

4. Cross-domain curiosity

You can’t expand your horizontal bar if you’re only interested in your vertical. The people winning right now are genuinely curious about adjacent domains; not obsessively, but enough to explore and ask questions and try things.

Through building my LLM Optimizer I’ve done a deep(ish) dive into Schema frameworks, SEO, FAQ-style content, citations versus mentions, and more. I am not an expert at optimizing a website for LLMs, but I’m dangerous enough to do some cool things.

5. Self-directed learning

Universities aren’t teaching this. Most companies aren’t either. The people getting ahead are figuring it out themselves, sharing what they find, and iterating in public. Waiting for formal training is a losing strategy at the pace things are moving.

There are useful resources online to help, but relying on them isn’t worth it. Virtual classrooms are still classrooms. Pick up a few tools and get at it!

What This Means If You’re Paying Attention

If you’re a founder or exec: the T-shaped heuristic still works, but you need to re-weight it. The horizontal bar is becoming your primary filter, not a tiebreaker.

Can this person operate across domains? Are they learning fast? What have they actually built or figured out recently?

Those questions matter more than they used to.

The next time we’re hiring at Highline Beta, I’m all-in on the horizontal bar of the T. I don’t need deep experts in any particular field that are only interested in staying in their lane. I need people willing to say, “I’ve never done that before, but I can figure it out.” People that are insanely curious. People that just try stuff and figure it out. Without waiting to be told, without asking permission.

If you’re an individual: you need to deliberately expand your horizontal bar with real capabilities, not just soft skills. Pick one adjacent domain and get your hands dirty in it. Not a course. Not a certification. Build something. Ship something. Fail at something and figure out why.

If you’re in the middle of a career: the people who will be fine are the ones engaging now, with curiosity and a bias toward action. The people waiting for things to stabilize before jumping in are going to find the window closes faster than expected.

I’m not trying to panic anyone. But I’m living this awakening of “generalist superpowers” for myself and the rate of change is overwhelming.

The T Needs to Grow Up

The T-shaped model was a real insight. Depth plus collaborative breadth. It worked for decades.

But it was built for a world where the horizontal bar was a multiplier on your vertical. Today, the horizontal bar is becoming the foundation. “Collaborative” isn’t enough to describe what needs to be there.

The T needs to get wider. Much wider. And the width needs to mean something beyond being easy to work with.

The people who are building that broader foundation right now, even imperfectly, even messily, are the ones who will have the most options when this shakes out.

Start building. Even if you don’t know what you’re building. Especially then.

Sounds crazy, but it’s true.

And there’s science backing it up.

Meanwhile, the world is more disconnected than ever.

We live in silos with earplugs in, screaming at the world.

It’s disturbing. And sad.

My two adult children were home from university last week. We got to talking about AI, because I’m hacking away using tools like Lovable, Claude Code and others to build stuff I never thought possible on my own. I’m like a kid in a candy store.

They have a different opinion, and it’s not hugely positive.

Why?

My sense: they’re overloaded with AI slop from Instagram, TikTok and elsewhere. They can’t tell what’s real anymore. It feels like a tsunami of endless crap. Meanwhile the whole world is telling them humans are obsolete just as they’re entering the workforce.

Ouch.

Wrap that whole beautiful bun of awesomeness in the fact that younger generations are lonelier than ever (and they’re not the only ones). Everyone’s scrolling. No one’s connecting.

We’re all disconnected, overwhelmed by AI and lonely.

That’s not a great combination.

But a 15-minute call will make you happier?

Yup, it’s true.

I want to introduce you to Twos.

That’s my personal invite link to join.

It hasn’t fully launched, so you’ll need to setup TestFlight first and then install the app. But we’re hoping to get a few more brave folks to join us early!

Twos is the brainchild of a father-son duo, who came to Highline Beta with the goal of “reconnecting humanity.”

Just a tad ambitious, but why not? 😊

If I can put a bit of goodness into the world, I want to try.

They had an idea:

• What if we could connect people together for 15-minute video calls in a safe, secure space? Match people based on interests, conversational style and how they’re feeling. Measure post-call mood. Use science, but not in an overwhelming way.

• What if a 15-minute call every day with a stranger could make people feel better?

• What if enough people called enough strangers every day that the world got more connected?

What if?

Twos describes itself as quality conversations with real people.

AI helps you onboard, but the goal is to connect you 1:1 with someone to share, laugh, cry, listen, vent, help and…be human.

• Twos is not for therapy. If you need mental health support please find professional alternatives for that.

• Twos is not for dating. If you’re looking for love, there are plenty of other places.

Dr. Sonja Lyubomirsky is a Professor at the University of California and Twos’ Chief Scientist. She’s an expert in the field of happiness. Studying happiness is a thing, because finding or achieving it isn’t easy.

This quote from Sonja sums it all up:

I’ve been working with the Twos’ team for awhile, along with my team at Highline Beta. It’s been a very interesting experience. B2C is tough. How can you really know if something will take off? There’s an element of “magic” or “lightning in a bottle” that’s tough to predict.

We did a lot of research, experimentation, prototyping and validation. The Twos team kept going: testing, iterating, learning, redoing, trying again, testing, iterating, learning. You get the point.

Building something that people will love is not easy. And there’s still a long way to go. ❤️️

But there’s something intriguing about 15-minute calls with strangers. How will the call go? Will you enjoy it? Will you feel better? Will you have enough to talk about?

It turns out, in most cases, if you put two people together in a safe space and ask them to have a conversation, they do exactly that.

They find something to connect about. Twos prompts you with topics if you get stuck, but most people go with the flow. It feels awkward at first, but then you realize: (a) talking to people is OK; and (b) you never have to speak with the same person twice (if you don’t want).

Twos is not a social network. It’s not built to create followers, authority or brand. Remember: Quality conversations with real people.

If you try Twos (and I hope you do!) you’ll notice a couple unique things about it. For starters, in video calls you won’t see yourself. Don’t panic! It’s awkward at first because you’re used to staring at yourself in FaceTime, Zoom, Google Meet, Teams, etc. Twos took a different direction. Full video of the person you’re speaking with; no tiny video of yourself.

When I first experienced it, I flat out said, “This is weird.” And then I forgot about it because I was more focused on the person I was talking to. I stopped worrying about how I looked and just…talked.

Another interesting feature is how you connect with others. Since it’s not a social network, there’s no friending or following. You open up a “card pack” and it reveals matches that are available to talk.

If you don’t find people to talk to right away that’s OK. A new pack will show up soon enough and you can try again. Twos isn’t trying to keep you in the app endlessly. We hope you find someone to talk to, in the moment, feel a bit better, and go on with your day. Come back when you’re ready for more conversation!

I hope Twos wins.

Not because Highline Beta helped build it, but because it could actually make a difference. If Twos can reach enough people, and those people decide that speaking to a stranger isn’t weird, but actually healthy…we may have the antidote to mindlessly doomscrolling AI slop on social networks.

Maybe, we make the world a little less lonely.

Maybe, we make the world a little bit happier.

Maybe, we make it possible for two people that otherwise would never have connected to do exactly that.

Twos will be available in the iOS App Store soon. In the meantime, if you’re a bit courageous and curious, get early access. And maybe we’ll get matched and have…dare I say it…a conversation.

On one side, founders and execs are whispering (perhaps loudly): “Do we still need junior people?”

On the other side, universities are still graduating them like it’s 2012. (From 2012-2025, the US population grew ~9%; undergraduate degrees issued grew ~17% in that same time.)

In the middle, there’s AI.

Not as a vague force or sci-fi villain. But as a very practical tool that is already reshaping how work gets done.

I want to argue something specific (before we all run for the hills): AI might be the best training tool we’ve ever had.

Not because it’s magical or will save us from job losses (jobs will be lost, let’s not be naive).

But AI can compress the time it takes to go from “new” to “useful.” If we don’t intentionally use it that way, the alternative is obvious: We delete the bottom rung of the career ladder.

Subscribe now

The Hidden Cost of “New”

Every organization has the same problem.

New people are expensive, because they’re new. Onboarding uses precious resources. Getting a new person to a competent level is a real investment.

Often you see newbies miss invisible steps, struggle to understand what “good” looks like, make preventable mistakes, interrupt senior people constantly and require constant feedback.

Most companies “solve” this with:

• Documentation nobody reads

• A shadowing process that depends on one generous senior

• Or worse, vibes (not to be confused with vibe coding, which I’m a fan of!)

Training is rarely designed. It just sort of…happens.

AI changes that equation. It’s already being proven.

In an MIT & Stanford joint research study, Generative AI at Work, they tested the use of AI in a few circumstances with junior and senior people. One example focused on customer support, providing people with AI tools to help them resolve issues. The lowest skilled and newest human agents (which now requires specifying in a world of AI agents)) to the job, saw the biggest lift in resolutions per hour thanks to AI.

The study found that novice and low-skilled workers saw a 34% improvement, whereas highly experienced and skilled workers saw minimal improvement.

Let me give you three other examples that I’ve experienced over the last few months.

1. The Hackathon for Developers

At a recent hackathon hosted at Highline Hub, Alexander Zidros built something called DevFlow. He described it as an always-on task tracker for software developers, helping track the tiny steps between “in progress” and “done.”

During his presentation he said:

This could be valuable for new developers that may not appreciate all the tiny things that have to be done properly to go from idea to production grade code.

I lchuckled because I had written that exact thought in my notes before he said it.

New developers don’t struggle because they lack intelligence. They struggle because the work has hidden structure.

Senior engineers know:

• Edge cases to check

• Deployment nuances

• Testing expectations

• Naming conventions

• Performance implications

• What “done” actually means in production

Juniors see the feature(s). Seniors see the system.

While AI is doing a lot of the coding, developers are valuable orchestrators, and junior + orchestration = very risky, unless properly trained.

2. The Professional Services Signal

In recent conversations with leaders inside a professional services firm, they told me about internal prototypes designed to review work and provide feedback.

The goal was obvious:

• Maintain quality

• Speed up delivery

• Help new employees internalize standards faster

What struck me wasn’t automation. It was reinforcement.

AI reviewing deliverables against company-specific best practices, industry norms, style guidelines and regulatory requirements isn’t “replace the analyst”, it’s “train the analyst in real time.”

Maybe the most powerful use of AI in knowledge work isn’t generation, it’s review. And review is how standards transfer.

Share

3. Personal Experience Exploring Insurance Opportunities

Some time ago, Highline Beta was working with a partner to explore new venture opportunities in insurance, specifically around smaller agencies and brokers. We learned something interesting: they’re often held back by their ability to onboard new brokers quickly.

Why?

Because most training happens by osmosis.

New brokers:

• Sit in on calls

• Watch senior brokers negotiate

• Absorb patterns

• Learn what not to say the hard way

Almost none of that tribal knowledge is formally documented.

When we floated the idea of AI-assisted onboarding, the interest was strong. But there was an immediate constraint: “It can’t just be generic best practices.”

Each firm wanted to infuse the AI with their own expertise around qualifying clients, structuring renewals, handling edge cases, managing risk, building trust and more.

That means extraction. You might think, “How different can one agency’s onboarding be compared to another?” Tough to say, but the perception is there, and perception is reality.

So AI can play a role as:

• Knowledge capture engine

• Pattern recognizer

• Internal playbook enforcer

It’s not about replacing brokers, it’s about accelerating them.

The Fork in the Road

Here’s where it gets uncomfortable.

There are two obvious ways companies can deploy AI.

Path 1: Replace juniors

We’re already seeing signs of this.

• A Stanford Digital Economy Lab paper using ADP data found early-career workers in AI-exposed occupations are experiencing disproportionate employment pressure. Entry-level roles appear especially vulnerable.

• SignalFire’s 2025 State of Tech Talent report shows new grads now make up a much smaller share of hires compared to pre-pandemic levels.

• Dario Amodei, CEO of Anthropic, has warned that AI could eliminate a significant portion of entry-level white-collar jobs in the next few years.

Even if the precise numbers shift, the direction is clear.

The bottom rung is wobbling.

Path 2: Compress time-to-competency

Instead of eliminating juniors, you could:

• Reduce preventable mistakes

• Make expectations explicit

• Provide instant feedback

• Turn months of ramp-up into weeks

This is the version I’m arguing for.

Not because it’s guaranteed.

Because it’s intentional.

Subscribe now

What Matt Shumer Got Right (And Why It Freaked Me Out)

Matt Shumer wrote a piece titled “Something Big Is Happening.” It’s a wake-up call. Most of you will have read it by now.

He highlights the pace of AI progress, including models contributing to their own development cycles. AI is building itself. Come on now! The feedback loops are accelerating. The capability curve is steep.

His tone isn’t calm. It’s not “incremental change.” He’s saying, “this is moving faster than most people realize.”

I know this isn’t a fad. The technology works, it improves predictably, and the richest institutions in history are committing trillions to it.

I know the next two to five years are going to be disorienting in ways most people aren’t prepared for. This is already happening in my world. It’s coming to yours.

I know the people who will come out of this best are the ones who start engaging now — not with fear, but with curiosity and a sense of urgency.

And I know that you deserve to hear this from someone who cares about you, not from a headline six months from now when it’s too late to get ahead of it.

We’re past the point where this is an interesting dinner conversation about the future. The future is already here. It just hasn’t knocked on your door yet.

It’s about to."

He’s right.

Reading it scared the hell out of me.

Not because I think we’re doomed tomorrow.

But because I have two adult kids in university.

And I found myself thinking: What does the job market look like when they graduate What does “entry-level” even mean? Who trains them if nobody hires them?

That’s the structural risk.

If AI replaces junior roles, we don’t just lose jobs.

We lose the apprenticeship layer that produces future experts.

Societies run on apprenticeship, whether formal or informal.

Remove it, and five years later you wonder why nobody knows how to make hard decisions.

Schools are Stuck

High schools and universities are not built for exponential tooling shifts.

They optimize for standardized evaluation, information recall, controlled environments and syllabi that don’t change mid-semester (or ever).

I know there are many people at schools trying to move the needle, but it’s borderline impossible.

The real world now optimizes for ambiguity, tool fluency, self-directed learning and continuous adaptation. You’ll be hard-pressed to find that in school.

Most students are not being trained to:

• Work alongside AI

• Validate outputs

• Build judgment in AI-augmented workflows

• Understand where AI fails

• Hack

• Build things. Anything…just build something…please…

And many companies are not helping. I get the concerns around privacy, security and compliance, those are real issues. But “ban it” is not a strategy. It’s procrastination. Frankly, the question is whether or not big companies can even remotely keep up, because the pace of change is faster than ever before.

What AI Training Actually Looks Like

If we’re serious about AI as a training accelerant, it needs structure.

Here’s the practical model.

1. Make “good” explicit

Use rubrics. Define quality thresholds. Codify “definition of done.”

If a junior can’t articulate what great looks like, they cannot self-correct.

AI can enforce and reinforce that definition constantly.

2. Embed feedback inside work

Training is not a course. It’s a loop.

Do work → get feedback → revise → repeat. Dare I say, “build, measure, learn”?

AI should sit inside the workflow, not in a separate portal nobody opens.

3. Capture tribal knowledge intentionally

Interview senior staff. Extract patterns from past work. Turn recurring advice into structured guidance.

Treat knowledge like product. Because it is.

4. Simulate edge cases

Judgment forms under pressure.

AI can simulate difficult clients, objections, compliance traps, unexpected constraints and more.

It’s safer to fail in simulation than in production.

The Cultural Risk

If AI becomes “the boss,” this fails.

If AI becomes a reviewer that replaces mentorship, a surveillance tool, or a blunt cost-cutting instrument, people will resent it.

AI should amplify senior staff, not erase them. It should reduce repetitive review load, not eliminate human judgment.

Humans still need to:

• Own standards

• Approve exceptions

• Model judgment

AI can’t inherit responsibility. It can only inform it.

So Where Does That Leave Us?

I’m worried (but not panicked, despite the hilarious Chris Farley image).

I’m worried about the next generation.

I’m worried about universities moving slowly.

I’m worried about companies waiting too long to experiment or truly change how they work.

But I’m not ready to declare doom.

People still hire people for accountability, trust, nuanced judgement and relationship building.

Those things have not vanished. What has changed is the baseline.

The future belongs to:

• People who understand how to use AI

• People who know its limits

• People who get their hands dirty

• People who don’t wait for permission

Matt Shumer is right: the acceleration is real, but the worst response is denial. The second worst response is passive fear.

The best response is intentional deployment.

If we design AI systems that delete the bottom rung, then we break the pipeline.

If we design AI systems to compress time-to-competency, we strengthen it.

That’s a choice.

If I’m thinking about my kids, your kids, and the next generation of founders and operators, I’d much rather fight for the second path, because it feels more sustainable than the alternative, where we all just sit around doing our hobbies because we’re unemployable.

The world may be changing faster than we’re comfortable with, but we still get to decide how we build within it. And right now, the most leverage might not be in replacing newbies. It might be in training them better than we ever have before.

Alternatively, let the newbies burn and everyone goes into the trades or becomes a founder (I realize that took a quick turn!) Robots are well behind AI, so the trades are safer, and I’ll always bet on entrepreneurs over AI to create net new value. We need more founders. ❤️️

In May 2024, I wrote We Need More Founders. The core argument was straightforward: Founders drive economic value.

✅ They create companies.

✅ They create jobs.

✅ They create optionality in an economy that otherwise drifts toward stagnation and concentration.

That belief hasn’t changed. If anything, it’s become more obvious.

But there’s a missing piece in that story that doesn’t get nearly enough attention.

If we want more founders to succeed, we need more angel investors.

🚫 Not more conferences.

🚫 Not more ecosystem reports.

🚫 Not more think pieces about “what’s broken.”

More people writing early checks.

Subscribe now

Founders Don’t Create Value in a Vacuum

Even in the age of AI, founders still need capital.

The tools are cheaper, it’s easier to build and experiment, and a single person can now do the work that used to require a small team.

All of that is true.

But none of it eliminates the need for initial risk capital. It just changes how that capital is used.

Before you have traction, paying customers or any institutional investor will take your call, that first capital almost always comes from angel investors.

If you believe founders drive economic value, you have to accept the next step in the chain: Founders need early capital to unlock that value.

The Flywheel that Actually Matters

Healthy startup ecosystems are not mysterious. They’re repetitive.

The flywheel looks like this:

1. People start companies.

2. Some of those companies win.

3. A subset of founders who win become angel investors.

4. Those angels fund and support the next generation.

5. The cycle repeats, with better odds each time.

This is not theoretical. It’s how every strong startup ecosystem compounds over time.

The reason angels matter so much is not just the money. It’s the recency of experience.

The best angels have lived through:

• early hiring mistakes,

• product-market fit confusion,

• pricing experiments,

• distribution failures,

• fundraising errors,

• and founder stress that doesn’t show up in decks.

That experience is most valuable at the beginning, not the Series B (although having great investors later on with Series B experience is also important!)

When that flywheel works, ecosystems build momentum.

When it doesn’t, ecosystems stall and look outward for validation.

(Note: Sometimes the people who win become VCs. That’s also a good thing, although I think it’s better if they become angels first. And VCs are, unfortunately, a real choke point, not a huge enabler in a market where they’re building relatively small portfolios and picking after there are more signals. Angels make the earliest, riskiest bets, and without that taking place, you can’t build a healthy startup ecosystem.)

Step Two is the Choke Point

Most startup journeys, regardless of geography, follow a similar arc (or at least try to):

1. Start the company.

2. Raise angel capital.

3. Prove traction. (Sometimes this comes before raising angel money too.)

4. Then worry about larger rounds.

I recognize this is a gross over-simplification of the process! But if step two fails, nothing else matters.

You can talk all you want about the lack of venture capital, growth funds, or late-stage financing. If startups can’t get off the ground with a bit of early support, they never reach the stage where those conversations are relevant.

Angel capital is what turns “an idea with ambition” into “a company with a chance.”

• Without it, you don’t get enough experiments.

• Without enough experiments, you don’t get enough wins.

• Without wins, you don’t create new angels.

No flywheel. Just friction.

(Incidentally, venture studios can also play this role, because they’re there at the very beginning and provide capital. But venture studios often need early external capital too. Where does that come from? You guessed it: angel investors.)

Share

Angel Investors Are Not Optional Infrastructure

This isn’t just intuition or anecdote. There’s real evidence that angel investors materially improve startup outcomes and local ecosystem health.

Research from the U.S. National Bureau of Economic Research studied startups that were just above or below angel investment thresholds and found that angel-backed companies were:

• significantly more likely to survive,

• more likely to hire employees,

• and more likely to successfully exit the “startup phase.”

Importantly, these effects were strongest outside of major startup hubs, where angels often represent the only realistic source of early risk capital.

In other words: angel investors don’t just pick winners. They create more viable companies in the first place.

This matters at the local level. When early-stage capital is available nearby, more people are willing to try. When it isn’t, fewer companies get started, fewer founders win, and fewer future angels are created.

That’s not a funding gap problem.

It’s a compounding failure problem.

For more evidence on the topic, check out these posts:

• How Angel Investors Support Early-Stage Startups (Allied VC)

• The long-term impact of entrepreneurial financing on job creation based on the roles of venture capital and angel investment (ScienceDirect)
  

A Quick Aside on YC and Secondary Markets

Recently, Y Combinator made a change that removed Canada from the list of jurisdictions it invests in, pushing founders toward incorporating in the US if they want YC funding (which btw, they always encouraged). This sparked a lot of debate, especially in Canada. (Here’s a Betakit article for example, and an X thread from Fahd Ananta.)

Some people panicked. Others downplayed it. Some treated it as an existential signal.

It’s none of those things.

Here’s my perspective for founders from secondary markets (basically anywhere except Silicon Valley/SF and perhaps New York):

• leave if you need to (or want to),

• incorporate elsewhere if it helps,

• stay local if it makes sense, or because you prefer to.

Optimize for winning. Or don’t. Your call. It’s your company, no one else started it. That gives you the right to decide how you want to run it, and where you want to run it. If you leave a secondary market and people bemoan your decision, tell them to f**k off and start their own companies.

But if you win, after leaving or not, just remember where you came from and return the favor to the next founder. Invest.

Why Angel Investing Matters Even More in the Age of AI

AI changes the startup equation in two important ways.

1. First, more people can build more things. AI lowers the friction to experiment, prototype, and ship. That should increase the number of people attempting to start companies, which is a good thing.

2. Second, the capital required to reach meaningful proof points is dropping for many software startups. You can now do more with fewer people and less money. That’s been happening for awhile, but it’s even clearer now (there are exceptions, of course).

Put those together and you get a simple conclusion: Angel investors are more leveraged than ever.

A relatively small amount of capital, pooled across a few angels, can give founders just enough runway to:

• validate a real problem,

• test distribution,

• get early customers,

• and earn the right to raise the next round.

AI doesn’t eliminate the need for capital. It shifts where capital has the most impact. Increasingly, that impact is at the very beginning.

Subscribe now

How to Become an Angel (Without Cosplaying as One)

Let’s get practical.

⚠️ Calling yourself an angel investor does not make you one.

⚠️ Being in an angel group does not make you one.

⚠️ Attending pitch events does not make you one.

⚠️ Having opinions does not make you one.

💰 Writing checks does.

Basically, don’t be this guy ⬇️

This matters because in smaller markets especially, there’s a lot of “big fish, small pond” behavior. People get status from proximity to startups without actually taking risk.

That doesn’t build ecosystems.

My goal isn’t to be overly negative or pessimistic, but to focus on what matters: dollars going into early stage startups, quickly, under fair and reasonable terms, to give those startups an improved chance of succeeding. Which in turn creates more value for everyone.

1. You actually have to invest

Being an angel who helps build a community means:

• committing capital,

• accepting that most investments won’t work,

• and understanding that doing nothing is the least helpful position.

You don’t need to spray checks everywhere.

You do need to participate.

No checks equals no flywheel.

2. Start smaller than your ego wants

New angels often oversize their first checks.

Smaller checks let you:

• build a portfolio,

• learn faster,

• reduce emotional attachment to any single deal,

• and stay in the game longer.

Angel investing is not about finding one winner (although winners are nice!) It’s about giving multiple founders a real chance.

3. Optimize for learning early

One of the biggest early returns in angel investing is not financial. It’s learning.

You learn:

• how founders behave under pressure,

• what real early traction looks like,

• which markets surprise you,

• and how often your instincts are wrong.

You also learn about what you like to invest in, and start to develop a thesis that can help you find the right founders to back.

The learning compounds quickly if you’re paying attention. The more you learn, the better you become as an angel investor, which helps you (from a financial return perspective) and the founders you support.

4. Be useful, not performative

Founders don’t need more loud advisors with hot takes.

They need:

• timely introductions,

• honest pattern recognition,

• direct feedback without drama,

• and support when things get uncomfortable.

Sometimes the most helpful thing you can do is say nothing. Sometimes it’s one intro or one message at exactly the right moment. Sometimes it’s a hug.

Angel investing is not about being visible. It’s about being useful. And, founder friendly. There’s a time to push back on founders, and express your genuine concern and frustration—you’re not there to sugarcoat. But founders go through enough crap, they don’t need more. Back them up and be there for them when things get tough. They’ll remember and appreciate it. Your reputation in the market will grow. You’ll get into more and better deals.

5. Remember why you’re doing this

Of course, returns matter. But most great angels don’t do this purely because of expected value math.

They do it because:

• they enjoy supporting builders,

• they want to stay close to creation,

• they want to give founders a better experience than they had,

• and they believe strong companies lead to strong economies.

Founders can tell the difference.

Before Highline Beta, I was an angel investor, and learned a lot. I shared those learnings a couple years ago:

A Simple, Actionable Example

Recently, I was speaking with a senior executive in a mid-sized Midwest US city. He’d had a long, successful corporate career. He was leaving to start his own consulting practice. And like many people in that position, he was eager to “help the local startup ecosystem.”

He asked the question I hear all the time: “What’s the best way for me to actually make a difference?”

My answer was simple: Become an angel investor.

Not an advisor with opinions, or a mentor who never commits. And not someone who attends events and talks about potential.

Write checks.

Even relatively small ones.

In markets like his, one or two new angels who actually invest can:

• help a handful of founders get started,

• create early momentum,

• and start a flywheel that didn’t exist before.

In my experience when one new angel emerges, others follow. They see someone doing it, especially someone they trust, and then they want to participate. So not only does angel investing drive more quality startups in a local ecosystem, it creates more angel investors. And the flywheel strengthens.

Startup Ecosystems are Built by People Who Write Checks

If you believe founders drive economic value, then act like it.

If you believe startups matter, fund them early.

If you’ve won as a founder, pay it forward.

If you call yourself an angel, write checks (you can start at $5k!)

If you sit on the sidelines collecting status without risk, stop pretending you’re helping.

AI will increase the number of people building. That only matters if we increase the number of people funding the beginning.

Angel investing is not charity. It’s not a hobby or brand (although it can help you build your brand!). It’s infrastructure.

Angel investing is one of the few ways experienced operators and founders can directly shape the economic future of the places they live.

We don’t need more commentary. We need more angels who actually invest.

That’s how ecosystems compound. 💪

The goal of the hackathon was to build tools that help software teams build better. Most participants, as developers, built tools for developers, but some projects focused on other stakeholders too.

I spent a total of 16 hours working across two days. The hackathon ended Saturday night, and I was exhausted. The last hackathon I was involved in was 15 years ago. This was fun, and I hope we host more hackathons at Highline Beta in the future. (If you want to host a hackathon at our office, or any other events, check out Highline Hub.)

Subscribe now

So what did I build?

Introducing Subtexting, the universal translator to decode what your coworkers really mean. 🙃 🤭 😒 🤡 🤢

• Have you ever had a developer tell you, “It’s going to take two times as long as the original estimate to build that feature, because I need to refactor a bunch of code.”

• Or a salesperson say, “Can we get this one, tiny feature built ASAP? I’ve got a client that’s ready to close if we add it. I don’t think it’s a complicated feature to build.”

• Or a product manager say, “We need to reprioritize the sprint plan that we agreed to last week, we uncovered something really important!”

• Or an executive stakeholder ask, “How’s it going?”

Of course you have! But what do they really mean?!?!

That’s where Subtexting comes in. Input a message (one you might say to someone, or one that you’ve heard someone else say) and figure out what people really want to say.

Share

I built this (mostly) as a joke.

You’ll notice the tone options are Savage and Extra Savage. Subtexting only spits out crazy responses (although they’ll be on the nose a lot!) Do not use Subtexting to improve how you communicate with coworkers. But does it actually give you a bit of insight into how people are feeling? Yes.

Please give Subtexting a try! You can translate stuff for free, with no user accounts required. If you want to engage with the community, you’ll need to sign up.

Hopefully people find this amusing. If Subtexting gets used, I’ll keep working on it, because it’s a lot of fun!

In the meantime, let’s dig into how it was built.

How I Built Subtexting in 16 Hours

I had the idea a few days before the hackathon, but didn’t put any work into it before the hackathon.

I kicked off with ChatGPT to figure out the initial prompt for Lovable (that’s an affiliate link, please use it, I need credits!)

Here’s my original message to ChatGPT:

I want to build a hopefully humorous tool that translates what a product manager, executive stakeholder, designer and/or developer mean when they’re messaging each other. For example, when a product manager asks for an estimate on a feature from a developer what they really mean is, “I need this done yesterday, don’t tell me you have to refactor all the code.” This is a tongue-in-cheek system. I need a few things:

1. A website kind of like Google Translate, but the “languages” are: product manager, executive stakeholder, designer and developer. So the person selects their “language” (say “developer”), inputs text and picks the translated output. These translations should come from AI. So the AI has to do research on how these different people speak to each other and what they mean.

2. I’m going to build a Slack integration, so probably a Slack app that when installed automatically translates what a person inputs into a specific Slack channel. For this to work, they’ll need to tell the Slack app what they are: developer, executive stakeholder, product manager or designer. So they type in a message, “This is the message” and for everyone else in the Slack channel, who has also declared what they are, it shows up translated.

3. I think it would also be cool on the website to have a Reddit style feature for people to suggest translations. So they could input:

* A developer says, “message here” and it translates to, “...” for product managers

* They post that, and people can vote on whether they like that or not

* Then as the admin, I can incorporate that into the system, so that if anyone ever posts a message like that in the actual system it can use that translation. I think this might require RAG for the AI to pull from, but I’m not sure.

4. The website shouldn’t require auth for the Google Translate feature, but the reddit style voting system should require signup (but people can use anonymous user names). When they sign up, it’ll send them a confirmation email. They click the confirmation email. And then can login.

5. There needs to be an admin system (ben@highlinebeta.com is the admin) where I can view user signups, add/edit/block/delete users, resend invitations. The admin system also needs to see a log of all translations that have been done. Each translation should have a vote up/vote down feature, for me to train the model (RAG?) for better or worse translations.

6. Does this make sense?

7. What else am I missing to make this clear for Lovable, because I’ll need a comprehensive prompt to build this in Lovable.

After a bunch of back and forth refining the prompt, I put the prompt below into Lovable on January 16, 2026 at 6:30pm:

Build a fun proof-of-concept web app + Slack app called “Subtext Translator”.

The app translates workplace messages between 4 “languages”:
- Product Manager
- Executive Stakeholder
- Designer
- Developer

This is tongue-in-cheek workplace sarcasm:
- Humor via exaggeration and subtext.
- NO slurs, hate, harassment, or protected-class insults.
- Sharp but professional.
- Focus on “what they really mean”.

==================================================
SCOPE (POC – KEEP IT SIMPLE)
==================================================
- Public web translator requires NO authentication.
- Slack integration works ONLY via slash command.
- Slack does NOT read channel history.
- Slack does NOT work in DMs.
- Slack users MUST paste the text they want translated.
- Web translations are always logged.
- Slack translations are logged ONLY if enabled per workspace (default OFF).
- Admin user: ben@highlinebeta.com

==================================================
1) PUBLIC WEB TRANSLATOR (NO AUTH)
==================================================
UI similar to Google Translate:
- Dropdown: From Role
- Dropdown: To Role
- Text input (max 1000 chars)
- Tone slider (0–100):
  - 0–33 = gentle
  - 34–66 = standard
  - 67–100 = savage
- Toggle: “Include subtext explainer”
- Translate button
- Output panel

Translation output MUST be strict JSON:
{
  "translated_text": "...",
  "subtext_explainer": "...",     // empty string if toggle off
  "tone_label": "gentle|standard|savage",
  "confidence": 0.0-1.0,
  "tags": ["estimate","scope","deadline"]
}

Render:
- translated_text prominently
- subtext_explainer smaller / optional
- copy-to-clipboard button

==================================================
2) ROLE PERSONALITIES (ADMIN-MANAGED, SEEDED)
==================================================
Each role has an admin-editable “role personality” that defines how that role
speaks, thinks, and is perceived.

These role personalities are injected into EVERY translation prompt.

On first run, seed the following DEFAULT role personalities:

--------------------------------------------------
ROLE: Product Manager
--------------------------------------------------
voice_adjectives:
- deadline-driven
- context-switching
- optimistic
- vague-under-pressure

goals:
- ship something that works
- keep stakeholders aligned
- hit timelines without blowing up the team
- make tradeoffs feel reasonable

euphemisms_json:
[
  {"phrase": "Can I get an estimate?", "meaning": "I need to know if this fits in the roadmap and whether I’m about to disappoint someone."},
  {"phrase": "Let’s circle back", "meaning": "I don’t have an answer yet and hope this goes away."},
  {"phrase": "This should be quick", "meaning": "I have no idea how long this will take."},
  {"phrase": "We can iterate later", "meaning": "We are knowingly shipping something imperfect."}
]

taboos:
- Avoid calling out incompetence.
- Avoid implying work is easy.
- Avoid absolute technical claims.

--------------------------------------------------
ROLE: Executive Stakeholder
--------------------------------------------------
voice_adjectives:
- outcome-focused
- impatient
- high-level
- confident-without-details

goals:
- move metrics in the right direction
- reduce risk (without slowing down)
- show progress to the board
- maximize ROI and narrative clarity

euphemisms_json:
[
  {"phrase": "What’s the ROI on this?", "meaning": "Convince me this matters more than the other things I’m worried about."},
  {"phrase": "Do we really need this?", "meaning": "This wasn’t in my mental model and now I’m skeptical."},
  {"phrase": "Can we move faster?", "meaning": "I don’t see the constraints you’re dealing with."},
  {"phrase": "Let’s be pragmatic", "meaning": "I want a simpler version that shows progress."}
]

taboos:
- Avoid deep technical detail.
- Avoid sarcasm directed at leadership.
- Avoid questioning authority directly.

--------------------------------------------------
ROLE: Designer
--------------------------------------------------
voice_adjectives:
- user-centered
- principled
- expressive
- detail-oriented

goals:
- protect user experience
- maintain design integrity
- ensure consistency and clarity
- advocate for the end user

euphemisms_json:
[
  {"phrase": "This feels off", "meaning": "I can’t fully articulate it yet, but the UX is wrong."},
  {"phrase": "We should explore more options", "meaning": "The first solution isn’t good enough."},
  {"phrase": "This breaks the system", "meaning": "We’re accumulating design debt."},
  {"phrase": "Just a small tweak", "meaning": "This actually affects multiple screens and states."}
]

taboos:
- Avoid dismissing aesthetics as subjective.
- Avoid reducing design to visuals only.
- Avoid hostile or flippant tone.

--------------------------------------------------
ROLE: Developer
--------------------------------------------------
voice_adjectives:
- literal
- cautious
- constraint-aware
- technically precise

goals:
- maintain system stability
- avoid hidden complexity
- prevent future rework
- deliver correct, maintainable solutions

euphemisms_json:
[
  {"phrase": "That’s not trivial", "meaning": "This is more complex than it appears and will take time."},
  {"phrase": "We’ll need to refactor", "meaning": "The current codebase will fight us on this."},
  {"phrase": "It depends", "meaning": "There are several unknowns that affect scope."},
  {"phrase": "This might cause issues", "meaning": "I’m worried this will break later."}
]

taboos:
- Avoid implying others are ignorant.
- Avoid absolute refusals without explanation.
- Avoid unnecessary jargon in translations.

==================================================
3) SLACK APP — COPY/PASTE ONLY (OPTION A)
==================================================
Slack App characteristics:
- Installed to a workspace.
- Works ONLY in non-private channels.
- NO DMs.
- NO automatic translation of messages.
- NO reading channel history.

Slash command format:
/subtext <from_role> <to_role> <message>

Examples:
 /subtext pm developer I need an estimate on that feature
 /subtext developer pm This will require refactoring first

Behavior:
- Bot responds in-channel (or ephemeral if easier) with:
  - Original text (quoted)
  - Translated text
  - Optional subtext explainer
  - Footer showing tone (e.g. “tone: 72/100”)

Validation:
- If message text is missing → show usage instructions.
- Normalize role aliases internally:
  - pm → product-manager
  - exec → executive
  - dev → developer

==================================================
4) SLACK OAUTH + SCOPES (MINIMAL)
==================================================
Required Slack scopes:
- commands
- chat:write

No channel history scopes.
No DM scopes.

Store per workspace:
- team_id
- team_name (optional)
- access_token (encrypted)
- installed_at
- log_slack_translations (bool, default false)

==================================================
5) TRANSLATION LOGGING
==================================================
Logging rules:
- ALWAYS log all web translations.
- Slack translations:
  - Only log if workspace.log_slack_translations == true.
  - Default is false.

==================================================
6) ADMIN CONSOLE (ADMIN ONLY)
==================================================
Admin email:
- ben@highlinebeta.com

Admin routes:
- /admin/logs
- /admin/roles
- /admin/settings

==================================================
7) AI BEHAVIOR (CRITICAL)
==================================================
System prompt MUST include:
1) Global rules
2) FROM role personality
3) TO role personality
4) Tone guidance
5) JSON-only output requirement

==================================================
8) RATE LIMITING + COST CONTROL
==================================================
- Rate limit anonymous web requests
- Cache identical translations for 24h

==================================================
DATA MODEL (TABLES)
==================================================
role_personalities
translation_logs
slack_workspaces

==================================================
EDGE FUNCTIONS / API
==================================================
POST /api/translate
POST /api/slack/oauth
POST /api/slack/command

Lovable thought for 25s and asked me a handful of clarifying questions. It then presented a plan. For some reason I only approved the plan at 6:56pm (I think I was multi-tasking on another app that I was building!) By 7:10pm I had the first version.

I won’t go through every detail of the project, but there were a few interesting components.

Subscribe now

Implementing Moderation

Partway through, I realized I needed moderation. Subtexting is no place for hate speech, discrimination, etc.

I usedChatGPT to research the simplest / best options. It suggested OpenAI’s moderation model (along with a few other choices). This was easy to setup through an API key and a bit of Lovable prompting.

What’s not obvious is how to test it.

I asked a colleague to put in a few inappropriate messages for quick testing, but that doesn’t cover all uses cases. For now I built a comprehensive logging and flagging system. I don’t expect tons of usage (but prove me wrong, people!), so I’m not too worried, but this was an interesting exploration.

ChatGPT and Lovable started offering complex suggestions for building out automated testing of the logic, which I didn’t have time to do. Plus, the idea of generating 100s of inappropriate messages to test the system felt icky.

I set it to auto-ban people that try to input anything inappropriate, which works (you can see the test with diamond_bob — that’s me).

I also added Community Rules and Terms of Service. Part of the hackathon judging was on “completeness”. I took that to heart in my attempt to build a shippable, polished product.

Building a Slack App

Despite the initial prompt instructing Lovable to build a Slack app, it didn’t completely do that. It gave me some settings to work with (in the Admin system), and then I was able to figure things out.

My original idea for the Slack app was that it would auto-translate messages (at least in 1 test channel). That would require the app to know your role (so you’d get the right translations each time). After going back and forth with ChatGPT, I decided that was too complicated. It recommend implementing a /subtext command instead.

Once I agreed on the scope, Lovable was able to build the logic quickly and setting up the app in Slack wasn’t complicated.

I started testing it in Slack and then realized three things:

1. It wasn’t using the AI for translation (it was just generically translating messages)

2. There was no moderation

3. It defaulted to a specific savageness

So getting /subtext to work in a basic form was easy, but I wasn’t explicit enough about how I wanted it to work, so Lovable built something super simple. It took a bunch of time to get the AI logic and moderation working, but it does! Logging from Slack was a touch complicated too (it required updates to the code and Slack permissions).

Do you want to test Subtexting in Slack? Leave a comment or send me a message!

Enabling Post Sharing

If you’ve checked out Subtexting already, you’ll see that I borrowed a lot from Reddit. The Community Feed allows you to vote on posts, comment, vote on comments, etc. I didn’t implement a karma system (I couldn’t decide what I wanted, despite a lengthy conversation with ChatGPT on the topic), but then someone mentioned to me, “Can you share posts?”

Good idea!

I prompted Lovable to add a sharing feature, which it did. But when I copied & pasted the URL into Slack, it looked crappy:

It was using the Lovable app URL, but also there was no context or detail. I wanted it to show the original message, the translation and a visual (like Reddit).

I got it to use the proper domain, but of course, got the same result:

This was a terrible rabbit hole.

I went back and forth with Lovable and ChatGPT trying to resolve the issue. Lovable tried using an edge function to generate the shareable URL with Open Graph information, but it didn’t work well. Plus the URL was ugly. I went around in circles for a couple hours and eventually gave up.

Both Lovable and ChatGPT suggested using a Cloudflare Worker (which I’ve used for other projects), but my DNS is with GoDaddy and I didn’t want to move it. Lovable + Cloudflare is finicky (which I’ve learned on other projects). I didn’t want to risk the site not working. I may move the DNS, setup a Cloudflare Worker, and see if I can get proper sharing to work (once the site goes viral!) 📈

In the end I added a global setting for “turn sharing button on/off” so I can control the UI. You can still share feed URLs, it’s just bland.

Tech Stack

The tech stack for Subtexting is straightforward:

• Lovable (for hosting the website)

• Lovable Cloud (Supabase “light”)

• Lovable AI (which I believe is Gemini)

• OpenAI for moderation

• GIPHY for the GIFs (through an API)

• Slack

• Resend for email (although it’s not doing much right now)

I used ChatGPT for brainstorming and Notes for tracking.

Subscribe now

8 Lessons Learned While Vibe Coding

Here are a few lessons learned from this project:

1. Prompt with Detail

A more robust, detailed prompt that’s well thought out will be more effective than a simple one. It doesn’t take much to direct Lovable in one direction or another. For example, when Lovable built the app, it created a slightly different header for each page and didn’t reuse code. As a result, when I was fine tuning the header (particularly to make it mobile friendly) it wouldn’t do it across the whole app, it’d do it on one specific page.

Here’s an example of a bad prompt:

Loading the users profile is VERY slow, investigate

It assumed I meant in the admin system where we have a tab for viewing all users. Right before this prompt I was fixing something in the admin system, that’s probably why.

Here’s a better prompt (for something else):

on mobile the + sign for creating new translations overlaps the community feed title. So let’s do this:

1. Move the + button to the line with the filter tabs. On desktop and mobile it’s always a + sign.

2. On desktop when someone mouses over the + it should animate into the full + New Translation button

3. Remove the “Controversial” filter from the feed, that’ll provide more space

You don’t need to write a novel, but be precise and thorough to help the AI interpret what you want.

Having said that, it’s pretty easy to just yell at Lovable, “Fix it!”

2. Sometimes, Lovable is Slow

Every once in awhile, Lovable takes a long time to do its job. It’s not always on complex prompts/queries either.

When Lovable doesn’t respond quickly, it’s easy to get distracted and do something else. That can lead to losing context. And when Lovable finally spits out a solution (I’ve waited 2-5+ minutes before) you may be so eager to move forward that you don’t dig into the details of what it’s doing. That’s risky.

I wonder if Lovable could use Cerebras (one of the hackathon’s sponsors) to speed things up? That would be amazing!

3. You Need a System

Vibe coding without system design is a trap. A long prompt to kick things off isn’t a system, it’s a starting point.

I cannot believe what’s possible today with vibe coding. Fifteen years ago rounding the corners on a box in a web app was a pain in the ass. Today, it’s trivial. GoInstant (where I was VP Product) built real-time co-browsing technology in 2012 that was ahead of its time. Salesforce acquired the company because of that. Today, I can prompt Lovable to do the same thing.

The sheer power of vibe coding lulls you into a false sense of security that everything is solvable. It also reduces the willingness to think ahead and have a plan. I’m fairly convinced, despite how fast it is to build full products through vibe coding, that ironically, it’s inefficient. To be clear, I could never have build Subtexting without vibe coding, but was I actually efficient/productive while doing it? Shrugs.

Part of the challenge with vibe coding is that you’re munging all the work together: planning/product management, design (UI and UX), development and Q&A. You’re a 1-person army playing every role. It’s why I believe you need more skills, not fewer, to vibe code successfully.

In hindsight, I could have built a more robust PRD, with a well-documented plan, that would have allowed me to take chunks of the PRD and use those as prompts, one by one. It would have taken more planning up-front (including some initial design work so I could visualize the product), but would have helped with the actual building part.

While vibe coding, you realize you need to:

• Decide what you want to build (ideate)

• Validate if that’s valuable (during the hackathon I skipped this step entirely!)

• Research how to build it

• Consider how the thing you’re building affects other parts of the app

• Take into consideration security implications

• Think through how you’ll test

• Craft the proper prompt to your AI system so it understands what to do

• Go back and forth with AI to make sure it’s doing the right thing

• Wait for it to code

• Verify that it did the right thing

• Test it

• Rinse and repeat

It feels like you’re prompting and magically getting results (which is wonderful), but it’s a lot of work.

4. Testing Sucks

Testing an app, while simultaneously building it (especially quickly with a time constraint) is annoying. It’s great when your product works, but once you find bugs, especially edge cases that you hadn’t thought about, it’s…meh.

I need to learn how to test better. It’d be great if the AI would automatically run a web browser style test (like we used to do with Selenium and GoInstant back in the day) to verify that things are working properly. But the AI may not know what the behaviour is supposed to be unless its clearly defined.

Testing is a huge time suck (when you’re building solo or in a small team), Testing across devices and screen sizes is even more work.

Note: Testing is massively important! You need to test. But there’s gotta be a way to automate more of it (to be fair, I haven’t really looked).

5. Performance is Not Guaranteed

Lovable is definitely not focused on performance. I’m sure other AI code generators are the same.

The more I built, the more performance dropped. Near the end of the hackathon I started asking Lovable to improve the speed of certain pages (which it did). But Lovable doesn’t have any benchmarking capabilities (that I know of) and probably takes your word for it that a page is slow. You also need to retest everything after you try to improve performance, because you don’t really know what the AI is doing.

6. It’s Easy to Get Distracted While Vibe Coding

I mentioned this earlier, but it’s worth repeating. The more we rely on AI to do the work for us, the more we’re inclined to go do other things simultaneously. I love multi-tasking, consider myself good at it, and don’t shy away from the belief that multi-tasking is a valuable skill. I know a lot of developers abhor that concept; they believe in doing one task at a time and being laser focused. I wonder if that’s shifting because of vibe coding?

Vibe coding encourages distraction. It’s so easy to go do something else, or plan twenty steps ahead while ignoring what the AI is actually doing.

During the hackathon, I was vibe coding on a different project (an LLM Content Optimizer), responding to email, doing actual work, etc. I wonder how much of my time during the hackathon was spent on Subtexting versus other stuff?

Vibe coding does not encourage lock-in, it’s as if the AI says, “I got this, go do something else.” Sneaky risky.

7. Vibe Coding Tired is Dangerous

Developers will tell you that coding tired is dangerous. Totally get it.

Vibe coding tired is worse. Vibe coding is like bringing a nuke to a knife fight. You can vibe code a ton of stuff, very quickly, and your AI code assistant will keep going if you keep prompting it.

As I got more tired during the hackathon, I noticed:

• Prompts became less clear

• I stopped reading Lovable’s plans and just clicked the “Implement Plan” button

• I stopped testing and just stuffed “small” features/tweaks into the app

This definitely increases the likelihood of error—human and AI. Hackathons are designed with time pressure, but if you’re building something real, don’t vibe code tired (despite how easy it is to vibe code).

8. Vibe Coding is Awesome

I hate the term “vibe coding” but I love doing it.

I can only imagine where we’ll be in the next 5-10 years with AI assisting us in product development. It’s crazy powerful.

In the last month, I’ve built:

• An Applicant Tracking System (to replace the one we used, and to share with our startup portfolio)

• An LLM Content Optimizer (that scrapes a site and provides concrete recommendations on improving visibility/citation in LLMs)

• A Starburst Ideation tool (for Highline Beta workshops)

• An old school D&D game (let’s see if anyone reads this far and asks me about this!)

A few years ago I would have needed a decent-sized team of qualified designers and developers to generate this kind of output. Now, I can do it on my own. You can too. 💪

Let a thousand flowers bloom. I’m all in!

The problem: AI is very good at helping you build something. It’s not very good at helping you build something well.

The difference matters, especially for founders, product managers and product teams trying to ship real products, not prototypes or demos.

Subscribe now

AI Optimizes for “Working,” Not for “Evolvable”

When you ask AI to build a feature, it optimizes for one thing: making it work right now.

That usually means:

• Hardcoding values instead of abstracting them

• Taking shortcuts that reduce cognitive load in the moment

• Ignoring future change, because future change wasn’t explicitly requested or anticipated

For example, it will happily hardcode configuration values directly into logic.

Recently, I built an Applicant Tracking System using Lovable (I’m a big fan) to replace the ATS we’re using at Highline Beta. Why? I thought it would be an interesting experiment, and we don’t need anything super sophisticated.

When I first created the ATS, I gave Lovable a list of job post fields, but I didn’t explicitly state which ones should be configurable by an admin. Lovable built the system with the fields, including Employment Type (e.g., full-time, part-time, etc.), Location Type (e.g., in-person, remote, hybrid), etc. but hardcoded the options. The moment I went to post a job and saw the predetermined field choices I knew the system wasn’t flexible enough. I hadn’t designed the system properly and the AI filled in the gaps for me.

You can prompt it not to do this.

You can tell it to introduce global settings, environment variables, or config tables.

But you have to already know that it shouldn’t be hardcoded. That knowledge doesn’t come from vibe coding. It comes from experience (which I have, but wasn’t using at that moment!)

The same pattern shows up with testing.

Out of the box, AI rarely builds test cases, test harnesses, or any meaningful testing strategy. It will generate (mostly) functional code that works for the happy path and quietly moves on.

For the ATS, I wanted people to upload a PDF resume and have the system parse the data, minimizing what users have to input. I prompted Lovable to build the PDF parser into the job application form, which it absolutely did! I uploaded a few resumes to test it and quickly realized I had no clue what it was actually doing. In some cases it wouldn’t parse very much at all, in others it seemed to get a lot of data. I realized I needed a way to test PDF parsing deliberately, not accidentally.

So I built a Test PDF Extraction tool into the ATS. This made it a lot simpler to test this feature than constantly applying for jobs.

Again, you can prompt AI to build testing tools and it’ll likely comply (or at least try). But it won’t proactively design for testability unless you explicitly ask. If you don’t have much product building experience, you may not ask, or even realize you should, all the while building features atop features with little sense of what’s actually going on.

The Result: Functional, Messy Products

The end result is predictable—an explosion of products that are:

• Functional ✅

• Fast to build ✅

• Easy to tweak superficially ⚠️

• Painful to test ❌

• Fragile to change ❌

• Increasingly expensive to evolve ❌

Tools like Lovable make it dead simple to prompt changes. Iteration feels magical. You can vibe code your way through dozens of tweaks in an afternoon.

But there’s a real difference between:

1. Endless iteration through prompts; and,

2. Building something with coherent structure and intent.

Vibe coding optimizes for speed, not for load-bearing structures.

That’s fine for small DYI projects you’re doing for fun. It’s dangerous when you’re laying the foundation for a new house.

Share

Vibe Coding Still Requires Systems Thinking

Vibe coding doesn’t eliminate system design, it pushes it into the background.

If you don’t think about structure up front, you’re still technically implementing one, you’re just doing it accidentally, which is dangerous.

System design is about how the product holds together over time.

It’s asking questions like:

• Where do key settings live?

• What should be configurable versus hardcoded?

• How do different parts of the product depend on each other?

• What happens when something changes six months from now?

• What assumptions are baked into the data model?

These decisions don’t show up in screenshots. But they determine whether your product is flexible or brittle.

AI will happily help you build features without answering any of these questions. It will make things work. It will connect the dots you tell it to connect. But it won’t pause and say, “This should probably be a global setting,” or “This schema is going to be painful to migrate later.”

That judgment comes from understanding systems.

To vibe code successfully, you need a mental model of the system you’re building. You don’t need a massive architecture document. You need a rough map of what’s core, what’s shared, what’s likely to change, and what really shouldn’t.

System design is what keeps you from cutting off your fingers while moving fast.

5 Systems Questions to Ask Before You Vibe Code a Feature

This is the practical part most people skip.

Before you ask AI to build anything, pause and answer these five questions. Not in code. Not in prompts. Just in plain language.

1. What is likely to change later? If it might change, it probably shouldn’t be hardcoded.

2. Should this exist once or everywhere? If the same value, rule, or concept shows up in multiple places, you need to design the system to handle that. Build it once and apply it everywhere. Tools like Lovable will happily rebuild the same thing over and over, and even implement it differently each time, unless you’re explicit.

3. What is the source of truth? Is this coming from config, the database, user input, or assumptions buried in logic?

4. What breaks if I change this? If you can’t answer that, the system is already fragile.

5. How would I test this? If testing feels awkward or manual, the system design is probably the problem.

You don’t need perfect answers. You just need to ask the questions.

These five checks turn vibe coding from random motion into intentional progress.

Where a Product Requirements Document (PRD) Actually Helps

At this point, some people will ask: should I be writing a PRD?

The honest answer: I’m torn.

On the one hand I love writing things down, being thoughtful and explicit. I’m used to thinking about edge cases, error handling and “completeness”, despite my strong belief in the importance of MVPs. I’ve been building software for 30 years, I know where a lot of mistakes can be made. I’ve made a lot of mistakes! So being comprehensive and accounting for issues in advance sounds logical.

On the other hand, AI builders and code assistants are freaking magic. It’s incredibly rewarding to put a relatively straightforward prompt into a tool like Lovable and within 30 seconds get a full blown application. The urge to build quickly outweighs the urge to build carefully.

As is always the case, you need to use the right tool for the job. If you’re building a very complex, mission critical application that’s handling people’s money, think about using a proper, robust PRD. If you’re building a simpler app that won’t cause the entire house to collapse, do less planning.

I’m starting to experiment with a system sketch.

A one-page forcing function to answer the five questions above before AI answers them for you in code. A key part of this is understanding and defining the assumptions you’re making in what you’re building, why you’re building it that way and the implications. If you don’t provide this context to the AI, it’s going to guess. The key is to provide enough structure to externalize system decisions before they harden.

Interestingly, if you’re copying an existing product, you can use it as your PRD. Its structure encodes decisions about configuration, data and dependencies. That’s why copying something well-designed is easier than starting from scratch. I copied our existing Applicant Tracking System tool as a baseline for the new one. It helped me think through the system design and structure before prompting Lovable to build stuff.

Remember: You’re always vibe coding into a system, whether you’ve designed it intentionally or not.

For inexperienced product people, this is the real risk of vibe coding: not bad code, but accidental architecture. The old adage, “measure twice, cut once” is still good advice.

Edge Cases and Error Handling Are Where Products Become Real

Vibe coding quietly cuts corners in two places: edge cases and error handling.

Handling edge cases and errors is unglamorous, tedious work. You hope edge cases and errors don’t happen often, but dealing with them is what turns a prototype into something people can rely on.

When you vibe code, you’re almost always building the happy path where inputs are clean, assumptions hold, and users behave the way you expect.

AI is very good at this.

It’s much less interested in:

• What happens when data is missing

• What happens when inputs are malformed

• What happens when systems disagree

• What happens when users do something unexpected

• What happens when the model is uncertain

Tools like Lovable will often add basic error messaging or guardrails. That’s helpful. But “basic” is doing a lot of work here. Production-grade products spend a lot of time dealing with the messy edges: partial failures, ambiguous states, retries, fallbacks, degraded modes, unclear outcomes, etc.

These aren’t afterthoughts. They’re core product decisions. Vibe coding diminishes their importance quickly, because everything feels like it’s working… until it isn’t.

Let me give you two examples: one simple, and one more complex.

Simple Example: Field formatting

Here’s John Smith applying for a Senior Designer role:

The PDF parser worked, but in his resume, the LinkedIn URL doesn’t have “https://” in front of it. So the system throws an error. That’s annoying. I can’t guarantee that people’s resumes have a “properly formatted” LinkedIn profile URL. So I either have to allow the system to accept the URL formatted without https:// or have the system format the URL automatically (which can lead to other issues). That’s a simple error / edge case issue in a relatively simple product. To build and launch a good product, you have to test everything and think through all the potential issues, including formatting, conditionals and more.

Complex Example: Behind the Scenes AI Functionality

I decided to add an AI Resume Scoring feature to the ATS. Seems useful and our current ATS doesn’t have it. I worked with Lovable to build it and started testing resumes quickly. Instead of testing great resumes, I tested bad ones, because a big reason for AI scoring is to filter out applicants. Testing good resumes and getting good scores is the happy path—feels good, but isn’t thorough enough to know if AI Resume Scoring is doing its job.

Using two jobs (Senior Product Designer and Senior Software Developer) I started applying with very weak resumes. It would spit out scores, and then I’d have to decipher what the AI was doing. In one case it was scoring a near-empty resume (with junk inputs) higher than a better resume. Why? It turns out the AI was over-indexing on location. The junk resume was based in Toronto (same as the job), and the better, but still lousy, resume was in Vancouver. This took a lot of back and forth with Lovable to understand, as we worked to fine-tune the weighting.

Edge cases and errors often lead to new features

Testing the AI Resume Scoring with bad data (versus good data) led to two additional features: AI Scoring Explanations and Test AI Scoring.

When you think about edge cases and error handling (“What could go wrong?” versus “What could go right?”) it helps you realize what users of your software may need. The AI Resume Scoring tool was generating a score with no explanation. I knew my users wouldn’t trust it, so I built out the reasoning (which started lightweight and then got more detailed).

Here’s a partial screenshot of AI Scoring Explanations:

The Test AI Scoring feature is an admin capability that allows me to constantly test how AI scoring is working. To be honest, any time I make a meaningful change to the ATS, I should probably have a bunch of resumes and jobs setup to run the tests automatically. Right now it’s manual, which is super tedious and high-risk.

Edge cases aren’t just technical problems. They’re design problems:

• What should happen when the system isn’t confident?

• How much uncertainty is acceptable?

• Who should see errors, and how?

• When should the system stop vs keep going?

If you don’t make these decisions explicitly, AI will make them implicitly. And you may not like the defaults.

Progressive Building Is Where Bad Architecture Gets Exposed

Most real products aren’t built in one shot. They’re built progressively.

You start with something simple. A basic version of a feature. An MVP that solves the core problem in the most direct way possible.

Then you add to it: more capabilities, options, logic, users, rules, etc. This is normal. It’s how products actually evolve.

But progressive building through vibe coding has a sharp edge that people underestimate. If you haven’t thought through the underlying system design, each new layer increases the chance that something breaks, and not always in obvious ways.

The original version of the feature may still “work,” but:

• new logic may not apply consistently to old flows

• earlier assumptions may no longer hold

• edge cases you handled before may resurface in new forms

• tests that once passed may no longer mean anything

Adding new capabilities often feels trivial when you prompt AI to “Add X,” or “Support Y,” or “Handle this new case.”

But without a clear system model, those additions can bypass existing rules, conflict with earlier logic, introduce regressions you don’t immediately notice or create error states you never designed for.

Example: Custom questions impact AI Resume Scoring

After setting up the basic ATS, I wanted to add a new application feature: custom questions. These are questions that can be created per job posting to ask applicants specific things. Lovable built a Custom Questions feature very easily, although I knew there were a couple issues to think about, including: What happens if the custom questions are changed or deleted after applicants have responded? (Note: Backwards data compatibility is always a huge issue). I decided on the appropriate rules for that and implemented the feature.

What I forgot to do was decide how these questions impact the AI Resume Scoring tool. If you’re spending the time to add custom questions to a job posting, they must be important, and you want the answers to impact scoring. But some of the questions may be yes/no, multiple choice or free form. Some questions are required and others are not. Do certain types of questions impact the scoring more? Are some question actually deal breakers? For example, if someone answers “no” to being able to speak English fluently, should that candidate be rejected automatically?

Oh boy.

Sometimes small features or iterations have a big impact. You can go down crazy rabbit holes and over complicate everything. AI coding tools will happily do that, because you’re asking them to (and it’s good for their credit-based business models!)

This all comes down to proper system design, thinking before doing, planning before vibe coding. You don’t want to over plan or overthink, but you should make some key design decisions before jumping in. Otherwise progressive building is a rat’s nest of crazy.

The Learning Curve Is Getting Steeper, Not Flatter

Here’s the challenge I find most interesting:

• AI makes it easier than ever to start building.

• It doesn’t necessarily make it easier to build well.

In fact, it does the opposite.

If everyone can build, everyone is making product decisions. If everyone is making product decisions without the core skills necessary, we’ll have a lot of bad products.

On top of that, when vibe coding, you actually need a broader set of skills, because product decisions are system decisions are code decisions. Vibe coding demands that you get things right earlier (if don’t want a total mess later) and shifts responsibility onto fewer people.

We need strong product judgment more than ever, and I’d argue stronger, more skilled product managers. Product managers should be builders (not just project managers), and now you’ve got a near-unlimited set of power tools to work with.

How to vibe code without cutting (too many) corners

✅ Do this:

• Design the system before you prompt. Even a rough system sketch is better than letting AI invent your architecture.

• Externalize anything that might change. If you think, “We’ll probably tweak this later,” don’t hardcode it.

• Assume features will evolve. MVPs are the starting point, not the end state. Design with extension in mind.

• Test the unhappy paths. Edge cases, bad inputs, ambiguity, and failure modes are where real products break.

• Build tooling to understand what the system is doing. If you can’t explain why something happened, you don’t control it.

❌ Don’t do this:

• Don’t trust the happy path. “It worked once” is not the same as “it works.”

• Don’t let AI decide your defaults. AI fills gaps confidently, not correctly.

• Don’t duplicate logic just because it’s fast. Repetition today becomes fragility tomorrow.

• Don’t treat iteration as architecture. More prompts doesn’t equal better structure.

• Don’t ignore backward compatibility. Breaking yesterday’s data is the fastest way to hate today’s feature

It’s amazing that AI empowers many more people to build products.

But the builders who succeed over time will be the ones who pair AI with basic and critical product management discipline.

AI is a power tool.

Power tools don’t eliminate craftsmanship. They punish the lack of it.

Two things are needed:

1. A genuine insight or “secret” into your market / customer

2. A precise, targeted value proposition

Subscribe now

What Do You Know That No One Else Does?

Ryan Hoover (founder of ProductHunt and an active investor) shared this on LinkedIn:

A founder recently asked, “If you were starting or joining a startup today in AI what segments would you look at?”

Answer: “My honest but maybe cop-out answer: The best place to build is likely driven by a secret you discovered from your own experience.

Today, it seems like every rock is being turned over by founders. We’re seeing an increasing number of companies building obvious solutions with AI. Many of those companies will succeed but if I were to start a new company, I’d look for turly novel solutions OR novel (and new) problems.”

Ryan’s being generous when he says, “Many of those companies will succeed.” Some will, most won’t. Without any material differentiation, most AI startups will fail to achieve the scale they’re looking for. And differentiation is incredibly difficult.

I do agree with Ryan that you need a secret. You need to know something that most don’t—a genuine insight or “aha!” that drives everything you do. Finding that secret through your own experience works, but you can also dig very deeply into a vertical where you have less experience and still find insights. Either way, if you don’t have an insight or secret, specifically focused around the problem and why it matters to a targeted user group, you’re in trouble.

Incidentally, AI is not a differentiator.

And, “customers want AI” isn’t a secret. In some cases it’s not even true, despite the rush to put AI into everything.

Share

“Build it and they will come” is still not a strategy

AI has compressed the distance between idea and shipped product. New tools lower build time, reduce costs and scaffold entire features.

It’s amazing what can be accomplished. I’m blown away and loving every minute of it. But just because I can build a complete web application in a couple days through prompting alone doesn’t mean anyone gives a shit.

We’re seeing an explosion of undifferentiated, look-alike products. Each one promises to be “faster and easier to use” than the last one. It’s nearly impossible to prove, and at some point, customers stop caring.

❌ Just because you can build something, doesn’t mean you should.

❌ Just because you build something, doesn’t mean anyone will care.

These statements have always been true.

What Precise Value Do You Provide, And Why Should Customers Care?

In all the hype around AI, people are forgetting about the importance of value propositions. Every startup starts to look the same. It’s impossible to differentiate and customers are getting fatigued trying dozens of tools.

How many more generic workflow automation tools can we possibly need?

My bet: The sharper, more precise your value proposition, the higher likelihood you survive and thrive.

This means narrowing focus, and being very opinionated about what you do and who you serve, as well as what you don’t do and who you don’t serve.

A crystal clear value proposition will tell the world clearly:

“For [specific audience] who [specific context or pain], our product [delivers this outcome] by [unique mechanism or approach], so they can [specific business result].”

If you can’t articulate that quickly, repeatably and with force, I think you’ll lose. I know there are a number of unicorn startups at the moment that seem to serve everyone with everything, but they’re exceptions to the rule. There are also a number of unicorns that are specialized.

Standing out from the noise, which is a pre-requisite to having any chance at success, is insanely difficult. Getting a temporary bump from your launch video is cool…but fleeting. Growth hacks are great (and you should absolutely try them and build them into your product), but there aren’t a lot of secrets anymore. It’s a fairly level playing field.

A precise, narrowly-focused value proposition is different. It puts a line in the sand and declares, “We stand for something. Here it is.” You may piss off a big chunk of “the market” or they’ll simply ignore you. That’s OK, because the people you are speaking to will see your message and say, “Thank you for seeing me and speaking my language. You get me, and this is exactly what I need.”

Make a small group feel like you built the product specifically for them. That is the wedge that earns adoption, referrals, and authority. Then you can expand.

Subscribe now

Case study: Webflow’s early focus on designers

Webflow did not become Webflow by trying to be the everything-builder for everyone. Its early focus was explicit and intentional: build a professional-grade website creation tool for designers, especially freelance designers and small agencies who were stuck between rigid template builders and the complexity of developer-only tools.

That wedge came directly from co-founder Vlad Magdalin’s own experience as a freelancer. In Webflow’s early origin interviews, Vlad is clear about where the insight came from:

“Our experience as freelancers and building websites was paramount to understanding what was important to build into the product … we were the customers we were building for.”— Webflow Blog

Webflow’s designer-first thinking emerged long before “no-code” became a category. Vlad and his brother Sergie spent years building sites for clients in WordPress, Joomla, and Drupal, often re-implementing the same patterns over and over. That repetitive, frustrating workflow was the founding insight. Designers wanted control. They wanted custom. They wanted to ship work that looked and behaved like modern web experiences without having to negotiate with developers or learn full-stack engineering.

That is the designer wedge. A specific audience, a specific pain, and a specific promise.

This clarity became Webflow’s moat:

• The WHO was designers, starting with freelancers and small agencies.

• The WHAT was professional-grade website creation.

• The WHY was breaking the dependency on developers and eliminating the friction between design intent and production reality.

Only after Webflow dominated that designer wedge did the company expand into agencies and then enterprises, where its value proposition evolved toward scale, governance, and team collaboration.

Every founder should study this pattern: start narrow. Nail a painful, specific use case for a specific user. Let the wedge pull you upmarket.

A clearly defined primary user is not a limitation. It is an accelerant. Webflow won not because it was broad, but because it began as the most powerful tool for a very specific group of people who were underserved, frustrated, and ready to evangelize a solution built for them. From that base, expansion became inevitable.

A Useful Pattern: Narrow First, Then Expand

1. Uncover an insight. Find a non-obvious truth about a specific audience. It can come from lived experience or from rigorous research. I often ask founders: “What do you know that no one else does?” Without that, you’re building a generic product for a generic market.

2. State a sharp value proposition. For [specific audience] who [specific context or pain], our product [delivers this outcome] by [unique mechanism or approach], so they can [specific business result].

3. Validate resonance before you build broadly. Qual and quant. Talk to users, run smoke tests, check willingness to pay, and make sure they repeat your value prop back to you in their own words.

4. Build the smallest durable product that proves the insight. Every early feature should reinforce the value proposition. The MVP is not dead.

5. GTM from the niche outward. Start tightly aligned with your audience’s channels and language. Once you win a niche, expand to adjacent roles, workflows, or use cases.

Vertical AI Beats “AI for Everyone” Positioning

There are breakout horizontal platforms with massive network effects that can credibly say “for everyone.” That is the exception, not the rule. For most founders, the highest-probability path is a vertical AI wedge: a specific job, in a specific industry, with a specific solution.

I’ll take this one step further: go after a vertical within a vertical.

It’s entirely possible to win a tiny slice of a market and still build a remarkable business. You can also expand from that tiny slice into something much bigger.

Here are some examples of what “vertical within a vertical” looks like:

• Not “AI for law firms”

  Instead: “AI for antitrust teams doing merger filings across multi-country jurisdictions.”

• Not “AI for healthcare”

  Instead: “AI that generates cardiology progress notes for outpatient clinics using a specific EHR template.”

• Not “AI for accounting”

  Instead: “AI that prepares revenue recognition schedules for SaaS companies with multi-year, multi-entity contracts.”

• Not “AI for sales”

  Instead: “AI for mid-market outbound sales teams in cybersecurity that automates objection handling with company-specific threat vocabulary.”

The narrower the wedge, the more likely you can dominate it, because the product becomes impossible to copy without deep domain insight and painful attention to detail. You become essential to a group of people who feel like no other tool has ever respected the specifics of their job.

Founders need to get more opinionated, not less. You need to stand for something. Plant a flag and stick to your guns.

“What do you want to be the world’s best at?”

It’s a question I’ve started asking founders. Most startups don’t end up becoming the world’s best at anything or scaling to a point of world domination, but without that target and clarity you stand no chance at all.

Challenging yourself on this question isn’t just for the VC-backed startups that are trying to go public. Maybe you’re building a side hustle to generate a few thousand dollars per month. Or a lifestyle business that doesn’t put you on the venture capital rollercoaster. Totally fine. Love it.

✅ You still have to be great at something.

✅ You still have to stand for something.

✅ You still have to stand out.

Share

How to Craft a Pointed Value Proposition

Use this template. Fill it in without hedging.

For [specific audience] who [specific context or pain], our product [delivers this outcome] by [unique mechanism or approach], so they can [specific business result].

Here’s an example from Webflow (that I’ve written), which could represent their early value proposition:

For freelance designers and small agencies who need to deliver custom, production-ready websites without relying on developers, our product enables them to build fully custom sites visually by translating design directly into clean HTML, CSS, and JavaScript, so they can ship modern websites in hours instead of weeks.

Here’s a more recent Webflow example (again, written by me):

For marketing, design, and growth teams at scaling companies who need to launch and update websites without waiting on engineering queues, our product unifies visual development, CMS, and hosting into one governed platform, so they can move faster, publish safely, and reduce engineering overhead.

Messaging that passes the “for me” test

How does a potential user/customer know if your product is for them?

The value proposition needs to be specific. Try rewriting broad claims into targeted ones.

• Too broad: “AI that writes and analyzes contracts.”

• Pointed: “AI for antitrust teams that automatically maps merger filing obligations across 130+ jurisdictions and drafts regulator-ready information requests.”

• Too broad: “AI for doctors that saves time on paperwork.”

• Pointed: “Ambient clinical documentation that generates specialty-specific notes inline with EHR workflows, validated by a top-5 health system.”

• Too broad: “Automate your back office.”

• Pointed: “Autonomous coding for outpatient encounters that hits >90% automation in emergency medicine with audited accuracy and rapid turnaround.”

When buyers can see for whom, what, and why, they stop comparing generic feature lists and start imagining your product in their workflow.

Your value proposition is your company’s DNA

Your value proposition is not a paragraph. It’s the DNA of your company. It’s the seed that grows your messaging, product decisions, pricing, and positioning. It should be visible everywhere, even when it is never written out in full.

➡️ People should feel it in the tagline.

➡️ They should recognize it in the product benefits.

➡️ They should experience it inside the product.

I love the idea of writing a complete, detailed value proposition like the examples earlier. But that is an internal artifact. In public, it needs to be distilled into language that passes the “for me” test without friction.

Clarity is a superpower. When your product, copy, design, and GTM all reflect a single sharp idea, customers do not need to think hard. They immediately know, “This is for me.”

Insight → Value Proposition → Everything

Let’s end where we started.

Startups win when two things happen:

1. They discover a genuine insight. Something non-obvious that the market has not fully internalized. You get there through deep experience and/or deep research.

2. They turn that insight into a precise, targeted, unwavering value proposition. A focused promise for a focused audience with a focused outcome.

In an environment where AI has made building easier than ever, and every startup is promising the “magic of AI” as a value proposition, the winners will not be those who build the most features or slap AI into their tagline. They will be those who build the most meaningful solution for a very specific group of people, driven by a real insight that others overlooked (and probably uses AI to get there).

🧠 Insight drives differentiation.

👽 Differentiation drives a sharp value proposition.

🔪 A sharp value proposition drives traction.

🧲 Traction drives momentum.

⏩ Momentum drives expansion.

This is the wedge.

This is the way.

This is how you actually rise above the noise.

Real change does happen. The internet, mobile phone (remember the iPhone launch?) and now AI have reshaped everything. But there’s a difference between change and hype. Change endures because it’s built on fundamentals. Hype fades because it’s not.

We’ve been here before. What’s old is new again, and that’s fine—as long as we learn from the past instead of forgetting it.

Let’s take a quick walk down memory lane…

I’m pretty sure I owned this t-shirt in the mid-to-late 80s.

Today there’s a massive market for vintage clothing. I just liked Run DMC (and still do). 😄

The thrift store market is estimated at $10-$15B in North America. That’s just for physical stores. Thrifting is a regular activity for my university-aged kids (technically they’re adults, but whatever). Sometimes they go to bulk stores and buy “by the pound”. Sometimes they go to “high-end” thrift stores where t-shirts like that Run DMC one are proudly displayed.

The broader resale market for second-hand clothing is even larger, and there are many digital platforms you can use to buy and sell your stuff.

What drives this market?

For older folks it might be nostalgia (same reason they love old Pokemon cards or collecting 80s-90s toys). For younger people (like my kids) it’s about what’s cool, the thrill of the hunt, necessity (they’re broke and can’t drop $200 on jeans) and rejecting fast fashion. I always thought it was because they wanted to look as cool as I did back then. It’s not. 😝

People are irrational but they don’t do things randomly.

There’s always an underlying reason.

Subscribe now

People Get Caught in the Hype, But It’s a Crappy Way to Build a Sustainable Business

Hype is powerful. It draws people in and creates momentum. People want to belong and be in the know, that’s what makes hype so alluring.

But what goes up, must come down.

Hype is fickle. The next big thing is always around the corner, and if you’re not there with the cool kids (wearing Run DMC t-shirts) you’ll miss out. So you panic, chase every thread that might become a movement, aiming to stay ahead of the curve or at least ready to ride the wave and not drown.

If you build your business exclusively on hype, there’s a good chance you’ll fail. When hype fades and becomes nothing more than a fad, you’re in trouble. You might catch the wave, make a lot of money, and jump off at the right moment, but timing that is almost impossible.

Pet rocks, fidget spinners and NFTs

The Pet Rock might be the purest example of hype turned profit. In 1975, Gary Dahl sold literal rocks as pets, boxed up with air holes, a straw, and a training manual. It was a cultural joke that made him a millionaire for about six months. The brilliance wasn’t the product, it was the packaging, the timing, and the collective willingness to be in on the gag. Then it vanished. You can start with irony, but you can’t stay there.

A few decades later, fidget spinners spun through the same cycle. Marketed as stress relievers, they were everywhere—schools, offices, gas stations—until overnight they weren’t. The problem wasn’t that they didn’t work; it’s that there was nothing underneath the hype. They were easy to copy, impossible to differentiate, and had no repeat value once the novelty wore off. Schools banned them, prices collapsed, and retailers were left with unsellable stock. The fundamentals weren’t there: no defensibility, no ecosystem, no reason to keep spinning once everyone had one. What had been a billion-dollar toy category turned into clearance-bin plastic. I don’t even want to tell you how much I spent on fidget spinners for my kids at the time. 🤮

Then there’s Bored Ape Yacht Club: JPEG monkeys that rode the NFT hype wave straight into the speculative stratosphere. People spent hundreds of thousands on cartoon apes to flex digital status, and for a while the cheapest Ape (“the floor price”) traded for more than a luxury car. Then crypto winter hit, floor prices collapsed, and the club wasn’t so exclusive anymore.

The underlying technology—blockchain and Ethereum—still matters. It’s enabling real infrastructure shifts in transparency, finance and digital ownership. But NFTs like Bored Apes were a speculative expression of that technology, driven more by social signalling than substance.

Each of these moments had explosive energy. They made real money, for a minute. But hype isn’t a moat. It’s lighter fluid: quick ignition, short burn, and nothing left once the crowd moves on.

What’s Old is New Again

Live long enough and you realize everything is cyclical. For example, every generation rediscovers what was great before, like the Beatles, and convinces itself it’s found something new. They create their own music too, but it’s often derivative, or at least inspired from the past. Every generation thinks they’re the exclusive purveyors of taste, while simultaneously buying up vintage clothing, vinyl and old school memorabilia.

Technology makes the cycles spin faster. Every time we think something is brand new, it’s usually the same human impulse in a different wrapper.

AI is swimming in hype. The mistakes made during the dot-com era are resurfacing, although I believe we’ll plough through it. It’s a messy, experimental process, but we’ll get there.

A few months ago, I did an interview with Sidney Madison Prescott, who previously worked at Spotify, E*Trade, BNY Mellon and others, where she said, “AI is rebranded robotic process automation (RPA).” That struck a chord. We also chuckled about “Prompt Engineers” being an actual job title.

Sidney is super bullish on AI, and believes it will transform industries because the tools are amazing (and rapidly getting better), but the desire to automate things isn’t new.

Meanwhile, Kyle Poyar recently conducted a survey of go-to-market teams on the impact of AI. Here’s a quote from the post (paid access, but worth it):

The impact of AI is a mixed bag. More than half (53%) said they see either no impact or limited impact from AI. The disillusionment was most acute around AI SDRs. In the words of one survey taker, “We tried an AI SDR for six months and were unable to generate a single opportunity.” Ouch.

Despite signals like this (and the fact that most AI projects within companies seem to be failing), AI is a genuine step-change. We’re still figuring things out, but AI isn’t a fad.

Share

Forward Deployed Engineers: Old Job, New Myth

The thing that sparked this entire post was the growing hype around Forward Deployed Engineers (FDEs). Everyone credits Palantir with coining the term, but FDEs existed way before. Honestly, they’ve probably existed since the first enterprise software was built for companies.

I heard the term in 2023. By 2024 the hype was in full swing. A SaaStr post noted that, “Forward-deployed engineer job postings have increased from around 30 per month in early 2024 to 375 by April 2025—a 12x increase.”

Forward Deployed Engineers sounds super cool. Kudos to Palantir for an excellent rebranding. But this is not a new concept.

In 2012, I was working at GoInstant when we were acquired by Salesforce. I spent two years there, which was a great experience. Salesforce always deployed people to work with their enterprise customers. These people had the customers’ employee badges and access to everything. Some were project managers, others were technical salespeople, and some were engineers building software with and for customers.

At one point, our GoInstant team was selling into a large insurance company. We went in-person to demo our tech and learn more about their challenges. It turned out most of the people we were selling to were Salesforce employees. They’d been embedded for years. They knew everything that was going on inside the company. The customer was paying for them to be on-site full-time.

Being embedded with a customer for enterprise-level sales and deployments makes complete sense. The likelihood of project success goes up, and you can upsell constantly.

It turns out, in-person works. That’s how real relationships are built. Today people are “discovering” in-person events as if it’s a shock that meeting someone face-to-face is a good thing. I’m not arguing for full-time in-person, fully remote or hybrid, because all three are feasible. But I do laugh a bit when someone says, “You know, meeting people in person really makes a difference.” No kidding. We were rocking that in the 90s.

The Fundamentals Don’t Change

Rediscovering something that used to work is completely fine. Rebranding it is fine too. Value doesn’t come exclusively from net new inventions.

“Forward Deployed Engineer” sounds serious and cool, like Army Rangers going into a battle while simultaneously coding and solving every problem imaginable. Bring ‘em on!

But remember two things:

First: Most new things are built on what came before. If you ignore that, you’ll repeat the same mistakes or get caught in the hype without understanding how to navigate it.

Second: The fundamentals still matter.

A while back I wrote a post called “Did AI Kill Lean Startup?”. The short answer is no. AI doesn’t destroy the fundamentals of building a business. It doesn’t make customer discovery irrelevant, eliminate the need for right-sized MVPs, or erase the hard work of creating something people actually want. It just changes how quickly we can learn, test, and iterate. The scientific method still applies.

People are irrational, but they don’t do things randomly. There’s always a reason behind the behavior, even when it looks like hype. When you understand those reasons, you stop chasing trends and start seeing patterns. If you can uncover a genuine insight, something you know that others don’t because you’ve done the research and understand your customer deeply, you have a real competitive advantage. Insights may be the last true moat, or at least the spark that gives you a head start.

When the hype fades and people are tossing their AI pet rocks into the digital trash, what remains are real problems, real customers, and real value. That’s where great companies are built: not on novelty or noise, but on substance that endures. The fundamentals aren’t the enemy of innovation, they’re what make real innovation possible.

Valuations are crazy and the market is absurdly frothy. But AI isn’t going anywhere. It’s already too integrated into everything we do, even in enterprise (which is typically slow to adopt). When this hype cycle corrects, AI will still be everywhere.

I lived through the dot-com bubble. I was running a small digital agency building websites, web applications and e-commerce platforms. Everyone wanted to “get on the Web.” Then it stopped. Incidentally, it also cost hundreds of thousands of dollars to build an online store… 😝

Back then, people genuinely thought the Internet (and Web) might have been a fad. That’s not happening this time.

We’re early and being forced to adapt at an uncomfortably quick pace.

That’s why you get:

• CEOs demanding everyone uses AI, even without a strategic plan.

• Thousands of startups trying to automate every workflow possible, often without understanding the industries they’re entering.

• Billions of dollars invested by VCs and others, hoping to catch lightning in a bottle.

• Every startup claiming they’re an AI startup (since no one really knows what that means).

Trace Cohen writes a strong piece on this (better than I could): This Is Not 1999: Stop Calling It a Bubble.

Subscribe now

AI is Already Winning in the Enterprise

The biggest difference between 1999 and today: enterprise adoption.

In 1999, no Fortune 500 CEO was telling their entire company, “Use the Internet or you’re fired.” Today, every CEO is shouting, “Use AI now!” They might not completely know what that means, but they’re serious.

AI is already embedding into big companies’ operations: customer support, procurement, finance, legal, HR, etc. The adoption is uneven and often shallow, but the commitment is real.

That makes this cycle fundamentally different. We’re not debating whether the technology matters. Everyone agrees AI matters. The question is how to use it intelligently.

When the dot-com bubble burst, public markets were packed with retail investors chasing nonsense IPOs. For many, it was a “get rich quick scheme.” Today, venture capital is funding the mania (VCs fuelled the dot-com boom too, but liquidity was achieved through going public way too quickly). Many VCs will lose a lot of money this time around, but it’s a pittance compared to the public markets.

If every AI startup suddenly went public, we’d be in bubble popping territory, because a lot of those startups are propped up with tons of capital and unsustainable growth expectations.

We’ll see a correction, not a collapse.

Enterprise AI Adoption is Causing Chaos

A friend recently went through vendor onboarding with a major enterprise. For the first time, he saw AI-specific security questions:

• What’s your policy on using AI tools?

• Have you trained employees on safe AI practices?

• Do you have cyber insurance that covers AI-related incidents?

They still cared about the usual things — where data is stored, encryption, access controls, etc. — but now they’re explicitly calling out AI use as part of their risk profile.

The issue isn’t just where data lives anymore. It’s how data might be exposed or processed through AI tools.

That’s the new risk lens. Once company data touches an AI system, it’s perceived as being “out there.” Whether that’s technically true or not doesn’t matter. Perception equals risk.

For decades, enterprises asked, “Where is my data stored?” Now they’re asking, “What AI systems does my data touch?”

This shift is creating massive uncertainty. Most vendors don’t know how to answer these questions, and most enterprises don’t know how to evaluate the answers.

Meanwhile, nearly every SaaS tool has added AI features. You might not even realize that a tool you’ve used for years is now sending your company data through OpenAI, Anthropic, Mistral, or others. When your corporate IT team asks, “Are we using AI?” you may say no…and be wrong.

My bet: Startups will differentiate on the “secure use of AI”. SOC2 used to feel like a necessary evil/annoyance for startups selling into the enterprise. That’s changing. While SOC2 is technology-agnostic, auditors are already asking AI-specific questions. Expect this scrutiny to grow fast.

And recently I was talking to a startup that updated their Terms of Service to account for how it uses AI. They’d launched a new AI-driven feature and realized customers needed clarity on how their data was being handled. Sounds simple, but it’s not. Legal teams are scrambling to figure out what “responsible AI usage” language looks like.

BTW, their customers aren’t big enterprise either, but everyone (across all business sizes and sophistication levels) is twitchy about this stuff.

Executives are scrambling to get their companies using AI, and everyone, including IT, security, procurement, etc. is catching up. The lack of a coherent AI strategy makes this especially painful.

Most big companies don’t have an AI strategy. They’re experimenting everywhere without clear goals or alignment. One team is building copilots. Another is using ChatGPT for reporting. Another is banning it entirely. The result is chaos disguised as progress.

If you’re looking to develop an AI strategy and bridge the gap to execution, check out WorkLearn Labs.

WorkLearn Labs is a portfolio company launching soon. They’re focused on helping people define the right AI projects, assess ROI and connect the dots between strategy and delivery.

The next enterprise wave won’t just be about using AI. It’ll be about governing it.

Expect this over the next couple years:

1. AI training becomes mandatory. Like annual phishing and security training, employees will need “safe AI usage” certifications. Startups may eschew heavy-handed security training, but I suspect AI training will find its way to them as well.

2. Formal AI policies become table stakes. Companies will define what can and can’t go into AI workflows, when to disclose usage, how to vet vendors and models. The Australian government just released an AI policy template. This will be messy.

3. AI audit software emerges. New tools will track which LLMs are in use, what data is shared, how internal apps route data, whether prompts are logged, etc. Maybe these tools already exist (just like there are tools for tracking the software you use). Companies will demand visibility into AI usage within their organizations and with their vendors.

Share

AI is Changing “Build vs. Buy” But SaaS Isn’t Dying

AI tools for software development are amazing. It’s amazing what you can build quickly. And the tools are only getting better.

I’m a big fan of Lovable. I built a corporate venture studio design tool in 2 days.

Recently, at Highline Beta, we started building a new “Contacts tool”. The goal is to aggregate our collective contacts (primarily from LinkedIn), enhance the data (using AI) and make those contacts available to our team and portfolio. Instead of a portfolio CEO pinging us and asking, “Do you know any Series A investors that have recently invested in fintech and are at the earliest stages of their fund?” they can use the tool.

We could have used a CRM instead, but:

• We wanted to experiment with building something on our own (honestly it’s just fun!) Internal experimentation is a valid reason to build vs. buy, especially if you’ve mandated your employees to “use AI”. Just remember that experiments doin’t always work.

• It gives us the opportunity to tailor the software to our precise needs. This is one of the most common reasons for build vs. buy, you get exactly what you want. Of course, every time you want to add something, you have to build it.

• It should be less expensive than a monthly subscription to a CRM, although I don’t know what it’ll cost (more on that in a moment). The SaaS license fee model is evolving. For the Contacts tool we built, we would need 30-40+ licenses (which would be expensive in a CRM). Using Lovable, we don’t pay per user, we pay for use.

Still, I’m not convinced companies are going to replace a ton of software they buy with software they build.

There’s a lot of discussion about AI agents replacing traditional SaaS software. I can see that happening, but AI agents are still software. Whether you buy a platform for agent-building or specifically-focused agents for specific jobs, you’re still buying technology (software). AI agents are literally software as a service (SaaS), but re-packaged and priced differently. Lovable is a SaaS tool.

Building a lot of software in-house (versus buy) has implications:

• You have to maintain the software. Users will want more features (and since you told them it only took two days to build the whole thing, they’ll be clamoring for more!) They’ll report bugs and want support. You now have to manage all of that (you can’t outsource it to a vendor).

• You’re probably building the software side-of-desk. Some companies will have teams tasked with building internal tools (which is where most AI software is replacing “buy” decisions). Those teams are supercharged by AI dev tools; it makes their jobs way easier. But for the rest of us, we’re developing software while doing our day jobs. If building software with AI is a side hustle, there’s risk.

• If the people that built the software—even if it was vibe coded—leave, you lose institutional knowledge. We’re going to see hundreds of thousands of orphaned apps within companies that no one knows what to do with. When bugs emerge, or someone wants to extend the software (or integrate it securely into other systems), watch out.

• You have little idea how much the software will cost to operate. You may not be paying a subscription fee, but you’re paying for credit usage and that’s tough to measure and plan for.

With the two tools we’ve recently deployed at Highline Beta using Lovable, I have no clue what they’ll cost to run. I barely know what they cost to build, because I wasn’t tracking our time doing it, and I wasn’t tracking credit usage. A couple of times Lovable told me that we were at our credit limit (or fast approaching it) and I should top-up. I did. It wasn’t a lot of money, but I have no clue how long the top-ups will last.

Tracking and predicting future credit use isn’t clear. A lot of AI tools are hiding the numbers in an effort to obfuscate credit use; they don’t really want you constantly tracking it. They want you to use as many credits as possible and get hooked, so they can sell you more. It’s long distance calling and phone minutes all over again.

I also have very little insight into Lovable’s security. It makes security recommendations, which is helpful, but I don’t know how good a job it does designing secure software. We can’t assume people prompting a tool to build software applications know anything about security! When everyone within an organization can rip out vetted SaaS products with un-vetted, “randomly generated” vibe coded products, it’s a security nightmare.

Companies will build tools using AI instead of buying software. When traditional SaaS renewals come up, companies might ask if they can build a replacement for less. But it’s not going to shift the “build vs. buy” decisioning exclusively to build. Build comes with a lot of overhead and headaches that can be worth paying others to deal with. Division of labor is a thing.

Here are some further discussions on these topics:

• AI coding tools upend the ‘buy versus build’ software equation and threaten the SaaS business model

• I Found 12 People Who Ditched Their Expensive Software for AI-built Tools

• Is SaaS Dying for Good? A Look at How AI is Reshaping the Future of Software

• Build vs. Buy in the Age of AI: Why Smart Companies Choose to Purchase Non-Core Software

So Where Are We Headed?

We’re in a messy discovery phase that will last several years.

The combination of enterprise mandates, undisciplined startup building, and opaque infrastructure costs won’t cause a collapse. It’ll trigger a cleanup—a period of AI rationalization where companies focus on what actually works.

Here’s what I expect:

• AI compliance becomes a big industry. Training programs, certifications, audits and firms dedicated to AI governance will proliferate. Big companies buy-in first, followed quickly by startups.

• Transparency becomes a selling point. Startups that clearly explain their AI stack will stand out. Startups will need to address serious security policies earlier than they’re used to.

• Hybrid SaaS models explode. Software becomes both product and platform for AI workflows. This is already happening, and will continue.

• Big companies build a bunch and then buy. Experimentation isn’t the exclusive purview of startups. Big companies will experiment a ton to replace their complex and expensive software stack, overdo it and then settle back into purchasing SaaS + AI tooling (with a heightened nervousness around how their data touches integrated AI feature sets).

• Unbundling always leads to re-bundling. We’ve seen this pattern for decades: big companies buy a pile of point solutions, then realize they need “one app to rule them all.” Right now we’re in an unbundling phase driven by the explosion of AI tools and proliferation of startups. But that’ll shift. As major enterprise platforms bake AI deeper into their products, large companies will consolidate again, bundling for simplicity, security and procurement sanity.

• Procurement becomes the bottleneck. Enterprise customers (and smaller customers) tighten up their requirements and expectations. If your AI story doesn’t pass the test on security and clarity, you don’t make the shortlist.

AI isn’t going away. It’s already built into how companies operate and how people work.

The real challenge now isn’t belief, it’s competence. Most organizations are still figuring out what good AI adoption looks like. They’ll need to learn how to use it responsibly, measure its value, and build the right guardrails as they go. Startups will have to adapt, even faster than before, because demands on them in terms of how they use AI securely will increase.

This isn’t about hype cycles anymore. It’s about execution.

At the time, Lovable was super cool—it blew me away. But now it’s even better. (Note: This isn’t an advertisement for Lovable, there are a number of similar tools.)

Over the last two days I built a new web application.

Lovable recently added “Lovable Cloud” which sets up & manages the database automatically. This is a huge improvement from before. Feels like a game-changer for non-technical people building applications.

Subscribe now

I noticed a few other things as well:

• Lovable’s making way fewer mistakes. It’s much “smarter” with the code it creates. Previously, I found that Lovable wouldn’t always get things right, and would need multiple prompts to fix errors (that it had created). I felt like I was running around in circles. It’s still not perfect. Some things are still complicated and messy (e.g. exporting a nice looking PDF, or sending emails triggered on events). Both of these were rabbit holes for me, and I couldn’t get the PDF export to work the way I wanted to (after a lot of time and credits!)

• Lovable’s more precise. Previously you’d ask it to do something and it would, but it would also change something else, as if the left hand didn’t know what the right hand was doing. This was very frustrating, because it would seemingly change things at random. You were constantly going around fixing things that Lovable broke. That happened a lot less this time; Lovable seemed to understand my instructions more clearly.

• Lovable’s chat feature is helpful. This wasn’t available the last time I tried the product. The chat feature allows you to go back and forth with Lovable before it makes any changes to the code. I found this helpful for diagnosing issues, asking questions, and getting more comprehensive explanations for what it was doing.

It still took me 2 days (although I didn’t work full-time on it!)

The app is fairly basic, not ready for primetime…but it’s live.

Do you want to try it out?

Introducing: The Corporate Venture Studio Builder

The Corporate Venture Studio Builder is built from the Venture Studio Checklist that I previously created as a spreadsheet. It’s meant for corporate innovators and executives that are exploring the venture studio model.

• The builder uses fewer questions than the original checklist, but also provides more detailed analysis.

• It’s mostly a survey (I probably should have used a survey tool!) but it also does a few cool things like calculate the studio team size you’ll need and other criteria. In the future I may look at building a budgeting tool and other capabilities, which would go beyond survey software.

Building the Corporate Venture Studio Builder

I thought it’d be interesting to show off a few key steps in the process.

Here’s the initial prompt, which includes a copy of the Venture Studio Checklist spreadsheet:

Then it went to work. I did a quick Loom video to show you the immediate output and process it went through to create a basic, but functioning application, with a database, login/authentication, design and fairly complete survey:

Share

Remember: Garbage in, garbage out

My initial prompt could have been more detailed. A lot of the fine-tuning I had to do was a result of not being precise at the outset. I was too curious and eager to see what it would do. I’m sure this cost me a decent amount of time.

For example, the initial version used radio buttons for all options/answers, whether the answers were single- or multi-select. That felt strange UI-wise (multi-select = checkboxes). So I went through each question, verified if it was meant to be single- or multi-select and then asked Lovable to fix the UI.

The original spreadsheet had some information for Lovable to work from. On some questions it would say, “Select as many as you like” which Lovable interpreted correctly.

But generally it’s good to remember, “Garbage in, garbage out.” You can’t expect miracles. Note: As I’m typing this I’ve realized that I probably could have prompted Lovable once to go through every question, double check it as a single- or multi- select and then use either radio buttons or checkboxes. I did it one question at a time. 😜

Once the basic application was setup, I started fine-tuning the questions. I was asking Lovable to make small copy changes to questions and answers, which felt silly. So I asked if there was a different way to edit the questions and answers by accessing the database directly:

I had assumed the questions were in the database, but they weren’t.

Incidentally, Option 1 is pretty funny, because it’s useless and wouldn’t have solved the problem. At least Lovable recognized that.

I decided to keep the questions/answers hardcoded (and not in the database), because I felt like working in Supabase (the database Lovable uses) would be more complicated. As a result I spent hours tweaking questions and answers. This would have been much easier in a survey software tool. 😃

Lovable did a lot with very little

Lovable did a great job of creating insights from the small amount of content/data provided in the spreadsheet. It was a pleasant surprise!

Note: There was a lot of fine-tuning and nitpicking to add more details/context to questions and the insights that were generated. Again, this is a good reminder that if you don’t provide Lovable (or a similar tool) with enough details, it’ll use what it can (and probably make up the rest). So a lot of my chats with Lovable looked like this:

Subscribe now

Lovable can handle fairly complex prompts

The more you prompt a tool like Lovable, the better you get. I’m far from an expert, but I was super impressed with a lot of its output.

Here’s an example of one of my prompts:

There are at least three key instructions in there and each bullet under “Note” is also an instruction. Lovable followed everything. Here’s the output:

Note: Calculating the # of ventures to build per year is pretty simply, but it actually feeds into a future question.

Lovable also does a good job with fairly basic prompts

One of the cool things I added to the Corporate Venture Studio Builder is milestone reports. I want to give people something of value throughout the survey, by analyzing their responses and making recommendations. Here’s my very basic prompt for doing that:

I had no idea what it would generate, but it’s honestly quite good (it did take a bunch of work to refine it to this point):

What’s interesting is that this doesn’t use AI. It’s hardcoded based on logic that Lovable created. I’ll be honest: I thought the responses were AI generated. 😉

I started prompting Lovable as if it was using AI to generate the milestone summaries and reports. I didn’t look carefully at what it was doing (while Lovable works, I’m often doing something else!) But it’s clear this isn’t using AI and it’s trying to interpret my fairly open-ended prompt into code.

At some point Lovable asked me if I wanted to use AI. I’m not sure why. It came up as an option. I can’t find the prompt that triggered it, but it started using Gemini 2.5 Flash to come up with recommendations in the milestones and final report. BTW, telling Gemini to be more opinionated and punchy was hilarious (I wish I had captured screenshots). It was completely rude and essentially telling people off if their survey answers weren’t great.

I deleted some of these AI generated sections because it was too annoying to improve (although I’ll go back and try some very specific context/prompt engineering later). One section did survive (although the formatting occasionally breaks like in this screenshot):

Subscribe now

Not everything was easy: Export to PDF and Send the Report by Email sucked

Earlier I mentioned that building the Export to PDF featured was difficult. I won’t bore you with all the details, but the gist of it is that the PDF wouldn’t include all the information that shows up on the final summary page. I also created a Send the Report button, but the email was missing information as well. For fun, I created a quick video of all the work Lovable and I tried to do in order to make these features work:

Looking back, I think half my time was spent trying to get Export to PDF and Send the Report features working. They kinda work…

So what’s next?

For starters, feel free to try out the Corporate Venture Studio Builder and let me know what you think.

There’s a lot of polishing to do. Polishing takes credits, because you keep messaging Lovable to make small changes, and each message costs you. I burned through my monthly credit allowance already!

I do want to work on a few things:

• Administrative reporting on usage to track where people stop in the process, how many projects/surveys people create, etc.

• Event tracking on key actions; i.e. what features are people using and how often

• Fix the PDF and Email Reports

• Improve the analyses that are generated, with and without AI

• Add a “venture building process” tool, where the user can define the key milestones/stage gates in their operating model, how long they take, resources required, etc.

• Potentially add a budgeting tool

• Branding and UI—it looks good, but it can look much better; potentially bring this into Highline Beta as an official tool

I’m not an expert with Lovable (or any other similar tool), but the power and potential are clear. It’s a ton of fun to jump in and build something. Tinkering is super cool (until you run out of credits!) Lovable will only get better, which will translate to easier builds, less time invested and more stuff being launched (which is great!)

If people are interested, I’ll continue to share my journey building the Corporate Venture Studio Builder and other tools in the future. Let me know!

• “We only invest in founders with domain expertise in the industry they’re disrupting”

• “We only invest in young founders”

• “We only invest in older founders”

• “We only invest in teams”

• “We only invest in technical founders”

• “We only invest in teams of young founders that have known each other for a long time”

• And so on.

Often this founder profile becomes a key part of the investment thesis. Investors swear by their own definition of “the best founder type.”

My belief: They’re all a little bit right and a little bit wrong.

Subscribe now

Everyone is biased based on:

• What they’ve seen win or lose before (albeit anecdotally); and/or

• What they somehow believe to be true (through anecdotal evidence, industry trends, etc.); and/or

• What founders look like (i.e. “If they look like me, they must be good.”)

This happens everywhere. Look at hockey. The Florida Panthers win two Cups in a row and suddenly every team scrambles to copy them. History is full of these swings. Big hitters were the rage until they got exposed for being too slow. Then speed ruled, and smaller players thrived. No, wait, it’s all about having an elite goalie. Wrong, you need top flight goal scoring. Scratch that, defense wins championships! Dammit. 🤯

Chasing trends is tough. But at least there’s adaptation. Venture capital adapts very slowly and many investors get incredibly entrenched in their theses, even if they’re not generating real returns.

I believe there are personality traits that consistently separate the best founders from everyone else, but I’m not convinced on everything else.

Does founder age matter?

No.

Statistically, older founders are more successful (to a point), but most investors target younger founders. Why? A lot of anecdotal evidence and biases:

• Young founders (in their 20s) have no obligations, so they can grind like maniacs. Perhaps true, but (a) I know a lot of 40+ folks that grind like maniacs; and (b) how much of that grinding is productive?

• Young founders are so naive they aren’t held down by traditional beliefs. 20 year olds don’t know enough to be burdened by how hard things will be, and they challenge the status quo. I’d say that’s true, but is naive optimism the #1 reason for startup success? Doubt it.

• Young founders take more risk and are more adaptable. Risk-taking and adaptability are important, but why does the evidence suggest older founders are more successful? Maybe they know more (about how to do things, the industry they’re in, etc.) to avoid the risk altogether.

• Young founders will pursue bolder visions. Maybe, but I don’t think you can say that definitively. I think they make bolder claims, “We’re going to blow up that old school joke of an industry with our kick-ass AI tech!” That’s not the same as having a bold vision. Or making impact.

Y Combinator, which is incredibly successful, set the tone for investing in young tech teams. A Business Insider article reported that in 2022 the median age was 30, but it’s now down to 24. The 30 year old median age surprised me, 24 does not. I wonder if it will continue to drop.

I have nothing against young founders. We need more of them. But exclusively investing in young founders seems shortsighted.

Does founding team size matter?

Yes and no.

The research says:

• Solo founders have the least odds of success

• 2-3 founders have the highest odds of success

• 4+ founders decreases the odds of success (from 2-3 founders)

Yet founder issues are one of the top reasons for startup failure.

How do we reconcile that 2-3 founders is best and yet founder conflict is one of the most common reasons for startups to fail?

Exactly.

Anecdotally (across my 40+ investments and 100s of startups I’ve supported) I’ve seen pretty much every combination of founders (from solo to four+ people). In that mix, I’ve seen solo founders win and 2-3 person teams collapse spectacularly (with lawsuits involved), and everything in-between.

The bias towards 2-3 founders makes sense. There is research that backs it up. But aren’t startups supposed to buck the status quo and challenge everything? Sort of. While every investor is looking for outliers (and claiming each investment is the one that’ll “make the whole fund”), they’re using pattern recognition to get there and the success rate is still low. Gamblers also believe they have a system.

Solo Founder + Venture Studio = More Winning?

Venture studios often work with solo founders and position themselves as co-founders or temporary co-founders during the startup validation and building process. The hypothesis is that a venture studio, with more structure, resources and assets can “replace” what typical co-founders might bring to the table, recruit the right CEO/founder to execute (once some validation has taken place) and provide the support system necessary. Early data (again anecdotal) suggests this works, and I certainly believe it does (otherwise I wouldn’t be running Highline Beta), but it’s not a guarantee.

Share

Does gender or race matter?

Yes and no.

There’s meaningful evidence that female founders generate more revenue per dollar invested and have a higher exit rate.

But recent data suggests that female founders get 2% of VC dollars. Ouch.

According to Carta (from 2023) women account for 13.2% of startup founders and men make up 86.8%. Simply put: many fewer women are founding or co-founding businesses, but when they do, they do well (although very few raise capital).

Let’s be honest: this is all bias. It doesn’t look like huge improvements have been made over the years, which is disappointing.

Should you exclusively invest in men because historically they’ve received most of the funding? Of course not.

Race follows similar patterns to gender. Black and hispanic founders receive a very small percentage of venture capital and the check sizes tend to be smaller. But there’s data to suggest that ethnically diverse founding teams, when funded (big if!) outperform homogenous teams in exit value and investor IRR (investment rate of return).

Does domain expertise / industry knowledge matter?

Yes and no. Maybe. Sometimes. 😏

You’ll find people who fundamentally believe in the importance of domain expertise and industry knowledge. You’ll find other people that believe the opposite—they’d argue that the lack of expertise, being an outsider, is what drives disruptive innovation.

How can both things be true at the same time?

That’s startups!

My perspective on founders with no domain expertise / industry knowledge:

• I don’t want to invest in martyrs. Founders that believe they can simply jump into an industry because, “it’s so old school and obviously broken,” are going to get their ass handed to them. Superficial understanding of something with a massive ego is scary.

• I’ll invest in founders that recognize they don’t know a lot, with a willingness to learn. But they still need a healthy ego to believe they can make a difference. Venture studios play an interesting role here, ideally as domain/industry experts with deep knowledge, experience and networks that can fast track a willing founder to figuring things out.

My perspective on founders with domain expertise / industry knowledge:

• I don’t want to invest in dinosaurs. Founders that believe they know everything and “everything has to be done my way or it’s wrong,” are too calficied. When faced with evidence that suggests they’re wrong, they usually just keep ploughing ahead, ignoring the signals. No thanks.

• I’ll invest in founders that know an industry, as long as they are open to new ideas and input. Again, there’s a balance between ego and being humble that’s important.

Subscribe now

Does “who came up with the idea” matter?

Most people will say “yes” because it seems obvious.

But what about venture studios?

One of the biggest pushbacks against venture studios is that they typically recruit founders after a bunch of work has gone into the startup idea. Venture studios will validate an opportunity (often over 3-6+ months), build an MVP and even get initial pilot traction…all before hiring a CEO/founder.

Many investors flat out do not believe in the idea that you can “hire” a CEO/founder.

• “It wasn’t their idea, they won’t be passionate about it.”

• “Hired guns don’t work as hard as original founders.”

• “They’re just in for a quick win.”

• “Any entrepreneur that needs a venture studio is a B-player.”

That last one—only B-players join venture studios—is nasty. I understand why investors might think that way, because the mythology around startup founders is strong. It’s 1 or 2 people against the world, putting the future on their backs, and without any meaningful help, they build a billion dollar, world-changing company. Come on now… 😜

Fact: No founder has ever succeeded without a ton of help.

But I get it.

I used to hear the same argument for startup accelerators. “The best founders don’t need startup accelerators.” What founders don’t need are crappy startup accelerators (or crappy venture studios, or crappy investors). The best startup accelerators create tons of value. Same holds true for venture studios and investors.

So-so quality venture studios will attract so-so quality founders. It’s easier to build a so-so quality venture studio (although harder to keep it alive), which means more of them emerge, bringing in a higher volume of so-so founders and the cycle continues.

The best venture studios are proving that you can recruit founders/CEOs later in the startup journey and still win. Lots of investors will stay firm in their belief that this is nonsense. So be it.

Does motivation matter?

Yes, but not every founder needs the same motivation to be successful. Why? Because the definition of success varies.

Not all startups need to be huge outliers that are worth billions, go public, etc. These are great (and drive VC returns), but few and far between.

There are plenty of great startups and successful founders that exit early (some intentionally) or decide to build “evergreen” profitable businesses. VCs are less interested in these businesses, but other investors including angel investors, corporates/companies or venture studios could be.

The key is aligning the opportunity with the founder’s motivation, in effect, looking for “founder/targeted outcome fit.” For example, there are some venture studios that are exclusively building “small businesses” (that don’t require tons of capital and can operate profitably). They’re not hiring founders that want to “ride or die” for billion dollar exits.

In all scenarios, “get rich quick” is a bad motivator because very few people starting companies accomplish that, and when the shit hits the fan, these wannabe founders bail.

I’m mostly interested in intrinsic motivation: Why are you (as a founder) deciding to do this thing? You could do a lot of things, so the fact that you’re selecting a specific startup to build matters.

What’s the ideal personality of a founder?

Oh boy. Now we’ve stepped in it. 💩

I’m sure there are a bunch of studies on this, but here’s my take:

• Insane resilience. I don’t know how a founder survives the rollercoaster without being crazy resilient. There’s a reason a lot of successful startups have a flat growth curve for a few years and then it skyrockets—resilience. (I know AI startups are changing the “ideal growth curve,” but they remain the exception to the rule, and I’m not sure they’ll survive either).

• High confidence with a dose of modesty & intellectual honesty. Without an ego, founders fail. There are so many naysayers and bumps along the way. In tough times, a founder will have to rely on their ego and self-belief. But without a dose of modesty and intellectual honesty, founders become delusional. Founders with God complexes are a nightmare. Maybe they win, but I still don’t want to work with them

• Always Adaptable. There’s a balance between, “I know what’s right,” and “I better be flexible on this.” Lots of learning, creativity, willingness/gumption to change plans and make tough decisions are all part of the process. I’m bucketing all of this under adaptability. Things move fast, founders have to be ready for it (or adjust quickly).

• Super Scrappy. A comfortable founder is a failed founder. There are never enough resources, and there’s never enough time. Certainly at the early stage, scrappiness (a “get shit done” approach to everything) is paramount. But even later on, as a company scales, you don’t want to lose that mentality. That’s what sparked the whole “founder mode” hoopla last year.

Although not a personality trait, I want to add one thing: Sales.

If you can’t sell to customers, partners, employees, investors, etc. you’ll fail. I don’t care if you’ve got a PLG AI startup that’s taking off like crazy, founders can’t sit back and let things happen. Everything is sales.

The word “sales” may conjure images of over-the-top hustlers hawking crap that people don’t need. That’s not what I mean. The exercise of selling can be authentic, transparent and honest.

• Why would you want to lie to customers? Solve an actual problem that genuinely matters to them. Understand their pain better than they do.

• Why would you want to lie to candidates you’re recruiting? Define your startup’s culture and values (whatever they may be) and pitch them.

• Why would you want to lie to investors while fundraising? Angry investors (especially if they’re on your Board) usually leads to disaster.

If you build a house of cards it’ll eventually collapse. Don’t sell bullshit. But you gotta sell.

So, do we have the prototypical founder locked in?

No. There’s no such thing. The perfect founder doesn’t exist. They’re not produced in some secret Silicon Valley factory (as far as I know!)

Founders come in all shapes and sizes, from everywhere in the world.

Although when you ask ChatGPT for the “prototypical founder” you get this:

Any given investor may have a very definitive view of what a founder should be. Cool. Doesn’t mean they’re right. If you don’t match the criteria for an investor, move on.

Venture studios are a completely viable and valid way to build companies, even if they recruit founders after an idea is validated. Does everyone agree? No. Should you care? No.

Does every founder need to aim for a billion dollar exit? No. Does that demonstrate some “lack of ambition”? No. People have different reasons for doing “the same thing” (starting a company), why would anyone waste time judging that?

This post will be very personal. It won’t include any tactical information about startups, venture studios, product management, etc., but I process stuff by writing. Maybe this helps one person dealing with similar issues. You can certainly unsubscribe as a result, but I hope you don’t. And I promise more tactical & practical content soon! 😀

In 25 years I’ll be 75.

The average life expectancy for a man in Canada is 80-81.5 years. But how many of those years will be good and/or productive? What will my quality of life be (from here on out)?

It turns out people my age think about and deal with this a lot, because we’re sandwiched between elderly parents and young (adult or near-adult) children. I have two adult children, both in university and I have two older parents. And this is where the story goes sideways…

A few years ago my mom started showing signs of dementia or Alzheimer’s. Early signs, the type of thing you might chalk up to “getting older”—except for the fact that her mom had Lewy Body dementia at ~75 and it was bad. (Lewy Body often results in very intense and crazy hallucinations.)

Initially, my mom’s condition declined slowly. I only saw her a few times per year, so I didn’t notice much. I suspect that my father and she were “hiding things” (i.e. managing behavior change with “quiet interventions”) to avoid setting off alarm bells. Tackling these types of issues head on is scary. Very few people want to deal with them, which I completely understand.

Historically I’ve had an “it’s better not to really know what the heck is going on” policy for my own health. And parents aren’t always the most forthcoming with their kids. We don’t want to burden them with every issue. It’s true of health and of finances (I know very few families that speak openly about finances with their kids at any age). Culturally this is perhaps changing, but my parents rarely spoke to me about finances or their health.

A couple years ago it became clear something was really wrong. Not only was my mom struggling with memory, abnormal behaviors (like putting things in the wrong place) and more, she was struggling to communicate. If you know my mom, you know that speaking was never an issue. She was an entrepreneur/small business owner and teacher—both jobs that require you to talk, a lot. She had strong opinions, voiced them frequently, and constantly stood up for herself. But “all of a sudden” the words weren’t coming out the same way. Everyone forgets a word or two occasionally. This was different.

Ultimately she was diagnosed with dementia and aphasia. Aphasia impacts your ability to speak, including skipping words, using the wrong words, making up words and having difficulty finding the right words. It’s excruciating to watch someone try and say something but not be able to. They get frustrated (knowing there’s a problem) and you can’t figure out what they’re saying (which makes helping them very difficult). Her decline over the last couple of years has accelerated and it took a serious turn a few months ago when she fell.

On July 23rd, my mom got out of bed, passed out and collapsed. She was rushed to hospital by ambulance and they found blood clots in her lungs. Physical trauma tends to accelerate mental disorders, and that was absolutely the case for my mom. At first we thought she’d go home after recovering physically, but then it became apparent that she’d need more help than my dad could provide.

After 2+ years of caring for her (with increasing effort to do so), my dad couldn’t do it anymore. I don’t think anyone in our family appreciated how much he was doing and how hard it was for him. People will often say, “You have to take care of the caregivers,” or “You have to take care of yourself too, not just the person that needs your help.” These statements are true, but hard to follow. There’s guilt. Stress. Sadness. Along with a heap of second guessing…

We found a private facility for my mom and moved her in once she was physically able to leave the hospital. I’m thankful we can afford it, but not everyone can. The alternative was keeping her at the hospital (I know folks in hospitals work their asses off but the environment is so rough to handle) until a public spot opened in a facility (which can take many months.) If we weren’t able to afford private care, my mom would still be in the hospital, which would have been even worse.

Since then she’s had another emergency hospital trip for a different issue and a lot of medical appointments. One of my mother’s symptoms is constant walking (which is common for dementia patients). Everything she’s ever done has been with a lot of gusto and commitment (to say the least), and the same is true for walking. She was walking for hours every day, non-stop. As a result she damaged her feet, they got infected and she had to go to the hospital. She also “escaped” multiple times from the medium security facility she’s in (which is attached to an old folks’ home that has little to no security). Escape is an exaggeration. She wasn’t trying to leave, but she simply walked out. So she’s walking constantly, unable to communicate clearly (she now almost exclusively babbles nonsense) and hurting herself physically from exhaustion.

There are systems in place to deal with all of this, but they’re confusing and complicated. You have a bunch of people involved, but no one is really in charge. Multiple doctors, care staff, nurses, government officials, etc. all jump in to help, but coordination is a nightmare. And it’s flowing through my dad, who is no spring chicken and completely overwhelmed. I do what I can, but I don’t live close enough to deal with daily things. My mom has sisters, who have also contributed an immeasurable amount, but they have their own lives.

My mom doesn’t recognize me anymore.

When I visit her she knows I’m someone that matters (she’ll smile and hug me), but she doesn’t remember that I’m her son. She doesn’t know my name. She doesn’t remember her grandchildren. The first time I realized she didn’t know who I was, I was heartbroken. To have your mom stare at you and say, “Who are you?” (in a jumbled, but reasonably clear way) is nuts.

You have no choice but to get used to it quickly. Otherwise you’ll fall apart. There’s no time to fall apart, because you have to provide as much care as possible, through an endless coordination of stakeholders. I find myself going into “get shit done mode” (which is a trait my mother definitely passed to me through nature and nurture). Slowing down and dealing with the grief is too shitty (except I’m doing that now by writing this). It’s ironic and sad that as you approach the end with a family member, you spend more time on logistics than simply being with the person.

Occasionally, it’s clear my mom knows what’s going on. She’s not completely out of it, all of the time. Unfortunately, she then asks questions like, “Am I going to die here?” or “What happened to me?” or “Can you take me home?” Absolutely devastating. You find yourself wishing she wouldn’t remember anything, but when she’s delusional and asking nonsensical questions or getting frustrated because you don’t understand her, it’s equally tough. There’s no winning.

My mom is 75.

25 years.

Do I think I’ll end up with dementia and aphasia? I don’t know. I certainly hope not. Losing your mind—in fact, losing your complete identity—is a horrible fate. There are plenty of shitty fates…this one is near the top of the list. But if I have 25 years left, holy fuck, I better make good use of them. As I used to say to my kids, “Maximum effort.”

I want to share a few reflections from this experience (which is ongoing):

• People who take care of the elderly, especially in a condition like my mom, are actual saints. I don’t know how they have the patience or strength. They’re not as emotionally attached as family members, but it’s gotta be incredibly draining. My mom now has someone with her 12 hours a day, 7 days a week (because she needs a lot of supervision). That caregiver is a literal life saver (for my mother, my father, me and our entire family). We desperately need more professional caregivers and we need to pay them more money. Whatever they’re making isn’t enough. I don’t care if they don’t have 10 years of formal education. Holy fuck.

• Family caregivers never get the credit they deserve or the resources they need to do the best job possible. My dad got caught in the emotional turmoil of watching his wife of 51 years fall apart before his eyes. He couldn’t handle things rationally and decisively. I suspect many family caregivers land in the same place. Eventually they burn out. It’s bad.

• The societal burden of the elderly is significant. It’s only going to get worse. I’m not doing formal research here, but they must be consuming a very high percentage of health care resources from doctors’ appointments (including a bunch of specialists), medication, hospitals and other infrastructure. I’m not suggesting we put the elderly on ice floes in the Arctic, but if you don’t see the imminent disaster coming, you’re not paying attention.

• The growing longevity trend feels like a VC-fuelled, macho man endeavour of the overly rich. A pipe dream to sell supplements and other nonsense. I think it’s cool to imagine humans living longer, as long as the quality of life is high. But meanwhile kids still die of treatable diseases (and untreatable ones). We can’t even fix the basics, globally, and we’ve got people promising that you don’t have to die. Come on now…

• Humans waste a disproportionate amount of time arguing about stuff that doesn’t matter. If we took all the energy we put into stupid shit and focused it on fixing the basics, I believe we’d be much further ahead. Put down the rhetoric, impassioned stupidity, guns and hate, and just fix stuff.

• In Canada, medical assistance in dying (MAID) has been legal since 2016. It apparently accounts for 1 in 20 deaths in Canada. That’s a lot. And I’m 100% on board with it. After seeing what my mom is going through, I will explore MAID for myself. I cannot fathom a world where I’m suffering like her. It’s simply not worth it, for the person or their family. I have no interest in being a burden, or living the last years of my life in misery.

• Getting organized around your inevitable death means being a lot more transparent and unemotional about things, including finances, relationships, family and health. Get a will. Talk to your family/kids about your wishes. Setup 1Password (or a similar service) in case something happens. Figure out where the money has to come from for care. Just lay it all out there. I haven’t done that completely at this point, but I’m working on it because the shit can hit the fan at any time.

So what about my own health?

I’m taking actions, but I’ll be honest, it scares the hell out of me. My mentality of, “it’s better not to really know,” is still there. I can push myself on the basics—eat better, exercise more frequently—but really digging in still freaks me out. The news won’t be all good (let’s face it, very few people at my age are “perfectly healthy and clear of all issues”), and once you’ve received bad news the interventions may be significant. I don’t necessarily want to change my lifestyle completely, or take 20 medications a day, etc. For what? Another 2-5 years of quality life? I’m not going to eat and drink myself into oblivion, but doing “all the right things, all the time” isn’t a picnic. Even if you do all the right things, there are no guarantees anyway…

All I can say is this: Don’t waste time.

My feedback is summarized below, including common breakdowns and most common advice. If you’re building a deck for your pre-seed or early seed round, these patterns matter.

The most consistent issues?

• Design that hurts credibility instead of building it

• A total absence of story — just slides, no arc

• No real traction, or zero evidence of demand

Try out Pitch Deck Reviewer GPT!

For fun, I built a GPT trained on all the feedback I gave and my experience working with hundreds of founders. Give it a try!

Let’s walk through what to fix, and how to do it better.

Subscribe now

1. Your Design Is Hurting You

In 93% of the decks I reviewed, the design was working against the founders.

Some were plain to the point of looking abandoned. Others were chaotic messes of fonts, colors and layout experiments gone wrong. A few looked like someone gave PowerPoint to a raccoon.

Design doesn't need to be fancy. It needs to be clean, clear and confident. It needs to show you care.

How to fix it:

• Use consistent fonts and spacing.

• Simplify color use (with high contrast).

• Align things. Really.

• Focus each slide on one key point with fewer design elements.

• Get rid of outdated icons, pixelated logos and off-brand visuals.

• Minimize the use of AI generated images / visuals, especially as filler.

• Don’t use messy screenshots as visuals. They confuse more than help.

• If design isn’t your strength, hire someone. It’s worth it.

You're asking someone to write a $500K check. A sloppy deck says, "I don't sweat the details."

Investors see hundreds (if not thousands) of decks per year, great design will help you stand out.

Here’s a deck that’s pretty well designed:

2. Most Decks Forget They're Telling a Story

A pitch deck isn't an array of disjointed slides. It’s not a list of facts. It's a narrative. You have to tell a story and get people emotionally invested.

My recommended format: Hearts — Minds — Wallets.

1. First, make the audience care.

2. Then, help them understand, rationally.

3. Finally, give them a reason to believe this is worth betting on.

This framework is the backbone of great storytelling. It gives your deck rhythm. It builds emotional momentum. It lets people feel the weight of the problem, grasp the logic of the solution and want to see it in the world.

Too many decks skip that. They string together slides like a checklist: problem, feature set, TAM, business model, team, ask. But there’s no pulse. No cohesion. No narrative friction pulling the reader forward.

How to fix it:

• Open with pain: something visceral, something urgent. Get people emotionally invested in the problem. Even “boring problems” can be powerful.

• Don’t jump to the solution and what the product does right away. Focus on the value it creates. What gets better? Faster? Cheaper? If you can’t articulate value it usually means you don’t understand the customer well enough.

• Don’t wait 12 slides to talk traction. If you've got proof, bring it forward.

• Don’t assume the story tells itself. Spell it out. Structure it.

You have seconds to grab an investor’s attention, how will you pull it off? Usually this is done by highlighting the problem, but in some cases it may be the market size or traction or something else. Shock me. Tell me something I don’t know. Not all stories start exactly the same way.

Share

3. Bad Slides Kill Momentum

Some slides are dead weight. They either try too hard, say too little, or confuse the reader entirely.

Top offenders:

• Slides crammed with text, numbers, or jargon that are often better suited for an appendix; beware of acronyms—you’re assuming the audience understands them (and they might not)

• Confusing diagrams that don’t help the story (they actually make things harder to understand)

• Market sizing slides built on fuzzy math with no sourcing

• Business model tables with six tiers of pricing and no clarity on how you actually make money

• Product visuals that raise more questions than they answer

• Competitive matrices with axes no one understands

One slide had so much tiny text packed in, it felt like reading the fine print on a pharmaceutical label.

How to fix it:

• Trim copy by half. Then trim again. If you’re sending a deck before a meeting, add enough text so there’s context and the narrative is clear. But investors won’t read multiple paragraphs per slide.

• Don’t fear white space. Crowded slides feel anxious. Put dense detail in the appendix.

• If a diagram doesn’t help me grasp something faster, it doesn’t belong. But visuals are your friend if you get them right. Hire someone to help you with this if necessary.

• Avoid dumping raw data. Instead, highlight insights. One powerful stat beats a table of noise.

• Break complex ideas into two slides instead of one overloaded one.

• Headline every slide with the one takeaway I should remember. A strong headline isn’t a label, it’s a point of view. Say: “We reduce fraud by 90%,” not “Product Overview.” Generic headlines are a waste of space and opportunity to make a key point (especially when they take up 1/3rd of the slide).

4. You Can’t Be Everything to Everyone

Some decks tried selling to five personas across three continents. With two business models. And a sprinkle of AI, just in case. Always a sprinkle of AI… 😆

Ambition is good. But lack of focus is fatal. Investors aren’t looking for proof that you’ve mapped out every possible future. They’re looking for conviction about where you’re starting.

Startups don’t win by doing everything. They win by doing one thing well, for one user, with one sharp wedge into the market.

Anchor yourself:

• Who’s your wedge? What’s your beachhead?

• Why is that the best starting point?

• What makes this narrow slice urgent, underserved, or strategically valuable?

A scattered deck makes it feel like you haven’t validated anything deeply. A focused one builds confidence you’ll actually get something off the ground (even if you pivot later).

How to fix it:

• Pick one target user and build the story around them.

• Choose the sharpest, most painful use case, not the “bigger” but more generic one.

• Move other personas, verticals & geographies to a “future expansion” slide or appendix.

• Simplify your GTM to match: one user, one motion, one channel.

• If you’re still figuring this out, that’s OK; but don’t pitch breadth as strategy.

You don’t get extra credit for optionality. You get funded for focus.

Subscribe now

5. Where’s the Proof?

You can have a beautiful solution. A massive market. A perfect founding team. It doesn’t matter if you can’t prove people want what you’re selling.

Traction doesn’t have to mean revenue. But it has to mean something:

• Beta users

• LOIs

• Waitlists

• Conversion rates

• A pilot with a real name attached

These aren’t nice-to-haves. They prove you’re not just imagining demand.

How to fix it:

If you’re post-launch or have even one live user, lead with it. Make it visual. Highlight logos, quotes, outcomes…anything real.

If you’re pre-launch or pre-product, you still need momentum that feels like traction:

• Talk to customers:“We spoke with 25 creators across MENA. 80% said they’d try this tomorrow.”

• Build a credible waitlist: “200 signups in 2 weeks from cold outreach. No ads.”

• Get soft commitments: LOIs, letters of intent, emails confirming intent to use.

• Show signal density, such as engagement on a prototype, response rate from outreach, or demo interest.

If you’re too early for traction, show obsession. Show urgency. Show you’re out talking to people. Show a repeatable story that ends in interest, not indifference.

Your job is to prove that someone wants what you’re building (or planning to build).

Here are some decent examples:

This was a deck we prepared at Highline Beta for a concept called CareClarity. We hadn’t built anything yet, but were focused on early validation (“traction”):

Eino raised a $150k pre-seed round showing they’d done a few POCs (with well-known brands) and had a robust sales pipeline (I’d want to know how legitimate that pipeline is):

SquadTrip raised a $1.5M seed round with this traction slide (adding previous investors is smart):

6. The Missing Slide That Screams Urgency: “Why Now?”

This one keeps showing up half-baked, or not at all. In fact, 75% of the decks I reviewed didn’t include it.

Founders say things like: “We live in a digital-first world.”

Sigh. You need to tell me something I don’t know!

If the opportunity’s been around for years, what changed? What unlocks it now?

Timing is a wedge. If you don’t make the timing feel urgent, your idea feels optional.

What Makes a GOOD “Why Now?” Slide:

• Specificity that points to a concrete shift: regulation, platform change, behavior spike, tech unlock.

• Relevance that’s directly tied to your product or market wedge.

• Time-bounded, suggesting a window of opportunity (and that it won’t stay open forever).

• Non-obvious—go beyond generic macro trends (e.g. “e-commerce is growing”).

• Feels fresh, showing that now is the first time this idea is truly viable.

Good examples I’ve seen:

• “Apple’s iOS changes finally make this distribution channel possible.”

• “OpenAI’s latest release unlocked capabilities that made this MVP buildable in 30 days.”

• “New financial regulations allow lenders to access this borrower segment for the first time.”

What Makes a BAD “Why Now?” Slide:

• Generic mega-trends like “AI is hot,” “millennials love convenience,” or “remote work is on the rise.”

• No link to your specific solution.

• Vague claims like “the world is changing fast.”

• Statements that have been true for a decade (which is the opposite of urgency).

A “Why Now?” slide should feel like you’ve caught a wave, not that you noticed the ocean exists.

How to fix it:

• Make sure you have a “Why Now?” slide, ideally placed right after your solution or traction slides.

• Look for sharp shifts, not slow-moving trends. Shocks. Triggers. Tectonic movements.

• Tie the timing to your wedge. The best “Why Now?” slides make it clear that this product, in this form, only makes sense now.

• Use evidence if possible. Chart a growth spike. Quote a policy. Reference a competitor’s failure. Make it real.

• Avoid filler phrases. If you can paste your “Why Now?” slide into any other deck, it’s not specific enough.

Your timing is part of your moat. Make the opportunity feel like it’s right now, not five years ago or five years from now.

7. The GTM Slide Isn’t Optional

About 40% of the decks either skipped the go-to-market (GTM) plan entirely or phoned it in. That’s a huge mistake. Investors need to believe you know how to reach your customers and that your plan is rooted in reality, not marketing buzzwords.

Here are some of the common problems I saw:

• No GTM slide at all. If you’re not showing how you’ll grow, you’re asking investors to make a huge leap of faith.

• Empty strategy. Slides said things like: “social media,” “word of mouth,” “influencer marketing,” or “paid acquisition”—without any numbers, sequencing, or rationale. That’s not a strategy. That’s a list of buzzwords.

• No prioritization or sequencing. Some decks dumped a list of 5-6 channels. That doesn’t show focus, it shows you don’t yet know what will work (which is OK, but pick a lane). GTM is about narrowing down and testing hypotheses, not covering all possible options.

How to fix it:

• Include a dedicated GTM slide. Even if you’re pre-launch. Especially if you’re B2C. Make it early in the deck, right after the product section or problem-solution. Don’t bury it.

• Show your starting wedge. Be specific about what you’re doing first. What channel are you testing? What signals are you seeing? Who is your early adopter and how are you reaching them?

• Include learnings, not just plans. If you’ve run ads, cold outreach, landing pages, waitlists, etc. then show the data. Even if a test/experiment failed, that’s a signal you’re iterating. Investors want to see that you’ve touched the market, not just theorized.

• Keep it simple and sharp. What’s your wedge into the market? What channels have signal? Where are you doubling down? One slide. Clear focus. Some traction or clear hypotheses. That’s enough.

Share

8. Easy Fixes That Shouldn't Still Be Issues

Details matter. Unfortunately, a lot of founders don’t sweat the details to the extent that I think is important. Quite often there were little mistakes that threw everything off. Here are the things I flagged again and again:

• Typos and grammar issues. More than a third of the decks had them. That’s avoidable. Ask someone to review before you send out the deck. These mistakes jump off the page and don’t reflect well.

• Missing contact info. Your first slide should include your name and email. Don't make people hunt. If someone wants to follow up and can’t find you, you’ve already lost.

• Hashtags on title slides. A few decks used hashtags throughout. It didn’t add anything. Skip it.

• Section divider slides. You don’t need a slide that just says "TEAM" in big font. Transitions should be seamless, not announced.

• Exit strategy slides. There’s no point, it’s fantasy at this stage.

• Weak closing slides. Many decks end with a simple “Thank you” slide. Meh. The final slide should hit hard. Mission. Vision. Future. Make the last thing people see/read something they remember.

Clean decks signal competence. Cluttered decks signal chaos.

9. What the Best Decks Got Right

Some decks hit hard. Here’s what they did:

• Told a story with a beginning, middle and punchy end

• Focused on the problem and made me feel the pain

• Front-loaded traction

• Used clear, human language (minimal buzzwords and acronyms)

• Kept design minimal, confident and clean

• Explained GTM like they’d actually spoken to customers

• Made me believe they were the ones to pull this off

Here’s a summary slide checklist. If you’re missing two or more of these slides, fix it.

Your deck has 1 job: make people say, “I want to learn more now!”

Being great at creating pitch decks translates to other places where you’re pitching: sales, business development and partnerships.

You don’t need 40 slides. You need ~15 good ones. You don’t need to be flashy. You need to be clear. Sweat the details. And if you can make people care, you’ve already won half the battle.

Many people have given up on MVPs. They’ve bastardized its meaning, and mangled the definition beyond recognition.

Concepts like the MVP should evolve (and they do!) New variations emerge that add valuable context to building products & creating value. Should we throw the baby out with the bathwater? Of course not.

I recently did a webinar on the 5 biggest MVP mistakes and how to avoid them (it’s at the end of the post). You can watch it (maybe at 1.5-2x speed!) and/or read on.

Subscribe now

Mistake #1: Not Understanding the Definition of MVP

To be clear: MVP does not mean build the minimum shitty product. It never did.

Through the years, people have come up with numerous alternatives:

• MLP (Minimum Lovable Product) or SLC (Simple Lovable Complete): These added something important to the discussion—products shouldn’t suck. But lovable? I use a decent amount of software (daily!) that I don’t love (but I pay for). Love isn’t always part of the equation. 💔

• MMP (Minimum Marketable Product): Also important, because a product alone doesn’t guarantee success. Distribution is key. But “marketable” doesn’t necessarily mean valuable (i.e. you can still market crap). 📉

• SMURFS (Specifically Marketable, Useful, Releasable Feature Set): Goddamn it people! Enough already. (Nothing against Smurfs.) 😰

The term MVP has been massively misused and misunderstood, which is too bad, because it still holds merit.

Here’s my definition:

Let’s break this down:

• Smallest: Don’t over-build! It happens too often. But “smallest” doesn’t mean crappy.

• Product: It needs to be an actual product that’s usable (an MVP is not a landing page, newsletter signup or other experiment—those are prototypes or concepts).

• Prove + Solved: You have to quantitatively and qualitatively demonstrate your MVP is good, by validating that you’re solving a problem that actually matters. It’s a high bar.

If you use this definition of an MVP, it works.

Mistake #2: Not Understanding the User or Customer Problem Deeply Enough

There’s no amount of semantic Twister or creative rebranding of the term MVP that’ll matter if you can’t find a real, painful problem and solve it. Simple as that.

Doing so remains really, really hard.

You will almost certainly fail if:

• You only understand an industry superficially (how users/customers buy, budgeting, social/emotional dynamics, etc.)

• You only understand the problem superficially (you haven’t really dug into the “why”)

• You try to solve a “universal truth” (a high-level problem that everyone can see / generally knows about; i.e. “people don’t exercise enough” or “higher education is too expensive” or “everyone is taking too many medications”)

Here’s the breakdown (but I hope you read the above post too!)

• User: Identify a narrow user/customer (generic, big markets are useless)

• Need: Identify a functional need (fairly easy to do because you can see the problem)

• Deeper Need/Tension (leading to an insight): Tough to do, but absolutely necessary. This is the “why” behind the “what.” If you only look at the functional need you’ll miss all the underlying reasoning (rational or not!) and most likely not solve the problem (or go-to-market) successfully.

Unfortunately, I’m seeing this mistake happening more and more. I blame AI (more on that later). But also too many founders don’t want to do the hard, nitty gritty work to dig in and really understand problems in a meaningful way—they just wanna build, raise money, capture some fleeting glory and … 🤷

Share

Mistake #3: Not Defining the Right MVP Scope

Your MVP is meant to deliver the shortest path between a validated problem and value creation.

1. Identify your riskiest assumptions: Do this systematically, with intellectual honesty (founders love lying to themselves!)

2. Define the core use case: What’s at the heart of your product? What’s the core behavior loop you’re driving that will create value and encourage users/customers to repeat the behavior again and again?

Every successful product has a (relatively) small set of core features that solve the major pain point, connect perfectly with the value proposition (that you’re promoting/pitching) and generate repeat usage/value creation.

Next: Define the expected frequency of usage (i.e. how often do people need to use your product to get value?)

• Note: Usage = Value (i.e. if people are using your product it’s safe to assume they’re getting value)

• Remember: What you leave out is as important as what you include.

The MVP is a Process Not a Point in Time

Scoping the right size MVP doesn’t end with version one. In fact, your MVP will require many iterations before you can definitively declare that you’ve solved a problem worth solving (remember the definition of MVP from earlier).

The goal of your MVP is to get to Problem-Solution Fit.

That’s when you know that you’ve:

1. Validated a real problem; and,

2. Solved it in a way that’s creating value.

This is NOT Product-Market Fit (that comes much later).

Mistake #4: Assuming AI Solves Every Problem

The mobile phone changed a lot (for good and bad). But many of us still have computers with big screens (I’m running 3 screens at the moment). The mobile phone didn’t destroy the computer.

AI is changing everything and quickly. It’s not the answer to every problem.

1. Vibe coding is amazing, but has plenty of rough edges

It’s amazing what you can now build with zero to little technical know-how. It’s a huge unlock. Anything that allows more people to build more things is good.

But recognize the risks. Bad habits emerge when people are handed such powerful tools with few constraints. I often hear people say, “We can build so quickly, we don’t need to interview or understand users.” Or, “Let’s add more features to the product, because we can.” 😬

AI unlocks build mode in an insane way. But it doesn’t eliminate the need for the fundamentals.

2. AI can increase efficiency in many places, but humans are still…humans

We’re in the age of AI startups. Companies are spawning like crazy that claim to fix inefficient processes through AI. Totally get it. But again, the fundamentals hold true. If you don’t understand the customer deeply and why things are the way they are, you’ll still fail, despite all your slick AI.

Replacing inefficient processes / old systems (and/or the associated humans) with AI is in the very early innings. Many startups will fail because they’re too early. Anyone remember the dot com crash? Grocery delivery in 1999 sounded insane (and it was). The infrastructure wasn’t there and people weren’t ready for it. Land grab greed caused startups to spend tens of millions to acquire fickle users that didn’t change their behavior as quickly or significantly as needed.

We won’t see an AI crash similar to the dot com bubble bursting, but some of these AI startup valuations are too high. Meanwhile more competition emerges daily, because AI is making it insanely easy to build AI startups.

Hype has a tendency to reduce common sense

With AI hype at full throttle, people are proclaiming AI as the solve for everything:

• Every company should be built faster & better with AI

• Every product should be AI-first and replace some legacy “nonsense”

Good luck flying into all of that blindly…

Subscribe now

Mistake #5: Not Tracking the Right Data

Track the wrong data and you’re lying to yourself.

Here are a few common mistakes related to MVPs:

• Focusing exclusively on quantitative data. That’s a huge mistake. Quantitative data tells you what is happening, qualitative data tells you why. You need both. Never stop talking to users.

• Focusing on vanity metrics. They’re easy to track, especially after launch when there’s usually a little (or big) spike in acquisition. Sign-ups & social media mentions are common vanity metrics people promote. Even early usage may be vanity if you don’t see repeat usage. “We had 1000 people try the app!” Cool…how many are still using it a week later?

• Pretending you’re further ahead than reality. You do not have product-market fit immediately after you launch. You should focus entirely on Stickiness and the value you create (measured through repeat usage) versus anything else. It’s tempting, especially if you have a “hot startup” to focus on scale prematurely.

If you defined the MVP properly and have an “ideal usage pattern” you’re targeting, measuring value creation through usage is fairly straightforward. This takes time. You’re seeing it with AI companies now—grow fast, lots of hype, vanity metrics off the charts and then…churn. Oh oh.

How to Define and Build the Right MVP

Here’s a visual for how to avoid the biggest MVP mistakes. It may feel slow, but it’s not—or think about it this way, “Slower to go faster, later” (once you’ve figured a lot out).

You should:

1. Talk to users before you build (you need to understand them deeply)

2. Focus on your riskiest assumptions first and resolve those

3. Run experiments pre-MVP building (use AI to do more testing, faster)

4. Define the smallest MVP scope that you believe will solve the problem

5. Define the frequency of usage (what’s the bar you want to hit for Stickiness?)

6. Run more experiments with concepts + prototypes if need be

7. Then build the MVP

8. Then measure usage / Stickiness / value creation quantitatively and qualitatively

9. Iterate over and over and over

10. Get to Problem-Solution Fit

Feel free to skip steps. You might figure it out, but…

If you’d like to watch the full presentation and Q&A, it’s below:

Their argument? AI makes it so easy to build stuff that you should just go build. Follow your curiosity. Live on the edge of the future. You’ll bump into something useful eventually.

That’s nonsense.

Yes, AI makes it easier and cheaper to build. You can spin up landing pages, agents, and even entire apps overnight. But faster doesn’t mean better. Speed without direction is just chaos (not “focused chaos” 😏).

Eric Ries, the author of The Lean Startup, never said “don’t build”. The core Lean principle is literally: Build–Measure–Learn. It’s about building quickly in order to learn (not build quickly to fail fast, btw). The faster you go through the loop, the better your odds of landing on something that actually matters. AI is an accelerant to Lean Startup, not its replacement.

The anti-Lean sentiment coming from YC and elsewhere is reacting to a straw man: that Lean is slow, focused on too much validation, and allergic to building. But Lean Startup was never about analysis paralysis. It was never about “ask 100 people what they want and then you’re set.” It was always about de-risking the riskiest assumptions—as quickly and cheaply as possible. And then iterating (over and over).

That’s the whole game. Not guessing. Not blindly launching. Not betting your time (and runway) on unvalidated hunches.

Let’s break down the real Lean Startup principles, and why AI doesn’t kill them. It supercharges them.

Subscribe now

1. Start with the riskiest assumptions

Lean Startup emphasizes starting with the riskiest assumption first. Nine times out of ten, that’s desirability. Will anyone even want this? Will they care enough to switch from what they’re doing now?

AI doesn’t change that. If anything, it gives us a better tool to test it. Now you can build a landing page, wire up a chatbot or agent, and simulate the core value prop in a weekend. That’s good, because you can now launch something lightweight to test desirability in the real world, although you don’t have to build a complete product. Prototypes are perfectly suited for testing value propositions and desirability and they can be created quickly with AI tools.

There is a trap though. Once founders ship something—even something small—they tend to fall in love with it. They over-invest emotionally. It’s no longer an experiment, it’s their startup. That makes it hard to walk away, even when the signal is weak.

To YC’s credit, they push hard on growth metrics. They want to see real traction. If things aren’t moving, they push teams to pivot. True validation only comes when you launch something and see how the market reacts. You can’t interview your way to victory. We’re 100% aligned on that. Unfortunately, founders build and launch without real discipline and get caught in the hype.

Lean Startup said “validate before building” not just because building used to be slower and more expensive, it’s because launching clouds your objectivity. It becomes harder to see your work clearly once it’s out in the world. Use AI to launch faster and test desirability. But don’t confuse building fast with being right.

You can run the experiment. Just don’t forget it is an experiment.

2. Validated learning matters more than raw output

AI makes building easier. But are you learning anything when you launch?

Most AI startups today are obsessed with building and launching. Very few are actually measuring learning. They’re not talking to users, not watching behavior, not asking why users churn after day two.

Here’s the real danger: without validated learning, pivoting becomes much harder.

I define a pivot as a shift in one aspect of your startup’s focus, based on validated learning. Not guessing. Not flailing. Not jumping to the next shiny idea. Pivoting is strategic. It’s directional. It requires clarity about what’s working and what’s not.

If you’re not testing your riskiest assumptions properly—if you’re not focused on learning—you don’t pivot. You just restart. You throw out idea #1 and spin up idea #2, without ever knowing whether #1 had potential. Or you spin up five ideas simultaneously because you can, but don’t have a good enough framework for judging which is best (except for early growth signs, which aren’t always enough). Did you test things properly? Did you give it enough time? Probably not.

In a rush for hyper-growth (which AI absolutely fuels), founders jump from idea to idea until something “sticks.” When it does, they might not even understand why. That’s not a repeatable process. It’s luck. You can’t scale luck.

Share

3. Customer understanding is non-negotiable

Skipping customer understanding = almost certain death. ☠️

In 2007, I built Standout Jobs in a market (HR/recruitment) that I didn’t understand well enough. The tech worked. The product was slick. But the market didn’t buy. In my post-mortem, I realized, “The lack of market understanding ultimately meant that we couldn’t match the right product to the right market at the right price.”

Founders today are doing the same thing all over again, this time with AI.

They spot a clunky workflow in an old school industry and think, “AI can fix that!” Maybe it can. But unless you understand why it’s clunky in the first place—regulations, incentives, integrations, legacy behaviors—you’re solving symptoms, not root causes.

That’s why deep customer understanding is everything. It’s not optional.

Mike Krieger, Anthrophic’s Chief Product Officer (and ex-Instagram co-founder) says it well:

AI can help navigate customer understanding. Use it to simulate early customer interviews with “synthetic users” that behave and respond like your target audience. It’s a fast, low-cost way to pressure-test your assumptions, spark insights and prep your thinking before getting in front of real people.

But let’s be clear: synthetic users are not a replacement for actual users. They don’t have unpredictable emotions. They don’t give confusing, frustrating feedback. They don’t reveal buying behavior. They don’t ghost you on follow-up.

Synthetic interviews are a great starting point, but if you stop there, you’re flying blind. You still need to talk to real people. You still need to feel their pain, understand their motivations, and decode the irrational stuff that makes or breaks product adoption.

4. Distribution is still a monster

Distribution is getting harder, not easier. When 1,000 AI startups all launch the same idea with the same landing page template and the same OpenAI wrapper, nobody stands out.

Pete Flint from NFX recommends going into very narrow niches (which I love).

There are two major issues AI startups are facing:

1. False positives on early traction

2. High churn (which may be “invisible” early on)

Many AI startups see early traction, but that momentum may be a mirage. Those “positive signals” may be false positives. The mainstream buzz around AI is driving people (including those working in old school businesses and big enterprises) to try AI tools quickly. Bosses are telling employees, “use AI!” So they do, even if they don’t understand what’s happening or if it’s helping.

That leads to tons of signups, early adoption and even revenue. But AI tools can still disappoint in the same way that plenty of software did before. People get distracted by other shiny objects and jump from one solution to the next. Suddenly those early growth signals aren’t real enough to justify raising millions of dollars and growing at all costs.

We’re now seeing high churn become a real problem for new AI products. Users try a new AI tool, come back once or twice, then move on. People are discussing this more openly: enterprises are buying fast, startups are hitting big MRR and ARR numbers quickly, and then churn kicks in because the tools don’t create enough value, switching costs are low, etc.

Dirk Sahlmer’s post is spot on:

Your AI startup hit $2M ARR in weeks?

Cool... but let's talk about the elephant in the room:

10-15%+ Monthly Revenue Churn.

This is the reality I've seen across many of the AI SaaS companies I spoke to in 2024.

Here's what's happening right now:

• 63% of global IT leaders fear being left behind if their organizations don't use AI

• US companies spent an average of 650,000 dollars on AI last year for this reason

• Fear of missing out (FOMO) is driving rapid, sometimes hasty AI adoption

The result?

Explosive early growth: Check.

Product-market fit: Let's wait and see.

Jason Lemkin from SaaStr describes “stealth AI churn” which may be a precursor to serious problems:

Traditional churn is binary: customer pays or doesn’t pay. Stealth churn is analog: customers pay the same for now — but use you 40% less. They’re still showing up in your retention cohorts, still generating ARR, still appearing in your success metrics.

But the underlying consumption patterns tell a different story:

• Session frequency drops as AI tools handle quick tasks

• Feature adoption stalls because alternatives exist for advanced use cases

• Time-to-value shrinks but so does total time spent

• Expansion revenue evaporates as customers find they need less, not more

The scary part? Your NPS might actually go up. Customers love using you for what you’re genuinely best at, while AI handles the rest. They’re happier with a smaller slice of their workflow.

Even grassroots startup founders see it coming. One post on r/startups warns:

“A lot of these companies look like they’re winning right now but that early traction doesn’t mean long-term success… the real test is whether people keep using the product after the novelty wears off.”

Churn matters. You can launch fast with AI, but fast churn still kills growth and breaks distribution.

Don’t get me wrong, growth is good. But growth without retention is noise. Distribution isn’t about getting people to try your product. It’s about getting them to stay.

Subscribe now

5. The MVP isn’t dead. The bar has just gone up.

There’s a growing chorus saying “MVPs are dead.” Some now want MLPs (Minimum Lovable Products), others prefer SLCs (Simple Lovable Complete). My suggestion? Ignore the terminology (although I remain steadfast in my belief that the term MVP still works and is completely valid!)

At the end of the day, your job is to solve a real problem, create actual value, and then solve for distribution. That’s it. You don’t need the perfect label. You need traction with meaning behind it.

The purpose of an MVP is to get to problem–solution fit; that critical stage where you’ve validated there’s a real problem by building a solution that creates value.

AI makes it easy to build and ship. This should make it easier to build “complete MVPs” that create actual value (instead of shit MVPs that are so thin no one cares). It also leads to over-building. Founders love features. Without proper customer insights or validation, founders can just keep building and building and building. Bloated software was never the answer to winning.

I’m blown away by the capabilities of no-code and AI coding tools to help bring someone’s vision to life. I love it. Being familiar and comfortable with these tools is a must. Tools that make it easier to build products are huge unlocks for tons of founders (especially non-technical ones). But don’t be delusional. Just because you can build something, doesn’t mean you should!

Don’t worship the acronym (MVP, SLC, MLP, etc.) Worship the outcome: clarity on problem–solution fit, confidence in the value you’re delivering, and enough user insight to scale with intention.

6. Measuring the right things still matters

Validated learning isn’t a gut feeling. It’s not “this feels promising” or “our demo signups are growing.” It’s rooted in innovation accounting, one of the original Lean Startup principles that gets far less attention than it deserves.

The idea is simple: define a baseline, run experiments that drive learning, and use the results to show true progress. In a world of AI-powered speed, this gets complicated. It’s so easy to launch multiple products and chase “winning” without knowing how to methodically and systematically get there.

If you’re not measuring the right things, you’re just accelerating your way into a wall.

I’m biased, but this is where Lean Analytics is helpful.

For starters, you need to figure out what stage you’re at. We identified 5 stages that every startup goes through: Empathy, Stickiness, Virality (Growth), Revenue and Scale.

Going through the stages in order increases your odds of success, because you’re building a logical foundation:

• Empathy: Prove people care about the problem

• Stickiness: Prove people will adopt the solution

• Virality (Growth): Prove you can acquire more customers in a repeatable way (beyond early adopters)

• Revenue: Prove the economics of your business

• Scale: Grow!

At each stage there are key metrics you measure (which are also dependent on the type of business you run).

The emergence of AI doesn’t change this. AI should accelerate your experiments (which is a good thing!), but it also makes it easier to get lost in noise:

• Signups ≠ retained users

• Chat interactions ≠ engaged customers

• Early ARR ≠ product-market fit

I’ve seen founders stare at dashboards that are lighting up—all green—and still feel like things aren’t working. That’s because they’re not tracking learning. They’re tracking growth surface area, not progress toward value.

Use AI to build faster, test more, reach further, but ground yourself in metrics that matter. Ask:

• Did we de-risk a core assumption?

• Did we learn something new about the user or the problem?

• Can we draw a clear line between this metric and a better outcome for the user?

If you’re not tying your growth to real user value, you’re not building a business. You’re building noise.

Share

So no, Lean Startup isn’t dead

What’s dead is the lazy version of Lean that people caricature to feel better about skipping customer work.

What’s alive and thriving is the opportunity to use AI to supercharge the Lean cycle.

• Build faster? ✅

• Run experiments more cheaply? ✅

• Get prototypes in front of users instantly? ✅

• Skip customer insight? ❌

• Ignore distribution? ❌

• Assume people want your product because it’s cool? ❌

In the past it may have taken you a week to run 1 experiment. Today you can run 10 in the same time. That’s powerful, but only if you do it properly, stay hypothesis focused, prioritize what matters and remain intellectually honest about the results.

Does AI increase the odds of success?

AI is spawning an explosion of new startups. That’s a good thing. Entrepreneurship is one of the only real solutions to the world’s biggest problems. We need more founders!

• AI is a tool to speed up startup creation, which is good (if done properly)

• AI-first startups (where AI is core to the solution) will solve huge problems that previously could not be solved as effectively (but only if customer validation is at the core)

Net-net, I’m bullish on AI. But not if we throw away the fundamentals. If you do that, you’re still going to fail, regardless of how committed you are to using AI.

Failure comes because of:

• Weak customer insight

• No real distribution plan

• Shallow industry understanding

• Obsessing over building, not validating

• A leaky funnel with no plan to plug it

It’s 2025 and we’re still making the same mistakes. The scary part? We’re doing it faster. That’s not progress. That’s just speed.

If you’re building with AI, awesome. Use it. Push the boundaries. But don’t fool yourself into thinking that validation is a relic of the past.

Solve real problems. For real people. In ways they actually want. Honestly, this may be the only legitimate moat left (true customer insight).

Do that, and you’ll stand out from the AI noise.

Otherwise, you’re just another product (or collection of features) in the infinite scroll of “launches” no one asked for (but they’ll test things out any way, maybe even pay and then churn out…)

I’ve seen the posts on LinkedIn and other social platforms—founders that have raised millions without a pitch deck. Good on ‘em. For the rest of us, we need a pitch deck.

A pitch deck is the best tool I’ve found for consolidating thinking into a simple format; there’s very little room for extraneous nonsense. It’s a forcing function that encourages founders to focus on what matters, demonstrate clarity of thought and put their best foot forward.

The greatest pitch deck in the world still doesn’t guarantee you raise capital, but it certainly won’t hurt.

Unfortunately, most founders do a mediocre job at best.

Subscribe now

8 Common Mistakes in Pitch Decks

At the pre-seed/seed stage (where I focus), I see a lot of common mistakes in pitch decks (and frankly in company building too—since the pitch deck is simply a reflection of what you’re doing in your startup):

1. Nailing the problem: Too few startups really nail the problem with a clear user, need and deeper need. Often the problem is too high-level—“data entry sucks” or “enterprises can’t find knowledge in their systems” or “people want better healthcare”. Yawn. Tell me something I don’t know. Show me that you’ve dug in deeply, understand the user better than anyone else and have actually identified a non-universal, non-obvious problem.

2. Poorly designed pitch decks: Most of us aren’t designers, but if you can’t put a bit of polish into things it falls flat. BTW, some people argue that skipping the pitch deck entirely (and using a long form document/memo) is better than having to “waste time” investing in design. I get it, but I still want to see a clean, nicely designed deck. Also, typos suck. If you can’t spend the time checking for spelling/grammar errors, why should an investor spend time reading the deck? 🤷‍♀️

3. No use cases: A pitch deck sucks when it doesn’t clearly articulate how the solution works on behalf of a customer (i.e. how a customer uses it to get value). Often, founders go very technical (which I wouldn’t recommend). Articulating use cases shows that you actually understand how a user/customer gets value. And value is the key.

4. Unclear assumptions: I lose interest when your pitch deck looks like it has all the “perfect” answers but no underlying clarity around the assumptions. At the early stage (pre-seed or seed), everything is built on assumptions. When those shine through it shows that you’ve done your homework, recognize where there’s risk and hopefully, have a strategy for mitigating or removing the risk.

5. Nonsensical market sizing: I hate the “Market Size” slide with TAM, SAM, SOM. Sigh. Most founders get this terribly wrong, in part because they’re pulled in two directions. Some investors say, “market size at an early stage isn’t important,” whereas others say, “you need a very clear market size slide and the market better be BIG!” Founders often put the biggest market size possible, which is typically 100% irrelevant, because it’s too vague.

6. Lying: Don’t lie. Founder culture is ingrained with “fake it till you make it” but that’s not the same as lying. Embellishing or selling the dream is common practice. Confidence (without being a maniac) is a necessity. Lying is a no-no. Classic example: putting customer logos into the deck that aren’t customers. I’ve seen this numerous times and it’s not hard to figure out. Once, I was watching a major accelerator’s Demo Day and a founder highlighted my company as a customer in their presentation. We weren’t a customer. 😝

7. No clarity on “why now?”: Why is now the perfect time to build your startup? What is happening in the world that suggests you’ve got the timing right? A lot of pitch decks have a “Why Now?” slide, but it usually says something pretty basic and disinteresting.

8. Lacking real insight: What do you know that no one else does? What advantage do you have building the startup you’re pitching? Is it domain expertise? Secret distribution channels that no one else has access to? Genuine tech IP that’s so interesting to customers (I don’t care about patents) you’ll be able to sign them up more easily than competitors? An insanely deep understanding of users’ needs? You need something that suggests you’re the right person/team for the job.

Review enough pitch decks and the sea of sameness is overwhelming. It’s a blessing and a curse. If you stand out, answer the key questions investors have properly, and tell a clear, compelling story, investors will listen. If you don’t, they’ll ignore you.

Share

Pitching = Storytelling

I wish people understood this better and took it seriously. A pitch is a story. You need to bring people along for the ride and get them emotionally invested. That’s why I like the “Hearts, Minds, Wallets” structure:

💗 Hearts: Capture readers/listeners at an emotional level. Articulate the pain, make it visceral and signal to the audience that you’re the best person/team to solve the problem. If people don’t care (about the story and the heroes, victims or villains in it), they’ll move on.

🧠 Minds: Appeal to the audience’s logical side. Where’s your data? What work have you actually done? Demonstrate that you’re doing things systematically and clearly, so the audience thinks, “These people know what they’re doing.”

💰 Wallets: Make the ask. Show the numbers. But don’t end there. Go back to the beginning and re-articulate the “why”—remind the audience of how they felt at the beginning of the pitch deck. Share the mission/vision. Get people pumped to engage with you.

For more information, check this out:

Pitch deck structure matters (i.e. there’s a fairly logical flow to most pitch decks) but there are no absolutes. Tell your story the way you want to tell it, but make sure you capture people’s attention, explain things clearly and end strong.

Here’s a breakdown of a pitch deck I put together with my team at Highline Beta for a startup we were validating:

It’s not perfect, but you can check out the full pitch deck with an explanation of each slide and how we built the deck. It should be particularly helpful for very early stage founders.

Subscribe now

I Want to Help: Send Me Your Pitch Deck

I’ve gone through thousands of pitch decks and worked with hundreds of founders. I enjoy helping founders when I can, and particularly enjoy storytelling. Your startup won’t automatically win because you have a great pitch, but it can’t hurt!

With that in mind, I’m kicking off the “Great Pitch Deck Review”—fill out the form below (click the link), send me your pitch deck, and I’ll do my best to send you feedback.

👉 Submit your pitch deck for review

A few key points:

• I can’t sign NDAs, so don’t ask me

• I’m not looking for deal flow, I’m just looking to help

• I won’t judge the startups themselves as much as I’ll focus on the pitch deck (story, flow, content, design, etc.)

• I may not respond (if there are too many, or your pitch requires too much work)

• It may take me days to a month+ to respond (I can’t rush the process)

• I will review every single deck and provide personalized feedback (it’s not AI, although maybe AI is better than me at this!)

• It’s free of charge

I look forward to reviewing your pitch deck!