In short, companies start simple, then, ‘evolve.

Astonishing how relevant this is today, if not more so. AI makes it far too easy to do too much stuff.

See all Des Traynor’s talks at BoS Conference here.

Transcript

Thank you. It’s just as scary being up here as it looks. So my thesis on product strategy, which I’m going to deliver in the next seven minutes and 30 seconds, is that it’s mostly around saying no. Version one of a product is actually the easy bit because when you’ve got nothing else going on, you can literally do what you want, and it’s usually easy to start good. The hard part is staying, staying, keeping your product really good, and also having to say no to all of these new forces that come along, presuming you have actually built something worthwhile. So, if you’ve never seen traction before, this is what traction looks like. It’s pretty awesome, and it brings with it a few friends. Your vision tends to expand for your product as you realise you have a business, and then you start to get competitors. That’s the best bit, and then you also start to get other things like you know maybe you raise some money and that gives you a few board seats, and now you’ve got other people who are interested in your product, and you grow a team. And usually, last to the party are the tech industry, who will come along and start writing about what you should do. And all of these things aren’t inherently a problem. What happens is you get, as we say in San Francisco, like things we should like totally build. And V1 is easy because it’s just what the founders want to build. But then you start looking at what the competitors have now, and now you’ve got what are our customers asking for, or what are our boards or advisors or mentors or whatever asking for, and then what does our actual product team want to build because they have ideas too, and we shouldn’t ignore them, and then what does the press say that we’re going to build next, and then also what do foresters think they’re always good for a laugh, and then what do our biggest customers want to pay us more for? And if you actually go with all that, you build this, the file matrix. Like the file matrix is actually a glib example. What you actually end up with is something more like this, right? Like which is like the ultimate toolbox for all your needs. Is Ben? That’s how you end up marketing it as well. What this here is a collection of tangentially barely useful things smashed together, and products end up there if you don’t say no to things. If I pull this out in the middle of a knife fight, you’d laugh at me, right? So it’s not a good knife, it’s not a good saw, it’s not a good anything. But you know that’s what happens when you basically trade off. Gall’s law tells us that you can’t design complexity. Everyone starts off beautiful and simple, and then evolves to complexity. And you even see this happen. Here’s early Windows Media Player. They had it right: a play, pause, and stop. Then they’re like, “Let’s manage your media, and they just went for it. And like, you see this happen over and over again. Like, here’s Outlook. Back in the day, I mean, I think I was like 17 or something. Like, this was beautiful. Now Outlook’s getting like this. And just as a frame of reference, here’s Dance, Dance Revolution, right? And. So there have to be 1000. This is Apple’s that words. There are 1000 noes for every yes, and that’s roughly the right ratio. You’ll be inundated with reasons why you should build things and why this is a great idea. But unless you’re willing to stare good ideas in the face and say that’s a brilliant idea, thanks for bringing that to me, but we’re not building it. Unless you can do that, you’re going to end up with like dance, dance revolution. Apple claimed they throw away better products than most people launch, and they’re probably right, but it’s an easy claim to make, right? They never have to actually back it up or anything. But like, you’ll get so many reasons why you should build it. But Dez, look, this feature is going to increase our engagements off the charts, and I say, yeah, well, will it increase their engagement, or does it just move engagement around?

Because most of the time, when you roll out a new feature, it just people stop doing something else, and now they’re doing this instead, and then you’ve just split your your engagement. You haven’t actually increased anything new. But a second question for that is, is all engagement actually good? Like, we could put like Tetris into our web product, and now people are in it every day, all the time. So we’re like funding, but like that’s how it works. Or but Des, it’s a small feature, and we’ve all told ourselves this lie at some point. Of course, it’s a small feature. Look, it’s tiny, and then at some point you’re like boom, because it’s like oh shit, we have to update the docs, the Android app, the iPhone app, the API, the product app, all these sort of things would tell everyone on the team. But even if it was a small body of work, that’s no reason to do it. Scope isn’t a reason. I could go out and rob a bank right now. It’d be a pretty small amount of work. But like, imagine I turn around to my CEO and be like, “Hey, look, I robbed the bank, but it was pretty quick, you know. Or another class that goes like blackmail from your customers. I’m going to leave unless you build this product. And you’re like, “Okay, you have to be willing to say, okay, off you go. Or another one is like, everyone’s asking for it. Okay, sure. This is what I call the frequency bias. And by the way, you’re all suffering from this right now. You think everyone’s asking for something because you hear it a few times at this conference, and it’s like frequency. It’s you hear it frequently and recently, and now you think it’s a must-have. A dude was talking to live chat today, and I was literally on my phone saying, “Guys, we need to build. Stop. We don’t need to build live chat. You know, it’s just it happens to all of us. It’s just totally natural. But there’s we can make it an option. Not everyone has to use it. Yeah, boom. Here’s our options. We’ve got seven pages options of every type of thing. Now everything gets inherently the obvious cost with this. You have to build all this junk, and then you have to try and get people to use it, and it confuses the hell out of customers. But if you recall, what Bob and Chris were talking. Yesterday, like one of the best strengths they they bring is like that they take junk out of a product just so people can use it, and that’s literally if you go down the whole oh we’ll make it a feature you’re walking right into that path you can’t market a product that’s so big, but Dez, we’ve nothing else to do at the moment, and this is the idea here. You’ve got the team here, and we just don’t know what’s coming next, and I’m like, I don’t care. We’re not building junk. If you’ve got time to lean, you’ve got time to clean, right? This is when you fix bugs, make your product faster, reliable things people actually care about. You know, like as I said earlier, like the the devil runs UX workshops for idle hands, and he comes up with bad features. You know. Ah, but Dez, Dez, Des, Des, all our competitors have this, so we have to do it, right? And I see this all the time with the startups I work with. Like, the competitors have projections, distributions, revenue, metrics, alerts, and all sort of stuff. And they look at that. Like, someone looks at it, like, we have to build it all. But meanwhile, the competitors are looking at their feature and going, “No one uses this. This one’s broken. This one never made sense. This was. We just did this one to keep that dude happy, but we shouldn’t have. So while you’re busy copying all their junk, they’re busy trying to work out a way to get rid of it. You’re delivering yesterday’s broken technology tomorrow, or like, like, yeah, like it’s like that Wayne Gretzky quote: “We’re skating to the pub with never going, you know. So good questions to ask before you say yes is: Does this fit the vision? Is it a forward step along the way?

Like we could integrate with facts in Intercom, but wouldn’t be a forward step? Will it matter in five years? Will it generate actual new engagement, not just you know like push a bit around? Can we grow the business because of it? So if this succeeds, do we actually get anything from it? Can we design it such that for people who use it, reward is actually better than effort. Does it benefit all the customers? And if it succeeds, can we even support it? Like, so we could just build an Android app, but we don’t have Android people. So how do we support it? So product strategy one on one for me is this: all of the people, all of the time. None of the people, none of the time. Plot out your features on a map like this. It takes very little time, a couple SQL queries, and you’re done. An easier way to do it again is what percentage of our customers are using these features. In this case, we can see this is like a typical project management type app. Chat room and calendar, no one’s using them, so we have to look at ways to either get people using them or get rid. It’s like fish or cut bait. This is how you maintain product market fit. So when you’re actually when you have time to lean and you don’t know what new features you’re betting, work on increasing the frequency of who’s using how often people are using it, or who’s adopting it, how many people are using the feature. That’s how you’ll actually pave your way towards a great product. That’s pretty much everything I know about product strategy. I’m sorry to say, but I hope you found it some way useful. So that’s everything. Thanks very much.

I joined BoS at exactly the wrong moment, which turned out to be the right one for understanding this particular problem.

Jann was on maternity leave. Mark was buried in conference prep. The person who had my role before me had one week left.

No drive with everything sorted in it. No map of how any of it worked.

Great timing all round.

The systems existed. They were just shaped like the people who’d built them, and none of those people had time to translate. The first thing I actually wrote down was our passwords, which tells you roughly how far from a shared source of truth we were starting.

So when a founder further along in the workshops described the same problem from the other side, I recognised it immediately.

What Robert would pay more money for

Robert Fryers named it plainly, four weeks into the programme, on his way out of the final session: “the bridge between a consistent source of truth for multiple people and rolling this out to the team” was the bit he’d pay more for.

It’s a bigger ask than it sounds, and it’s the same problem I was on the receiving end of, from the other direction.

Shared tools don’t fix shared vocabulary

The first problem is never the infrastructure. It’s that two people can work on the same goal for months, using different words for the same thing, and never notice the overlap until somebody makes them say it out loud. A shared drive doesn’t catch that. It just makes the mismatch easier to automate.

Tim Barker built his own version of this the hard way, a single-machine, always-on backlog system, built specifically because coordination across people and devices was the actual bottleneck, not the work itself. “I managed to get to a point where I’m burning credits all the time because I’m continuously adding to the backlog,” he said of it. The discipline of shared structure was what made the output possible.

Jann, who runs operations here, saw the same thing from inside BoS. Turning a conference talk into publishable material used to take days. Once the workflow itself was agreed, not just assumed, that changed. In her words: “I can even do like 10 transcripts in one day with all of those outputs.”

Agree on the map before you build the road

Agree what you’re automating and why, in words everyone in the room uses the same way. Then pick the infrastructure that supports it, not the other way round.

If you’ve built something that works beautifully for you and you’re now staring at the team rollout, you didn’t do it wrong. This is just the next problem, and it comes for everyone.

What helped on my side wasn’t a folder. It was somebody sitting down and answering my questions out loud until the answers existed somewhere other than their own head.

The BoS OS Workshop is built for this stage. Two 120-minute sessions, 12 people max, for turning a system that works for you into one that works for the team.

My first reaction to AI agents wasn’t excitement. It was the specific fear of watching something capable make a decision I hadn’t approved.

That fear turned out to be the useful part. Left to itself, an AI will happily pull you down a rabbit hole for four hours and act like that was a sensible use of your afternoon. One of the first rules I wrote into my own setup was a hard stop once I’ve hit my limit for the day.

Sitting in the BoS OS workshops, I found out that instinct scales.

Most people here aren’t sceptics

That surprises people who haven’t sat in the room. The founders who show up have usually already watched an agent do something clever and slightly alarming on its own, and it unsettled them a little. Powerful and pointed at something that matters is exactly the combination that makes people hesitate.

The question isn’t whether to use AI. It’s where, specifically, it’s allowed to act on its own, and where it has to stop and ask a human. That’s a governance question, and it’s the one most AI tooling skips.

The $2,000 lesson

Tim Barker has the story that makes it real, one he tells from the stage. Early on at his own company, he asked an agent with browser access to stub out some LinkedIn ad campaigns. Placeholders, he’d tidy them up and launch properly later.

He never told it that it wasn’t allowed to spend money.

So it built the campaigns, switched them on, and ran $2,000 of traffic to a staging website. He noticed three weeks later.

There was no bug. The agent did exactly what it was asked. There was just no constraint.

His frame for it comes from security, and it’s the right one: “The idea of zero trust security still applies in AI.”

Agents do the work, humans approve it

At BoS that’s a hard rule rather than a nice sentiment. Every agent output is a proposal, not a decision. Nothing goes out, nothing gets written, until a human has actually signed off on it.

Move at the speed of trust

A demo convinces you the technology works. It doesn’t convince you it’s safe to point at your business, and only one of those two things decides whether you ever use it.

Tim’s phrase for the way through is that you “move at the speed of trust.” You review, you feed back, it gets better, you review less often, and eventually you hand the loop over. That progression only exists if you built the checkpoint in the first place.

If the idea of an agent running loose inside your business has ever made you close the laptop, that instinct was right. What fixes it is a system that knows where to stop, which is a different thing from using less of it.

Introduction to BoS OS is two 120-minute sessions if you haven’t started yet. If you’ve already got a first draft running, the BoS OS Workshop is where the edges get properly drawn.

Most onboarding starts with the business, not the person running it. This starts with the person. It is called founder-alignment, and it runs before we build anything else in BoS OS.

It asks five things. What your company does. What your personal goal is, exit, longevity, independence, something else, no wrong answer. The one number you watch that tells you the business is heading the right way. Who your key people are, what they are responsible for, and whether they know your personal goal at all. And what you are thinking hardest about right now next to the last emergency you had to deal with.

That last pair is where most of the signal is. A founder will name a long term worry and a recent fire that point in completely different directions, and not notice until they say both out loud in the same breath.

The conversation ends with a brief, not a verdict: company, personal goal, north star metric, team map, whether the team is aligned on that goal, and where the answers pull together or apart. Then it hands straight into building the rest of the OS, research already pointed at the tension the founder just confirmed. No repeating yourself, no generic questions, no starting from a blank page.

You can run it yourself: the founder-alignment skill is free, in Quick Questions.

Skip this step and you can still build an operating system. It will just be well organised around the wrong thing. An OS built on misalignment does not fix misalignment, it just executes it faster.

If this surfaced something worth a reply, not just a quick reaction, send it to mark+bosos@businessofsoftware.org. Mark reads these.

Founders often believe their shiny new product needs an entirely new market category to positioned effectively. Over the years, you can almost guarantee at least one audience question at any talk April gives will touch on this. It can be a sign that you haven’t understood the value of your product. April, will generally push back strongly if a founder feels this is their only route to market.

True category creation is incredibly rare, risky, and expensive. It’s unlikely to be worth the risk.

What about HubSpot’s ‘Inbound Marketing’ someone will ask? They created a new category. It’s not the ‘gotcha!’ moment the questioner thinks it is…

April Dunford’s take. Hubspot identified a new category, it did not invent it.

Market Shifts Caused the Category, Not the Company
April doesn’t think HubSpot single-handedly engineer the inbound marketing movement from scratch. External, macro-technological and cultural shifts were moving the market: buyers were experiencing severe spam fatigue, ad-blockers were rising, and Google’s algorithm began heavily rewarding high-quality content.

Naming vs. Creating
HubSpot’s genius wasn’t creating the trend, but spotting it early and giving it a snappy name – ‘Inbound Marketing’ Then they built a movement and an education machine around it.

The ‘Old Way’ vs. ‘New Way’ Story:
HubSpot then shifted how customers evaluated software. They’re not positioning themselves as a better tool in a crowded marketing automation space, competing with giants like Marketo. They framed traditional outbound marketing as obsolete. Buyers had a very clear understanding of why they needed a better solution than the one they currently had

Result, Hubspot were the clear market leader in a category that became an industry standard.

April Dunford’s Advice on Creating a Category

Ideally, don’t. It’s probably a last resort option. Consider these options first.

Understand your value first
Know your product’s differentiated value and best-fit customers before you do anything. If you were creating a new category. This is fundamental. Understanding this will often point you towards better solutions.

Avoid more work
Remember that inventing a brand-new category means you have to educate the market on solution, problem, and solution. This is resource-intensive.

Identifying market-segments
Consider existing or adjacent market categories where your resources can be focused on dominating a specific niche before expanding.

If a New Category is Necessary

(99.99% of the time it won’t be).

Define the anchor concept:
Describe your solution with a familiar anchor to help customers understand the idea quickly. This is usually with reference to a current well-known brand:

• Uber for Pets
• Netflix for Books
• Facebook for Introverts

Make your strength obvious
Your frame of reference must highlight your unique capabilities against the status quo.

Focus on the problem
Lead messaging with a specific pain point, not product features. You want your offering to be the natural answer.

There’s a lot more wisdom from April Dunford here.

Just remember, no matter how important you think it might be to create a new category, 99.99% of the time it won’t be.

I made my own onboarding document during a call.

There wasn’t one. So I asked every question I had and typed the answers straight into a Google Doc while the other person was still talking. Not clever. It was just the first time any of those answers existed outside somebody else’s head.

That doc got me through my first month.

I assumed that was a new-person problem, nothing more.

Then I watched a founder years into his own business do a much bigger version of the same thing, in three minutes.

The list that was never waiting for time

One founder came in with 1,200 lines: blog ideas, to-dos, market observations, things he’d meant to follow up on and never had. He’d been meaning to sit down and sort it for weeks. Minutes after pasting it in, it came back structured, prioritised, turned into something he could actually use: “It’s actually done what I wanted it to do, what I was going to ask it to do next week.”

The easy read is that AI made him faster. That isn’t quite it. He was never short of an afternoon. He was the only person in the business who could make sense of those 1,200 lines, and a list like that sits there for years waiting for its one qualified reader to be free.

The number six months couldn’t produce

The same thing happens on bigger questions. One founder came in with something he’d been circling since the start of the year: his North Star metric, the single number that would tell him whether the business was actually working.

What he said after one session: “I never boiled it down to something so simple.”

Nobody handed him an answer. He got asked the same question from enough angles that the only version left standing was the one he’d been avoiding.

You still decide

Worth being clear about this, because the workshops are unusually blunt about it. The system offers options, weighs trade-offs, makes recommendations. It never makes the final call. That stays with the founder, every time.

Most founders aren’t short on ambition or effort. What’s missing is something that makes you finish a sentence you’ve been starting for half a year.

If you’ve got one of those rattling around your head right now, you’re probably one direct conversation away from being done with it. Not six more months of thinking about it.

That’s what the BoS OS Workshop is for. Two 120-minute sessions, 12 people max, and you bring the question you’ve been avoiding.

At Business of Software USA, Ivan Barajas Vargas, CEO and co-founder of MuukTest, walked through the findings from five of the most cited academic papers on AI in development. The picture: speed and efficiency aren’t the same thing. Code that requires endless review, security audits, and refactoring costs more than it saves.

The problem is how teams are using the tools.

Tool Overload Hides Real Security Risks

There are now hundreds of AI coding tools on the market: Cursor, Copilot, Claude, GitHub’s own offerings, plus specialised tools for every framework. Most teams pick one by gut feel, try a second, and end up running both in production.

That’s shadow AI: unauthorised, unvetted tools loose in the development workflow. A sales intern tries a new tool to “help.” Each one opens its own security surface.

The real risk is copy-pasting credentials into a system nobody’s vetted. Once that data leaks, it’s gone.

The fix: pick one stack and enforce it. Write standards. Any team can write a prompt, but the good ones write guidelines for how AI gets used in development, with input from business and product, not just engineering.

“It’s Like Using a Chainsaw”

That’s how Ivan puts it: AI coding tools are powerful in trained hands and a mess in untrained ones. Auto-complete, refactoring, scaffolding, root cause analysis, they all work, provided someone actually knows what they’re doing.

AI generates thousands of lines of code, most of it syntactically fine and conceptually plausible. Until you dig in and find APIs that don’t exist. That’s built into how these models work: they extrapolate from training data, and sometimes the extrapolation is fiction.

That’s tax.

The fix is context. Load your RAG system or vector database with documentation, architecture decisions, and code standards. Test performance regularly. Don’t assume generated code scales just because it compiles. And keep reviewing outputs: the more your team generates with AI, the more a senior developer ends up validating.

When my team ships faster with AI but I’m not sure code review is keeping pace, I want to know whether the tool is the problem or whether we skipped the guardrails.

The New Job Description: Full-Time Reviewer

Senior developers are reviewing five times more code than before AI entered the workflow. A junior developer with AI generates more code, faster. But every line needs review, testing, and validation. And the people you actually need for architecture, mentorship, and strategy are stuck validating what the junior team generated.

More code doesn’t mean better code. AI writes like a junior developer: a lot of output, some of it buggy, most of it immature. Tech debt compounds.

The burnout point is the one worth sitting with. A tool that’s supposed to save time is quietly taxing your best people, and most teams haven’t noticed because the dashboard still says “faster.”

The fix starts with acknowledging the shift: AI tools multiply senior workload, they don’t eliminate it. Monitor that load. And assign ownership: if someone is responsible for vetting the AI, integrating it, and maintaining standards, the workflow stays manageable. If no one owns it, it metastasises.

Treat AI Like a Chainsaw

The teams getting real value from AI aren’t treating it as a replacement for architecture or strategy. They’re treating it like a chainsaw: powerful, but only in trained hands with the guards on.

That means picking one tool and committing to it. Writing standards. Feeding the system context. Testing for performance. Instrumenting observability from day one, so you know why things break. Naming owners. Watching developer load so your senior people don’t burn out reviewing everyone else’s output.

It also means accepting where vibe coding belongs: prototypes, mockups, small features. Not the core architecture of a fintech platform or a healthcare system. There, AI scaffolds and refactors. It doesn’t decide.

The vibes are only off if you skip the integration work and hope for the best.

Chris told this story at BoS USA 2025, alongside Chris Lavigne, Wistia’s head of production and a 14-year employee, in a fireside conversation about what actually happened after they turned the deal down. The headline decision is the memorable part. Proving it was the right call took the next five years.

Why founders say no to the pot of gold

Three companies approached Wistia about buying the business in 2017. Chris and his co-founder, who’d always turned those conversations down before, said yes this time and got deep enough in to land a real offer. While making a list of everything they’d do after selling, they realized the list was just Wistia again, the same people, the same problems, rebuilt from scratch. That was the moment they admitted to each other they were actually unhappy with how they were running the business:

• chasing growth at all costs
• saying yes to ideas without ever asking what to stop doing
• accumulating what Chris calls zombie projects that stayed alive because nobody asked if they should.

Raising to serve growth, not to search for it

Turning down the offer left an open question: what to do about the roughly 1.4 million dollars already raised from angel investors, and the liquidity everyone had been promised someday? The answer was the 17 million dollar debt round, structured so early investors and employees could choose to take cash now rather than wait for an exit that wasn’t coming. Chris’s framing for founders weighing a raise: are you raising to search for growth you don’t have yet, or to serve growth you already know how to produce. Pre-product-market-fit, you may need outside capital and want the smallest raise you can get away with, since that dilution is the most expensive you’ll ever take. Already know what works? Wistia funded a chunk of its own growth just by switching the default payment plan from monthly to annual, and the debt round was the more dramatic version of the same idea: borrowing against a business they understood, rather than diluting further or selling outright.

Independence didn’t automatically buy speed

The buyback bought Wistia the right to set its own terms. It didn’t automatically buy a fast product org. By 2021, flush with profit and conviction, Wistia doubled its product and engineering headcount from 50 to 100 people in a single year, fully self-funded. Shipping got slower. By October 2022, Chris stopped assuming the fix was more people and asked a harder question: what if the bottleneck was his own review process, where every roadmap ran through him first and the best-organized deck won, not the one that shipped the most customer value.

The fix was structural: all 13 product teams got full ownership of their own roadmaps, judged on a single measure, shipping real customer value every two weeks. A tagging feature scoped at six months under the old process shipped in two weeks under the new one. Product releases went from 12 a year to 70, then 130, with no change in team size.

The through-line across both moments: the buyback bought Wistia the right to set its own terms. Making that worth anything meant being honest, twice, about where the business was actually stuck, and changing the structure rather than pushing harder inside the old one.

Watch the full talk, including the equity program, the hiring pendulum, and the Q&A on OKRs and product structure.

I nodded along the first few times Mark said this without actually understanding what he meant. He thinks of the BoS OS as “a way of finding the co-founder you never had who is almost the exact opposite of you.”

What changed my mind was sitting in the workshops and hearing founders say the same thing back to him, in their own words, without being asked.

Dom Reed got there working through the mission planner with his co-founders, one session, one shared screen. What struck him was the probing. By the end he called the whole thing “proper therapy.”

Nobody in that room was being lazy

I know this one from the other side. I joined BoS and inherited systems nobody had time to walk me through. Nothing written down anywhere. Not because anyone was careless. Because the people who built it never had to explain it to themselves.

That’s the pattern the workshops keep surfacing: founders who aren’t short on effort, just short on someone forcing them to say the quiet part out loud.

The agreeable ones are much less useful

A co-founder worth having sits on a position you haven’t considered and stays there until you deal with it.

Tim Barker builds that instinct into the architecture itself. Alongside the agents that do the work, he runs guardians whose only job is to check the ones producing it, built specifically so nothing optimises for growth at the cost of trust or economics.

That’s the whole point. An assistant that only agrees with you isn’t a co-founder, it’s a mirror.

The bridge nobody quite has yet

Even the founders furthest along keep hitting the same wall. Robert Fryers put it plainly, four weeks in: the bit he’d pay more for was “the bridge between a consistent source of truth for multiple people and rolling this out to the team.”

That’s not a small ask. It’s the same instinct, pointed at a harder problem: not just a counterweight for one person, but one the whole team can trust.

If you’re running on instinct and a very full head

I’m not a founder. But my first months here ran on instinct and a head that was far too full, and what helped was having something in the room that wouldn’t let me leave a decision half-made.

If that sounds like your week, sit with it for a minute. Not because you’re doing it wrong. Because the arguing part is the bit you’re missing, and it’s the one thing you can’t do on your own.

The BoS OS Workshop is two 120-minute sessions, capped at 12 people, for founders who’ve already got a first-draft OS and want it to hold up when something pushes back.

Matt Lerner told the story at BoS Europe 2026. Elemental Software made a WYSIWYG website builder, drag and drop, connect to a database, right in the middle of the dot-com boom. The CEO hired a professional comedy writer and sent Lerner’s team to executive conferences to perform fake product demos in front of the room’s most important investors, on the theory that laughter would translate into offers.

The first attempt was Atonement.com, a fictitious confession website where visitors could enter their sins and receive an appropriate penance. They performed it straight after Steve Forbes, then running for the Republican presidential nomination, used his dinner speech to describe an abortion procedure in graphic detail. “Worst warm-up act ever,” Matt said. The room was tense enough that the comedy demo landed hard. It got laughs, business cards, no offers.

The second attempt raised the stakes: a fake site where you could start your own religion, complete with two original songs from a hired composer and a professional singer performing live on stage. Again, the room loved it. Again, nobody bought the company.

The third attempt is the one that worked. Matt’s co-founder, Peter, went through the attendee list ahead of time and built the demo around the people in the room, giving investors like Mary Meeker and Vinod Khosla actual speaking parts in a fake IPO pitch. After the show, the chairman of the board of Macromedia walked up to Peter and said, “We’re actually looking to buy a company in your space. Can we talk?” Negotiations followed, backed, by Matt’s account, by nothing more sophisticated than a yellow copy of Negotiating for Dummies on Peter’s desk. The deal closed at $20 million.

That would be a fine story on its own. What makes it worth telling is what happened next. Matt joined Macromedia as part of the acquisition and was handed a cubicle previously occupied by someone else, complete with a shelf of abandoned binders. Cleaning them out, he found a board memo: the proposal to purchase Elemental Software, authorizing Macromedia to pay up to $78 million. His company had sold for roughly a quarter of what the buyer was prepared to spend.

He told Peter that night at dinner. Peter’s reaction was one word, followed by stuffing the memo into his laptop bag and telling Matt never to mention it again. Matt kept that promise for 25 years, until he caught up with Peter over the most recent Christmas and got released from the arrangement, on the condition that he tell the whole story, memo included.

The lesson isn’t really about comedy demos, though those clearly worked as a way to get noticed in a room full of people who’d seen every standard pitch before. It’s about the gap between getting a company bought and getting it bought for what it’s worth. Differentiation, memorability, and nerve got Elemental Software an offer that a conventional sales process hadn’t produced in two prior attempts. None of that told the team anything about how much room the buyer actually had. Only a forgotten memo in an old cubicle answered that question, and by then the deal was already signed.

Watch Matt Lerner’s full talk to hear the whole thing, including the specific line that made Peter swear him to secrecy.