In a company like Anthropic, excellent project management is an extremely high-leverage skill, and not just during crises: our work has tons of moving parts with complex, non-obvious interdependencies and hard schedule constraints, which means organizing them is a huge job, and can save weeks of delays if done right. Although a lot of the examples here come from crisis projects, most of the principles here are also the way I try to run any project, just more-so.
The counterintuitive thing is, we often feel like our task is to get to a “yes.” But what we actually need is a way to say “no.” It’s the ability to eliminate many, many things that aligns us on the one thing. It’s the “no, no, no, … YES!” that gives us the power to move forward and to stick with a project.
For years, communicating tradeoffs to senior leaders was one of my biggest challenges. While presenting the pros and cons between two priorities, I’d somehow always end up committing to doing both, and in less time than I had planned. As you’d expect, this usually went … badly. I’d burn myself out or, worse, burn out my team.
Initially, the team carried just two product managers and one or two designers alongside dozens of engineers — a flatter and more coder-dominated group than most Meta product teams, Mosseri said. (At launch, it had grown to three product managers, three designers and 50 coders.) Instead of 30-minute presentations on a single design decision, typical at Facebook and Instagram, “It would be like, ‘Here are six things we need to go through this week.’”
Innovation should almost never happen. It’s incredibly rare. It mostly happens by accident, not by intention. It’s wonderful when it does, but you merely fluctuate in and out of it, it’s not steady state.
When you’re staring a huge, challenging project in the face, don’t align your team around just getting it done. Instead, align your team around continually reducing uncertainty.
Organizational effectiveness in market development is efficiently running a lot of experiments to find promising opportunities.
Organizational effectiveness in growth and maturity is efficiently building, scaling, iterating, and exploiting capabilities in order to maximize business value.
After I have a lay of the land, the next step is to determine what to work on first, second, third etc. Not every concern in the product provides equal value to the customer. Some parts are core to the problem. Without them the app has no purpose. Others are necessary but have nothing to do with the domain, like user-authentication.
You need to take a step back and view data on a macro level, not micro. As the founder, you should care more about the trends not the constant, inexplainable anomalies.
Stephen Covey explained that “trust is a function of two things: competence and character. Competence includes your capabilities, your skills, and your track record. Character includes your integrity, your motive and your intent with people. Both are vital.”
Sadly, or perhaps luckily, most experimentation isn’t all that dramatic. It mainly means trying something new and using the results to decide a further course of action. You can experiment with a more efficient route to the office, with a new dinner recipe, or a new vacation destination. The element that distinguishes an experiment from serendipity is that you have a hypothesis that you are looking to verify or falsify based on data that you glean from running the experiment.
Ken Kocienda tells stories of how Apple built the iPhone and iPad: a small team (less than twenty people) charged with delivering on direction set by executives.
Since HEY made a big splash on arrival, I thought it’d be fun to share the backstory of how we ended up reinventing email. Because we certainly didn’t start by wanting to reinvent email.
Kent Beck comparing baskets of options to product roadmaps and goals:
I’ve come to hate the damage the “product roadmap” metaphor does to the brains of everyone involved in developing a product. When I use an actual map of actual roads, I assume that I know where I’m going and how I’m going to get there. This is never the case when developing a product.
The cliché “celebrating failure” misses the point—we should be celebrating learning, not failure.
…
Without discipline, almost anything can be justified as an experiment. Discipline-oriented cultures select experiments carefully on the basis of their potential learning value, and they design them rigorously to yield as much information as possible relative to the costs.
We couldn’t just start replacing old code with new code willy-nilly; without some type of structure to keep the old and new code separate, they’d end up getting hopelessly tangled together and we’d never have our modern codebase. To solve this problem, we introduced a few rules and functions in a concept called legacy-interop:
We’ve repurposed the idea of a technology tree, popular in many strategy video games, and used that as a vehicle to communicate the Up product roadmap.
There are three types of product features, a seasoned head of product told me recently. MMRs, neutralizers, and differentiators. MMRs are minimum market requirements; basic features that every customer expects and demands. Neutralizers mitigate competitive threat. Differentiators are your startup’s competitive advantage.
It’s not that new technology should never be introduced, but it should be done with rational defensiveness, and with a critical eye in how it’ll fit into an evolving (and hopefully ever-improving) architecture.
I’m very fond of Erlang creator Mike Williams point: “If you don’t make experiments before starting a project, then your whole project will be an experiment”
The purpose of a self-imposed deadline is to sharpen the edge of your prioritization sword and stake a flag of coordination for the team. It’s not a hill to die on. It’s not a justification for weeks of death marching. It’s a voluntary constraint on scope.
Facebook’s struggle pivoting to mobile illustrates the potential for trouble. Facebook’s speedy, individualistic and iterative way of designing and shipping software was deeply embedded in product team culture. If you worked in the web tier, the cost of releasing was pretty close to zero and literally everything else about the way you worked was optimized to take advantage of that assumption. As the company’s focus shifted to native mobile apps, the engineers hired for their mobile expertise insisted on a heretofore unknown process like feature and UI freeze, functional specs and QA.
The best — maybe the only?— real, direct measure of “innovation” is change in human behaviour. In fact, it is useful to take this way of thinking as definitional: innovation is the sum of change across the whole system, not a thing which causes a change in how people behave. No small innovation ever caused a large shift in how people spend their time and no large one has ever failed to do so.
Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don’t say you did something, provide a URL that proves it.