people mix up two very different types of pivots and that it’s important to differentiate which path you’re on: Ideation pivots: This is when an early-stage startup changes its idea before having a fully formed product or meaningful traction. These pivots are easy to make, normally happen quickly after launch, and the new idea is often completely unrelated to the previous one. For example, Brex went from VR headsets to business banking, Retool went from Venmo for the U.K. to a no-code internal tools app, and Okta went from reliability monitoring to identity management all in under three months. YouTube changed direction from a dating site to a video streaming platform in less than a week. Hard pivots: This is when a company with a live product and real users/customers changes direction. In these cases, you are truly “pivoting”—keeping one element of the previous idea and doubling down on it. For example, Instagram stripped down its check-in app and went all in on its photo-sharing feature, Slack on its internal chat tool, and Loom on its screen recording feature. Occasionally a pivot is a mix of the two (i.e. you’re pivoting multiple times over 1+ years), but generally, when you’re following the advice below, make sure you’re clear on which category you’re in.

When looking at the data, a few interesting trends emerged: Ideation pivots generally happen within three months of launching your original idea. Note, a launch at this stage is typically just telling a bunch of your friends and colleagues about it. Hard pivots generally happen within two years after launch, and most around the one-year mark. I suspect the small number of companies that took longer regret not changing course earlier.

ou should have a hard conversation with your co-founder around the three-month mark, and depending on how it’s going (see below), either re-commit or change the idea. Then schedule a yearly check-in. If things are clicking, full speed ahead. If things feel meh, at least spend a few days talking about other potential directions.

Brex: “We applied to YC with this VR idea, which, looking back, it was pretty bad, but at the time we thought it was great. And within YC, we were like, ‘Yeah, we don’t even know where to start to build this.’” —Henrique Dubugras, co-founder and CEO

inside look at how Perplexity builds product—which to me feels like what the future of product development will look like for many companies:AI-first: They’ve been asking AI questions about every step of the company-building process, including “How do I launch a product?” Employees are encouraged to ask AI before bothering colleagues.Organized like slime mold: They optimize for minimizing coordination costs by parallelizing as much of each project as possible.Small teams: Their typical team is two to three people. Their AI-generated (highly rated) podcast was built and is run by just one person.Few managers: They hire self-driven ICs and actively avoid hiring people who are strongest at guiding other people’s work.A prediction for the future: Johnny said, “If I had to guess, technical PMs or engineers with product taste will become the most valuable people at a company over time.”

Typical projects we work on only have one or two people on it. The hardest projects have three or four people, max. For example, our podcast is built by one person end to end. He’s a brand designer, but he does audio engineering and he’s doing all kinds of research to figure out how to build the most interactive and interesting podcast. I don’t think a PM has stepped into that process at any point.

We leverage product management most when there’s a really difficult decision that branches into many directions, and for more involved projects.

The hardest, and most important, part of the PM’s job is having taste around use cases. With AI, there are way too many possible use cases that you could work on. So the PM has to step in and make a branching qualitative decision based on the data, user research, and so on.

a big problem with AI is how you prioritize between more productivity-based use cases versus the engaging chatbot-type use cases.

we look foremost for flexibility and initiative. The ability to build constructively in a limited-resource environment (potentially having to wear several hats) is the most important to us.

We look for strong ICs with clear quantitative impacts on users rather than within their company. If I see the terms “Agile expert” or “scrum master” in the resume, it’s probably not going to be a great fit.

My goal is to structure teams around minimizing “coordination headwind,” as described by Alex Komoroske in this deck on seeing organizations as slime mold. The rough idea is that coordination costs (caused by uncertainty and disagreements) increase with scale, and adding managers doesn’t improve things. People’s incentives become misaligned. People tend to lie to their manager, who lies to their manager. And if you want to talk to someone in another part of the org, you have to go up two levels and down two levels, asking everyone along the way.

Instead, what you want to do is keep the overall goals aligned, and parallelize projects that point toward this goal by sharing reusable guides and processes.

Perplexity has existed for less than two years, and things are changing so quickly in AI that it’s hard to commit beyond that. We create quarterly plans. Within quarters, we try to keep plans stable within a product roadmap. The roadmap has a few large projects that everyone is aware of, along with small tasks that we shift around as priorities change.

Each week we have a kickoff meeting where everyone sets high-level expectations for their week. We have a culture of setting 75% weekly goals: everyone identifies their top priority for the week and tries to hit 75% of that by the end of the week. Just a few bullet points to make sure priorities are clear during the week.

All objectives are measurable, either in terms of quantifiable thresholds or Boolean “was X completed or not.” Our objectives are very aggressive, and often at the end of the quarter we only end up completing 70% in one direction or another. The remaining 30% helps identify gaps in prioritization and staffing.

At the beginning of each project, there is a quick kickoff for alignment, and afterward, iteration occurs in an asynchronous fashion, without constraints or review processes. When individuals feel ready for feedback on designs, implementation, or final product, they share it in Slack, and other members of the team give honest and constructive feedback. Iteration happens organically as needed, and the product doesn’t get launched until it gains internal traction via dogfooding.

all teams share common top-level metrics while A/B testing within their layer of the stack. Because the product can shift so quickly, we want to avoid political issues where anyone’s identity is bound to any given component of the product.

We’ve found that when teams don’t have a PM, team members take on the PM responsibilities, like adjusting scope, making user-facing decisions, and trusting their own taste.

What’s your primary tool for task management, and bug tracking?Linear. For AI products, the line between tasks, bugs, and projects becomes blurred, but we’ve found many concepts in Linear, like Leads, Triage, Sizing, etc., to be extremely important. A favorite feature of mine is auto-archiving—if a task hasn’t been mentioned in a while, chances are it’s not actually important.The primary tool we use to store sources of truth like roadmaps and milestone planning is Notion. We use Notion during development for design docs and RFCs, and afterward for documentation, postmortems, and historical records. Putting thoughts on paper (documenting chain-of-thought) leads to much clearer decision-making, and makes it easier to align async and avoid meetings.Unwrap.ai is a tool we’ve also recently introduced to consolidate, document, and quantify qualitative feedback. Because of the nature of AI, many issues are not always deterministic enough to classify as bugs. Unwrap groups individual pieces of feedback into more concrete themes and areas of improvement.

High-level objectives and directions come top-down, but a large amount of new ideas are floated bottom-up. We believe strongly that engineering and design should have ownership over ideas and details, especially for an AI product where the constraints are not known until ideas are turned into code and mock-ups.

Big challenges today revolve around scaling from our current size to the next level, both on the hiring side and in execution and planning. We don’t want to lose our core identity of working in a very flat and collaborative environment. Even small decisions, like how to organize Slack and Linear, can be tough to scale. Trying to stay transparent and scale the number of channels and projects without causing notifications to explode is something we’re currently trying to figure out.

While there were undoubtedly people who came in for the food, worked 3 hours a day, and enjoyed their early retirements, all the people I met were earnest, hard-working, and wanted to do great work. What beat them down were the gauntlet of reviews, the frequent re-orgs, the institutional scar tissue from past failures, and the complexity of doing even simple things on the world stage. Startups can afford to ignore many concerns, Googlers rarely can. What also got in the way were the people themselves - all the smart people who could argue against anything but not for something, all the leaders who lacked the courage to speak the uncomfortable truth, and all the people that were hired without a clear project to work on, but must still be retained through promotion-worthy made-up work.

Another blocker to progress that I saw up close was the imbalance of a top heavy team. A team with multiple successful co-founders and 10-20 year Google veterans might sound like a recipe for great things, but it’s also a recipe for gridlock. This structure might work if there are multiple areas to explore, clear goals, and strong autonomy to pursue those paths.

Good teams regularly pay down debt by cleaning things up on quieter days. Just as real is process debt. A review added because of a launch gone wrong. A new legal check to guard against possible litigation. A section added to a document template. Layers accumulate over the years until you end up unable to release a new feature for months after it's ready because it's stuck between reviews, with an unclear path out.

Even Obsidian’s most dedicated users don’t expect it to take on Notion and other note-taking juggernauts. They see Obsidian as having a different audience with different values.

Obsidian is on some ways the opposite of a quintessential MacStories app—the site often spotlights apps that are tailored exclusively for Apple platforms, whereas Obsidian is built on a web-based technology called Electron—but Voorhees says it’s his favorite writing tool regardless.

Efficiency initiatives are all about doing the same (or more) with less.  And while sometimes that can be done purely through technology, humans often bear the brunt of efficiency initiatives.

When Zuckerberg says the organization is getting “flatter,” he means that more non-management workers will have to take on types of work—coordinating, synthesizing, communicating, and affective tasks—that managers used to do. For many, that means a significant intensification of a style of work that is not for everyone.

becoming more efficient and productive seems to hold positive moral value. It goes into the plus column on the balance sheet of your character. But this moral quality of efficiency acts to turn us each into a certain kind of person. Not just a certain kind of worker, but a certain kind of voter, parent, partner, mentor, and citizen.

Social theorist Kathi Weeks argues that the responsibilities we feel toward work—and I’ll add our responsibility specifically to efficiency and productivity—have “more to do with the socially mediating role of work than its strictly productive function.” In other words, the stories we tell about work and our relationships to it are actively creating our “social, political, and familial” stories and relationships, too.

A Year of Efficiency is bound to make shareholders happy. But what does it do to the humans who create the value those shareholders add to their portfolios? A Year of Efficiency might mean you can fit in more social media posts, more podcast episodes, more emails, or even more products or services. But how do you feel at the end? How has your relationship with yourself changed? How has your relationship with others changed?  Who do you become when efficiency is your guiding principle?

It’s worth questioning the moral quality we assign to efficiency and productivity in our society is healthy, or even useful. And it’s worth asking whether efficiency and productivity are really the modes through which we want to relate to our partners, children, friends, and communities.

While I certainly won’t deny the satisfaction of learning how to do a task faster, I do think it’s worth interrogating the way efficiency comes to shape our lives.