February 2, 2025
"Fail fast, learn fast," "agile," and "canary deployment" have been buzzwords I heard everyday. Yet, in my experience, truly effective implementations of these principles are rare. Too often, they've been twisted into micro-management tools, stifling initiative and hindering progress. After a decade in the industry, I've reflected on my experiences and distilled a set of rules for implementing these concepts effectively, particularly within small to medium-sized product-driven companies. This is my "Fast Manifesto."
The cornerstone of the Fast methodology is the hypothesis. It's crucial to distinguish between a hypothesis and an objective. This deliberately challenges the traditional approach of market research, perimeter definition, and target objective setting.
An objective is a desired outcome, usually based on some level of assumed knowledge. A hypothesis, on the other hand, acknowledges the "known unknowns." It's a starting point based on a belief, not a certainty. For example, instead of an objective like "Increase campus community engagement by 20%," a hypothesis might be, "Everyone on campus wants to know each other." We believe this to be true, but we don't know it. This distinction is critical. Your journey begins now, with the hypothesis, not after lengthy feasibility reports, polished slide decks, or even a Minimum Viable Product (MVP). The hypothesis itself is the starting gun.

This fundamental shift in thinking has several key implications:
- Embrace Uncertainty: The Fast Methodology recognizes that we rarely have all the answers in advance. It encourages exploration and experimentation in the face of the unknown, abandoning the 12 months planned agenda.
- Focus on Learning: The goal isn't immediate success, but rapid learning. Each experiment must be measurable to whether call it "succeeds" or "fails," provides valuable data that informs the next iteration.
- Iterate Quickly: Short feedback loops are essential for validating or invalidating hypotheses quickly. This requires a culture that embraces experimentation and doesn't punish "failures" as long as they are learning opportunities. This concretely mean that features are facing the users as soon as they are developed alongside many others.
- Small, Focused Experiments: Start small. Avoid the temptation to build a full-fledged product before validating the underlying assumptions. A simple landing page, a quick survey, or even a series of conversations can be enough to gather initial data.
- Data-Driven Decisions: Base decisions on evidence, not gut feeling. Track the results of your experiments carefully and use the data to inform your next steps and sometimes discover the “unknown unknowns”. This requires defining clear metrics upfront that are relevant to the hypothesis being tested.
- Culture of Psychological Safety and Infrastructure: Team members must feel safe to experiment, take risks, and admit mistakes. This requires both a blame-free environment and robust technical infrastructure - including feature flags, monitoring systems, and automated rollback capabilities - to support rapid experimentation while maintaining system stability.
- Continuous Refinement: The Fast methodology is not a one-time process, ditch that scrum pseudo agility, we need kanban all the way. It's a continuous cycle of hypothesis generation, experimentation, learning, and refinement. Regularly revisit your hypotheses and adjust your approach based on what you've learned.
The next step, after defining the hypothesis, is designing an experiment to validate or invalidate it. This is where the principles of agile development and canary deployments come into play. But that's a topic for another article. For now, remember this: Start with the hypothesis. Embrace uncertainty. Vertically integrate your whole process, Focus on learning. And go fast.