Speed > Process
A process is a series of actions or steps taken in order to achieve a particular end.
All companies have processes — there’d be no sane employees left otherwise — but not all processes are the same:
- Implicit processes mirror general systems or values e.g. collaborating closely with co-workers when building a new feature.
- Required processes keep the lights on e.g. setting up payroll to pay employees or collecting payments from customers.
- Explicit processes solve with precision e.g. asking specific stakeholders to give written approval before launching a feature.
This article is about the last type so please make sure employees keep getting paid!
Friends and coworkers always tell me I’m a process-oriented person, so this article may come as a surprise.
I do love writing up and rolling out SOPs (standard operating procedures). But after spending time at Amazon, a process-laden behemoth, then jumping to Persona, a startup with no product or customers and founders who were seemingly allergic to process, I have a more discerning view on when to throw down process.
Processes inevitably grow as a company grows, but startups should err on the side of too little rather than too much. When you have no idea what you’re doing, moving fast is more important than doing things right.
Some pitfalls I’ve experienced at Persona:
Too early
It’s human nature to bring order to chaos, but chaos can also be the optimal path to experiment and learn quickly. Experiencing the pain in different ways over time unlocks a deeper understanding of why and how that pain is solved. And oftentimes, that particular pain wasn’t the highest priority to solve anyway.
As we closed our first couple customers, we started debating whether to create a sales playbook. But conversations with prospects at the time were more different than similar. We customized our pitch for each prospect (e.g. creating personalized demo videos based on the job function of the decision maker and their use case), and creating a playbook that early would’ve impacted our flexibility and creativity to close a deal by any means possible.
Conflating WHY and HOW
In other words, focusing on a solution instead of understanding the problem. As a PM, this is one of the biggest challenges in multi-month product development. We get distracted and grasp onto specific solutions too tightly while slowly losing sight of the original problem over time.
Every couple months, we have a conversation with the product marketing team about whether it’s time to set up an internal changelog for product launches. It’s an enticing feature but doesn’t address the more fundamental and unanswered question of “how deeply do we expect different internal teams to understand what’s being launched?”.
Maintenance cost
Startups are constantly changing, and maintaining heavy process is a cost startups can’t afford to pay. As every experienced developer knows, “the best code is no code at all”. The cost of maintaining code is always more than planned. So instead, let’s keep learning and collecting information that builds stronger conviction that we’ll solve the right problem in the right way.
Last year, I tried writing a “how-to” guide for a new version of our product. I spent a week fleshing it out, only to spend many more weeks re-writing it when we decided to descope some features we initially committed to. At one point, I realized I was spending more time updating the guide than saving the time of those who were working with the product! Not to mention the added communication tax of constantly announcing new updates to the guide.
Worse, we’re naturally reluctant to abandon existing processes due to loss aversion and sunk cost, opting instead to spend even more precious time trying to fix them. Similarly, newer hires at the startup may assume that the current process exists for a reason and stop questioning whether it truly solves the problem.
Overextending
This one is the real killer! Just because one process works in one company or scenario doesn’t mean it works in another. Don’t just “trust the process”. Be careful when new hires, advisors, investors, and others who may not have insight into the nuances of the company start recommending processes. Every process we have at Persona is heavily inspired by successful previous iterations we’ve seen, but with our unique twists.
We’ve adopted a decentralized roadmap planning process for each product team because they’re in different stages of development. While some products have millions of users, others are looking for their first paying customer. Rather than dictating how each team sets their roadmap, we define the expected outcome of roadmap planning and empower each team to figure out how to get there. Why spend multiple weeks planning a detailed version of the next year’s roadmap when there’s not even a demo-able product? Use that time to build a demo and start selling.
So how might we avoid such pitfalls?
Define the problem
- What’s the problem? A process usually solves for one of either quantity (i.e. scaling efficiently) or quality (i.e. making sure things don’t break). If the former, figure out how much time or money is currently lost. If the latter, figure out why things keep breaking.
- How important is that problem? As an extreme example, the military relies on heavy process because people’s lives are literally on the line. One kink in the system could be catastrophic.
- Are there alternatives? First talk to relevant stakeholders about the problem to develop a shared understanding. Recognizing that there’s a problem is often just as important as trying to implement a solution.
- How likely is the problem to change, and how drastically? If the first customer hasn’t signed yet, don’t create an integration playbook. Once the tenth fintech customer has signed, the overall integration process won’t change much.
Start small
If the problem is worth solving, what’s the lightest-weight process that can be put in place? Expect to iterate constantly and keep those sneaky maintenance costs as low as possible. An old startup adage is relevant here — invest in scale only after finding product market fit.
Revisit the WHY, not just the HOW
When it’s time to update the process, it’s also time to revisit the problem anew. Is it still important to solve? How’s it changed over time? Don’t assume what worked before works now.
To sum up, explicit process is often implemented too early and aggressively, stifling a startup’s most important advantage — speed.
Reflecting on my time at Amazon, I was blinded by the personal satisfaction of creating order but didn’t think critically about the tradeoffs. Now, I’m one of the crazy early hires at Persona who pushes everyone to be more comfortable with ambiguity and embrace the speed of chaos 🤷.
