When do you let go of Process and Accept Controlled Chaos? [Mind the Product]

I’ve worked at two different startups, going from beta to 1.0 as the first non-founding member of the product team. Surprisingly, I had a completely different experience at each startup, even though they were both open source databases. If I were forced to prioritize (as all product managers naturally tend to do) and choose the most important lesson I learned, it’s that it’s not about the process, it’s about the people.

Process is a Safe Place

The concept of “process” is a safe place for product managers. In fact in many companies, product managers double up as project managers, ultimately defining and executing processes that speed up the product development process. The reason why product managers perceive process to be important is because it helps them to scale high-quality product decisions. Typically, there are more than five engineers for each product manager, so product managers need process in order to make sure things don’t fall through the cracks. In fact, I’ve had to work with about 20 engineers in the past, and I have friends and colleagues who tell me about even crazier engineering-to-product management ratios. The only way to juggle multiple features and projects while communicating across multiple teams is to define a process that checks for quality at different stages of the development lifecycle.

Because of the importance of process in product management practice, it’s really easy to think that implementing process when joining a startup is a quick win. The problem is that you can’t shove process down people’s throats – process requires buy-in, and it is incredibly difficult to get buy-in for process when you first join a startup. There are cases where you are explicitly hired to put in process, but this typically happens when a startup is more mature and is less likely to happen if the product management team is still small.

As a more tangible example, when I first joined my current startup, I had a process I was hoping to implement. I was already comfortable with it from my previous company. The process involved bottom-up roadmap planning, feature kick-offs to define acceptance criteria and write user stories, weekly development check-ins, acceptance testing, and ultimately go-to-market if needed. I had templates that I used for each step and the teams I worked with knew when to involve me at different stages of the development cycle. Obviously, I would have loved to bring this process into my current startup, but I quickly realized that the process was too heavyweight for a smaller team.

This became apparent because I would mention certain pain points that I thought could be addressed through process, but the rest of the team didn’t necessarily agree. This was a good signal that any process I wanted to implement would not be met with strong buy-in, thus rendering the process useless. In fact, focusing too much on process right at the start results in two critical consequences: (1) you force a process in place that doesn’t fit the people who make up your new team and (2) you pit yourself against the status quo when you haven’t yet built trust.

But Doesn’t Process Help you Scale?

But giving up on process isn’t really an option, especially since, as we all know, process helps to scale product management. So instead, I decided to step back and focus on what I was trying to achieve rather than the actual process. I knew I needed a way to map out acceptance criteria for user-facing features, so I set up explicit meetings with the engineers working on those features before they started to implement the feature. This was essentially executing a step of the process I needed without forcing the team to buy into it. I also knew that I needed a way to track feature progress, so I created a personal Airtable (love this product) to track feature development status. Rather than asking the engineering team to keep it up-to-date, I started to message engineers every week for a status update so that I could keep things up-to-date myself. I know it sounds like a lot of responsibility for the product manager to manage and track these things, but acting as the glue across teams is essentially a product manager’s job. When the glue (or process) doesn’t yet exist, it falls to the product manager to act as the glue until things start to break and a more heavyweight process is needed.

Just sit Back and Listen

In fact, I would argue that as a product manager joining a new team, the first thing you should focus on is NOT building process. Instead, you should focus on building trust. This means sitting back and listening to both your internal team members as well as your external users, so that you can develop a deep understanding of how your team works internally and how your users think externally.

Internally, this means asking questions, even if they sound stupid, about the product and the engineering process that supports it. Externally, this means taking advantage of every opportunity to get closer to the user. When I joined my current startup, I would troll our support channels and engage with users, join every sales call our Sales team would let me join, and set up meetings with existing users of our product. Only by fully understanding the lifecycle of your product, from development to actual deployment, can you start to build a process that actually fits the unique team you work with.

My advice then to product managers at a new startup is this: stop worrying about process. Startups are chaotic, and things will always be out of control. Instead, find a way to empower the people around you with a perspective founded on user feedback. If and when process becomes important, process is so ingrained in your blood that you’ll be ready to tackle that problem head on!

The post When do you let go of Process and Accept Controlled Chaos? appeared first on Mind the Product.

Source: Mind the Product http://www.mindtheproduct.com/2018/12/when-do-you-let-go-of-process-and-accept-controlled-chaos/