The importance of process/team fit

Why process is more important than product and how to iterate on process.

At SharpestMinds, we value habits over goals. Goals are fleeting—once you accomplish them, you need new ones. Good habits, done consistently, will deliver value forever. We try and apply the same attitude to our business: process before product.

Product is essential to the success of a startup. If you don’t build something people want, you won’t survive. You can get lucky and build an excellent product on day one. But, typically, you’ll have to iterate several times before you reach product/market fit. This implies some minimum dose of process to guide that iteration.

The Lean Startup framework describes the ideal process to find product/market fit at a high level of abstraction: build, measure, learn.

Implementing this framework in practice, however, is another story. Each step in the loop above requires it’s own processes. You need to determine what to build and how to build it. What to measure and how to measure it. How to source and shape ideas. How to deal with maintenance costs and technical debt.

Process defines how the team communicates, makes decisions, settles disputes, and gets work done. Process is built on top of tools, rules, and conventions.

Bad process introduces bottlenecks and bureaucracy and will slow you down. Good process will remove bottlenecks and increase productivity.

But there is no right way to do things. The best processes will depend heavily on the people involved—on their habits, communication styles, work styles, and preferences.

Just like you want to find product/market fit. You also want to find process/team fit. Both require continuous experimentation, and the latter is more important. Markets can change fast, and product will have to keep up. A good process is more sustainable than a good product because it provides a framework for iterating on product as markets change and users get more demanding.

But just like product, process can’t be set and forget. What works for a team of three people probably won’t work for ten, or fifty, and so on. Every new addition means process/team fit must be rediscovered.

How to find process/team fit

You don’t need a new framework. Treat your internal processes like products and apply the Lean Startup loop—build, measure, learn. Though try might be a better word than build in most cases. Try a new process, measure it’s effectiveness, learn from it and adjust.

Measurement can be tricky. Chances are you already have some processes in place, so the loop should start here. You want to measure how the current processes are affecting the team’s productivity.

There may be quantitative things you can measure. For developing software, this might be how often you deploy to production, or how many bug fixes are required on any given week.

But most of the measurement will have to be qualitative. How does the team feel about the current process? Do meetings leave them drained? Do they feel like their time is being wasted? To catch these, schedule time for retrospection and feedback.

At SharpestMinds, we keep the end of every meeting reserved for feedback. What went well? What should we change? This meta-process has helped us arrive at very efficient meeting practices (I wrote about our approach to meetings in a previous Index).

We also have a retrospective at the end of every development cycle to reflect not only on what we just build, but on how we built it. How did our current process fair? Where did we fail, where were the bottlenecks. Are there any changes we can make to our processes?

Product is never done. Especially for software companies, constant iteration is the name of the game. The same should be true of process. We try to encourage trying new things by emphasising that every process change is an experiment. If someone on the team thinks a change in process will increase productivity, then it’s worth trying. Worst case, we revert to our previous process, having learned something about how the team works.

Of course, with both product and process, there is an exploration/exploitation tradeoff. When things are working well, you want to bias towards exploitation—if it aint broke, don’t fix it. When things are not working well, explore other options.

But, without making time for retrospection and feedback, it’s possible to not realize when things are not working well. Perhaps you love the project management tool you are using, but others on the team struggle to fit it in their workflow. That’s no good.

Remember, you want process/team fit. Everyone should be on board. Always be open to feedback. Always be open to experimentation. Exploit what works, but never turn exploration down to zero. There’s always room to improve process.

- Russell