An SVPG Process?

Recently I’ve been sharing more publicly my growing concern about product organizations’ increasing focus on heavyweight processes and process people.  

This isn’t a new phenomenon, but it does seem to come and go in waves over the years.

I understand the appeal, especially in organizations struggling with scale.

One consequence of my efforts to shine a light on this problem is that I’m often asked something along the lines of “what about the SVPG process?” (or “the INSPIRED process” or “the EMPOWERED process”, or yikes, “the Marty Cagan process”)?

In this article I wanted to clarify this because I do consider it important to how good product teams think about the role of process.

I did try to address this in an earlier article describing the difference between processes and conceptual models.  But that article is probably too wonky for people that aren’t product coaches.

So I want to take another pass at this.

First, it’s important to acknowledge that at some level, nearly everything is a process.  

When you make dinner you are following a process.  When you run a user test you’re following a process.  When you write software implementing a new feature you’re following a process.

In fact, in the book INSPIRED, I structure the book around four major concepts: people, product, process and culture.  But the section on process is actually a set of techniques that are helpful in specific cases, depending on the problem you’re facing at the moment.  

At the time I wrote the book, the term “process” didn’t have the baggage associated with it that it does now.

Second, it’s also important to remind everyone that the things we (SVPG) write about and advocate are not things we invented ourselves.  They are simply the practices and techniques we observe being used in the best product teams and product companies.

It is true that because companies often refer to their practices by different terms, and because their favorite techniques are sometimes tangled up with their unique cultures, we occasionally need to introduce a term to describe the concept in a neutral way.  

That’s the origin for the term “product discovery.”  But it’s similar for the terms feature teams and empowered product teams, delivery manager and a handful of others.

Third, there are of course many different discovery processes, just as there are many different delivery processes.  Just as there are many different software engineering processes, and many different software testing processes.  

Discovery and delivery are just two activities going on in parallel.  Just as software engineering and software testing are two activities usually going on in parallel.

So hopefully it’s clear that there is no specific SVPG process.  Instead, we’re trying to convey a set of principles and a mindset for attacking tough problems, and we’re trying to share the tools and techniques that can be helpful in figuring out a good solution.