A nicely laid out story of how we got where we are in software product design.

Lea Verou:

Treat user effort as a currency. To create a product users love, design the tradeoff curve of use case complexity to user effort with the same care you design your pricing scheme.

…

Incremental user effort cost should be proportional to incremental value gained.

Catherine Wu (via Sachin Rekhi):

Step 1: Idea → Prototype Got a feature idea? Skip the spec. Build a working prototype using Claude Code instead.

Step 2: Internal Launch Ship that prototype to all Anthropic engineers immediately. No polish required—just functionality.

Step 3: Watch & Listen Track usage religiously. Collect feedback actively. Let real behavior, not opinions, guide decisions.

Step 4: Data-Driven Prioritization

• High usage + positive feedback → roadmap priority
• Low engagement or complaints → back to iteration

I’m increasingly of the opinion that focusing on prototypes first cuts through a lot of what ails many product development processes.

Ben Khun:

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.

Folks often want to know the cost of implementing an idea.

Estimating that cost is work too and we need to surface that cost.

Ryan Singer:

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.

To help us to eliminate (not forever, but for the purpose of making a decision now) I’ve found one technique very helpful. The trick is to flip things around. Instead of describing the good that will happen by doing an idea, we look at what goes wrong when we don’t do it. To make that flip, we can ask two simple questions:

1. Knowing the customer can’t do what’s in the idea today, What are they doing instead?
2. What’s bad about that?

Tara Seshan:

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.

But when I started managing, I finally understood why I had been so ineffective at it. Sitting on the other side of the table, I watched others make the same mistakes I had. I realized I hadn’t been framing tradeoffs correctly.

Johanna Rothman:

But instead of placating the managers and trying to estimate, consider starting with this question:

How do you plan to use this information?

That might offer you ways to answer the question that does not require any prediction.

Also read part one and part three.

Naomi Nix:

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.’”

Meta went for an engineer-heavy team composition and light weight process to build Threads.

Dan North:

tl;dr

• Model and visualise your value chain.
• Structure the people around the value chain.
• Make all the demand visible, so there is no hidden work. This is key.
• Identify work that will reduce drag and give you more discretionary capacity.
• Decide what you want to invest in, and structure the people around that.
• Repeat every quarter, which is long enough to get work done, and short enough to iterate.

Jason Fried:

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.

Work is mostly mundane. It’s mostly maintenance. It’s mostly local improvement and iteration. Work is mostly… Work. Any innovation is an outlier, nearly a rounding error.

James Stanier:

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.

You reduce uncertainty until the software exists. You reduce uncertainty by doing: prototyping, designing, writing code, and shipping. Each of these actions serve to reduce the uncertainty about what is left to build.

Jason Yip:

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.

Organizational effectiveness in decline or commodity / hygiene capabilities is reducing total cost of ownership.

Anthony Murphy:

Having overlap is deliberate and a good thing. It helps create shared accountability and remove any bottlenecks or single-points of dependencies.

A snapshot of the planning process at Netflix, Mailchimp, Asana, LaunchDarkly, and more.

Casey Winters:

there’s one big thing that needs to change for wartime CPOs I want to cover today, and that is prioritization and evaluation.

Ryan Singer:

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.

…

One of the really frustrating parts of running a business is that many times we just don’t know the answer to “why?”.

Why did churn go up 10%? Why are trial conversions decreasing? Where did all these new users come from? Why is our growth half of what it was last month?

Many of those questions have no answer and trying to find an answer will cause you to rip your hair out.

Marty Cagan:

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.”

…

Great teams are comprised of ordinary people that are empowered and inspired.

…

Truly empowered teams that produce extraordinary results don’t require exceptional hires. They do require people that are competent and not assholes, so they can establish the necessary trust with their teammates and with the rest of the company.

Truly empowered teams also need the business context that comes from the leadership – especially the product vision – and the support of their management, especially ongoing coaching, and then given the opportunity to figure out the best way to solve the problems they have been assigned.

Pat has collected a list of resources for learning about product management.

Gregor Hohpe:

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.

Part one:

• Viewing product development decisions as economic tradeoffs.
• Shifting from deterministic planning models to a stochastic perspective.
• Managing the Fuzzy Front End: the time from opportunity identification to commitment.

Part two:

• Assessing the reserve buoyancy of a project.
• Using loss of safety margin as a leading indicator of project deterioration.
• Becoming more rigorous about how we think about technical debt.

Jonas Downey:

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.

Elisabeth Hendrickson:

What I’ve learned is that if we want things to go fast, a sense of momentum is much more effective than a sense of urgency.

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.

…

When you encounter long lead times, you’re hearing option-on-a-basket thinking. “We need to know what features will be in the release in 8 months so Marketing has time to prepare.” What if product development doesn’t go according to plan? The value of the option on a basket falls to zero. What if the launch doesn’t come off? The value of the option on a basket falls to zero.

Gary P. Pisano:

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:

• old code cannot directly import new code: only new code that has been “exported” for use by the old code is available
• new code cannot directly import old code: only old code that has been “adapted” for use by modern code is available.

The progressive approach to the rebuild is interesting. Especially the rules that enforced how the rewritten parts of the code base could interact with the old code they were ultimately replacing.

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.

It’s effective.

Ryan Singer on the Product Love podcast talking about strategy, design, and outcomes.

Tomasz Tunguz:

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.

…

As the product team talks to customers, they are likely to hear feedback encouraging more investment in MMRs and neutralizers. “Your product is missing this feature. We need this capability that exists in another piece of software in yours.”

…

customers rarely push vendors to further their differentiation. By definition, the unique selling proposition doesn’t exist elsewhere in the market. So advances or improvements to the differentiator may not be obvious to customers.

Brandur Leach:

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.

It suggests improving increasing productive output by continually improving the efficiency of a system even while keeping input the same. I project this onto technology to mean building a stack that scales to more users and more activity while the people and infrastructure supporting it stay fixed.

Jesper Louis Andersen:

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”

If we instead ask about prototyping, then we need a programming language with certain traits. The team is usually small, so we need an expressive language, and we need to address the core kernel of the system in isolation, first. We don’t need a lot of interfacing to foreign systems and in general we won’t care too much if the system we build is fast. Also, we usually won’t need to operate the prototype in production, since it is simply a proof of concept.

There are more interesting points about language design in part one and two of this broad reaching interview.

DHH:

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.

Yes, deadlines are wonderful! They’re the tie-breaker on feature debates. They suck all the excess heat out of the prioritization joust: “Hey, I’d love to get your additional pet feature into the first release, but, you know: THE DEADLINE”.

Jocelyn Goldfein:

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.

Stuart Butterfield:

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.

This is the best definition for an overused term I’ve heard in a while.

The whole piece is an enthralling call to arms to a group of people building a product.

Adam Wiggins:

Make it real

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.

Plenty more great stuff in there.