In product development, you can orient a team toward process or practice. Process is about repeatability, scalability, efficiency, execution. Practice is about creativity, inventiveness, searching for solutions.

Choosing between them isn’t purely zero-sum (like more practice = worse process), but there’s a natural tension between the two. And as with most ideas, the right approach varies depending on your product, your stage, your team, your timing. In general, you’re looking for a balance.

I heard about this concept on a recent episode of the Circuit Breaker podcast, with Bob Moesta and Greg Engle. A recommended listen.

In the discussion Bob mentions his experiences in Japan, and how the Japanese see process differently than we do here in the US:

A lot of this for me roots back to some of the early work I did in Japan around process. The interesting part is the difference between the way the Japanese talked about process was around the boundaries by which you have control.

The boundaries of the process basically say that you have responsibility and authority to change things inside that process, and that it was more about continuous improvement, changing, and realizing you know there’s always a way to make it better, but here are the boundaries. When it got translated over to the US, it got turned into “best practices” — to building a process and defining the steps. “These are ways to do it. I don’t want you to think. Stop thinking and just do the process and it works.” And so what happens is that most people equate making a process to not thinking and “just following the steps”. And so that’s where I think there’s this big difference is that at some point time there’s always got to be some deeper thinking inside the process.

Process assumes there’s a linearity to problem-solving — you program the steps in sequence: do step 1, do step 2, do step 3. At a certain stage of maturity, work benefits from this sort of superstructure. Once you’ve nailed the product’s effectiveness (it solves a known problem well), it’s time to swing the other way and start working out a process to bring down costs, speed things up, and optimize.

So what happens when a team over-indexes on process when they should be in creative practice mode?

A key indicator that it’s “practice time” is when you’ve got more unknowns than knowns. When there are still more unanswered questions than answered ones and you try to impose a programmatic process, people get confused and feel trapped. If you start to impose a linear process before it’s time, your team will grind to a halt and (very slowly) deliver a product that won’t solve user problems.

Too much process (or too early process) means you don’t leave room for the creative thinking required to answer the unanswered.

Legendary engineer and management consultant W. Edwards Deming had a saying about process:

“If you can’t describe what you do as a process, then you don’t know what you’re doing.”

But I love that Moesta calls this out, which I agree with. The quip overstates the value of process:

“But that doesn’t mean that if we can describe it as a process that we know what we’re doing. We can have a process and it doesn’t work!

The best position for the process ↔ practice pendulum is a function of your need at a point in time, and the maturity of your particular product (or feature, or function). In general the earlier you are on a given path, the less you should be concerned with process. You need the divergent-thinking creativity to search the problem space. You’re in “solve for unknowns” mode. In contrast, later on once you’ve solved for more of the unknowns and have confidence in your chosen direction, it’s beneficial to create repeatability, to shore up your ability to execute reliably. At that point it’s time to converge on executing, not to keep diverging into new territory.

Back to Bob’s point about process meaning “no thinking inside the process”, perhaps we could contrast process and practice by the size of the boundaries inside which we can be divergent and experimental. When we need to converge on scalability and consistency we don’t want to eliminate all thinking, just shrink down the confines of creativity. Even at this point in a mature cycle, the team will still encounter problems that we need them to think creatively to navigate — but the range of options should be limited (e.g. they can’t “start over”). When our problem space is still rife with unanswered questions, we want a pretty expansive space to wander in search of answers. If our problem space is defined by having Hard Edges and a Soft Middle, at different stages of our work we should size that circle according to how much divergence or convergence we need.

All this isn’t to say that during the creative, divergent thinking period that you should have an unbounded lack of structure to how you conduct the work. Perhaps it’s better to say that at this stage you want to define principles to follow that give you the degrees of freedom you need to explore the solution space.