Problems with Process
Much has been written about things that can kill companies. While this may fall into that category, Paul Graham is a much better source for that.
The problems I’m writing about can exist in startups, but more likely plague medium sized teams, or small teams inside giant organizations. In startups, process is a problem when there is too much of it, or too little; when it is too much the focus, or when it is completely ignored. One reason why there are so many productivity apps is because startups, faced with the failure of their original idea, pivot to make their particular brand of process or workflow into a product.
In startups, at least not the ones that pivot to productivity software, there is often a key driver — some issue the founders face, some unique technology that is being built, or some other reason that the group of people decided to get together and work. When that is the case, process is almost always completely useful. Setting up trello boards, starting asana projects, getting into scrum or agile and doing sprints, whatever it is that helps you get to the finish line of building your solution to the worlds problems. Ideally these processes would involve great user feedback sessions, pre and post mortems, well written user stories, constant iteration, etc. But the great part about small/early stage startups is that process is only a means to an end. It is brought in to do a job, just as the founders and team are building a product to do some job.
When Process Becomes the Product
In medium sized teams, or small teams in large companies, there is rarely that driving force that you see with a small, eager, passionate startup. Perhaps the product is built and didn’t become the next Facebook/Uber, so now the team is trying to figure out what to do next; perhaps there is a grand mission, but the CEO or leadership team has no concrete plans of how to get to the vision; perhaps the team was formed by a smart manager thinking that all of the highest performing employees would work well together. When not everyone on the team is on the same page about why they are there, or what they should be building, you’ve got a problem that process cannot solve.
The problems with process here end up being that there is no big problem to solve. Maybe there are a bunch of small ideas, or two ideas split down the middle. Someone (typically a product manager, but could be anyone) will usually say “we’ve got this great process, lets just run the ideas through it.” If you hear that, run away as fast as you can. Process is great, and maybe you really do have the best process in the world. But no process can discover a great product, only great people can do that.
It takes people, and insight, andproblems to build a great product. If your goal is to simply build a cool new mobile view of your existing product, or the next great SoLoMo photos app, use your process. But if you are trying to figure out what real things to work on next, you need to avoid process like the plague. User interviews are good, sure. Experimentation is great. They are not alternatives to passion, and they cannot tell you what you and your team should be working on.
Always Put the Product First
Look back to the beginnings of every moderately successful company in the history of the world, and you will rarely, if ever find a team of people running A/B test, hosting user interviews, and sending out email surveys. The process isn’t what made them great.
It is difficult to go back to the drawing board. And I’m not saying you can’t bring the ideas you were putting through your process with you. But if you are spending more time talking about your process than your product, then its time to take a break — host an offsite, go spend a day in random coffee shops around your city, do anything that isnt a typical work day — and try to incubate some new ideas.
Then comes the hardest part, especially for medium sized teams: get everyone together, and go through the ideas. Unless you as CEO are willing to fire the whole team and start over, you need everyone to be supportive of, and interested in, the new things you are going to be working on. At this point it is important to be vigilant of process-creep. Don’t let anyone say something is a great idea because it is testable, or because it fits well within the process.
You might need to blow up the process and start over again. That is going to seem hard and painful, and it should be. But it is much less hard and painful than having to close down shop because you eventually ran out of money.
Maybe this post is just a combination of a couple of Paul Grahams ideas (3, 4, 10, and 18 are all strong candidates), but there is something more to it than just that. Lots of things can kill a company; few have the ability both to make things easier, and a lot harder, depending on how you treat them.
