Pierre Chamberland told the story at BoS USA 2025. Netgovern sold email and file archiving software. When Pierre needed to buy out an investor and his co-founder, he asked his team for help and promised to replace both with them. He then gave employees actual stock, and 90% of them became shareholders. He stepped aside as CEO in 2015, returned in 2018, and kept the numbers open.

One currency beats a stack of schemes

Pierre argues that profit sharing, phantom stock and options at exit do not create a visceral connection to the outcome. Shares did. Everyone held the same class of common stock. Pierre kept it simple on purpose, because people struggle to be enthusiastic about something complicated. Employees paid $10 when they joined and got the $10 back if they left, and Pierre kept the votes through a voting trust.

The grant formula was open. Anyone could ask a team lead where they ranked on equity, and if one person held twice as many shares as a colleague in the same role, that opened a conversation about why. Pierre calls this vulnerability, and also uncomfortability, a word he admits he made up.

Teach the numbers before you open the books

Early on, Pierre asked staff three questions about the company and collected written answers. Nobody came close on his salary. People assumed he took home half a million dollars a year, when the salespeople earned more than he did. That started a ten-year effort to teach financial literacy through weekly sessions and monthly meetings. The team dropped formal accounting terms for cash accounting, which covers money in, money out and what is left. About a third of employees wanted the formal statements.

The simplest tool was the profit zone. At the start of each year the company declared the date it would become profitable, then tracked that date every month. When weak sales pushed it later, people asked whether to delay a server purchase or skip an event.

Openness also produced ideas Pierre had not planned for. Some hospital and airline customers wanted 24/7 support, as Symantec and Microsoft offered. The support team arrived with a plan. Two engineers would carry a phone for a week at a time, with a new menu option for system-down calls, at $100 a week each, about $800 a month in all. In the first three months, with roughly 450 customers, the line took eight calls, four of them tests.

Count the costs before you start

Pierre puts the minimum at three to five years just to get people to understand how the business makes money. The costs were personal too. Departing employees received their $10 back, and after some poor performers and layoffs, some relationships broke. Pierre says some people still will not talk to him.

An incoming CEO later called the cap table uninvestable and replaced stock with options, which gave Pierre a comparison. About 50 people held options, and Pierre says only two executed them, even after he offered to lend directors and executives the money. He asked why. One answer was that options at an earlier employer had gone to zero. Pierre said that, given the choice, he would have kept the shares.

If you are weighing the same decision, Pierre Chamberland’s talk covers the grant formula, the voting trust and a short Q&A on shares versus options.

Every product team has said it. Then the work shows up. The docs need updating, then the Android app, the iPhone app, the API. The small feature was never small.

Even when the work is small, that still isn’t a reason to build it. That was the point Des Traynor, co-founder of Intercom, made in a seven-and-a-half-minute lightning talk at BoS USA 2013. His comparison: he could go out and rob a bank right now. It wouldn’t take long. That doesn’t make it a good idea.

Des’s thesis was simple. Product strategy is mostly about saying no.

Version one is the easy part

When you start, nobody else has an opinion. You build what the founders want, and it’s usually easy to start good. The hard part is staying good.

Traction brings company: competitors, board members, a growing team with its own ideas, big customers offering to pay for what they want, and a tech press with opinions on what you should build next.

None of these voices is wrong on its own. The trouble comes when you say yes to all of them. Des’s picture of where that leads is a Swiss Army knife: a collection of barely useful tools smashed together. Pull it out in a knife fight and people laugh. It isn’t a good knife, a good saw, or a good anything.

Early Windows Media Player had play, pause and stop. Early Outlook was beautiful. Neither stayed that way.

1,000 nos for every yes

Des borrowed the ratio from Apple: 1,000 nos for every yes. The hard skill is looking a good idea in the face and saying, “That’s a brilliant idea, thanks for bringing it to me, but we’re not building it.”

Then he took on the usual excuses.

“It’ll increase engagement.” Will it, or will it just move engagement around? Most new features split the use you already have. And not all engagement is good. Put Tetris in your web app and people will use it every day.

“Everyone’s asking for it.” That’s frequency bias. Hear something a few times, recently, and it feels like a must-have. Des admitted to reaching for his phone mid-conference to tell his team they needed live chat, after hearing one person talk about it. Then he stopped himself.

“A customer will leave if we don’t.” Be willing to say, “Okay, off you go.”

“We can make it an option.” Now you have seven pages of settings, more to build, and more to confuse customers.

“All our competitors have it.” Those competitors are looking at the same features and working out how to get rid of them. Copy them and you deliver yesterday’s broken technology tomorrow.

If you’ve got time to lean, you’ve got time to clean

No new feature to build? That’s not a reason to invent one. It’s the time to fix bugs and make the product faster and more reliable.

He also gave a way to decide what stays. Plot every feature by how many customers use it and how often. A couple of SQL queries will do it. In his example, a project management app, almost nobody used the chat room or the calendar. Features like that face a choice: fish or cut bait. Get people using them, or get rid of them.

That’s how you keep product-market fit after version one.

Questions to ask before you say yes

Des closed with a short checklist:

• Does it fit the vision, and is it a step forward?
• Will it matter in five years?
• Will it create new engagement, or just move it around?
• If it succeeds, does it grow the business?
• For the people who use it, is the reward bigger than the effort?
• Does it benefit all customers?
• If it succeeds, can we support it?

The last one catches teams out. Build an Android app without Android people, and who looks after it?

Watch the talk

It’s seven and a half minutes, and it holds up more than a decade later. Watch Des’s full lightning talk from BoS USA 2013.

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.

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.