The independent thinker's guide to product process

process is an opiate

Pae White, Smoke Knows, 2009

Process is an opiate. It is not a cure for your organization’s problems, but a way to dull your organization’s specific pain. Founders and leaders sometimes think that process can solve a deterioration of quality and creativity within their organization. Those problems have their own, different solutions. Instead, the process should be directly in response to alleviating the specific pain that a scaling organization feels. 

All stagnant organizations are alike; each scaling organization experiences scale in its own way. Because the pain is fairly unique, the process should be too. I saw this when I tried to copy the product development process from Stripe to Watershed. Like any good product leader, I knew that I needed a process to keep the fast-growing team moving in the same direction. But what I failed to realize was that Stripe’s problems were wildly different from Watershed’s – the pain of building something for developers in a competitive market was very different from the problem of sales coordination in a nascent market. We wore the wrong process, like an ill-fitting garment, for a couple months. I then realized it was solving the wrong problem. Instead of cargo-culting something from my past, I’d need to carefully interrogate the organization’s pain points. 

For a dynamic software company, the right type of “pain points” to address with processes are coordination and context problems. As the organization scales, it’s harder and harder for everyone to know what they’re doing in the context of the broader organization’s goals and vision – the founders included. Everything’s changing, people are doing lots of work in all different places in the organization, and keeping everyone in the loop is a constant effort. When you start looking for this type of problem, you’ll find that most things are coordination and context problems in disguise. Worried about your product quality and think that people are building garbage for customers? It’s likely that nobody has context about your product quality bar. Feel like everyone’s shipping risky products that don’t acknowledge the potential for fraud and security vulnerabilities? Clearly there’s a coordination issue between your risk and product teams. Is sales selling stuff that’s off the roadmap? That’s a rats’ nest of context and coordination problems, starting with “have you properly told them what’s on the roadmap?”

An important word of caution while implementing “process”: one of its typical side effects is standardization. In some ways, that’s a good thing – by reducing variance, you’ll reduce the potential for catastrophic disasters. However, this standardization also limits the best teams from acting in aberrant ways. If you put processes in all the wrong places, it’ll cap your upside as a company. My advice is to grit your teeth and bear the pain wherever upside is important, and use the process as a catastrophic-downside mitigation tool. 

When I originally set out to write this piece, I thought I’d provide examples of others’ product processes, but I realized there’s a lot available already on the Internet. Then, I thought I’d provide my own, prescriptive guide and template instead. But I realized that 1) I’d already done that (!) while on this podcast right here and 2) I don’t want people to copy the process without thinking about its applicability to their company – that’s falling into the same trap I just warned against. Instead, here’s my take on guidelines for the independent thinker. It’s the right accompaniment to the great examples of product review processes (like this one from

Lenny Rachitsky

, this one, and really anything that Shishir at Coda publishes!) and check whether it makes sense for your team. 

Good product process stems from a company-specific set of goals. For example, my friend MLM recognized that Notion’s value is in its integrated whole of features seamlessly working together. Therefore, the product process was directly focused on solving those problems, with synchronous meetings where leaders would ask questions like, “Have you considered how this works with the next part of the flow?” or “You and [other team] are both doing X, have you considered a higher level abstraction for both of you to use?” Bad product processes, on the other hand, are copied from others without a thoughtful examination of company-specific problems. If your product needs a specific type of AI-researcher brainstorm, do that! Don’t copy what other companies do willy nilly.

Good product process is based on norms, not rules. Rules are brittle. At a startup or fast-growing firm, as soon as you set them, they’ll break because the organization is now fundamentally different. Norms, in contrast, are resilient and flexible. They encourage agency on the part of the individual, and don’t have to be set tops-down. For example, if there’s a norm of cross-functional “bug bashes” and runbook creation prior to launch, you don’t need to set up an annoying “product launch process” rule that requires bringing a ritual sacrifice to the door of every stakeholder team. Bad product processes treat employees like children, with silly rules and checkboxes for every launch that assume developing software products is a rote task like warming up a cake at the Cheesecake Factory. 

Good product process is founded in legible principles. Product principles are a great way of sharing opinionated context across the company. They’re primarily useful in cases where a reasonable person could plausibly do the opposite of what the principle recommends. As my wise friend

Sam Gerstenzang

said to me, “A principle is not a principle when it is not used to make hard decisions – it’s just a weakly held belief. A good test of a principle is that it should make someone grimace.”

A good principle:

• Tells us what we will not do, when a reasonable person would plausibly do the opposite.

  • It sounds very nice to say something should be frictionless. Who wants friction? Less friction is better. Obviously. But what will we sacrifice for it? Will we make the feature less powerful? Will there be some users who want more friction in exchange for more customizability – and we won’t serve those users?

• Is written from the perspective of the user, not from the internal company-centric view. 

  • If we define principles inside-out rather than outside-in, we’ll design products that are functions of their own constraints rather than our users’ needs.

• Is illustrated with practical examples.

  • A good principle says “an Estonian software maker should be able to sell their software online in the native currency and preferred payment method of the buyer.” A bad principle says “all payment methods should be available everywhere” and leaves it at that.

• Is specific:

  • A bad principle is a broad platitude that sounds like marketing speak. A good principle is relevant to a specific area of the business and aligned with its mission and vision.

Principles help teams make decisions on their own and avoid unnecessary synchronous processes wherever possible. Principles make lots of things legible — the company bar for product quality, the important strategies, and the things that matter (e.g. compliance risks.) Organizations need to articulate both principles and process and show that the process leads to the team upholding the principles​​.Bad process is quixotic, painfully synchronous, and at the whim of the leader in charge. Teams being surprised “in the room” should be a rarity. 

Good product process pushes transparency amongst decisionmakers. As the company gets bigger, it’s harder to know what everyone’s up to. Being more transparent about the product process makes the company feel smaller and empowers more people to take action. At Notion, MLM sent out product review notes and critiques to the entire product organization despite some protest. The context sharing, however, is always worth the cost. Sharing context allows teams to be right more often and “radiate intent” – that is, move deliberately in the direction they’d like to head in while still giving enough signal about what they intend to do. In contrast, bad product process feels secretive and bureaucratic.

Good product process is not a bear sticky with honey. Sometimes, being directive is unavoidable – there’s an urgent issue, priorities have suddenly changed, or there’s just a lot of clarity in a founder’s very specific vision. In those cases, a good product process makes the directive feedback very clear, easily distinguishable from other types of feedback, and actionable. Even though being directive is 1) in direct contrast with the “norms not rules” principle and 2) perhaps an override of the team’s interpretation of principles, it becomes necessary when your team is junior or too used to directive feedback. I love to use Jackie Bavaro’s “Do, Try, Consider” framework to make this happen. Bad product processes are super indirect and ambiguous. In those cases, the classic failure mode will be the “last minute executive swoop in,” where the exec will derail everything last minute. The other issue is the sheep-like team who misinterprets everything the execs say as directive feedback. 

Good product process benefits the team. Process should be useful for everyone involved and pushed in both directions: it isn’t a top-down thing, nor exclusively bottom-up. The process should allow the team to get clarity and feedback on cohesiveness and success, while leadership should be able to get into the details and obtain clarity on all of the “why” questions they’d like to ask. As a result, this process is a two way street. In contrast, bad product process has a hidden motive and feels tops-down, a crutch for a suspicious leadership team who doesn’t trust their employees and feels like they need to get involved in contrived ways. Bad product process feels like it’s solely benefitting leadership instead of being mutually beneficial. 

Good product process is primarily about alignment on the problem area. The LinkedIn cofounders would tell my friend Carl Cummings that a team shouldn’t leave an executive review without ensuring everyone was thinking about the problem the same way. Bad product process tries to use executive review as a type of QA, which makes everything slow and encourages teams to hide the real work they’re doing. If your teams can’t ship quality product, you have the wrong team composition.

Good product process makes decisions by using the right kind of evidence. Consumer companies often need quantitative experiments/data on a prototype. Enterprise-driven companies need in-flight sales deals and revenue commitments. Companies that straddle independent users and enterprises (like Stripe, for example) usually need a strong hypothesis and qualitative user research. This can be cultural and related to the stage of the company, but is largely the right heuristic. Bad product processes mistake one type of company for another and give the wrong sort of evidence for the company’s needs. 

Some of these principles conflict. “You say that good product process is about alignment on the problem area and not nitpicking solutions, yet you also say to be directive – what gives?!” The way to navigate this tension is to think very intentionally about two things – the nature of the business model, and the nature of the team in question. For example, Ivan from Notion and MLM spoke about the Stripe model of product review and how that didn’t apply at Notion, because Stripe’s product suite was more decomposable than Notion’s, and the PM team at the time at Notion came from very structured PM organizations.

If the team needs structure (maybe they’re junior), if the organization is especially information siloed, or the upside in a particular opportunity is pretty minimal, you should err on the side of directiveness.

This, however, is the entire art of applying these principles and where the complexity lies. If you want to talk through this at any point, I’d be happy to advise.

Special thanks to Michael Manapat and Carl Cummings for all of their help in drafting this post.