The Loop

When I see founders "build in public," it commonly looks like this: * Graphs of revenue going up, shared after they figured out their growth levers * Changelogs that detail all the cool shit they built, but don't share if the features delivered better customer outcomes, or not. * Post mortems of lessons

After a company achieves product/market-fit, things get complex. Business complexity compounds with the expansion of the customer base, code base, and team. Developing a strategy at this stage requires systems thinking. To make forward progress, you must find leverage points. Donella Meadows writes [https://donellameadows.org/archives/leverage-points-places-to-intervene-in-a-system] : > Folks

When I joined a previous company as the head of product, I tried hard to make the company more data-driven. We paid for an expensive business intelligence platform and I worked with our data team to create a killer dashboard. I led a weekly meeting where we reviewed the dashboard

OKRs (objectives and key results) are a critical tool. I helped bring them to my last company. Using OKRs successfully made us more objective and quantitative in how we built products. My favorite part of OKRs is the KRs (key results). It’s easy to be sloppy in our thinking

The way that the FAANG companies use metrics to build products is vital to their success. They invest an army of people and homegrown tools to pull it off. My last article, Balancing short-term and long-term product bets [https://blog.doubleloop.app/balancing-short-term-and-long-term-product-bets/], describes Google's process. While the very top

Dan Rubinstein [https://www.linkedin.com/in/ydanrubinstein/] has a unique vantage point on the evolution of the product management craft. He joined Google as a PM in 2005. His initial role was to put in place processes and systems to help other product managers understand the efficacy of what

Publishing a changelog is the highest value activity that you’re probably not doing. You might think that keeping a changelog is a boring chore reserved for developers. On the contrary, changelogs are a medium with the potential to transform how we all work. For those of you that already

What are the heuristics for separating “important” product changes from minor changes that are essentially background noise? If this question sparks your interest, keep reading. Everyone who works at a software company must perpetually ask the question: “How did our product change?” The folks who sell, market, or support the

Accountants have ledgers. Scientists record their experiments. Marketers have CRMs. Engineers have code version history. Product builders, however, lack a sufficient source-of-truth for their past work. It’s a fundamental gap that holds back product management craft. What is a “source-of-truth” (SoT) for product iterations”? A SoT for product iterations

Babies are born with exogenous attention. This means that the external world dictates what they pay attention to. A baby could be playing with the best toy ever, but when another toy drops next to them, their attention uncontrollably shifts to the new shiny object. In The Philosophical Baby, Alison

Innovation requires a combination of work and meta-work. By “work” I mean doing things that tangibly impact your product; designing, coding, marketing, etc.. “Meta-work,” in contrast, involves improving how you’re working. This often looks like meetings to synchronize the activities between teams or applying frameworks like OKRs or lean

Making the transition from hands-on product management to leading a PM team can be disorienting. On the one hand, if you get overly involved with projects, you’ll stifle the creativity of the team. And it’s unsustainable to be on top of every detail, especially with products that require