Ourmada’s goal is to ship DAO tools.
Ourmada’s goal is to ship DAO tools.
Subscribe to Ourmada
Subscribe to Ourmada
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
I’ve started slowly incorporating elements of working in public at the suggestion of my Co.Lab Fellows sponsored by ArbitrumDAO and RnDAO. It is uncomfortable at times and has been inconsistent, but helpful nonetheless. Writing has always been critical since the early days of Ourmada and it has been powerful to journal the journey. Documenting the process in a public fashion, however, has been difficult and seemingly a distraction. Some recent lessons have compelled me to reflect on what I’ve been learning - and what I need to forget - as a founder.
The following post is about mapping out assumptions and continually returning to them as I build Ourmada, software focused on transparency.
One of the best conversations I’ve had so far has been centered around stack ranking assumptions. In general, stack ranking is a great tool when working on a team where you divide and conquer. When you are on a team by yourself though, this exercise can seem superfluous; I mean what's the point when you are dividing by the number 1. However, in an attempt to become more self-organized, I’ve tried to be deliberate on the key assumptions that need to be true for the current version of Ourmada to be successful.
Question the assumptions to your Assumptions
To get a little meta, I first outlined assumptions in how I should create a list of assumptions. I worked with Lino Velev from ArbitrumDAO Co.Lab to create a framework. It included the following premises when outlining your project’s assumptions:
I’ve started slowly incorporating elements of working in public at the suggestion of my Co.Lab Fellows sponsored by ArbitrumDAO and RnDAO. It is uncomfortable at times and has been inconsistent, but helpful nonetheless. Writing has always been critical since the early days of Ourmada and it has been powerful to journal the journey. Documenting the process in a public fashion, however, has been difficult and seemingly a distraction. Some recent lessons have compelled me to reflect on what I’ve been learning - and what I need to forget - as a founder.
The following post is about mapping out assumptions and continually returning to them as I build Ourmada, software focused on transparency.
One of the best conversations I’ve had so far has been centered around stack ranking assumptions. In general, stack ranking is a great tool when working on a team where you divide and conquer. When you are on a team by yourself though, this exercise can seem superfluous; I mean what's the point when you are dividing by the number 1. However, in an attempt to become more self-organized, I’ve tried to be deliberate on the key assumptions that need to be true for the current version of Ourmada to be successful.
Question the assumptions to your Assumptions
To get a little meta, I first outlined assumptions in how I should create a list of assumptions. I worked with Lino Velev from ArbitrumDAO Co.Lab to create a framework. It included the following premises when outlining your project’s assumptions:
Detailed: The more specific, quantitative, or actionable the assumptions, the more strategic the thinking
Less like this: “Companies want to consistently engage with their customers”
More like this: “Web3 Orgs are spending x hours/week going out of their way to interact with their customer’s comments”
Dimensional: The more dimensions assumptions can be ranked by, the more nuanced an understanding
Less like this: Have one column to rank assumptions like “Importance”
More like this: Add additional columns to rank assumptions such as “Risk Level”, “Difficulty to test”, “Consequences if correctly/incorrectly assumed”,
Divisible: the more group-able the assumptions, the better tests to run
Less like this: Start with the most “important” assumption and go down the list
More like this: Group assumptions that are easiest to test and give it someone who can do it using no-code or easy tools. Or group all your assumptions that will need some product work AND select the single one that is most consequential. The goal is, first, a clear organization to your assumptions and then, second, divide and conquer to test them.
These meta assumptions can be proven wrong too and I am sure my thought process is not comprehensive - this is kind of the point of the exercise. If I write another set of posts, talk to better founders, or get feedback from this post, then I have more content that will refine - or in some cases abandon - what I have listed above. Having a framework for your process will help you reiterate on this process which is a critical skill for any founder.
Follow an Order of Operations
There are books written about this topic and many exercises that result from defining your assumption. The most direct one is Challenge Your Assumptions, Change Your World: Introducing the Assumption! By Andy Cohen. This book is good for embracing uncertainty in the grand scheme of life, but probably not so good for the entrepreneur who is trying to hone in on their core value proposition to customers.
Another great one comes to mind - The Mom Test: The Lean Startup by Rob Fitzpatrick This book is great for conducting conversations about your startup idea and product, but may not help you if you don’t fully understand the core truths underlying your business. Questioning your assumptions will guide your customer interviews and allow customers independently validate or refute any of your identified assumptions.
Additionally, The Lean Startup by Eric Ries first popularized this concept of testing your assumptions and making Minimum Viable Products. MVPs are 100% part of the startup process and it makes sense to write code in a quick and iterable way that tests your core truths. However, most of the time, tests for your assumptions ≠ writing code for an MVP. In many ways, questioning your assumptions is the precursor to code. Yes, for some of your assumptions, a full blown MVP would help. At the same time, you don’t need code for all of your assumptions because a no-code splash page wait list, a couple of hours of market research, interviews with budget managers, or other Ops hacks can confirm or refute assumptions without having to spend precious development time.
I don't know which startup book founders should follow if there even is one. Personally, I tend to go by the YC mantra “write code, talk to users” which is pithy but powerful. Regardless of what advice is best, I’m finding that questioning assumptions should be pretty early in the order of operations.
Do it quickly, and return to it frequently
Just like anything, balance is the key to this exercise. Spending hours detailing and classifying your assumptions is probably overkill. Spending 30 mins of focused time on being decisive and comprehensive should do the trick here.
It may be tempting to map every potential reality that your startup may encounter and have a white boarding session about strategy, but try not to get ahead of yourself. It may be equally tempting to give in to our fragmented schedule and just jot down assumptions on the back of a napkin while in a taxi en route to some industry event, but this is not a good spot for shallow work. There may not be an optimal amount of time spent on questioning assumptions, but it is probably a mistake to build a foundation off either extreme.
I posit that 30 mins for an initial session and 15 mins once a week thereafter should get you good value. Frankly, it is up to you if you run it scientifically or if you want to treat it as an art. Really depends on your product and your team’s style. However, there is a risk to not explicitly mapping out what your company needs to be true for your idea to take off. Not doing so could possibly cost you months of failed sales cycles or thousands of hours on shipping code that never applies to your core value proposition. The math isn’t exact but it should be compelling to map it out.
Detailed: The more specific, quantitative, or actionable the assumptions, the more strategic the thinking
Less like this: “Companies want to consistently engage with their customers”
More like this: “Web3 Orgs are spending x hours/week going out of their way to interact with their customer’s comments”
Dimensional: The more dimensions assumptions can be ranked by, the more nuanced an understanding
Less like this: Have one column to rank assumptions like “Importance”
More like this: Add additional columns to rank assumptions such as “Risk Level”, “Difficulty to test”, “Consequences if correctly/incorrectly assumed”,
Divisible: the more group-able the assumptions, the better tests to run
Less like this: Start with the most “important” assumption and go down the list
More like this: Group assumptions that are easiest to test and give it someone who can do it using no-code or easy tools. Or group all your assumptions that will need some product work AND select the single one that is most consequential. The goal is, first, a clear organization to your assumptions and then, second, divide and conquer to test them.
These meta assumptions can be proven wrong too and I am sure my thought process is not comprehensive - this is kind of the point of the exercise. If I write another set of posts, talk to better founders, or get feedback from this post, then I have more content that will refine - or in some cases abandon - what I have listed above. Having a framework for your process will help you reiterate on this process which is a critical skill for any founder.
Follow an Order of Operations
There are books written about this topic and many exercises that result from defining your assumption. The most direct one is Challenge Your Assumptions, Change Your World: Introducing the Assumption! By Andy Cohen. This book is good for embracing uncertainty in the grand scheme of life, but probably not so good for the entrepreneur who is trying to hone in on their core value proposition to customers.
Another great one comes to mind - The Mom Test: The Lean Startup by Rob Fitzpatrick This book is great for conducting conversations about your startup idea and product, but may not help you if you don’t fully understand the core truths underlying your business. Questioning your assumptions will guide your customer interviews and allow customers independently validate or refute any of your identified assumptions.
Additionally, The Lean Startup by Eric Ries first popularized this concept of testing your assumptions and making Minimum Viable Products. MVPs are 100% part of the startup process and it makes sense to write code in a quick and iterable way that tests your core truths. However, most of the time, tests for your assumptions ≠ writing code for an MVP. In many ways, questioning your assumptions is the precursor to code. Yes, for some of your assumptions, a full blown MVP would help. At the same time, you don’t need code for all of your assumptions because a no-code splash page wait list, a couple of hours of market research, interviews with budget managers, or other Ops hacks can confirm or refute assumptions without having to spend precious development time.
I don't know which startup book founders should follow if there even is one. Personally, I tend to go by the YC mantra “write code, talk to users” which is pithy but powerful. Regardless of what advice is best, I’m finding that questioning assumptions should be pretty early in the order of operations.
Do it quickly, and return to it frequently
Just like anything, balance is the key to this exercise. Spending hours detailing and classifying your assumptions is probably overkill. Spending 30 mins of focused time on being decisive and comprehensive should do the trick here.
It may be tempting to map every potential reality that your startup may encounter and have a white boarding session about strategy, but try not to get ahead of yourself. It may be equally tempting to give in to our fragmented schedule and just jot down assumptions on the back of a napkin while in a taxi en route to some industry event, but this is not a good spot for shallow work. There may not be an optimal amount of time spent on questioning assumptions, but it is probably a mistake to build a foundation off either extreme.
I posit that 30 mins for an initial session and 15 mins once a week thereafter should get you good value. Frankly, it is up to you if you run it scientifically or if you want to treat it as an art. Really depends on your product and your team’s style. However, there is a risk to not explicitly mapping out what your company needs to be true for your idea to take off. Not doing so could possibly cost you months of failed sales cycles or thousands of hours on shipping code that never applies to your core value proposition. The math isn’t exact but it should be compelling to map it out.
No activity yet