In the seven months since we founded NotionTheory, we’ve gotten diverse reactions when we explain our process. For some, we’re the answer to a founder’s prayers. For others, building and launching a product in four weeks is just too good to be true.
After having some variation of this conversation easily 1,000+ times in those seven months, there’s one thing that keeps getting lost in translation, which is actually beneficial for our audience to understand. The four-week MVP is not meant to be a silver bullet for launching your next great app idea. Instead, the four-week MVP is our product deployment philosophy for tackling the new and unique via a systematic, repeatable process. This is a philosophy and process you can adopt.
Anyone, meaning you, could be using this model to hack their way to success at almost anything new. At NotionTheory, we love building products; it’s by far what we’re best at. Helping potential entrepreneurs turn their side-hustle into their livelihood is incredibly gratifying. However, if you peel back the layers on our process, you’ll find a framework that can be applied to every aspect of business (and perhaps even help you find your next life-hack).
This framework forms the foundation for everything we do within the four-week MVP and includes three core tenets: focus, feedback, and discipline. We build these tenets into the experience in a few different ways, but we’re confident that you’ll be able to adapt them to fit your projects as well.
Focus
Anytime you’re setting out to do something new, whether for yourself or your company, the conventional wisdom is to start small. We like that approach, but we believe it does not go far enough.
If you’re coming from the corporate world, how many “pilots” have you participated in that start as a new idea and end up as a test of internal culture and process? How many “proof of concept” projects actually address the critical concerns or uncertainties of a new idea? Even if the answer was 80%, that would be 20% of all new projects that wasted a team’s efforts.
For a startup, the opposite scenario is usually the problem. With no organizational inertia to limit the vision of a founding team, it can be difficult to resist trying to be all things to all customers. The implication of this is more than just scope creep for a startup’s product(s); it makes characterizing the value that any product is creating nearly impossible.
In both cases, we’re a huge fan of Ash Maurya’s Lean Canvas as a tool for honing in on what matters for a new product. We’ve even slimmed his canvas down further to inspire even more focus on essential vs. non-essential considerations. Another useful hack we’ve instituted is scoping all of our projects to 80 hours of development time (with a few exceptions). With only 80 hours of time to build something, we find that it’s hard to build anything extraneous.
Apart from these hacks, the general rule that we’ve come to goes beyond starting small. It really starts with asking yourself what is the most critical component of this concept I’m working on. From there, it’s all about finding ways to make sure you don’t stray from working on just that component.
Feedback
Even after you effectively prioritize components of a new idea or process, how will you know if you’re making progress? More importantly, how will you even know if you’ve prioritized the right components?
When it comes to building products, we think it’s actually a bit easier to set up this feedback loop than in other arenas. We integrate a metrics suite (we love Mixpanel) with every product we build so that our startup clients know what’s working and what isn’t for their users.
But feedback goes deeper than metrics. We scope our projects to a four-week build because we believe four weeks is the maximum amount of time any startup should go before putting an MVP in front of their users. It’s actually less than four weeks when you think about it, since we push our clients to do pre-sales just off the wireframes we create. However, the larger takeaway is this: if you haven’t aligned your entire approach around collecting feedback on those critical components, then you’re missing the mark.
As an example, let’s say you’re implementing a new management structure at your company or for a specific project. The metrics you collect might include time or money saved on the project or perhaps team members’ opinions of the new paradigm. Beyond intuition, how do you know these are the right components to track and prioritize? That’s not an easy question to answer, which is why the approach you use to collect feedback will always be more important than the data you set out to collect.
Generally speaking, this means being steeped in that new process, service, or experience, yourself. In addition, it’s important to consider how often you’ll be checking your progress against any global indicators for success. In our work, that includes beta programs with usability studies, rapid launches, and post-launch check-ins, but we’re positive there are analogs for your work as well.
Discipline
Let’s say, for a moment, you’re building a service-based business (like us!). You’ve honed in on the value assumptions you want to test, and you’ve setup your feedback loop perfectly. Now, the really hard question comes: how will you force yourself to stick to that approach?
Our approach is the fixed-fee, fixed-timeline engagement. Our MVP program costs $12K, flat. Even if we were to get carried away with an idea, we’re held in check by what’s economically viable and the contract terms that we set on the way in. To be fair, we price the service this way because it’s by far what works best for our clients. The incredible byproduct is a program structure that forces us to build laser-focused products that generate value in as many ways as possible: early adopters, market insight, revenue and more.
The underlying principle behind a fixed-fee engagement is one of induced scarcity. We’re surrendering some level of control over the situation (e.g. the ability to bill for time and materials) in order to keep ourselves honest. The key is to engineer an environment where you have just enough of what you need to succeed but not so much that you can get complacent.
Recap
Hopefully, it’s apparent by now that an MVP doesn’t need to be a product, per se. It could just as easily be a new process or a lifestyle habit you’re trying to adopt. It matters less what the new thing you’re trying to do is and more about the approach and process you take to making it happen. For us, the four-week MVP program came out of answering the questions listed below, just in the context building products for startups. I’ve updated them to be a little more general:
- Beyond anything else, what is the one thing–knowledge, consensus, etc. that will help this idea/process/service/product move forward?
- How will I measure the value that one thing is adding? Separate from this one thing, how often will I check my progress against any global measurement of success?
- How will I enforce this level of focus and hold myself accountable to feedback for the duration of the project?
Now, that we’ve gone through all of that, the question really becomes “what’s your four-week MVP?”