In 2013, Alistair Croll and I published Lean Analytics, a book about using data to make better decisions. One of the most popular parts of the book was our business model diagrams. We mapped six business models: freemium Saas, e-commerce, mobile apps, user-generated content, marketplaces and media sites. The focus wasn’t exclusively on how these businesses make money. The focus was on understanding the whole business, each moving part and how one part affected another. Everything is a system.

We described each business model in-depth, drew diagrams to understand user/customer journeys, and identified a set of key metrics that matter, depending on the stage of your business.

Then along comes AI…

Suddenly, we have a host of new business models that warrant investigation.

I started exploring this further with a simple version of a usage-based product, using Candor as my case study. I published it as “Model 7” in my post on systems thinking.

Subscribe now

On LinkedIn, Alistair was gracious enough to suggest that I’d just written the missing chapter of Lean Analytics.

This wasn’t quite the missing chapter, but got me thinking…what are the new AI business models and how do they actually work?

With that in mind, I dug in.

Introducing AI Business Models

This is a new website with 8 AI business models that are defined and mapped.

The content isn’t as thorough as Lean Analytics, but it’s an interesting starting point.

Share

How to use AI Business Models

The website lists each of the AI business models:

1. Model and inference APIs (e.g., OpenAI, Jev, Fireworks AI)

2. Consumer AI subscription (e.g., ChatGPT, Midjourney)

3. Subscription for usage credits (e.g., Lovable, Clay, Moselle)

4. Pay per job (e.g., Crosby, Candor, EvenUp)

5. AI add-on to existing SaaS (e.g., Microsoft Copilot, Notion, Canva)

6. Outcome-priced AI agents (e.g., Fin, Sierra, Chargeflow)

7. Ad-supported AI (e.g., ChatGPT, Amazon Rufus, Koah)

8. AI-native services

It’s a comprehensive list, but not necessarily exhaustive. AI business models are evolving quickly. It’s tough to keep up.

Each model has a detailed description, metrics that matter and a systems diagram.

The site gives you a walkthrough for how to select the right model(s) for your business. Most companies leverage at least two models at a time, which is exactly what we uncovered with Lean Analytics as well. It’s rare to find a company using one model. Things are even more complicated today.

Each systems diagram can be downloaded as a PNG, PDF or PPTX file. The PPTX files are easy to update, which you’ll want to do, to customize them to your business.

The site also has a News section, which updates weekly with curated information about AI business models. If you want to stay up-to-date with things, please subscribe.

My hope is that people see AI Business Models as a genuine resource that they come back to over and over. I intend to update things regularly.

How to read a business model diagram

The business model diagrams represent a high-level, but complete view, of how each AI business model works.

Here’s an example:

I know that’s not easy to read or digest, but you can download the file, or zoom into it on the site.

• Read the diagram top to bottom, starting with how users/customers are acquired.

• In this case, I’ve mapped two approaches to customer engagement: a free trial with free credits, or a sales-led approach. That definitely adds complexity to the diagram. It’s also a good reminder for why you need to customize the diagrams to your business.

• Imagine a user/customer flowing through the diagram, where the movement between steps is represented by a metric.

• Not every single detail is mapped. For example, the diagram assumes the customer sees a demo, runs a pilot and converts. That might require multiple sales calls. Technically, each of the business model diagrams could have multiple levels, where you double click into, or zoom into, specific sections to see more precise detail. I didn’t map out those details, but you could (and should) when designing your own business models. When you do that you truly start to understand every step and flow through your business, and where there may be bottlenecks.

• The goal is to understand the system, not just one part of it. Then, it’s important to decide where to focus. Pick one area of the map that’s the most troublesome, and work to fix it. Once that’s done, you can logically move to the next part of the map and fix that. And so on.

Subscribe now

Things I want to add to the site

There’s a lot more I can do with AI Business Models. Here are a few of the ideas I’m pursuing:

1. A business model generator: An AI-tool that would take your inputs and help you map your customized business model.

2. More case studies: I’ve used Candor as a case study, to demonstrate how models blend together, but I want to publish more case studies. Lean Analytics had some great case studies that brought the concepts to life.

3. Metrics per stage: In Lean Analytics we defined 5 business stages (Empathy, Stickiness, Virality, Revenue and Scale) and there were specific metrics to focus on per stage. The site might list those metrics, but doesn’t organize them by stage. Once I’ve got metrics per business model per stage, I can help identify the One Metric That Matters at any given point in time.

4. More benchmarks: Each business model has a few examples and benchmarks for metrics, but it’s not comprehensive. In some cases, there isn’t enough data yet, or I could only find anecdotal data. Eventually, I could see the site having up-to-date benchmarks for every key metric.

5. A survey: I’d like to collect more data from people on what business model(s) they’re exploring. I want to understand how people are pricing their products, integrating business models and figuring things out.

If you have any ideas for how to improve the site, please let me know!

AI is fundamentally changing how businesses work

Thank you mister obvious. AI is pretty much changing everything. Some of that’s good, some less so. But here we are, in the midst of insane change, trying to wrap our arms and brains around it.

From a business perspective, AI changes the very fundamentals of the work we produce and the value we create for others (and ourselves). It changes expectations (and is doing so faster than I’ve ever seen).

If you’re building an AI product, you have to completely revisit everything, from how you on board users to how you monetize. AI is leaving no stone unturned. But it’s still extremely new and unclear.

Each of the eight business models I’ve defined have historical precedence. For example, there are lots of companies built on ad revenue. We understand how ad revenue businesses work. But ad-supported AI businesses? Very different, and still unproven.

SaaS (software subscriptions) has been a mainstay for twenty years. What about subscriptions for usage credits though? Similar, but different. And the new subscription model for AI use is in flux. Even the concept of “a credit” is fuzzy, because it’s a made up way of defining some amount of use.

With all of this change, I thought it would be cool to centralize AI business model information, with a Lean Analytics lens. Hopefully others feel the same way!

You can check out the site today at https://businessmodels.ai.

I’m a fan. But as I watch the hype around systems thinking reach a feverish pitch, my first reaction is: wait, wasn’t this what we were supposed to be doing already?

As far as I know, no one’s claiming they invented systems thinking recently. Elizabeth Stone points to Donella Meadows’ Thinking in Systems, which came out in 2008. What’s new is the urgency. Systems thinking has gone from a nice-to-have skill to the thing that will save your career in the AI era. Come on now, it was always mission critical. The AI hype machine needed something new to latch onto. Enter systems thinking.

When Alistair and I wrote Lean Analytics in 2013, we didn’t specifically call it systems thinking. But that’s what we were articulating: map the business, figure out where you are, identify the biggest constraint, measure it, test ways to improve it and repeat. We designed diagrams that mapped business models. We created frameworks for logically figuring out what to focus on. I guess we’re systems thinkers. Who knew? 🤷

Beyond the insane hype machine that is “everything AI,” systems thinking really does matter. AI can make individual tasks faster and output cheaper. That creates more opportunities to improve a business, and more opportunities to make one part look productive while quietly breaking another. You can generate ten reports in the time it used to take to write one. Congratulations. Who’s reading them? What decisions are they improving? How much work did you create for everyone else?

Subscribe now

Old Ideas, New Consequences

A lot of the current “systems thinking” advice says things like, “be strategic” or “think about the big picture.” Not helpful.

The useful part is understanding how things interact: feedback loops, delays, constraints and unintended consequences. Improving one part of a system doesn’t automatically improve the whole. Sometimes it makes the whole worse.

Lean Analytics gives you a practical way to act on that understanding. The business model is the system. The stage you’re at helps identify where to focus. The One Metric That Matters (OMTM) gives you a priority. Lines in the sand tell you what result would justify a decision. Build-Measure-Learn gives you a way to test your assumptions.

Lean Analytics is systems thinking with a scorecard.

That’s the kind of discipline needed when using AI and embedding AI into your products.

What are you measuring? Why? Over what period? What would convince you that your understanding of the system is wrong? What will you do differently when you find out? Without those questions, you can spend a lot of time producing tons of output and very little time learning anything useful.

The simplest example is how people are adding AI to their work. I wrote about this in How I Use AI Without Outsourcing the Thinking. Documents are cheap to produce now, so people produce more of them, and the work of figuring out what matters shifts to whoever has to read them. At this point, everyone’s received workslop. It’s exhausting.

If you add AI to one step and only measure that step, you may miss the cost you pushed somewhere else. Measure the whole workflow: time to a usable decision or completed job, rework, quality and the effort required from everyone involved. Writing the report faster is useful if the report helps someone do something. Otherwise you’ve accelerated the production of homework for your colleagues.

The same issue shows up when AI is the product, with a few additional complications.

A Business Model Where Every Use Has a Cost

In Lean Analytics we included six business models: e-commerce, SaaS, free mobile apps, media sites, user-generated content and two-sided marketplaces. Each had a diagram showing how users move through the business and which metrics matter along the way.

Building Candor, I went back to the SaaS chapter, and it was a bit of a time capsule. We wrote that consumption pricing was “largely confined to Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) cloud computing companies today.” We also described the incremental cost of another SaaS customer as negligible. Those assumptions need revisiting for AI products.

Usage-based pricing predates AI. Variable costs do too. But if delivering your core value requires model calls, the relationship between usage, revenue, quality and cost becomes very visible. I’d pay attention to four things:

1. Usage can drive both revenue and cost. In a usage-based product, revenue depends on active customers, jobs per customer, units per job and price per unit. A subscription may add a fixed component, but usage still matters. More activity isn’t automatically better if you lose money delivering it.

2. Customers can disappear without cancelling. A pure pay-per-use customer has nothing to cancel. They just stop using (and therefore spending). Subscription customers can cancel or downgrade, but how we measure churn is changing.

3. Delivering trial value can incur material costs. Traditional free trials aren’t free to operate either. But in an AI product, showing someone what the product can do may require substantial computation. That cost belongs somewhere in your acquisition economics.

4. Successful execution and useful output are different things. Traditional software can produce disappointing results too. But AI adds another source of variability: the same workflow can run successfully and deliver outputs of very different quality. You have to evaluate the result, not just whether the job completed.

To bring this to life, I created a new business model diagram for Candor. It represents a usage-based AI product with a free trial and an optional subscription. It won’t fit every AI product, nor should it. You need to map your own business.

The beginning looks familiar. Visitors become trial customers, complete setup and reach their first result: the AI does a real job and delivers an output. But reaching first value requires another question. Was that output useful? Then comes the question that matters most at my current stage: does the customer return for another job? If they do, they become a repeat, paying customer.

In Candor, we have two pricing models: one is completely pay-as-you-go, the other has a subscription with usage fees as well. This makes the diagram a bit more complicated. Fundamentally, the key is whether or not people try Candor, see enough value, and then use it again.

Share

Three Problems That Look Like the Same Problem

A customer runs one job and goes quiet. What happened?

1. Maybe the output wasn’t good enough. They tried the product, didn’t get sufficient value and decided to move on.

2. Maybe they don’t have another job right now. The product worked. They’ll return when the need comes up again.

3. Maybe they never had a recurring need. They were curious, or had a one-off task, but they aren’t the right customer.

From the outside, all three look the same: one use, followed by silence. But what you do about them should be very different. A quality problem calls for product improvements. An infrequent need might call for patience, or better pricing, along with an understanding of the customer’s timing. A customer-fit problem calls for changes to acquisition and positioning.

You can easily choose the wrong response. Improve the product for someone who has no further need, and they still won’t return. Send more reactivation emails to someone who got a lousy result, and they’ll ignore you (and potentially get quite annoyed too). Decide your positioning is broken when the customer simply needs research once a quarter, and you may abandon a useful segment too soon.

Those aren’t the only explanations. Price, setup friction, competing tools and internal approvals can all get in the way. The point is to build a set of hypotheses you can investigate, rather than assigning every quiet customer the same label.

Two feedback loops can help:

1. The first is sharing. Some AI products create reports, decks, code or other outputs that customers share, and those outputs can bring in new visitors. That only becomes a growth loop if people actually share the assets they create and recipients become customers. A “share” button is not a growth strategy.

2. The second is learning. Review outputs, identify failure patterns, turn those patterns into evals and improve the product, and better results may increase reuse. But the loop doesn’t run itself. Usage generates material you can learn from. You still have to do the learning.

Underneath all of this are the economics. Every job consumes resources, so you need to understand gross profit per job, including the retries and checks required to produce an acceptable result. Sometimes better quality requires a bigger model or additional steps. Sometimes a better prompt, better routing or less unnecessary processing improves quality and lowers costs. You need to measure both.

Dormant pay-per-use customers generate little or no usage-related cost, which makes them easy to ignore. But you paid to acquire them, and their absence may be telling you something important. Silence is cheap to host. It can be expensive to misunderstand.

What This Looks Like With Candor

Quick background: Candor is a synthetic user research tool. You describe an audience, Candor researches it and creates synthetic participants grounded in that evidence, interviews them and produces a research report.

The business is primarily usage-based, with a subscription layered on. Every new workspace gets a trial project, enough to build an audience, create synthetic users and run a real study. After that it costs $7-$10/interview depending on whether or not you’re subscribed monthly. Users are unlimited because we’re charging for research, not headcount. We also hope this encourages customers to invite more team members, who subsequently do more research. The pricing details are public.

In the “Usage-based AI product lifecycle” diagram above, an interview is a unit, a study is a job and the workspace is the customer account.

In Lean Analytics terms, we’re in the Stickiness phase. It’s live and people are using it. Now we need to answer the questions we put in the book: “Are people using the product as expected?” and “Are people getting enough value out of it?”

Growth isn’t the priority yet. As we wrote in the book, “if you can’t convince a hundred users to stick around today, you’re unlikely to convince a million to do so later.”

My One Metric That Matters (OMTM) is the percentage of workspaces that complete a trial study and then complete a second, paid study within 30 days.

People signing up and running a trial is encouraging. Someone paying to run another study is a much stronger signal that the first experience was worth something. It isn’t proof of lasting value, but it’s a meaningful next step.

• The 20-30% paid conversion target is a bit high based the early benchmarks I’ve found (although there isn’t a ton of data out there about AI usage-based product conversion yet).

• The “within 30 days” target is a line in the sand. I need the learning cycle to be quick. More than 30 days between studies and I’m learning too slowly.

If I can’t hit the OMTM (20-30% paid conversion in 30 days) it’s a problem that would then need to be diagnosed:

1. Maybe the product isn’t creating enough value?

2. Maybe we’re attracting the wrong customer type, which means they don’t see the value, and/or they don’t have a frequent need?

3. Maybe the price is wrong?

4. Maybe it’s a combination of these things, and/or something else I’m not thinking about?

BTW, I’m not sure if 20-30% conversion to 1 paid study is even economically viable. I know what it costs for a user to run 1 free study, and I’ll have to account for that in my overall CAC.

For now, I focus on value creation, in the Stickiness phase, measured by usage. But that alone may not be enough to build a sustainable business.

Subscribe now

The Scorecard I Need

Reuse is my focus. That doesn’t mean I can ignore everything else. I could encourage more studies by making them cheaper, while destroying the economics. I could add reminders that increase activity without improving value. I could make the first experience look impressive while producing research that doesn’t help anyone. The scorecard needs to keep me honest.

The OMTM gives me focus. Quality and economics provide guardrails. The other evidence helps explain what I’m seeing.

Systems thinking for me, at this stage, means:

1. Focus specifically on what matters

2. But recognize that everything you do in one place likely affects everything else

To do this, I need to collect qualitative and quantitative feedback. I need to better understand customers, their needs and how Candor delivers value. It’s simple, but complex at the same time, which is what makes building products and startups so difficult.

Getting Evidence from Quiet Customers

Happy customers that use your product frequently are fairly easy to get to. Trust me, I’m doing that! I need testimonials and social proof.

You can also learn a lot from happy customers:

1. Why and how are they getting value? Is it what you expected and/or something different?

2. How can you improve the product to create even more value?

3. What’s similar about them that might suggest you’ve identified the right ICP (ideal client profile)? Customer segmentation is super valuable. You might be surprised.

The quiet customers are much harder to get to, but also incredibly important.

I reach out to everyone that signs up. I reach out to everyone that starts using the product. I reach out to everyone that completes their free trial. Some reply. Unfortunately quite a few don’t.

I don’t blame anyone (although it frustrates the heck out of me!) Answering a founder’s follow-up email is rarely the most important thing in someone’s day. So I’m trying to collect useful evidence inside the experience too. A few things I’m doing or planning:

1. Grade the first study myself. I’m already reviewing every study by hand. If an output is clearly weak and the customer doesn’t return, that supports a quality hypothesis. It doesn’t prove why they left, but it gives me somewhere specific to investigate

2. Ask at the moment of value. A one-click question on the report, such as “Would you use this to help make a decision?”, should get more responses than an email days later. If it does, I can see whether the answers help explain who comes back.

3. Ask about expected frequency. “How often do you run research?” gives me a starting point for segmentation. If someone expects to run research monthly and disappears, that’s worth investigating. If someone expects to run research a few times a year, thirty days of silence may be completely unsurprising.

4. Segment by customer and use case. Product managers, consultants and founders may have different needs, and concept testing and problem discovery may have different usage patterns. If one segment returns more consistently, I want to know why. It could be my beachhead.

5. Track return behaviour over time. Days since last study matters, but so does whether dormant customers eventually return when they have a new question, with or without a nudge from me. The second study is my current focus. The longer-term question is whether Candor earns a place in how someone does research.

None of this is particularly fancy. It’s the work Lean Analytics has always asked you to do: identify what you need to learn, choose evidence that helps you learn it and set up the business so you can get an answer. Systems thinking.

Measure What Helps You Decide

AI changes some important economics and introduces new uncertainty into product quality. It also makes it easier to optimize a task while overlooking the consequences elsewhere. That makes systems thinking useful, as it always has been. It makes measurement and judgment useful too.

If you’re adding AI to a workflow, follow the work all the way through to a usable outcome. If you’re building a usage-based AI product, understand how quality, frequency, pricing and cost interact.

For Candor, the question is whether the customer got enough useful value to pay for another study when they have another research job to do. The scorecard helps me investigate that question. It won’t answer it for me. That’s the work: form a hypothesis, collect evidence, make a decision and be willing to change your mind.

If you map your own AI product this way, I’d love to see it. And if you think I’ve got Model Seven wrong, tell me. It’s version one. I expect to learn something.

Evals are essentially ways of systematically testing whether AI output is any good. Pretty important when LLM output can vary from run to run.

I’ve been dealing with this problem inside Candor. The answer? Evals! (Sort of, and that’s the point.)

But not automated ones. There’s no shortage of eval frameworks, benchmarks, LLM-as-a-judge setups, automated regression tests, scorecards and increasingly sophisticated tooling. I’ll use more of that in the future. Today: I’m doing it mostly manual. I’m convinced this is critical, because before you automate things you need to answer a key question: What does good actually look like?

Subscribe now

AI products can be wrong without being broken

Traditional software is relatively straightforward to test. You click a button and something should happen. You submit a form and the data should save. You call an API and you should get the expected response. Software testing can get incredibly sophisticated, but fundamentally you’re checking whether it did what it was supposed to do.

AI adds another layer. The workflow can succeed and the output can still be wrong.

Let’s dig into this using Candor as an example.

Candor is a synthetic user research platform. Someone defines an audience they want to learn from, and Candor creates synthetic users, interviews them and produces a research report. It’s heavily reliant on LLMs.

When Candor works, it creates 15-24 synthetic users, interviews them and produces a polished research report. No errors, no crashes, everything is smooth sailing. But were the users realistic, and did they actually match the audience the researcher wanted? Did the interviewer listen to what someone said and ask smart follow-up questions, or just plow through the script? Did the report overstate something or include a quote that nobody said?

You could call these bugs, but they’re different from traditional software bugs. The workflow succeeded. The output just wasn’t good enough. AI is good at hiding quality problems. A synthetic user can sound completely convincing and still be wrong. A report can read beautifully and contain something unsupported. An AI interviewer can ask perfectly reasonable questions while conducting a mediocre interview.

If you don’t look closely, everything seems fine. Until a customer notices. Or, more likely, they don’t tell you and just stop using the product.

The first version of an eval is you

When people talk about evals, the conversation moves quickly to automation. What model should judge the output? What’s the scoring rubric, the dataset, the pass rate? How do we run evals automatically on every change?

All useful questions. But I wasn’t ready to answer them. I didn’t have a rubric for product output. I didn’t know which things mattered most, and I didn’t know what kinds of failures I was going to find. So I’m starting manually.

I'm not the first to say this. Hamel Husain and Shreya Shankar call error analysis (reading the output yourself) "the most important activity in evals," and Teresa Torres makes the same case for product teams.

Here's what it looks like in practice for Candor:

1. Run the study, or inspect a real customer study.

2. Look at the output.

3. Find the problems. Claude Code helps me find issues, but I read the important parts myself.

4. Look for patterns.

5. Figure out what “better” would mean.

6. Make a change.

7. Test again.

Not very sexy, but it’s already finding real issues. This is the grind of building quality software. We found synthetic user profiles that included facts that didn’t make sense. We found the interviewer occasionally covering ground that had already been discussed, and not handling lukewarm or ambiguous answers as well as I’d like. We found quotes in reports that needed stronger verification against the underlying interviews.

So we fixed those things. Quotes are a good example. Candor now verifies every quote against the underlying transcript before the report is saved. If nobody actually said it, it doesn’t get presented as a quote. That’s a pretty obvious rule once you’ve found the problem. But first you have to find the problem.

That’s really what I’m doing by systematically evaluating everything. I’m discovering the eval. Eventually the patterns become criteria, the criteria become a rubric, and parts of the rubric become automated. Human judgment, then rubric, then automated eval. I don’t think I’d trust that last step nearly as much if I skipped the first one.

Share

Not everything needs an eval

Sometimes the answer isn’t another LLM-based eval. It’s code.

Candor starts by researching an audience and creating synthetic participants. Let’s say a researcher asks for people who work at companies with more than 500 employees. That’s a requirement. I don’t want an LLM to get it right most of the time. Same with age ranges, seniority or other explicit criteria. So we’ve moved those things out of the AI’s judgment. The model can create the person. Code makes sure the person meets the requirements. I have a feeling that people are becoming overly dependent on LLMs to make decisions that are better served through other instruments.

I’ve started using this distinction: If something is a rule, don’t ask the AI nicely to follow it. Enforce it.

This applies way beyond Candor. If something:

• has to be a particular format

• must fall within a range

• needs to match an enum

• must contain exactly five items

• has an explicit eligibility requirement

• can be verified deterministically

…you may not need an eval. You need a check.

Save the AI for the stuff that actually requires judgment. Is this participant realistic? Is this answer vague? Did the interviewer ask a good follow-up? Does this evidence actually support the conclusion? Those are harder questions, and those need evals.

This distinction sounds obvious, but AI makes it incredibly tempting to throw another prompt at every problem. Sometimes the correct amount of AI is less AI.

Sometimes a failed eval is telling you to fix the UX

Candor’s output is not solely the responsibility of LLMs. A user’s input matters too. Candor has a very clear “garbage-in, garbage-out” problem. As people use Candor, I can evaluate the quality of their inputs and the impact it has on the outputs.

It’s tempting to say, “Well, that’s the user’s fault.” It isn’t. Or at least that isn’t a very useful way to think about it. If users regularly put the wrong thing into a field, the field is probably wrong. Or the example isn’t clear enough. Or we need to validate the input before running the research.

I wrote recently about people using AI to generate giant blobs of text and pasting them into Candor. People don’t read instructions. Maybe they never did. Now, I think it’s worse: they have an AI that can instantly create 700 words for a box that probably needs 50.

This is leading to a bunch of product changes. We’re adding better examples directly below fields, with clearer context. We’re warning people when an input looks suspicious, like a concept description that reads more like a research brief. Unfinished setups get saved so people don’t feel like they have to rush through everything.

That’s not an LLM fix. It’s a UX fix. And that’s changed how I think about evals. I’m not evaluating a model. I’m evaluating a product that has AI in it. The quality of the final output depends on the user, the interface, the inputs, the web research, the models, the prompts, the code around them and all the small decisions happening in between. If the final result sucks, asking “Which prompt do I need to fix?” is way too narrow.

Subscribe now

Define “better” before you make the change

I’ve written before about defining “done” before I let Claude Code build something. Claude Code is very eager to declare victory. Ask it to build something, then ask, “Did you do it?” and you’ll get some version of, “Absolutely! Everything is working perfectly!” 😄 Instead, when coding, it’s best to define pass/fail criteria upfront. That way you can define what a feature should do, how it should work, and your expectations on how to validate whether it’s done properly or not.

I’m now using the exact same habit for AI behavior. Before we make a meaningful change, I want to know the current baseline, what we’re trying to improve, how we’ll measure it, how much better the new approach has to be, and whether there’s a cost or latency tradeoff. Then we test it.

This matters because AI makes experimentation incredibly cheap.

“Let’s do more web searches!” Sure.

“Let’s use that new, cool model!” Why not?

“Let’s have another AI check the first AI!” Sounds very AI. 🤣

Before you know it, your product is slower, more expensive and significantly more complicated. But is it better?

I built a blind taste test for search results

Candor builds its synthetic audiences, in part, using web research. If the research is weak, the participants are weak, and everything downstream inherits the problem.

As more people used Candor, I noticed two problems:

1. The system was generating too few synthetic users

2. The synthetic users were too similar

After some investigation, I had a hypothesis that Perplexity could be a better web search tool than Tavily. So I tested it.

I ran the same web search queries through Perplexity and Tavily and compared the results. The initial analysis was inconclusive.

Then I had Claude Code build me a blind review page. Each page shows one study brief and two lists of search results. Nothing tells me which approach produced which list, and the sides are shuffled.

I answer one question: Which list would better help me build realistic synthetic users for this audience?

I ran about 30 of these head-to-head tests.

Perplexity was stronger on some regional searches, especially when we were looking for something specific to one country. But it performed worse at finding broader trends that were still important for creating realistic synthetic users.

That led to another round of questions. Were the search queries themselves the problem? Should we run more searches? Fewer? Should each query focus on one question instead of several?

Down the rabbit hole we went. 😄

The key is that it’s OK, and probably necessary, to evaluate things by hand.

It takes time, and you’re only one judge. But early on, someone has to establish the quality bar. You need to decide what “better” actually means before you ask a system to evaluate it for you.

The whole experiment cost $7.54. A few dollars and a bit of my time saved us from making a change blindly.

A hot new model is exactly when you need evals

This came up again with Jev, a new model from TypeSafe that’s getting a lot of attention. I’m working on a future post about Jev now.

The short version: Jev isn’t designed to generate text like ChatGPT or Claude. TypeSafe calls it a “System One” model. You give it a decision to make (yes/no, pick an option, score something) and it gives you a structured, probabilistic answer. That maps nicely to a bunch of small decisions Candor makes behind the scenes. Is this answer vague? Has the participant already covered this topic? Do we have enough evidence on this audience, or should we keep researching?

New model, interesting architecture, super fast. Let’s put it everywhere!

Nah. Let’s test it first. We took 261 real answers from our test environment and had a stronger model grade each one. That became our answer key. Then we compared Jev against what Candor was already doing.

Some of the results were pretty dramatic. For deciding whether a participant had already told us something, our old keyword rule was right 1 time out of the 26 times it fired. For detecting vague answers, the keyword approach caught 6 of 60. Jev was significantly better at both because it judges meaning instead of matching words. We also tested the decision Candor makes about whether it has enough audience research to continue. Our existing small model wrongly stopped the research 48% of the time across 490 replayed cases. Jev did that 11.5% of the time.

Then we tested Jev for fact-checking participant profiles, and it wasn’t good enough. At least not yet. Depending on the test, it would have missed somewhere between a sixth and a quarter of the real errors. So we’re not using it there. Same model, same product, different job, different result.

That’s why “Is Jev better?” is the wrong question. Better at what? On which data? Against what baseline, at what cost, and how good does it have to be before you’re willing to put it into production?

“New” isn’t a reason to use something. If anything, the opposite is probably true. And “everyone on X is talking about it” isn’t a reason either. Hype is hype. Test things on your actual problem.

Evals tell you what not to ship

In the last couple of weeks we’ve tested more than a dozen ideas that didn’t make it into Candor: different search providers, different ways of creating queries, different models for small decisions and extra verification steps.

Some worked.

A lot didn’t.

This is the part of evals I’m appreciating the most. Most discussion about evals focuses on making AI more reliable, and that’s important. But evals have another job: they tell us what not to ship.

That’s increasingly valuable because the cost of building things is collapsing.

For most of my career, engineering capacity was constrained. You had ten things you wanted and enough capacity to build two. That forced prioritization. We definitely didn’t always prioritize correctly, but there was friction. Building something cost enough that you generally had to make a case for it.

AI is stripping that friction away.

In the last couple of weeks alone I’ve merged more than 200 changes into Candor. That’s a lot compared to what I could have done a couple years ago (which, on my own, might have been zero!)

It’s also dangerous.

Shipping 200 changes doesn’t mean the product is 200 changes better.

AI coding tools are perfectly happy to keep going. There’s always another bug, optimization, prompt tweak, model, agent or verification step. They don’t get tired. They don’t have somewhere else to be. And they don’t particularly care if the product gets better.

I do.

Engineering capacity used to be a forcing function. If building is getting dramatically cheaper, we need a new one.

I think evals are part of that.

The question I’m asking is, “Can I build this?” Yup, I can.

It’s not even, “How quickly can I build this?” Usually, pretty quickly.

The harder question is: How will I know if this actually made the product better?

That’s what I’m trying to build evals for.

And for now, apparently, that means reading a lot of synthetic interviews by hand. 😬

This isn’t an ad for the product. It’s about what I learned getting it ready to launch.

We started in March. I’ve written all the code (thanks AI!) My colleague, Elizabeth van Monsjou, who leads research at Highline Beta, has provided the expertise, research rigour and a ton of testing. Tim Sun, one of our product designers stepped in last minute to help as well.

Candor hasn’t been our full-time job, which means it’s taken longer than I would have liked. I get twitchy if it takes more than 3 months to build an MVP.

But here we are.

Candor is now live, and I spent most of last week and the weekend grinding through final details. It reminded me of something that’s increasingly easy to forget in the age of AI coding: The gap between “the product works” and “the product is launchable” is significant. Most of it isn’t code.

AI made building Candor dramatically easier. It didn’t solve onboarding, positioning, design, customer segmentation, support, feedback, metrics, sales motion or distribution.

Those things still require judgment.

Here’s what I learned.

Subscribe now

The happy path is a lie

We piloted Candor with real users for a month before launch. We learned a lot.

Of course they found bugs. More importantly, they showed us how people actually tried to use the product.

It’s easy when you’re building something to focus on the happy path. You know how everything is supposed to work. You know what to type into every field. You move quickly through testing because, subconciously, you’re trying to confirm that what you built works.

Real users and customers don’t work that way. They go in with fresh eyes and do what people do: muck things up. 😂

It only took two people using Candor for us to see where we’d gone wrong.

The first step in Candor is creating a project and generating an audience of synthetic users to research. To do that well, Candor needs information from the user.

Our first test users weren’t sure what to provide.

They didn’t know what “good” looked like. They didn’t know how much detail to include or how their inputs would affect the synthetic participants being generated.

Some gave us almost nothing. Others wrote a lot without much intent behind it. Both could produce poor results. And if Candor generates weak synthetic users, the customer blames Candor.

They’d be right to.

We had a classic garbage-in, garbage-out problem, with an AI-twist: poor inputs don’t necessarily generate an obvious error. They can generate something that looks plausible but isn’t very good.

We made a bunch of changes:

• We simplified the workflow. Originally you created a project, then an audience, then participants. Each felt like a separate object and it wasn’t obvious what decisions users were being asked to make. Today it’s a single three-step flow. You finish with what you actually want: synthetic users you can research.

• We added better examples. Candor supports B2B and B2C research, so examples for text inputs change depending on which you choose. Context matters.

• We clearly separated required and optional fields and explained why we’re asking for each one.

• We added quality checks on inputs that help people improve weak inputs before Candor generates participants.

None of this surfaces if you only walk the happy path. You built the thing, so you use it the way it was designed to be used. Your users don’t know the design. They just start doing things.

Get real people into your product early. Watch where they struggle. Look specifically for places where user behaviour can create bad outcomes.

And deliberately test edge cases. Some edge cases are fine to ignore. Others are product holes masquerading as unusual behaviour.

AI has dramatically accelerated development. That makes it even easier to rush past these details. Don’t.

Sweat the details that affect whether someone gets value.

Share

AI has given us the “build forever” trap

There are always bugs. There are always improvements. There is always another thing you could refactor, redesign, optimize or clean up.

AI coding makes this worse.

AI is good at finding problems. It’s also good at over-complicating solutions.

Every time Claude Code or Codex (or any AI coding tool) does something for you, it’s going to find more things to do. It’s so easy to agree with the AI tool and get it to keep doing things. Suddenly you’re four hours deep on something no user will ever notice.

I’ve written before that vibe coding without system design is a trap. But there’s another trap: AI has made the marginal cost of changing software so low that it becomes harder to stop changing it.

Before AI, the cost of another feature or refactor forced prioritization. Now another change feels cheap. Twenty minutes here. Thirty minutes there. Forever.

At some point I had to draw a line with Candor and say, “F*ck it, ship it”.

That’s a judgement call, not a surrender. Polishing Candor forever would delay the thing that matters much more now: putting it into customers’ hands and learning whether they actually get enough value to keep using it and pay for it.

The purpose of an MVP isn’t to eliminate uncertainty. It’s to move uncertainty from inside your head into the market.

Eventually you have to ship.

I want to interrupt this post for a moment to introduce you to the Highline Beta Shop.

It’s a merch store for startup folks and corporate innovators, with clothing, accessories, prints and more.

Every Focused Chaos subscriber gets a 20% discount. 🎉

Please go check it out and buy some merch! 😍

OK, back to our regularly scheduled post…

An MVP isn’t an excuse for ugly

I’m a fan of the MVP. I’ve defended it more than once.

Minimum never meant crappy.

People are inundated with software, particularly new AI products. They make very fast judgments about whether something deserves their attention.

A rough product from a company that looks credible may get another chance. A rough product that also looks sloppy probably won’t.

Candor’s first website was completely AI-generated. I focused most of my energy on the content and relatively little on the design. It was OK. But OK is invisible.

At the very last minute I asked Tim Sun, one of our product designers at Highline Beta, for help. I gave him a couple days. What he produced is dramatically better.

We’re still working through messaging. For example, one line we liked, “Building got easier. Building the right thing didn’t.” resonated with a particular audience but not everyone. So we removed it.

There’s definitely more to do, especially inside the product. Candor needs real UI/UX love. Small things compound: the words on a button, a single line of instruction above a field, an empty state. Those are product decisions, not decoration.

An MVP doesn’t need to be beautiful, but it can’t look like it’s completely AI-generated with no attention to detail. Otherwise it won’t clear the credibility threshold required for someone to give it a real chance.

Subscribe now

Your ICP can be fuzzy but your data shouldn’t be

I don’t know Candor’s ICP (ideal client profile) with certainty. I think that’s true for a lot of startups at launch.

My current hypothesis is that Candor fits larger companies with multiple product and/or marketing teams, plus consultants who run a lot of market and customer research. But we’ve also seen smaller and mid-sized startups get value from it. Different buyers, different research cadence, different willingness to pay. Potentially different reasons for using the product at all.

The mistake would be averaging them together.

You don’t have to be right about your ICP on day one. But it’s a mistake to blend different customer segments together.

Right from the get go, I’m trying to define segments:

• If someone books a demo, I ask a few questions to understand more about them.

• When a user signs up, the onboarding process asks for a bit of context as well, without creating too much friction.

• We can also enrich customer data to learn more about the companies signing up.

At the top of the funnel, I want to understand who shows up.

Then I want to understand what happens by segment. Do senior product leaders at large companies use Candor more than senior marketing leaders? Do research and insights teams use Candor more than product teams? Do consultants run more studies? Which segments activate faster? Which retain? Which pay more?

The goal isn’t to create ten segments and drown in analysis.

It’s to avoid concluding, for example, that “retention is mediocre” when one customer segment loves the product and another doesn’t care.

I’m fairly certain I’ll be surprised by which segments emerge.

Before launch, define a handful of plausible segments. Then track them separately. Your customers will tell you which segmentation actually matters.

Your value proposition is a hypothesis too

Before launch, you’ve probably landed on a value proposition you believe in. Maybe two. That’s the right starting point. It isn’t the same thing as knowing.

Customers constantly surprise you about why they care about what you built.

With Candor, we currently see at least three potential value propositions:

1. Research is dramatically faster.

2. People who aren’t professional researchers can still run useful research.

3. Companies can do research more frequently because the cost and effort drops.

Which one matters most?

I don’t know yet.

And I suspect the answer changes by customer segment. A consultant may buy speed because speed is margin. A large product organization might buy frequency because PMs can run research without waiting for access to a research team. A smaller startup may care most about access: they want customer insight but don’t have an internal research or a big research budget.

Same software. Different product in the customer’s head.

That made the website surprisingly difficult. We have two jobs on one page:

1. Explain enough about synthetic research that someone understands and trusts the concept.

2. Communicate why they should care.

Those goals fight each other. Explain too much and you’re teaching a category instead of selling a benefit. Explain too little and people may not trust what the product is doing.

I used Jason Cohen’s new book, Hidden Multipliers to help work through this. His framing around need states and the hierarchy of needs forces you to separate the functional need from the deeper one underneath it.

It’s the same muscle I wrote about years ago in How Do You Know You’re Solving a Problem that Matters?. The “what” is easy to see. The “why” is where the value proposition actually lives.

For now, Candor’s website leans fairly heavily on functional benefits because we believe establishing credibility around the quality of synthetic users and research is essential.

I’m not convinced we have it right. That’s OK (for now).

Write down your competing value propositions before launch. Then listen for which ones customers repeat back to you without being prompted.

That’s far more valuable than arguing internally about which headline sounds best.

Share

Ask for feedback at the moment of judgment

Don’t launch without a way to hear from users.

Usage is usually the first signal. But usage tells you what someone did, not why.

Why did they come back? Why did they stop? Did the output actually help? Was something confusing? You have to ask.

We built two short feedback mechanisms directly into Candor at moments when the user is best positioned to judge quality:

• immediately after Candor generates synthetic participants

• immediately after Candor generates a research report

My goal is to determine if what Candor generates is good and creates value for users.

We’ve also added two other feedback loops:

1. First, we’ll try to speak with as many early users as possible after they’ve actually used the product. Those conversations will almost certainly produce richer insight than any survey.

2. Second, we installed Fullstory, with all inputs excluded from capture, so we can understand how people actually navigate the product.

The key: Have a feedback plan in place before launching that covers what people are doing and why, through quantitative and qualitative analysis.

Decide what “good usage” means before you see the data

You should define what good usage looks like before launch. Otherwise every number becomes easy to rationalize.

Every product has some natural frequency of use. I wrote about this in 4 Steps to Building Super Sticky Products, including the HighScore House story where we set an expected benchmark and adjusted it once real behaviour gave us better information.

For Candor, I’m not sure what the right frequency is. That bugs me. 😏

Candor isn’t a daily use product. It may not even be weekly. How often does a company actually run user research? Monthly? Quarterly? I’m targeting weekly use, but I think that’s ambitious.

Infrequent-use products are harder to evaluate. If someone hasn’t logged into Candor for three weeks, have they churned? Or are they simply between research projects? We may not know for months. That makes early retention data especially difficult to interpret.

Still, pick a number.

An expected usage cadence gives you something to falsify. Without one, inactivity can always be explained away.

For Candor, that number is a hypothesis, not a truth. And like everything else, I expect it to vary by customer segment.

Support is a signal, not just a service

Decide what support you’re willing to provide before the first confused customer asks for it.

Candor has detailed help documentation and Candor Bot, an in-product chat interface with access to those docs. Candor Bot also understands some context about where you are in the product, which means it can answer questions such as, “What am I supposed to put here?”. That kind of AI support is increasingly common. I don’t know how effective ours will be.

We’re also offering training sessions to new customers. I’m wary of adding onboarding friction, but for such a new category it might be the difference between someone getting value and someone bouncing.

There’s an irony when it comes to support. You want it to be excellent, but you also want almost nobody to need it.

Having said that, I’m convinced it can be a differentiator. With everyone automating customer support, having access to a real human could be amazing. I plan to be very proactive.

But, if everyone needs a training session to use Candor, we’ve failed at the product.

Track what people ask. Repeated support questions aren’t just support issues. They’re product data.

The sales motion you want versus the one you get

Candor is a B2B product. The motion I want is simple:

• People discover Candor

• They sign up

• They try it with our free trial

• Some percentage convert into paying customers

What percentage? No idea yet. A high percentage would be…nice. 😆

We also have a “Book a demo” option on the site, because synthetic user research is still unfamiliar to a lot of people. We want to give people an option to engage with us before jumping in. Hopefully this reduces the number of people that sign up, poke around a bit, get confused and leave. At the same time we can’t do a demo for everyone.

The problem is economics. If everyone needs a demo, the motion probably doesn’t work at our price point.

If Candor requires a traditional enterprise sales motion with multiple meetings, procurement, pilots and long sales cycles, we may be in trouble. We don’t necessarily have the bandwidth or business model to support that.

That’s why we’ve kept self-serve signup prominent. “Try for Free” is a strong CTA.

What I want to learn isn’t simply, “Will people buy Candor?” I also need to learn if Candor can be sold in a way that makes sense for the business.

You can have a product customers want and still have a broken business if the cost of acquiring, selling and supporting those customers is too high. Set a threshold for how much human involvement your pricing model can tolerate. Then watch what the market actually demands.

Launching is legitimately just the beginning

A couple years ago I wrote a post called “What Comes Before Zero to One”. I’ve been thinking about this a lot while building Candor.

People often talk about “zero to one” as the process of building and launching something. I don’t think launching gets you to one.

Getting to one means you’ve demonstrated real traction and shown that you’re consistently creating value. Note: That’s still not the same as product-market fit. But it’s much further than, “We have a website,” or “We have 3 users trying things out.”

Candor already has a few customers, a few pilots underway and a waitlist of ~200 people we’re working through.

That’s a good starting position. It isn’t a business.

Now comes the hard part. Marketing. Distribution. Conversion. Retention.

We still have to figure out which customers care most and why. We have to learn why people come back, whether they’ll pay and what breaks when usage increases.

We have a content plan that should help with SEO and AEO. We’ll do social. We’ll work our network. That won’t be enough on its own.

We’re not planning to spend heavily right now because Candor is one of several initiatives at Highline Beta. But we do want customers. And wanting isn’t a channel.

A launch is you standing up and saying: “Here I am. I’m ready.” Usually you get a little burst of activity. And then…😴

That’s when the real work begins. The launch isn’t the milestone. Month two is. And month three. And four. And five. Ask me again then what I’ve learned.

The rules were simple:

• The first letter of the word had to be the first letter on the plate (“A”)

• The last letter of the word had to be the last letter on the plate (“E”)

• The other letters (“V T”) needed to appear in the word, in that order

The quickest person to blurt out a correct word won. We’re a nice family, so we’d let others in the car also come up with a word; often they’d try and come up with a bigger word to sound smarter. 😂

For AVTE you could go with: Adventure. Advocate. Abbreviate. (There are others too!)

It was a fun way to pass the time.

So I decided to build the game.

Introducing Wordspine.

I built Wordspine in a weekend. I’ve been improving it for a week, adding stats, badges, a native keyboard, cleaning up the UI, adding themes and more.

It’s amazing what you can do with AI code development.💪

I shared the game on LinkedIn, X and with a few friends. People showed up. As of 7:47pm last night, I’ve had 481 people play a game. Some try it and leave right away, but there are already a bunch of regulars that have played for several days consecutively.

I haven’t quite hit Wordle-level usage yet, but I’m working on it!

Share

Why am I doing this?

1. I love building things. Too many side projects is dangerous, but this game is really simple. I needed something easy to build compared to my work at Highline Beta and Candor (our synthetic user research platform).

2. The game is fun! If you’re a word game enthusiast, I think you’re going to enjoy it. You might prefer Sprint over Pro (or vice versa), but I genuinely think it’s fun.

3. I get to experiment with specific things. Wordspine is simple, but there are certain mechanics, like how to improve shareability and virality, that require real thought and high-level execution. Game mechanics aren’t easy, I don’t want the game to be too easy or too hard. UI/UX is so important; people have to understand the game quickly and find immediate joy in playing. These are all interestingly complex issues, despite the game itself being dead simple.

4. GTM is always tough. I want millions of people playing Wordspine. Word games are very popular, but getting people’s attention is tough. I’m not an expert. But I like to dabble, experiment and learn. Wordspine is the perfect thing to do that with.

5. There’s no AI. To be clear, AI is writing the code, but there’s no AI in the product. I’m a fan of AI and use it a ton, and Candor is incredibly AI-heavy in the product itself. Wordspine gives me a small little piece of the world that’s for the most part AI-free. 😃

Subscribe now

What’s next?

World domination. Maybe an exit to the New York Times. Who knows?!?!

Product-wise I’m tinkering. A few things I’m thinking about:

• Adding some type of score to Sprint. Right now it’s only time-based, but a few people have given me feedback that they’d like to get points for longer words and compete on score along with time.

• UI improvements. I’d like to tighten up the UI, and add a bit more to it. I want to give the game more personality. It needs to remain super simple, but it can also be distinct (without feeling foreign to word-game fans). (Brand is one of the only remaining moats!)

• Increasing competition. You can share your progress in Wordspine with friends and challenge them. The mechanism is starting to work, but I’d like to make it really valuable and fun for people.

• Native mobile apps. If the game gets popular enough, I want to build native mobile apps for iOS and Android. I’ve never built either, so I figure…why not?

Not all the feedback has been positive. I posted Wordspine in /r/playmygame and got this comment:

That was before I redid the brand and UI completely. They were right: the design was very basic and felt AI generated. Hopefully that’s not the case now. I have no clue if responding to comments on reddit makes a difference, but I couldn’t help myself. Also, come on reddit, be nicer. :)

GTM-wise, I’m also experimenting.

I used Claude Cowork to help me devise a plan. It generated a very cool interactive artifact that provides me with a to-do list, websites to visit, people to connect with and more. It recommended I spend more time on Bluesky (so I will!)

To-date, I’ve:

• Started posting on X and Bluesky

• Added Wordspine to a bunch of daily word game directories (one of them featured the game, which drove a lot of users!)

• Posted on LinkedIn

• Challenged a few friends randomly to see what they think

• Shared with 20-30 people I know

• Refreshed the user stats 100000x. 😏

I also used Claude Cowork to improve SEO/AEO. Discoverability matters. People do search for word games or “Wordle alternatives”. The site now has daily archives and word lists. We’ll see if any traffic comes from SEO/AEO in the future.

Stats are fun. Here are some that I’m tracking:

1. Where users come from. I’ve got Google Analytics and Search Console running too, but I find this gives me a quick sense of what’s working. A lot of users are flagged as “Unknown” because I implemented source tracking a few days after launching.

2. Viral loops / sharing. The game has a few sharing mechanics, where you can challenge others after winning a game. The people you challenge can play and brag back, or share with others.

Give Wordspine a try!

You can play Wordspine on desktop or mobile web.

You don’t need an account, play as a guest. Or sign up and track daily stats, earn badges and more.

I’m looking for feedback:

• Which version do you prefer: Sprint or Pro?

• Is the game too easy, too hard or just right?

• What other game mechanics or features would you be interested in?

• Is it fun enough to share with friends and family? (If yes, please do!)

• How could I market Wordspine more effectively?

• What else am I missing?

Thank you!

You’ve probably experienced this already. Someone feeds a pile of analysis into a model, writes a long prompt, and out comes 22 pages. The recipient opens it, sees 22 pages, and does one of two things: skims it and moves on, or drops it into their own AI and asks for a summary.

Machine generates. Machine consumes. Two humans exchange the illusion of work.

None of this is a new observation. Merriam-Webster made “slop” its word of the year for 2025 (sigh). But I’m living this on a regular basis now and starting to push back.

Subscribe now

If a document needs instructions, the document is broken

We recently wrapped a client engagement that required a series of strategic briefs. Deep topics, real analysis behind them.

AI loves this work. You feed it everything, write an extensive prompt, and it kicks into high gear. At first glance it looks fantastic.

Then you realize every single brief opened with a section called “How to read this document.”

I laughed the first time. By the third one I stopped laughing. If your document needs a manual, your document is broken. Nobody wrote a “how to read this” section when they had to type the whole thing themselves, because the cost of writing forced you to decide what mattered.

That cost is gone. So nothing gets cut, and the job of figuring out what matters lands on whoever opens the file.

People aren’t reading basic product instructions, let alone the manual

Here’s another example that I’m dealing with right now.

We’re piloting Candor, our synthetic user research platform. When a user builds an interview guide there’s an optional field called “Project Context.” The label says: “Add more context on anything specific you’re trying to learn from this interview.” There’s a one-line example sitting right in the field.

Multiple users have pasted hundreds of words in there. Persona behavior rules. Questions they want asked. Formatting requirements. In one case it read exactly like what you’d get if you asked ChatGPT, “I’m using a synthetic research platform and need to provide it with project context.”

They didn’t read the label, or the example sitting directly beneath it. They asked an AI what to put in a box, and pasted the answer.

Now, before I get too righteous: people never read. Jakob Nielsen measured this in 2008 across 45,000 page views and estimated users read about 20% of the text on a page. That’s not new.

What’s new is that the 80% they skip is now infinite, and they’ve got a machine to write their half of the exchange too.

Share

Provenance tells you which machine, not whether anyone thought

Anthropic just started marking Claude’s output: an invisible watermark in the text itself, plus C2PA provenance on files.

Directionally, fine. But read what a detected mark actually tells you. That the content “may have been processed by Claude.” That’s it.

So a 3,000-word report the model wrote from a one-line prompt carries the same mark as a paragraph I wrote myself and asked Claude to tighten. Those are not the same act. AI-generated is verbose and hard to wrangle into something good. AI-edited means I brought the thinking and the structure, and that’s closer to spell check than authorship.

Which is the problem with provenance as an answer. It tells you which machine touched the words. It can’t tell you whether a human did the thinking.

Honestly, at this point we should be watermarking the human stuff. It’s rarer.

The more you can make, the more people want you to

Once you can produce a strategy deck in four minutes, the expectation becomes that you produce more decks. Not better ones. More. Volume is the only thing anyone can measure at a glance.

That’s the Catch-22. The faster you generate stuff, the more you’re asked to generate, and the less time anyone has to read any of it. This is true of documents, code or anything else.

Researchers from BetterUp Labs and Stanford’s Social Media Lab call the result “workslop”: work that looks polished but has no substance, so the recipient does the thinking the sender skipped. 41% of workers say they’ve received it. Each instance costs about two hours to sort out.

Cory Doctorow puts it more bluntly. Sending someone unverified AI output, he writes, “is an attempt to coerce a stranger into unpaid labor on your behalf.” I love this line. Hysterical, annoying and depressing all at the same time.

Content producers are turning off their brains and asking recipients to keep their brains on. Why should they?

Subscribe now

When everything is AI-generated trust collapses and no one learns

So where does all of this end up? Here’s my experience, and I’m sure others are there too:

1. The more AI-generated content you read, the more you see the tells. Even when people try to hide them.

2. The more tells you see, the more jaded you get about anything you’re asked to read, review or look at.

3. The more jaded you get, the more you skim, or skip, or hand it to your AI for the summary.

4. The more you do that, the less you learn from any of it.

5. Then you ask follow up questions or challenge the sender, but they’re incapable of answering because they didn’t create the work in the first place. They ordered it. Now we have two people that aren’t learning.

In the end, you start assuming everything you’re sent is mediocre. You see a long document and think, “AI generated. Probably garbage.” You start assuming you and your AI could have produced the same thing in four minutes anyway. You might be right.

This is now a product design problem

If people won’t read a one-line field description, what do you think happens to your onboarding, your tooltips, your product tour, or your docs?

Pew tracked 900 US adults across 69,000 Google searches. When an AI summary appeared at the top, people clicked through to an actual source 8% of the time. When there was no summary, 15%. The summary roughly halved the number of people that clicked into anything to dig in further. And only 1% clicked a link inside the summary itself.

In the relatively short time we’ve had LLMs to engage with, we’re already seeing a re-trained expectation. People want answers immediately, with no exploration and no reading. Then they bring that expectation to your product, which is a tool they’ve never used, doing something they don’t yet understand. If they don’t get value out of your product quickly enough or decide they can just ask their own AI for the same thing, you’re cooked. Incidentally, this is why I think time to value is collapsing and churn is increasing for AI products.

AI makes building much easier, but doesn’t make it easier to build the right thing for the right market. AI building can’t keep up with changing expectations, where users and customers decide they don’t need to read anything, they have no time to learn and they just want everything done for them magically. AI is not magic. Software is not magic.

Back to Candor. We stopped asking how to explain inputs better. Better copy doesn’t help someone who isn’t reading anything. Instead, we’re building comprehensive quality checks on input fields. For synthetic user research the inputs are critical, you have a very real “garbage in → garbage out” situation. We’re already seeing challenges with this: someone designs a study with bad or mediocre inputs, they get so-so results and question the value of Candor. I know Candor works, it’s my job to help others use it properly.

We’ve also implemented Candor Bot, a chat interface that knows how Candor works, has built-in best practices, and can read the context of your inputs. I don’t know if people will use it (everyone has “app chat fatigue” while they chat endlessly with LLMs) but it’s an attempt to embed real-time help into the application.

Here’s what I’ve learned:

• UI/UX is changing quickly. At some point I suspect most software UIs will be replaced by MCP servers / APIs integrated into a person’s AI interface of choice. People barely want to log into different software products any more. But that’s a discussion for another time.

• LLMs have set an expectation of instant results. If your product takes a few minutes to do something or explain something, you might be in trouble.

• People are trusting LLM output a lot, in an effort to move faster and feel like progress is being made. They’re blindly copying & pasting things everywhere, whether it’s a report or into an input field in your software product, without stopping to think.

The reality is that you’re no longer designing for a user. You’re designing for a user plus their AI, and the AI is going to do more and more of the work.

Share

What I’m telling our team

AI is good! AI is bad! AI is… 🤬 🤨 😢

I’m not interested in raging against the machine. I want to wrangle the machine to do what I need and help others do the same. The more I produce and consume “workslop” and see how people interact with Candor, the more I’m encouraging the Highline Beta team to take certain actions.

1. Write it yourself first, then use AI to edit. Not the other way around. The quality isn’t close, and you can’t defend something you didn’t think through. The pull to go the other direction is enormous. Resist it.

2. Ownership matters. Whenever you send something to a client, prospect or anyone else, you are responsible for it. You own the thing you sent, whether you produced it or not. That ownership means you now stand behind what was produced and sent. Tough to do when AI wrote it all.

3. Define “done” before you generate. I do this when building software with Claude Code: three to five pass-or-fail checks written down before any work starts. Same for a document. If you can’t say what good looks like in advance, the model will happily hand you 22 pages of not-that. A smaller version of this: write out the sections of the document, why you need them, what they should contain and how you expect them to link together. Better prompting (to some extent) can wrangle AI to produce better quality.

4. Treat length as a cost you’re imposing on someone else. If your document needs a “how to read this” section, cut it in half. Then cut it again. Editing is critical, but not if your eyes glaze over and you’re going through the motions.

5. Be ready for follow-ups. We don’t send things to clients hoping they file them away and ignore them. We want them digging in, asking questions, challenging us and connecting dots. We have to be prepared for that. If we can’t do that, we’re not doing our jobs.

6. Design for people who won’t read. Content needs super clear summaries that are actionable. Software products need to assume people skip all instructions and just copy & paste AI generated stuff into them. Think about how our output can do more of the work and make it easier for recipients to digest, learn and action things quickly.

Outsourcing to AI is the wrong way to think about it

We talk about outsourcing work to AI as if we’ve handed responsibility to another person. We haven’t. AI can produce the output, but it can’t own the outcome.

Most of the code in Candor is written by AI. But I decide what gets built and why. I evaluate the work, test it, change direction and ship it. If Candor sucks, it’s not the AI’s fault. It’s mine.

The same applies to everything we produce at Highline Beta. Clients don’t care whether AI helped generate a report. They care whether it’s precise, useful and worth what they paid for. They care whether we can explain the thinking, answer their questions and help them decide what to do next. Six hundred slides nobody has time to consume isn’t value. It’s output masquerading as progress.

That’s the distinction we’re losing. AI makes it easy to produce something and mistake that act for finishing the work. But generating is only the beginning. The work isn’t done until you understand what was produced, know why it matters and can defend it.

Delegate production. Accelerate execution. Use AI aggressively. But don’t delegate judgment or responsibility.

AI naturally leans toward more output. Humans need to stay focused on better outcomes.

Produce less. Mean it. Be able to defend it. 💪

Companies are changing their pricing every six months. Buyers don’t know what they’ll pay, how to budget, or whether all the AI being stuffed into products is creating enough value to justify the cost.

What’s going on?

The market is moving away from traditional seat-based pricing toward usage- and outcome-based models. But we’re stuck in the messy transition: companies are changing their products and business models simultaneously, while customers are being asked to absorb unfamiliar, and often unpredictable, ways of paying.

I’ve been working to figure this out, because we’re launching Candor, a synthetic user research product we’re building at Highline Beta, and we need a business model. That means instrumenting the real costs, researching the market, building a model and putting it in front of potential customers.

Here’s what I’ve learned so far…

Subscribe now

Read more

For more on Brent, check out his Substack: Growth Recalibrated, a weekly diagnostic for founders, CEOs and product leaders navigating growth inflection points. You can also find him on LinkedIn.

I recently met with a B2B software founder about the challenges he’s facing. The company hit $12M ARR and he believed they had achieved initial Product-Market Fit (PMF) 18 months prior (e.g. net revenue growth of 120%+, shortening sales cycle, rapid growth among “look-a-like” ideal/target customers).

But over the past two quarters, something shifted. The roadmap debates that used to resolve in a single meeting now drag across three. His sales team is requesting features that serve customer profiles he didn’t used to close. When a new hire asks him to describe the ideal customer, he finds himself hedging in ways he didn’t before.

I asked him what he thought was happening, his answer was immediate: “It’s hard to tell if this is normal friction or something more structural.”

That ambiguity is usually the first signal. He doesn’t have an execution problem. His product-market fit is eroding.

Subscribe now

Product-Value Fit and Product-Market Fit Aren’t the Same

Ben has written extensively on Focused Chaos about what PMF actually requires: a product that creates genuine value, customers who pay in some meaningful form, and a repeatable way to acquire more of those customers at scale. That third element is the one most companies underweight. Product-Value fit (the sense that existing customers love what you’ve built) can look a lot like PMF. It isn’t the same thing.

Consider what the full picture looks like when everything is working. This company (offering a B2B infrastructure solution for location services for mobile applications) hit all the right signals: net revenue retention above 120%, sales cycles that collapsed because buyers already had budget and urgency, API usage climbing as existing customers scaled their own products. By any reasonable measure, the system was working.

Then net new customer acquisition stalled. Not because the product declined. Because the company had worked through the initial Ideal Customer Profile (ICP) of fast-growing apps that already needed location services. When that cohort was exhausted, sales cycles expanded again. It wasn’t the team’s fault; they now had to educate cold prospects rather than convert warm ones.

The underlying market also shifted. As Android and iOS embedded basic location capabilities natively, the addressable market for a premium/custom API quietly narrowed. Product-Value fit was intact. The distribution engine needed to reach and acquire new customers at scale had never fully developed.

This is only one pattern. Market exhaustion and platform shifts are real causes of growth stalls, but so are ICP drift, channel saturation, pricing compression, and competitive entry. What the diagnostics below are designed to catch isn’t any specific cause…it’s the moment the system starts losing coherence.

Where PMF Erosion Shows Up First

PMF erosion doesn’t announce itself in revenue or retention. By the time it appears there, it’s been compounding for quarters. The earlier signals show up across three dimensions.

1. Ideal Customer Profile (ICP) drift. As I’ve written about, ICP expansion at this stage is rarely a strategic move. When the original segment starts producing less reliably, the instinct is to cast wider. Sales closes deals with profiles that are “close enough.” Marketing broadens the message to stay relevant. Each individual decision has logic behind it. Together, they represent the original fit quietly giving way to a more diffuse version of the customer the company was built for.

2. Product signal decay. This one is less discussed and harder to see. When a company has genuine PMF, the product team receives a coherent signal from customers: the same pain points, the same use cases, the same feature requests clustering around a clear job to be done (JTBD). As fit erodes and the customer base diversifies, that coherence breaks down. Feature requests start arriving from multiple directions at once because different customer types now need meaningfully different things. The roadmap debates that once had a clear anchor (e.g. what does our core customer need?) start generating multiple legitimate answers. The product is still shipping. What’s decaying is the clarity of what to build and why.

3. Messaging drift. The value proposition that used to close deals gets softer at the edges. Not because the team is less prepared, but because no single explanation covers the range of customers’ needs the company is now selling to. The pitch broadens to stay relevant. Specificity gives way to optionality. Deals still close, but the team finds itself making slightly different arguments to slightly different buyers, with slightly different framings of what the product does. Each version is defensible. None of them is as sharp as the original.

Share

Why PMF Drift Looks Like an Execution Problem

These three signals compound quietly. By the time they show up visibly — longer sales cycles, softer conversion rates, board questions that are harder to answer with confidence — they read as execution problems. Leadership responds with execution solutions: more pipeline, tighter process, a new hire. Each response is reasonable. None of them addresses the underlying cause.

That’s what makes this stage expensive. As one marketplace founder put it to me directly: “If you’re only selling to promoters, your net promoter score is going to be really good.” The surface holds. The erosion happens underneath it. Companies operating in that ambiguity tend to address symptoms for several quarters before realizing and naming what’s actually happening.

The Diagnostic

Three questions cut through the noise faster than any metric.

1. Deal Assessment

Pull your last 20-25 closed deals. For each one, ask:

• Who actually bought it?

• What problem were they solving?

• What triggered the decision to purchase?

Then run the same exercise on the cohort you closed 9-18 months ago. If the buyer profile, problem, and trigger have shifted meaningfully - not dramatically, but meaningfully - the center of gravity has moved.

2. Internal Consistency

Ask your product, sales, and marketing leads separately to describe your best-fit customer today. If you get three substantially different answers, fit has already fragmented across the organization’s mental model, not just the pipeline.

3. Primary Acquisition Channels

Are conversion rates holding or declining? Is the cost to reach a qualified prospect rising? If existing customers are healthy and expanding while new customer acquisition is getting harder, the issue may not be ICP drift at all. It may be that the pool of ready buyers has narrowed and the company hasn’t built the distribution engine to reach beyond it.

None of these is definitive alone.

Together, they tell you whether the original fit is intact, where the erosion is coming from, and whether you’re dealing with:

• a customer-definition problem,

• a product-clarity problem,

• or a distribution problem.

That distinction determines what comes next.

What To Do When You Find Drift

The first and most important step is distinguishing between two very different situations, because they require different responses.

1. Accidental Drift

The ICP or product focus shifted without a deliberate decision to go there. If that’s what the diagnostic reveals, the path forward is to narrow back. Say no to edge cases. Recommit to the original customer profile. Tighten the product roadmap around the core JTBD.

This feels counterintuitive when growth is the goal, but it’s often what restores the coherence that makes growth repeatable. The companies that do this well treat narrowing as a strategic choice, not a retreat. They get more specific about who they serve, sharpen the value proposition around that customer, and let the clarity do the work that activity couldn’t.

2. Deliberate Recalibration

Where the original market is genuinely exhausted, has shifted structurally, or was never as large as it appeared. This is harder, and riskier. The companies that navigate it well make an explicit choice about the next customer: who they are, what job they’re hiring the product to do, and why this company is the right solution. The ones that struggle continue treating the new segment as a slightly adjusted version of the old one, which means the same erosion pattern repeats in a different direction.

In either case, the organizational move is the same: name it explicitly.

When the leadership team can’t agree on whether the drift is accidental or structural, the company will continue operating under different assumptions and every debate from roadmap to Go-To-Market (GTM) to hiring will be harder to resolve than it should be.

And what happened to the startup I referenced at the beginning of the post?

They chose the “deliberate recalibration” path. The core organization stayed focused on serving and expanding existing customers and contracts, while the original founding team was carved out to rapidly discover the next $50M product and market. Structurally, it was the right call. It still produced real tension between the two founders over authority, resourcing, and whose mandate now defined the company, but at least they made a decision and pushed towards it. Time will tell if it was the right one.

Thank you Brent for this great post and deep dive on PMF. People: please go check out Brent’s newsletter.

The short answer is, “yes.”

I’ll share how I use Lovable, Cowork, Claude Code and ChatGPT. But I’m not married to any of them. New or upgraded tools show up regularly, I test them, and I’ll switch when something’s better. The real answer to “which AI tool” is boring and true: use whichever ones you want, because the point is to learn.

I can’t hand you a tidy chart that maps every tool to every job. Those posts are silly and they rot within weeks, because the tools change too fast. You only figure out your own toolkit by building with it, not by reading comparison posts. This one included. (But please keep reading!)

One thing that did help me: stop thinking of these as competitors and start thinking about what each one is really good at removing from your path. Every tool kills a different bottleneck. Lovable kills the time it takes to get something working. Cowork kills the wall between thinking and doing. Claude Code kills the risk of shipping something broken (if used properly). There’s overlap between them, but once you see it this way, “which tool” stops being a loyalty question and starts being a “what’s in my way right now” question.

Here they are, easiest to hardest to learn.

Subscribe now

Lovable: get something real, fast

Lovable is the simplest on-ramp. You describe what you want, it wires up the database, uses built-in LLMs, handles deployment and after a few minutes you’re clicking around a real thing. When a newbie asks me how to start building with AI, I send them here. They’re always amazed (because it’s amazing!)

Don't file it under "toys." I built a complete corporate venture studio builder in two days with it (learn more here). Last year I started building a sophisticated fantasy RPG in it: AI-generated map, thousands of items, hundreds of skills & spells, complex combat rules and more. Lovable does sophisticated work.

The trade is that it makes most of the decisions for you. That’s why it’s fast, and why you learn less. You’re not choosing how the pieces fit. Perfect when your only job is getting something in front of a human.

My most complicated Lovable app is a D&D game

Last year when I first got into Lovable I decided to build a robust fantasy game. It still needs lots of work, but it’s been insanely fun to build.

Some of the cooler features (imo):

• Music that changes depending on the setting

• City builder back-end where you can custom-build specific locations

• Decision paths that allow you to do class specializations

• A complete pantheon setup (courtesy of my old MUDding days)

If you’re interested in trying this out, message me. 😊

Share

Cowork: where thinking and building blur

Cowork is where thinking and building stop being separate activities. I write in it, research in it, build decks and work through analysis in it. That’s the part people know. What surprised me is how much it also builds.

Recently I made a multi-page marketing site for a client (copy, calculators, and more) that started in Cowork. I used it to pull logos off the web, strip their backgrounds, and lay out the pages.

Another recent build: a complete clickable prototype of an enterprise e-commerce product. No database, no auth, just flat files and interactivity, exactly the scrappy prototype you’d otherwise reach for Lovable to do. I ran it through Cowork on purpose, to find the edges. It held up well.

The one thing I don’t do in Cowork is images. I’ve tried, and they’re meh, so I generate those in ChatGPT and drop them in. Different tool, better result, no loyalty required. That’s the whole philosophy in one small task.

ChatGPT for second opinions

Sometimes I get into debates with Claude and need a “second opinion”. So I ask ChatGPT. I find it helpful to get a different perspective, from a different model.

You can use one LLM for most of your work, and use a second LLM as a critic or counterbalance. I know the models are autocomplete machines, but it’s easy to get value from comparing and contrasting their output.

What makes Cowork different from Lovable is reach. It’s plugged into my desktop and Google Drive. It works where my actual files and workflows already live, which means it’s often less about “building an app” and more about killing the twenty context switches a real task usually takes.

Claude Code: correctness, and the real story

Claude Code is the steepest climb, and it can do the most. It’s where things go when I actually believe in them.

Early on it drove me nuts, because it loves to declare victory before the job's done. You ask for a feature, it grinds away, then announces "all set" like an over-eager junior who never checked their own work. Better prompts barely moved the needle.

What fixed it was forcing it to define “done” before it starts. Three to five specific, pass-or-fail checks, written down first. Then a separate agent grades the work against them, one at a time, citing evidence. No scoring out of ten (a “7” just starts an argument with yourself). Pass or fail. If something fails, it stops and tells me which check and why. It doesn’t get to judge its own homework.

It’s important to recognize that you need to put a lot of work into ensuring Claude Code does what you want. Roughly 20 to 30% of my Claude Code time isn’t spent building the product. It’s spent harnessing Claude Code: the commands, the reviewers, the hooks, the rules.

AI hasn't eliminated software engineering. It's moved it upstream. I spend less time writing code and more time designing how the AI writes code. The leverage isn't learning Claude Code. It's teaching Claude Code how you work. Your setup becomes the product.

I put my whole workflow and setup on GitHub and wrote it up here. Every rule in that setup is a scar. Your config ends up reading like a list of mistakes you’ve agreed never to repeat.

Claude Code is wired for more than Cowork. Custom commands, hooks, configuration you build yourself. I've got one that wraps every session, saves my notes, and refuses to quit until my work is safely stored. Claude Code requires that you do more work: connecting the LLM of your choice, setting up the database, deployment infrastructure, etc. That's the price of looking under the hood, and it's worth paying when the thing has to be real.

My most complicated project with Claude Code is Candor.

Candor is a synthetic user research platform. It allows you to create digital personas (with your own data + Web search) and interview them for problem discovery, problem validation, concept testing and price testing. You can interview the personas manually, or have the AI Interviewer Agent do it. Everything is summarized into a comprehensive, actionable report.

Wanna try it? We’re open to beta testers now. It’s great for researchers, product managers, marketers or corporate innovators looking to do more research on a regular basis.

Join our waitlist at https://www.runcandor.com.

Moving between tools

I still prototype quickly in Lovable. It’s the most convenient tool and plenty powerful. But just because you start in one tool doesn’t mean you can’t move to another.

In a few cases, here’s what I’ve done:

1. Start in Lovable.

2. Connect the Lovable project to GitHub.

3. Ask Claude Code to clone the GitHub repo and work with it.

That’s a seamless way to move from a quick prototype to production-grade software, if you want to jump between Lovable and Claude Code.

Here’s my “cheat sheet” (today)

I just spent this whole post telling you there’s no clean answer. And there isn’t. But I want to make this as actionable as possible, so here’s how I split it right now. Use what you can, then outgrow it.

I should point out I use other tools as well, including Claude (chat), Perplexity (web search & research) and a host of others for the software I’m building: Tavily, Sentry, Vercel, Apify, Supabase, GitHub, Resend, Cloudflare, Inngest and more.

The actual point

Six months from now, nobody will care whether you started in Lovable, Cowork, or Claude Code. IMO, they shouldn’t care now. They should care about whether you shipped something useful, and whether you got smarter building it.

The people making the fastest progress aren’t hunting for the perfect tool. They’ve used enough of them to know, in their gut, which one fits the job in front of them. Sometimes that means jumping between three tools in an afternoon. Sometimes it means staying in one for a month. The switching was never the point. The judgment is.

So stop reading comparison posts (yes, this one too) and go build something this week. Which tool should you use? Doesn’t matter. Anything else is procrastination dressed up as research.

What are you going to build?

And yet, when it actually starts happening to you, something strange kicks in. You go quiet. The investor updates slow down, then stop. You stop returning certain messages. You start spending a lot of time alone with your laptop, refreshing dashboards that aren’t going to save you, telling yourself you’ll deal with it once you’ve figured out the next move.

I’ve been there. It sucks. But you can’t hide.

This isn’t a post about how to shut down a company. I’ve written about when to shut down and I’ve picked apart my own failure in detail. This is about something narrower and harder. It’s about what you do with yourself, and with the people who backed you, when the thing you’ve poured years into is going sideways.

Subscribe now

Hiding feels safe. It isn’t.

When things go bad, the instinct is to retreat. Curl up. Go dark. Pretend it’s not happening until you’ve got it under control.

This instinct is exactly backwards, and there’s decent evidence for why.

Avoidance feels like relief in the moment. You dodge the hard conversation, you skip the update, and the anxiety drops for an afternoon. But psychologists who study avoidance coping have found the same thing over and over: ducking the thing you’re afraid of gives you short-term relief and makes the anxiety and depression worse over time. The relief trains you to keep avoiding. The problem keeps growing. (Here’s a decent overview of the research if you want to go deeper.)

Founders are especially exposed. Michael Freeman’s research on entrepreneurs found that mental health conditions touched 72% of the founders studied, with 49% reporting a personal history and 30% reporting depression. That’s far above the comparison group. We are not a population that should be white-knuckling a crisis alone in a dark office.

Read enough founder postmortems and you see the same trap described from the inside. Nancy Hua, who ran Apptimize, wrote that she spent years hiding her struggles from her own team: “This was not fun for me because it was lonely, but I didn’t know another way to operate.”

That’s the thing about hiding. It doesn’t just fail to protect you. It walls you off from the exact people who could help.

Your investors already know

If you raised money, you have a second obligation on top of looking after yourself: you have to be straight with the people who funded you.

There’s an old adage that as soon as the investor updates stop, everyone knows there’s a problem. It’s true. Silence is its own message, and it’s the worst one you can send. It reads as either “things are bad and I’m hiding it” or “I’ve checked out.” Neither builds the trust you’re going to need later.

Rand Fishkin put it well when he wrote candidly about Moz going sideways: “It’s a hard time to be transparent, but to me, that is the most important time to be so. If we shy away from transparency when things are rough, then it’s not really a core value, it’s just a marketing tactic.”

That applies to how you treat investors, your team, and yourself.

Founders need to remember: investors run portfolios. They expect most bets to fail. That’s the entire model. So when your company is the one that doesn’t make it, you are not the disaster you feel like you are. You’re a known, priced-in outcome. A good investor would much rather hear “I’m done, I can’t do this anymore” than watch you disappear.

You don’t owe them an apology. They took a bet. It didn’t work. That’s the job. What you owe them is the truth, on time, even when it’s bad. You took the money. Be responsible for it.

The upside of doing this well is real. When a founder handles failure with transparency, good investors remember. I’ve backed founders who failed and then went on to win, sometimes watching the same investors write cheques two and three times. It happens all the time. Good investors back people. People occasionally fail, but that doesn’t mean they won’t win the next time.

A big part of whether I’d back someone again is decided right at the end, when things are falling apart, by watching how they carry themselves through it.

The flip side: some investors will treat you like garbage on the way down. They’ll talk down to you, go cold, or worse. Those are bad investors, and there are plenty of them. It stinks, but it’s not a reason to start lying or hiding. Be forthcoming anyway. You’ll know you did it right, and the people worth keeping in your corner will notice.

Share

The day I learned investors care less than you think

Late 2009. Standout Jobs was failing. We’d let the employees go. I went to my investors expecting help devising a plan, some type of direction, and what I basically got was, “Do whatever you want.”

I don’t like how they approached it, but I get it. The returns weren’t going to be there, and it isn’t economically rational for a VC to pour time into a company that’s going to lose. They’d moved on.

I remember sitting alone in our empty office, lights off, feeling completely abandoned.

I was depressed. Abandoned, angry at everyone, caring way too much about what other people thought of me. I should have gotten help. I didn’t. I just gutted it out.

I decided not to go quietly. I reached out to a bunch of potential acquirers, aiming to recover whatever value was left. It worked, sort of. We sold Standout Jobs for cents on the dollar. Everyone still lost money and time. But I did what I felt I had to.

Don’t think of that as a playbook. When it’s over, it’s over, and a good investor should help you get to that ending cleanly. I’m not even sure the perseverance was healthy. Part of it was me proving to myself, and I suppose to my investors, that I wasn’t quitting.

I pulled through and moved on. But I’d have traded a lot of that grim solo determination for someone to lean on. I definitely could have used it.

What I’d actually tell you

1. If your startup is going sideways, don’t put your head in the sand. Deal with it, and deal with it fast, for your own sake. The avoidance feels protective. It isn’t. It just lets the problem and the dread compound while you pretend.

2. If you took other people’s money, respect that. Most investors are adults who know the business they’re in, and they lose most of the time. That’s not a license to lie, withhold the truth, or disengage. You took the money. Own it all the way to the end.

3. Get help from people who’ve been there. Other founders with real scar tissue. A therapist. Your family (although in my experience family doesn’t quite “get it”). Failing is isolating by design, and the founder population is already carrying more than its share of anxiety and depression. The Lago founders, writing about scrapping their first product, said the thing that helped most was simply talking to friends a little further along the road: “It was good and refreshing to talk to them.” Don’t go dark. You’ll suffocate in there.

4. Don’t pin your worth to one outcome. Success isn’t all the founder’s doing. Luck plays an enormous role, and timing, market conditions, plus a hundred things outside your control. Failure usually isn’t all the founder’s fault either. Mistakes get made. That’s how this works. A startup dying isn’t necessarily a verdict on the person, unless you ignore it and shut everyone out (include those that supported you), then (as an investor) it starts to feel that way.

5. Everything has an opportunity cost. You are not immortal and Father Time is undefeated. Wasting time is a huge mistake. You are better off admitting defeat, moving quickly through the shutdown and grief, and restarting something new. Maybe you start another company, or join a startup, or take a break. Whichever way you go, I bet you’ll be stronger for it. The lessons learned from failure are real (and often more powerful than the lessons from success), and most founders go through it. But dragging things out, surviving on life support, is not worth it.

Failing hurts. A lot. Spending years of your life, singularly focused, and losing anyway is brutal, and it’s worse when it’s other people’s money on the line because the responsibility sits heavy. I’m not trying to soften any of that. I’m telling you the opposite of what your gut is screaming at you to do.

Don’t hide in your shell. Face it. Tell people what’s happening. And move on (for the better).

We’re still not 100% there. I’m constantly iterating on my workflow and setup.

That’s one of the key lessons learned: expect to spend 20-30% of your time improving your workflow, not writing code for your product.

This work is critical. Without it you’ll be caught in a near-endless loop of prompt-response, prompt-response, prompt-response. At best, you’ll launch cool demos.

If you’re interested in what I’m building, check out Candor: a synthetic user research platform. We’re looking for a few design partners right now. I share more about it here.

This post isn’t for Claude Code vibe coding experts or actual software developers. I’m definitely still learning (a lot), and I’m far from an expert.

Subscribe now

Claude Code declares victory prematurely

The more I worked with Claude Code, the more I realized it was eager to declare things complete, even if they weren’t.

The gap between “the AI says it’s done” and “the thing actually does what I want” is the most frustrating part of building software with an AI agent.

When it works, it’s amazing and you can move faster than ever before. When it declares victory early, it feels like managing an over-eager junior who says “yep, all set” before checking their own work.

Initially, I tried fixing this the obvious way. Better prompts. More detail up front. Robust PRDs. “Make sure you do X and Y and don’t forget Z.” It helped a little. It did not solve the problem.

As fun and easy as it is to prompt Claude Code to do stuff and watch it (partially) work, I knew I needed more process and rigor to build quality software.

The fix: write the test before the work

The real problem was never the prompt. The problem was that nobody defined what “done” meant before the work started. So the AI got to decide, after the fact, whether it succeeded. And it almost always decides yes.

So I flipped the order.

Before Claude writes a single line of code on anything non-trivial, it has to write down what “done” looks like. Not vaguely. Three to five specific, pass-or-fail checks. It’s my task rubric.

If the task is “add rate limiting to our API,” the rubric might be: requests over the limit return the right error, the limit is configurable without a redeploy, internal traffic is exempt, the counter survives a restart, and nothing else in the app breaks. Each one is a yes or a no. No “kind of.” No “looks good.”

Here’s an example task rubric (not for the rate limiting feature):

Once I approve the rubric, Claude Code does the work.

Then a separate step (using a separate sub-agent) grades the result against that rubric, pass or fail, one criterion at a time, with the actual evidence cited. If everything passes, great. If anything fails, it stops. It does not quietly patch over the gap and call it done. It tells me which check failed and why, and we go back and re-plan that specific piece.

I built this as a command I run, called /assess. (In my own setup it's actually a "skill," a slightly more capable cousin of a command, but a plain command file does the same job and is the simplest way to start, so that's what I'll show you below.) The discipline matters more than the tool. You’re just refusing to let the AI be the judge of its own work against a standard it invented after the fact.

You don’t need to be a developer to write commands (or skills).

They’re not code. A Claude Code command is just a markdown file you drop in a folder (~/.claude/commands/), and you write it in plain English. The entire /assess command is about half a page. It says, roughly: read the .rubric.md file, run a diff to see exactly what changed, go through the rubric one item at a time and mark each pass or fail while citing the specific line of code as proof, and if everything passes say so and stop. If anything fails, name which check and why, and do not try to fix it. That's the whole thing. The power isn't in clever tooling. It's in forcing that one honest grading step to exist.

A few things I deliberately kept out:

• No scoring out of 10. A “7 out of 10” invites a debate with yourself about whether 7 is good enough. Pass or fail is honest.

• No letting the AI fix and re-grade itself in a loop. It reports, it stops, I decide. An agent grading and re-fixing itself against a fuzzy standard is how you get a confident mess.

• No inventing the rubric afterward. If you didn’t define “done” before you started, there’s nothing to grade against, and the whole point evaporates.

If you’re not technical, this matters even more. An engineer can read the code and determine whether it’s right. I often can’t. The rubric is how I get a real answer without being able to fully eyeball the work myself. It turns “trust me, it’s done” into “the proof is right here, one line at a time.” When something fails, the failure is specific and useful: not “this doesn’t feel finished,” but “the limit isn’t configurable yet, it’s hardcoded.” That’s a thing I can hand right back, in plain English, and get fixed.

Share

What this actually looks like, start to finish

Let me walk through a real feature, end to end. Say I want to add a CSV export to the persona list in Candor.

I don’t have to run every step by hand. A lot of this is wired into the project’s instructions so Claude Code does it on its own. But this is the full sequence, and the specific commands and skills involved.

1. I describe the feature in plain English. “Add a button to the persona list that exports the visible personas to a CSV.” That’s the whole prompt. In some cases I may write something more robust and include a spec doc or PRD.

2. It investigates before it builds. Because this isn’t a trivial change, Claude doesn’t start writing code. It produces an Investigation Report first: which files it read, what the change touches, who else calls the code it’s about to modify, and what tests already cover it. A small command I use here, /blast-radius, greps the actual importers, callers, and tests of a file or function, so the report is grounded in real output instead of a guess.

3. It writes the rubric. The last section of that report is the task rubric, saved to a file called .rubric.md. For this feature: the button appears only when there are personas to export, the CSV columns match what’s on screen, exporting respects the current filter, large lists don’t time out, and no existing list behavior changes. Five yes-or-no checks.

4. I approve the plan, then it writes the code. I read the plan, not the code. If the plan is wrong, we fix it before a line gets written, which is far cheaper than fixing it after.

5. It runs the build and the tests. Standard checks that the project compiles and nothing obvious broke. For changes that touch sensitive parts of the system, it also runs what we call a smoke test, a more expensive check against the real services. The instructions tell it which kinds of changes require that, so it doesn’t skip it and it doesn’t waste money running it when it isn’t needed.

   

6. It runs /assess. This grades the diff against .rubric.md. Say the “respects the current filter” check fails, because the export grabbed all personas, not the filtered ones. The /assess command catches it, says so, and stops. It does not commit. We re-plan that one piece, fix it, and re-run /assess. Now all five pass.

7. It runs /pre-commit. A broad gate that fires on every commit, built up over time. It scans for the security stuff you never want to ship (hardcoded secrets, a missing permission check), confirms the tests and types still pass, and runs a pile of project-specific checks I've taught it. For Candor that includes flagging when a code change has left one of our help articles out of date, and, when I've touched a marketing page, making sure the SEO basics (sitemap, structured data, an FAQ) are in place before it ships. This time it passes. When it doesn't, it hands me the list to fix first.

   

8. It commits and opens a pull request to our staging branch. Staging is our pre-production environment. The PR merges automatically once the automated checks pass, so I’m not babysitting it.

9. It deploys to staging and I actually click the button. This is the one step no automation replaces. I open the staging site, export a CSV, and confirm it does what I wanted. The rubric tells me the criteria were met. My own eyes tell me it feels right.

10. I run /session-end. First it checks I haven't left unfinished work lying around that the wrap-up could bury. It won't proceed until that's clean. Then it writes a structured entry to a running SESSION_NOTES file: what got done, what's still in progress, the decisions I made and why, and any open questions for next time. It scans that note for anything sensitive, commits and pushes it, and only then clears the temporary workspace the session used. It refuses to clear that workspace unless my work is provably saved on the server first, so wrapping up can never cost me work. The SESSION_NOTES file has become one of the most useful pieces of the whole setup. It lets me break big work across many sessions without losing the thread, and lets me (or Claude) remember what we did weeks ago without re-reading a pile of code. Next time I sit down, Claude reads the recent notes and picks up where we left off instead of starting cold.

Production is a separate, deliberate step. Staging is automatic. The promotion from staging to live is a human decision I make on purpose. The AI never ships to production on its own.

That’s the whole loop. Plan, build, grade, check, ship to staging, wrap up. The feature took one prompt and maybe fifteen minutes of my attention, and I trust it, because every step had a gate that wasn’t “the AI says so.”

Every so often, a deeper sweep

The loop above runs on every feature. There are a couple additional checks I run once in a while. These are deeper sweeps. (The video quality sucks, but the video is epic.)

The first is called /code-watch. It does a lot at once, which is exactly why it isn’t an every-commit thing.

It makes two passes over recent work. The first is a real security and bugs audit, the kind that hunts for the classic vulnerability patterns: injection, missing authorization, leaked data, that sort of thing. The second grades the code against my project’s own quality rules.

Two lenses, security and quality, in one run. It’s slower and more thorough than the per-commit checks, so I treat it as an occasional deep clean rather than a daily habit: after a stretch of riskier work, before a bigger merge, or just every once in a while to catch what slipped through.

The second is called /project-health.

Where /code-watch audits what I've built, /project-health audits how I've configured Claude Code: whether my CLAUDE.md files have quietly bloated, whether I'm missing an obvious command or guardrail, whether the docs still match the actual code. It's the same instinct, one level up. The tools that build the software need maintenance too, and left alone they drift.

Subscribe now

An instruction file that earns its space

A lot of what makes the loop run on autopilot lives in two CLAUDE.md files: one global and one for the project.

Claude Code reads both CLAUDE.md files at the start of every session. They are effectively briefing docs: how we work, what to never do, what the project is.

The global file holds the cross-project stuff: how I want the AI to behave in general, and the “define done before you start” habit that the rubric comes from. It loads no matter what I’m working on. Candor’s project file holds the machinery specific to that codebase: the maintenance protocol that forces an Investigation Report before edits, which changes require a smoke test, which sub-agents to use for reviews, how our branching and deploys work. The project file leans on the global one instead of repeating it.

The temptation with CLAUDE.md files is to stuff everything into them. The trap is that a bloated briefing makes the AI follow instructions worse, not better, because the important rules drown in the noise.

Keep it disciplined with one test for every line: does this shape how the AI thinks, or just tell it what to do?

The “how it thinks” stuff stays in CLAUDE.md and loads every session: behavioral principles, our security posture, the workflow loop. The “what it does” stuff gets moved out and referenced instead of inlined.

For example, Candor’s CLAUDE.md does not contain our architecture write-up, our data schemas, our database schema, or the distilled research that grounds how we model things. None of that is in the file. Instead, the project CLAUDE.md has a short “required reading” section that names those documents and says: before you implement anything in this area, go read these. Claude pulls them in only when it’s actually about to do relevant work, and ignores them the rest of the time.

Same idea for tactical detail like framework gotchas and our UI conventions. Those live in separate rule files that load only when Claude opens a matching type of file, so the front-end rules show up when it’s touching front-end code and stay out of the way when it isn’t.

This isn't something I rigged up. Claude Code supports it directly: a rule file with a short paths: line at the top loads only when you open a file that matches it. The "required reading" pointers work the same way, the documents sit in the repo and get pulled in on demand, not jammed into the briefing.

# CLAUDE.md  (loads every session — short and behavioral)

## How we work
- Before any non-trivial change, write a task rubric to .rubric.md, then run /assess.
- Match existing style. Touch only what the task requires.

## Required reading (pulled in on demand, not pasted in here)
Before working in an area, read the relevant doc first:
- Architecture:  docs/architecture.md
- Data schemas:  docs/data-schemas.md

# rules/frontend.md  (loads ONLY when you open a matching file)
---
paths:
  - "src/**/*.tsx"
---
- Every list needs a loading state and an empty state.
- Validate money as a finite number before storing it.

The result: the always-loaded briefing is short and behavioral, and the heavy detail is one pointer away, loaded on demand. For Candor, that cut the always-loaded instructions roughly in half with no loss of coverage. The deep knowledge is all still there. It just shows up exactly when it’s relevant.

The other thing I’ve learned: treat every rule like it was earned, because it was. Almost every good line in Candor’s CLAUDE.md is a scar from a specific time something broke. The AI truncated a long output once and corrupted a file. Now there’s a rule about output size. A change got shipped from a stale branch and created a mess. Now there’s a rule about how we cut branches. Your instruction file shouldn’t read like best practices from a blog. It should read like a list of mistakes you’ve agreed not to repeat.

Why I didn’t just install someone else’s setup

There are great pre-built workflows out there. Garry Tan, the president of Y Combinator, open-sourced his entire Claude Code setup as gstack, 23 opinionated tools that turn Claude into a virtual startup team. The rubric idea I use came from a framework called SPEAR. My thinking on lean instruction files was shaped by Yanli Liu’s article “The 4 Lines Every CLAUDE.md Needs” and the Andrej Karpathy thread behind it.

I could have just installed gstack and run with it. I didn’t. And I’d push you not to, either.

These aren’t bad. They’re genuinely good. The problem is that grabbing a pile of skills and commands you don’t understand is how you end up with a workflow you can’t debug, can’t tailor, and can’t trust. When something goes sideways, and it will, you’re stuck, because you never understood the system you’re running.

I took the core idea from SPEAR and deliberately modified it to fit my approach. Pass-or-fail instead of scoring out of 10 is my call, and I can defend it, because I worked through why. I read Yanli Liu’s article and fact-checked it against Anthropic’s actual documentation, and several of its specific claims didn’t hold up (it cited hard character limits that don’t exist). The direction was right. The details were wrong. I’d never have known that if I’d just copied it.

Don’t ignore what other people built. Engage with it instead of copying it. I point Claude Code at someone else’s setup, a public repo like gstack or a workflow described in a blog post, and ask it to compare that setup to mine. Where are they doing something I’m not? What gap does theirs expose in mine? Is there an idea worth adapting, and if so, how would it actually fit the way I work? Then we work through the changes together. I get the benefit of other people’s thinking without inheriting a black box, because every change that lands in my setup went through my understanding first.

Doing this work yourself is valuable precisely because you learn how things work. And if you’re a non-developer, that learning is critical. You’re not going to out-code a senior engineer. But you can architect a system good enough to ship real software, as long as you understand it.

Borrow ideas freely. Take other people’s frameworks apart to see how they tick. But build your own version, and understand every piece of it. The understanding is the asset, not the config file.

Where I actually work on the workflow

If I spend close to a third of my time improving the workflow, the fair question is where that work happens. Not in a project directory. That was a mistake I made early.

At first I tinkered with my setup inside whatever I was building. Bad idea. A project folder is for the product. The moment you start drafting half-finished workflow experiments in there, you clutter the project with things that have nothing to do with it, and the AI starts loading your unfinished ideas every session. That’s the exact noise problem the lean-file approach exists to avoid.

So I made a separate place for it. A dedicated folder, its own little repo, with no product code in it at all. Workflow ideas live there until they’re ready.

It runs like a lab. When I get an idea or read someone’s article, I ask Claude to evaluate how it compares to what I already do and whether it holds up. If it’s worth pursuing, I write down the exact change I’d make. Then I either adopt it, in which case it graduates into my real config, or I reject it and keep a short note on why, so I don’t reargue it in six months.

Two things come out of that. My live config only ever holds rules that actually work. And I have a written record of why every rule is there, which matters, because most of them are scars from something that went wrong.

The pieces, if you want them

I put my own setup, sanitized and templated, on GitHub: github.com/benyoskovitz/claude-code-workflow.

This is in no way the world’s greatest workflow, but it’s a start. 😄

It’s not my actual Candor config dumped out. It’s the reusable bones, with the project-specific parts marked for you to replace. A starter instruction file. The /assess rubric skill. The lean-instructions pattern. The session and cleanup commands. And a small “lab” structure for treating your own workflow as something you version and improve over time.

Don’t install it wholesale. That would contradict everything I just said. Read it, take the one or two ideas that fit how you work, and rebuild them yourself so you understand them.

Start this today

If you’d rather not touch my repo at all, don’t. You can stand up the core of this in about twenty minutes.

First, create the rubric command. Make a file at ~/.claude/commands/assess.md and paste in the plain-English instructions (see code block below): read the rubric, diff the change, grade each item pass or fail with evidence, stop and report on any failure, don’t self-fix. That file is your /assess. (Claude Code turns the filename into the command name, so assess.md becomes /assess automatically. No extra wiring.)

You are grading a code change against a task rubric. Do not write or fix any
code. You only read, grade, and report.

1. Read the file `.rubric.md` in the project root. It lists 3 to 5 checks, each
   a pass-or-fail criterion. If the file doesn't exist, say "No rubric found"
   and stop.

2. Run `git diff HEAD` and `git diff --staged` to see everything that changed.

3. Go through the rubric one check at a time. For each, decide PASS or FAIL and
   cite the evidence: the specific file and line that satisfies it, or the exact
   thing that's missing. No "probably fine." If you can't point to proof, it's a
   FAIL.

4. If every check passes, say "PASS, ready to commit" and stop.

5. If any check fails, list which ones and why, in plain language. Do not try to
   fix them. Do not commit. Stop so I can decide what to do next.

Be honest, not generous. The whole point is to catch the thing that isn't
actually done.

You could create this as a more robust skill if you want, which is how I’ve got it setup in the Github repo.

Second, add one line to your CLAUDE.md. Something like: “Before any non-trivial change, write 3 to 5 pass-or-fail checks to a file called .rubric.md, and don’t treat the work as done until /assess grades them all green.” That single rule changes how every task runs.

Third, start a workflow notes file. A plain text file, anywhere outside your project, where you jot the ideas you want to try and what happened when you tried them. That’s the seed of the lab.

The rubric and /assess command together are a powerful combination. Make your AI define “done” before it starts, and grade the result (through separate sub-agents) against that and nothing else. That single habit fixed more of my frustration than anything else I’ve tried.

The people getting the most out of these tools aren’t the best prompters. They’re the ones who treat the workflow around the tool as the actual work, and keep sharpening it.

What rules have you put in your own setup? How are you wrangling Claude Code to be better?

Candor is a synthetic user research platform built by Highline Beta.

You can join the waitlist today.

Why did we build Candor? A few reasons:

1. We do a lot of research. Building things is easy. The hard work is the early validation (and then the go-to-market). Candor is helping us do in-depth research quickly. It’s not replacing human interviews. It’s a strong compliment.

2. We’re all-in on AI. I’ve shared a few posts about my experience building with AI and how to create value with AI features. If you’re not neck-deep in it, you’ll be left behind. Simple as that. I don’t want to be left behind. 😄

3. We’re experimenting with GTM and new business models. AI is fundamentally changing a lot of things. Go-to-market (GTM) is one of them. How do you acquire users? How do you build a brand? How do you automate things intelligently without it feeling like AI-slop? From a business model perspective, we see the rapid shift in pricing and how software companies have to adapt. It’s a world we’re building and investing in, so what better way to figure it out than to do it ourselves.

I want to explain a bit more about how Candor works, then share some interesting things we’ve done and a few lessons learned.

Subscribe now

How Candor Works

Candor is a synthetic user research tool. You create personas and interview them, either manually or automatically. Everything is rooted in our expertise and scientific rigor.

1. Generate an audience

First you generate an audience. Audiences can be B2B or B2C (there are meaningful differences between how these are handled). You fill in some basic information, and can upload documents.

The system does deep Web research and uses your inputs to generate several archetypes/segments. Here’s an example:

Every pain point, behavior, goal, attitude, belief, preference, etc. is grounded in evidence from your documents and/or Web search.

The goal is to build personas from a very in-depth, fundamentally grounded base.

2. Generate personas

Next you generate personas. These are the actual “people” you interview.

Persona generation is equally in-depth and validated. Everything that’s generated is reviewed by a critic. You can double click into the details, or jump into interviews.

Each persona has a ton of detail. We spent a lot of time on this part, ensuring that the personas are robust. This goes well beyond what you get from simulating conversations in ChatGPT or Claude.

Share

3. Create an Interview Guide

Once you have personas, you create an interview guide. There are four basic types: Problem discovery, Problem validation, Concept testing & Price testing.

Each requires different inputs and generates different learning goals. From there, Candor creates an interview guide and allows you to automatically interview the personas. Or you can manually interview personas and chat with them as you see fit.

4. Synthesis

Once interviews are complete, the system runs a detailed analysis and generates a synthesis report. The report highlights everything you need to know (at a glance or in depth) to move forward.

I know that was a lot to go through, but I wanted to highlight Candor’s ease of use, along with the underlying sophistication.

Next Steps

We’re putting Candor through its paces and will open it up to early testers soon.

• If you’re interested, sign up on the waitlist.

• You can also follow Candor on LinkedIn.

Our goal is to launch within a month or so. There’s a lot of work to do on refining the product and experience. We also have to implement a business model.

Beyond Candor’s Core Product Features

Building a production-grade product involves more than its features. I want to share a bit more about those experiences.

Candor’s Website

Not surprisingly, Candor’s site is designed by and mostly written by AI.

I’m not in love with the site’s design, but I did use VoltAgent’s awesome-design-md to kickstart the process. It helped me identify similar brands to take inspiration from. I now have a couple design-related Claude Skills for future projects too.

For content, I used my own SEO/AEO experience and fed Claude Code with best practices, so it could structure the site and create key anchor pages. Some examples include Use Cases, Comparison, FAQ and Glossary.

I then used Kyle Poyar’s Claude Skills to refine the copy. I found /icp-sharpener was quite helpful. I combined the output from ICP sharpening with domain expertise from Anthony Pierri to rewrite the copy.

One last thing: The screenshots on the website are AI generated. They’re accurate images, but composites of a few features. Claude Code and I decided which images would resonate, and then it built them for me. This took a bit of work, but it was still easier than taking screenshots of the product and having to mash everything together in Figma or another tool.

Candor’s Help Files

Candor already has a bunch of help files (although this isn’t complete). They’re generated by AI; reviewed by me.

Claude Code went through the code base to structure the help files intelligently and write them.

The coolest thing is that help files get automatically updated when the product changes. This is done through a Claude Skill I created called /pre-commit, which I run before committing code.

The pre-commit skill does a few things, including running standard tests, verifying security issues and checking to see if help files need updating. It will tell me which help files need changing, write the changes, and give me an opportunity to review. As a result, help files should never be outdated and the site’s content gets frequent updates.

This is a great example of how AI can speed up the development process, including “around the edges” where things are often forgotten. Integrating help file management into the AI coding process is an easy win.

The Admin System

Every software product has an admin system for managing users, updating settings, tracking performance, etc. Historically this has been a pain in the ass to build: it can take a lot of time and it doesn’t provide users/customers with value. But without it, you can’t manage things properly.

Using Claude Code, I built a robust admin system very quickly.

I asked Claude Code to identify SOC2 compliance requirements, so we could build the necessary infrastructure. Candor isn’t SOC2 compliant yet, but the underpinnings are there. For example, it has a robust audit log of everything that’s done. It also tracks what admin users are accessing. This is “boring stuff” but super important.

• Candor’s admin system has full account and user control.

• Multi-factor authentication is built in (required by admins, configurable for regular users)

• Email templates are fully customizable

• Failures are monitored and reported in real-time

• And more…

One of the more interesting aspects of the admin system is the cost management part:

Almost every action in Candor costs money, because it’s heavily reliant on LLMs. In the last 30 days I’ve spent $499.75 testing!

Cost tracking is a huge part of building a successful AI product. You have to know what costs money, how much, how frequently those features are used and by whom.

Your power users could bankrupt you.

I wrote about AI business model shifts here: Lean Analytics, Reconsidered.

Candor’s cost management system tracks every action and its cost. It slices the data by user, project and feature. I know what it costs to generate interviews, run reports, create audiences, etc.

This should help me create a reasonable business model to cover my costs, provide customers with maximum flexibility (I don’t want to restrict usage significantly) and maintain a margin.

I’m not focused on optimizing LLM costs yet. Claude Code did occasionally recommend using cheaper models for certain tasks, so there’s some cost optimization built in. But more can be done.

Subscribe now

Lessons Learned Building Candor

Candor is the first production-grade AI product we’ve built at Highline Beta (for ourselves). It’s teaching us a lot.

1. PRDs & feature building can get out of control

The more you feed an AI code assistant tool (like Claude Code) the more it’ll do. But it’s also easy to get overwhelmed. I would never recommend that you build a “massive, feature-rich product” in one sitting. It’s better to eat the proverbial elephant one bite at a time. But it’s so alluring to write a gigantic PRD, try to think of every detail, feed it into Claude Code and watch the magic happen.

Thankfully, Claude Code will chunks the work, but it’s still up to you to deploy and test things piece by piece, review what’s going on, and encourage / force Claude Code to iterate. Otherwise…it’ll just keep building.

Vibe stuffing is a legitimate risk.

Candor already does a lot. After showing it to a couple people, guess what they said? “Very cool, but you could also do X and Y and Z…”

AI + vibe coding is encouraging everyone to build more. But more doesn’t always equal value creation. When building was hard, we had to be a lot more disciplined about what we built. Today that’s out the window unless you’re really pragmatic and careful.

Lessons learned:

• Don’t over plan. Focus on designing the minimum first, testing it, sharing it with others, and then adding new things.

• Don’t over build. Launch early and often. It’s why we’re releasing Candor now; otherwise we could spend the whole time building.

2. Invest meaningful time in building better systems

When you want to build production-grade, scalable software, you need the right infrastructure to do so.

I use the term “infrastructure” loosely, but some things to consider:

• Code quality: Claude Code (and others) are great at software development, but they make mistakes. I’ve gotten into heated discussions with Claude Code about drift or being lazy. You need systems to vet code quality, so you can hold your AI code assistant accountable.

• Performance: One person testing the product is a lot different from 5 people using it simultaneously, or 20, or 200, or 2000. You need to engage with your AI code assistant about performance, otherwise it won’t get prioritized. I’ve had multiple discussions with Claude Code about what we’ll need to do as users onboard, although to be honest, I don’t know what will happen.

• Tests: Every software developer will tell you that tests are important. But if you’re not a developer, you won’t know what kind or how to build them properly. Code quality tests are usually pretty basic and not enough to catch actual bugs. Candor has a variety of smoke tests that run, which simulate workflows, but even that’s not enough.

• Staging vs. Production: Many people will vibe code and push changes to their live system on the fly. I’ve done it, but it’s risky. For Candor, I implemented a staging environment. If you’ve never worked as a developer it’s not something you might think about. But managing dev, staging and production is important to minimizing risk.

Lessons Learned:

• The key is that you need the right systems to do the job. Vibe coding can be completely ad-hoc or very structured. The more serious you get, the more serious your infrastructure needs to be.

• I spend a meaningful percentage of my time on these issues. Probably 25-30%. I’ve spent entire “sprints” (1-2 weeks of time) on hardening the infrastructure, so that Claude Code is better/smarter, my hosting is more robust and error logging is in place.

3. Build and learn at the same time

You do not need to be a software developer to vibe code a quality product.

You do need to be willing to learn best practices.

You do need to pay attention to what your AI coding tool is doing so you’re not simply agreeing to everything blindly.

If you don’t learn along the way, you won’t get better. If you don’t get better, you can’t guide your AI coding tool to be better.

Lessons learned:

• Read (most of) what your AI coding tool spits out. Ask it questions. Challenge it. I often ask Claude Code to explain things in plain English, because it’s getting too technical for me.

• Focus on pattern matching. You need to build up your instincts around how to do things, so you can implement the right systems. Instincts = patterns.

• Don’t vibe code tired. It leads to laziness, which increases the odds of mistakes or failures.

• Don’t leave sessions unattended for too long. When you return to a session a couple days after starting it, I can almost guarantee you won’t remember what was going on. You were letting Claude Code run wild and now you don’t know how to pick things back up. You’re better off doing smaller, discrete sessions, ending them and moving on.

• Learn how to use the tools. AI coding tools are insanely powerful. You need to learn how to use them, shape them and build systems for yourself and the tools to do what you want. Don’t just install Claude Skills blindly. Ask Claude Code to tell you what they do, why you might need them, how you could use them. Do your research. Spend a meaningful portion of your time learning, not coding.

We’re going to continue developing Candor and sharing our experience.

If you do any form of user research, please check it out and join our waitlist!

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

Read more

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

Read more

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. 💪