The two simple questions to ask before adding a new process

I frequently meet with founders who feel overwhelmed. They have become the bottleneck of countless decisions and notice important tasks falling through the cracks. They know they need structure to stay on track but have a knee-jerk negative reaction to adding processes.

But the right processes, implemented at the right time, are critical to maintaining velocity and sanity as you scale. Asking yourself two simple questions can help you implement the minimal amount of process to keep you nimble and organized.

Question 1: What's the objective of this process?

When someone suggests a new process, ask: What is the objective? Broadly speaking, processes fall into two categories: Risk mitigation processes prevent mistakes or catch errors before they cause damage, often through additional checks or approvals. Enablement processes remove barriers, eliminate distractions, or provide structure to help the team move faster, often through streamlined coordination or communications.

You shouldn't tolerate repeated mistakes but beware of the impulse to gate everything behind the risk mitigation process. Very few risks are worth a new process, yet in my experience, most processes at larger organizations aim to reduce risk rather than enable velocity.

You should always size and segment risk mitigation processes: Take the time to assess the true cost of the risk you're trying to mitigate. You might be surprised that even seemingly severe events have a relatively low financial impact. In a previous role, we discovered that a risk we were addressing only cost us a few thousand dollars per month. In such cases, you may choose to accept the risk rather than implement a costly, time-consuming process to mitigate it.

Second, segment your process: Effective risk mitigation processes have fast-track options for low-risk situations. While it can be challenging to determine which cases require the full risk mitigation process, it's often easier to identify scenarios that pose minimal risk - define those cases and build fast-track exceptions.

Finally, ensure that every risk mitigation step has bounds. For example, if you add a required approval, set a specific timeline (e.g., 24 hours), after which the request is automatically approved if no action is taken. Risk mitigation processes without well-defined boundaries will grind your velocity to a halt.

Question 2: Is the underlying activity already happening?

If teams are already performing the underlying activity inconsistently or in a disorganized manner, that's usually a strong signal that it's time to formalize the workflow into a repeatable process. But if the underlying activity is not happening today, a process is unlikely to enable the team.

For example, at nearly every scaling B2B company I've been involved with, the sales/eng feedback loop started out as a direct connection - sales reps ping engineers for feature requests and technical questions. This direct communication is great in the early days, but as the company grows, it quickly becomes distracting and chaotic. Implementing a simple intake process, like a form or sheet where reps can log requests for a weekly review, can channel the existing communication into a structured flow.

On the flip side, let's say you want your team to think more strategically. Mandating a "vision process" with required steps for each team is unlikely to spark strategic thinking if it's not already happening. The process rarely creates the underlying behavior; it often adds unnecessary bureaucracy and overhead.

To encourage specific activities, focus on incentives over process. Frustrated analysts will tell you that a lack of dashboards or instrumentation isn't the root cause of product teams neglecting metrics. The real issue is rooted in incentives. While a weekly metrics review can force action & accountability to numbers, it is the direct executive engagement that drives the action, not the meeting itself. The evidence speaks for itself: engaged executives can drive metrics accountability without a formal meeting, whereas a meeting without genuine executive involvement is usually just a ceremonial waste of time.

Processes are a lot like salt. The right amount at the right time makes everything better. But pour on too much too early, and you'll ruin the dish.

Watch out for process creep, where risk mitigation measures get tacked onto an enablement process. Product requirement docs (PRDs) are prone to this trap. The goal of PRDs is noble: get everyone aligned on what’s shipping and why. However, as a central point of product development, PRDs often attract risk mitigation mechanisms.

It might start with a suggestion to run the PRD by localization to ensure international viability. Then, someone suggests a section for customer support to outline training needs. Next, sales want a pre-launch FAQ to help field customer questions. Suddenly, your PRD has ballooned to 27 sections and needs five approvals before a single line of code is written. The once-streamlined process has become a bureaucratic nightmare.

To avoid this, assess each risk mitigation add-on as its own process and apply the sizing and segmentation principles. A well-designed PRD process should have limited approvals, and ample fast-track escape hatches to maintain overall velocity.

If you implement a new process, remember it's not set in stone. Continuously evaluate what's working and what's not. The best processes evolve as you scale.