Knowledge Crunching in Your Startup
Fail fast does not mean you must stupidly fail 1 million times in order to converge to success you fool! Do your due diligence mother fucker!
Fail fast or Build-Measure-Learn are the first mottos anybody who’s heard about the Lean Startup paradigm will attempt to apply when they embark into their first startup. However, it is really mind boggling to see how many founders omit to continuously and thoroughly research their domain, their problem, their potential segment, their competition, etc.
Instead of doing their due diligence like a mother fucker(from now on referred to as DYDDMF), misled founders ignore that an early stage startup is not a small version of a large company, and jump straight into optimizing business processes.
The “Lean” of Lean Startup is not about the lean processes used to build your product or service.
Don’t get too busy building your MVP to the point where you forget to challenge your assumptions. Don’t get ecstatic at the idea of being more efficient at implementing processes similar to those in place in large companies. You will waste precious time and resources implementing a Cargo Cult, or a made-up solution, rather than focusing on what really matters: The quest for insights.
The quest for insights is the name of the game, and this is what Build-Measure-Learn is all about.
In that context, “lean” means hacking the fastest ways to learn and discover a business model that is either innovative or disruptive. To implement that framework, the one critical aspect that needs to be sorted out at the very beginning of your company is to build a team of explorers.
Your startup must be made of Knowledge Crunchers.
The term Knowledge Cruncher originates from a software engineering methodology called Domain Driven Design (aka DDD). The main idea is that a project should start with exploring a problem to define a clear domain model. Defining a meaningful domain model should present complexity in its simplest and most meaningful form, which will then result in a faster feedback loop and better code. Those Knowledge Crunchers will continuously do their due diligence. There are no rules whether they should do it on their own, or together; as long as it leads to a collaborative debriefing where all insights are shared and criticized. That being said, the quality of the Knowledge Crunching is not only measured in terms of individual abilities to research, analyse, and share.
Diversity amongst your Knowledge Crunchers is a killer asset
The debriefing session is where the magic of Knowledge Crunching happens. We’ll talk about how that session can be structured in a minute, but it is important to realize that diversity amongst your Knowledge Crunchers will make the exploration phase more organic, and will also make it converge faster towards hidden insights. The intuition behind that idea is that a diverse set of Knowledge Crunchers will increase the likelihood to represent a population that is similar to your customer segment. At this stage, you have laid out your riskiest assumptions, and gathered a team of diverse Knowledge Crunchers that has started to do their due diligence to challenge those assumptions. So what’s next?
UX design workflow is a great way to conduct a Knowledge Crunching session.
UX designers have been confronted with a very similar challenge to DDD: Taming complexity without simplifying. Indeed, complexity provides power, which means that over-simplifying your domain may strip its power off. What UX designers have been developing for years now is a workflow to help users to solve complicated issues without dealing with complicated interfaces. Explaining the details of a UX design workflow is beyond the scope of this post. Designing a content model for a better UX team is a great example of UX workflow.
Combining the Knowledge Crunching approach from DDD with a UX design workflow is from my experience the most efficient way to continuously do your due diligence as you Build, Measure, and Learn.
Gathering your Knowledge Crunchers to DYDDMF does not mean spending weeks of pure analysis, trying to foresee any possible outcomes of any move possible. It is about collaboratively refining an initial assumption, and making sure that this assumption is not pure ludicrous. This is just another lean step in de-risking your business model, and increasing the focus of the team during each Build-Measure-Learn cycle; one of the core ideas behind the Lean Startup movement.