The Operating Lessons Brian Balfour Keeps Returning To

Brian Balfour keeps a Notion document called 'lessons learned' because, as he puts it, he does not tend to remember things unless he writes them down. Each entry is a one-liner describing the lesson plus a few sentences of explanation; some lessons come from others, while some are what he calls OG Brian lessons learned the hard way. When he faces a big strategic question at Reforge, he returns to the document and usually finds two or three lessons that help unblock him or point him toward a better answer. The document now contains more than a hundred lessons.

The host notes that many people wish they kept such a list and even more fail to use one, and Brian says the key is keeping it light. When he used to take exhaustive notes from books, both creating the notes and returning to them created friction. Now he captures only the essence of an idea from a podcast, book, or conversation, which makes the list quick to create and quick to revisit.

Brian credits Frank Slootman with the phrasing for a lesson he had felt strongly throughout his career: inspect the work, not the person. Judging someone from a conversation is heavily biased, whether the context is hiring, performance, or promotion. Going to the actual output—what someone has created, shipped, and helped bring to life—shows far more about their capabilities, approach, and ability to work with others.

At Reforge, 80 to 90 percent of the hiring decision is based on a portfolio review or a simulation, sometimes called an exercise. Brian says his team pushes back because these take work to design and add friction to the hiring pipeline, but every time he has made an exception and skipped them, he has regretted it. The lesson is that surface-level conversation almost always misleads when the decision is really about people and their work.

The same logic applies to performance and promotion processes, where decisions often rely on a story told by the individual and advocacy from a manager. That game of telephone creates bias and can hurt people who do excellent work but are less skilled at self-advocacy or who have managers who do not advocate well for them. Reforge is slowly building regular processes for people to log what they have helped ship and their role in it, using lightweight screenshots and bullet points rather than long write-ups. Brian emphasizes that the log should capture shipped work and customer impact, not just obvious wins, because good work can fail for reasons outside the person’s control.

Reforge has also built a product called Artifacts, which Brian describes as a portfolio or GitHub for everybody. It stores and showcases work such as performance-review processes, career ladders, interview simulations, or product features, and later colleagues can use those artifacts as ingredients for their own problems. Brian has posted his original Reforge hypothesis document there, and people can find it through reforge.com or artifacts.reforge.com.

As teams grow, more ideas come from the bottom up, but by the time a proposal reaches the person who can greenlight or fund it, it has often passed through many filters. People worry about being denied, sounding too wild, or being told something is too much work, so they water down the proposal before it reaches the decision maker. Brian’s lesson is to tell him what it takes to win first, then discuss the costs; only after that can the team collaborate on a smarter or cheaper approach. He does not want the team spending time on watered-down ideas that will not help the company win.

A related lesson in Brian’s list is to define the ideal end state and then iterate toward it. That is tricky because people can attach themselves to the ideal and resist revisions, while the ideal itself must be revisited as the team learns. Leaders have to align people around a direction without implying that every pixel or feature will be exactly as described. Brian also notes that finding time to step back and update the ideal end state is a real source of friction.

For yearly planning, Brian argues that most teams would be better served by product visuals than by a neatly formatted set of OKRs. Reforge moved toward this approach about four or five months before the conversation, after several planning processes during a chaotic growth period turned into disasters. In this mode, 80 to 90 percent of the assets produced should be actual visuals of the experience, including marketing assets or customer-facing supply-side assets, because those create a more productive conversation than a Notion document full of words. At roughly 75 people, Reforge finds this method effective for keeping coordination costs low while still landing new product bets, even if the process may need to change as the company scales.

Brian has often fallen into the trap of thinking that one big hire, one strategy, or one solved problem will finally make everything easier. The reality is the opposite: the more problems you solve, the bigger the problems you take on. Hoping things will get easier creates frustration, anxiety, and stress, while saying 'if I solve this, I get to take on an even harder thing' actually reduces stress. He found language for this in a Ray Dalio passage about every day bringing problems and about each person needing to be a problem-solving machine, and Reforge has worked that idea into its cultural values.

The host observes that leadership is often a professional firefighter role because only problems bubble up; things that are going well usually do not. Brian agrees and says many people end up in management roles and dislike them, partly because they are not good at the work and partly because they do not like it. A big driver is the belief that management is the only way to progress in title, compensation, and access to compelling roles.

Reforge has responded by flattening its org and converting many managers back into Captain IC roles. Its framework distinguishes players, coaches, and captains: managers coach from the sidelines, while senior ICs lead from the playing field. Reforge created the same titles across levels, removed the compensation trade-off for staying on the IC track, and gave strategic problems to captain-level ICs while managers focus on hiring, coaching, and positioning players. There are more captain roles internally than manager roles.

Brian warns about a manager death cycle in which people become managers only to progress, star ICs are taken off the field, and new managers create meetings and processes that repeat the cycle. He argues the future favors super ICs because AI tooling gives one person a wider set of creation abilities, allowing smaller teams to solve the same problems with less coordination; he cites Scott Belsky and others making similar predictions. Reforge encodes this in a cultural value that small teams do bigger things, and Brian points to HubSpot seeding multiple bets with limited funding and small teams. The mistake is piling capital and people onto bets that are only kind of working, which tends to make them worse.

Brian learned at HubSpot that the year is made in the first six months. Plans often look realistic for the first three to six months, then teams imagine an inflection point in the back half that will somehow hit an ambitious target. For many products, that is not how it works because buying cycles and decision windows are long; in SaaS they can run from months to a year. By the time a second-half initiative is built, adopted by customers, and carried through a buying decision, the impact may already land in the next year.

Consumer social products may have lower friction and short-window levers such as paid acquisition, but Brian says even those products are often shaped by viral loops, engagement, and retention. Building and shipping those systems, then letting them propagate through the user base, takes longer than most planners assume. He sees a human tendency to overestimate both how fast something can be done and how fast it will take effect, especially as the customer base grows and the new number needed for meaningful impact gets larger.

Brian’s growth lesson is that acquisition, retention, and monetization form a system: change one and you affect them all. A problem that shows up in one area may be solved in another, such as retention problems created by acquiring the wrong users or monetization problems stemming from engagement issues. Teams often see low revenue retention or low conversion and go straight to levers inside that same part of the system. Sometimes the answer really is there, such as a bad pricing page or dunning flow, but often the actual lever sits elsewhere. Brian says this system-level thinking is the main thing that separates great growth people from merely good ones.

He offers examples across companies. An Airbnb guest-retention team found that retention depended heavily on trip quality and host quality, which pushed resources toward improving the trip experience rather than keeping a retention team focused on retention alone. In early HubSpot sales days, renewal figures were only okay, and customer conversations revealed that sales was selling to the wrong persona or an undesigned use case; HubSpot eventually changed sales incentives so selling certain personas would not earn comp. Early Reforge had a similar lesson in its application process, where questions helped shape the peer-to-peer experience, though COVID later removed the in-person component that made those lessons relevant. Reforge’s move into marketplaces makes this system thinking even more central because demand and supply conversations constantly run into each other.

Brian also teaches a concept called good friction. Many people are taught to reduce friction everywhere, but sometimes the right move is to add friction to create the right down-funnel experience and engagement. Internal incentives fight this because adding good friction can lower short-term conversion while the benefits take time to propagate, and people are rewarded for quick metric wins. Reforge’s application process is an example: the team rejects applicants who are excited to join and would generate revenue when it knows they are likely to have a bad experience, leave bad reviews, and create negative word of mouth.

When Reforge started, the online education norm was short-form, self-serve, low-priced, and open to everybody. Brian and Andrew did the opposite for the first growth series: a small group, in-person components, a high price, live elements, and an application process rather than pure self-serve. The first run had an amazing response, and cohort-based courses later became a familiar model. The lesson is to study what everyone is doing not so you can copy best practices, but so you can ask what the opposite would be; major trends almost always leave an opportunity on the other side.

The same idea applies to paid acquisition, where looking at other advertisers’ creative can help you design something completely different and stand out. Brian notes that categories have gravitational forces that pull products toward sameness, such as SaaS sites copying the same character illustration style, and the dynamic operates in strategy, product design, ad creative, and growth tactics. In content, HubSpot’s old playbook was high-volume short articles, at one point around ten articles a day, and many people copied it; Brian and a few others went low-volume and very long, which stood out and performed well among the noise. This is a constant pendulum because once others copy you, you have to step back and flip again.

Brian sees the current AI content wave as another place to look for the opposite. While many people use AI to generate large volumes of content for search ranking, LinkedIn used AI to lower friction for more user-generated content, which can be more unique and rank better. He cautions that the opposite is not guaranteed to work, but it is an interesting area for finding opportunity, and he points to podcast formats as another example: Lex Fridman’s long conversations and Acquired’s long monthly episodes with no guests run against conventional advice. Reforge’s own Unsolicited Feedback podcast avoids being another interview show; it brings on a guest but analyzes recent product releases as if the hosts were the company’s VP of product. In category creation, HubSpot defined inbound marketing as the opposite of outbound, though Dharmesh has said category creation is rarely the right answer even though HubSpot did it well.

Brian argues for use cases over personas because persona definitions often put emphasis on the person or category of person rather than the actionable situation. In Reforge’s framing, a use case starts with the problem being solved, the value proposition against that problem, the user’s alternative, and why the user chooses you over that alternative. Once those pieces are defined, the team can ask about the natural frequency of the problem, which shapes retention and activation metrics, and the natural frequency of adoption, which shapes acquisition. Many SaaS customers are only in market every few years, so HubSpot’s content marketing built a relationship before buyers were ready, making HubSpot the first place they went when they entered the market.

Most products are adopted by multiple personas, which leads teams to try to solve multiple use cases and problems across those personas. Brian thinks it is more detrimental to solve many use cases than to focus on one use case that multiple personas adopt, so Reforge starts with the use cases it wants to build against and only then asks who has those problems. He has often been surprised by people who have the problem but would never have appeared in persona research. The use case map, developed in Reforge’s Retention Program with Casey Winters and Shaun Clowes, lays out rows for the problem, who has it, alternatives, why the user chooses you, and natural frequency; teams often map eight use cases, which signals they are trying to solve too much.

Brian’s most repeated line in Reforge courses is that solving for everyone is solving for no one. The important guardrail is not just being specific about who you are solving for, but being specific about who you are not solving for, because otherwise people rationalize adjacent use cases and adjacent users. He cites an HBS case study on early HubSpot, which found four surface-similar use cases: Marketing Mary, a mid-market VP of marketing seeking an all-in-one solution; an enterprise buyer seeking compliance and security; a small-business owner; and a technical marketer who wanted customization. HubSpot focused on Marketing Mary and the all-in-one use case, explicitly decided not to serve the other three, and aligned sales comp, success, and marketing around that choice.

The lesson extends beyond product and marketing into culture. Brian says generic culture statements become watered down because they try to accommodate everybody, while strong culture is opinionated and acknowledges that a company is not a place for everyone. Reforge’s values document includes anti-patterns and explanations of what each value does not mean, which helps hiring and other decisions identify who fits and who does not. He also shares a personal example from his summers as a wedding planner in Los Angeles: the most miserable couples tried to solve for the fiancé, both sets of parents, friends, and the annoying Uncle Eddie, while the best experiences came when couples identified the most important group and designed for them. He sees the same trade-off problem in relationships and work-life balance, where not acknowledging what you are not solving for creates stress and anxiety.