minimum viable process
The Overlap #41
The Overlap is a newsletter somewhere between product development and organizational development.
As a reminder, the next issue comes out on May 4th. I’ll be on vacation April 8-23! Very stoked to hike in Patagonia and do some climbing in Colombia.
This one’s on creating just enough process to get the job done well.
Process, process, process.
I think organization designers and product managers can borrow the concept of “minimum viable product” when thinking about process. Let’s call it minimum viable process.
What are the least amount of features we can launch that successfully meet our user’s/business’s need? That’s a minimum viable product.
What is the minimum amount of process we need to create to get the job done in a way that meets our goals? That’s a minimum viable process.
Minimum viable process gets us to take a step back before creating process to solve a problem.
I notice myself creating tons of process when really I should just get the thing done. If I’m behind on my writing schedule, I’ll find myself tinkering with my writing calendar, when I should be sitting my ass down and writing. If I lose my favorite hat, I’ll scramble around my entire living space looking for it, create a checklist of spots I should check, check those spots, add more to the checklist… rather than do nothing and trust my hat will show up when I least expect it.
Many times, process is useful! Think about when you need to make a presentation. You just want to know what typeface, font size, and colors to use. You (most likely) don’t want to have to design the deck’s template as you’re designing the deck.
But other times, process creates more work than it accomplishes. Maybe we’re overreacting to a circumstance that may not happen in the future. Or maybe we’re creating a bandaid solution to solve multiple problems when we instead need to clarify our defaults or separate our concerns. Or maybe we’re turning agile into a rigid process without even knowing it.
A minimum viable process exercise
One exercise you can try with your team. Ask them: which of our meetings are irrelevant? What docs are outdated? What processes do we have written down that we rarely do in practice?
Start a thread for things that can be removed. Once a month with your team, go through each suggested thing and ask “Will removing this meeting/doc/process cause irreversible harm? Does it actually speed us up as a team?” If there are no yeses to both questions, remove that thing!
Don’t create a template until you’ve used it three times
We’ve all created templates that never got used.
These templates come from a good place! Tons of teams are asking you how to do X. So to serve all those teams, you write a single template to accomplish X. But this template isn’t something you’ve actually done, it’s just a way you think it could theoretically work. A team member of yours tries it, and comes back to you with thoughtful questions that you don’t have answers to. You were hoping your template would reduce Slack back and forth, not increase it.
As a founder/org designer/PM, you want your templates to be used! And you want them to actually work.
There’s one practice I love from Matt Lemay in Product Management in Practice that can help here: Don’t create a template until you’ve used it yourself three times. Resist publishing templates that aren’t pressure-tested. Only publish the template once it’s been used three times.
White space helps us realize our intent
Newer org designers tend to add. We need more agile. More process. More product thinking. More workshops.
When I notice myself adding more, I try to remember the concept of white space. Designers use white space to help users focus and realize their intent. Designers build empathy for why the current designs are the way they are, yet they know how to use white space. More white space often means removing existing features, elements, and information.
The same is true for org designers. Org designers develop empathy for why certain processes exist in the first place, yet identify processes that may no longer serve their org. They bravely invite the organization to shed these processes, acknowledging that they’ve served its purpose. They know that this creates the white space for better ways of working to emerge.
More can get in the way of better. Remove first. Then introduce new.
What I’m Reading
I wrote a thing about How garden3D works. As a company that’s gone through tons of change in the past few years, we feel this lesson daily.
Letting go of assumptions and patterns that are no longer serving your org starts with letting go of assumptions and patterns that no longer serve you! My friend and collaborator Kathryn Maloney put this elegantly in her latest essay.
How big tech runs tech projects and the curious absence of scrum. The Pragmatic Engineer is a really great newsletter.
“…I’ve come to the conclusion that improvement is rarely continuous over an extended period of time. Our attempts may be continuous, but the actual improvement is not. In fact, things often get worse—or *need* to get worse—before they get better.” (Read).
See you May 4th,
–Tim