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.

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.

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?

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

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.

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.

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.

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.

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

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:

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.

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:

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.

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.

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.

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”

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.

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.

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.