Should You Build It? Use This Framework to Assess Your Product’s Viability
As product people we are primed to test for desirability. However, building a high-demand product is dead in the water if it makes us no money.
Many of us, brave product people, obsess over the problem and build a solution irresistible to users. We’ve been taught to be user-centric and this is exactly what we do: we over-index on building desirable products, which is getting 33% of the job done.
A successful product rests on three legs:
Desirability ✔️
Feasibility
Viability
This is why, we we also need to go beyond the desirable and validate whether our product is feasible and viable.
I’ll skip the feasibility piece for now and focus on how to determine whether something is viable, i.e., worth building.
But hold on. If something solves a real problem, i.e., it is desirable, isn’t it already worth building?
In an ideal world of unlimited resources and unicorns, it is. In the real world, however, products must solve problems for customers and businesses.
Business problems are money problems. At least, that’s what they all come down to. Here’s why: investors and business owners make bets by putting money into businesses. The goal is to get the highest possible payout. So, the ultimate goal of any product is not just to solve a customer problem but to do it in a way that delivers the maximum possible return to the business owners (the shareholders).
No matter how you define business problems, they usually come down to money problems. 97% of the time, business problems are money problems. Since businesses, like us, work with limited resources, the money that comes in has to be higher than the money that goes out. In other words, the business has to be profitable.
This is why viability is a critical piece of building a successful product. In fact, it is so critical that it’s pretty much the only thing your executive team and board are guaranteed to ask about.
So, what is viability, anyway?
One way to describe viability is to equate it to profitability.
Use this definition if you want to piss off your finance friends. We get pernickety about what profit actually means and how we measure it. It’s a rabbit hole for another time.
In any case, viability is more than just the profit, no matter how you define it. Simply put, a business is viable if it is worth the time/money/resources to build it.
Whether something is viable depends on the context and who is asking the question:
Me, considering a side project to help me pay my mortgage: “viable is something that can make me $1,000 a month, while putting in 3-4 hours on the weekends.”
A former boss of mine running $200M portfolio of products: “viable is a business that can generate at least $10M of annual revenue and deliver 15% IRR and has a comparable risk profile.”
A VC investing in early-stage B2B SaaS: “Viable is a $1M investment able to deliver 10x return within 3-5 years.”
Regardless of the context, viability is worth pursuing, given your unique circumstances.
Okay, let’s get to the framework.
The framework is simple. However, the theory can be boring and dry like most finance topics. This is why I’ll walk you through an example.
Several months ago, someone sent me a link to a service that roasts landing pages. For the price of a knock-off Gucci purse, you get a 20-minute video of a gnarly marketing professional walking you through the wins and misses of your landing page. Cheap enough to be considered petty cash, funny enough to be worth your time, and useful enough to justify it in front of Gladys from Accounting.
I loved the idea and wondered if I could do the same. I set up a simple board in Miro and started capturing ideas of what my offering could look like. It didn’t take me long to come up with the following:
Landing page audits solve a painful problem (Desirability)
I have the skills needed to do the job well (Feasibility)
I can make some money (Viability)
I already had some early signals to support my Desirability and Feasibility assumptions. I didn’t feel so confident about the viability, though. I was certain I could make some money, but I didn’t want to waste time on something that would barely buy me a nice dinner.
Step 1: Set financial thresholds
When I worked in private equity, we assessed all investment opportunities against a set of financial metrics like:
Minimum deal size ($)
Maximum deal size ($)
Minimum annual revenue/EBITDA/cash flow ($)
IRR (%)
Business maturity
Vertical
etc.
We didn’t look at deals that didn’t meet our internal financial thresholds. In cases where there were no meaningful forward-looking numbers (e.g., annual revenue, IRR), we assessed how likely it was to reach the threshold metric within a reasonable time.
The threshold metric I had set for myself was $8,600 monthly revenue. Any opportunity to bring in that much gross revenue within the first four months was worth the effort.
$8,600 seemed like a random amount, but it was very deliberate. After taxes and deductions, it was going to give me roughly $4,000 of net income—enough to pay my mortgage and even cover the hydro.
Step 2: Set a deadline to hit the threshold
With unlimited time, any goal is achievable. Since this was not me, I needed to set some time limit for how long it would take to hit my financial metric.
In companies, the finance team builds financial forecasts to assess when the new product will achieve its financial targets. Doing such forecasts for a solo project will earn you some serious finance nerd clout and my deep respect. That’s the extra effort you don’t need to put in, so simply set a clear deadline that tells you when you’ll keep grinding to hit your goal.
You want to avoid product purgatory, where your product never hits its target but churns out just enough cash to keep it around.
For the landing page audit, I decided to set a six-month deadline. By then, the service would have to hit the $8,600 revenue target.
Step 3: Identify the target drivers
Think of how your product will deliver and capture value. Put simply, what will you offer, and how will you make money doing it? Write down the things that will drive revenue and expenses.
For the landing page audit, I identified these drivers:
Revenue:
Price per audit
Number of monthly audits
Expenses:
Hours per audit
Number of hours available in a month
Subscription expenses needed to provide the service
The revenue was price times quantity. The expenses were the hours I spent working on a given audit and administrative expenses. I assumed the admin expenses would be small, so I have ignored them.
Step 4: Set your assumptions for each input value
In the table below, I set values to the key drivers for my service:
The green cells were input values, and the numbers in the white cells were calculations. My logic was as follows:
Price per Audit: A brief competitive analysis showed that similar services were priced around $300. I decided to go with that average but use the sneaky marketing trick of odd pricing, hence $299. The exact number didn’t matter so much as it was within the market’s range.
Hours per Audit: I did a few audits on existing landing pages and timed how long it took me to complete them. I came in under four hours, and with practice, I was confident I could come under.
Work Hours per Week: This was a limiting value set by reality. If I were to do this full-time, I was planning to do 30 hours of audit work per week. This was enough to leave me another 10-15 hours of non-audit work and end up with an average work week of 40-45 hours.
Target Monthly Revenue: This was how much I wanted to make as gross revenue in a month: the target I set above.
Step 5: Set the interdependencies between the inputs and the metrics
You’ll notice I don’t have any input for the number of monthly audits. This is because I have no idea what it will be. Instead, I know that I need to generate $8,600 of monthly revenue at the given price. So I can reverse calculate how many monthly audits I need to have.
The monthly audits are the Target Monthly Revenue divided by the Price per Audit.
But what happens if I increase the price? Then, I need to do fewer audits to achieve the same revenue.
If I increase the price by $100 to $399, I must complete 22 audits to achieve the same target revenue.
What if I go in the opposite direction and reduce the price?
Two things happen:
The number of monthly audits is capped at 30 for the month. This is the same as the Audit Capacity number. The limiter here is Work Hrs per Week, and the driver is the Hours per Audit. I’ve set a formula in the Monthly Audits cell to cap the monthly audits to the Audit Capacity value. If I want to go higher, I have to:
Adjust the Hours per Audit
Work more hours per week
Be okay with making less
I get flagged that I will miss my target revenue at this new price.
Step 6: Assess the risk around each assumption
Each of our model's assumptions is subject to some risk. We will mitigate these risks by identifying and ranking them.
How to think about risk
If our goal is to build a desirable, feasible, and viable product, then we can think of risk as uncertainty around these pillars. In the table above, I’ve assigned a risk type to each assumption. The only purpose is to give some structure to my thinking.
For example, Price per Audit carries risk around desirability. Would the customers (broadly the market) find the product attractive at this price? Knowing that price is a risk related to desirability, I can validate the price by running tests involving my users.
What is risk anyway?
This is how the Merriam-Webster dictionary defines risk:
As it turns out, risk comes down to the probability of things not working out how we want them to. Probability is a statistical measurement of likelihood, which is impractical in everyday life.
People think about risk in two dimensions:
Impact: how badly would it affect me
Knowledge: how much do I know so I can make the right decision
I didn’t care about the Saharan sandstorm last Saturday because it was far away from me. By 8:00 pm, when my wife and I were about to leave for dinner, it had no impact on our lives. Things looked quite differently an hour later when it materialized in a thunderstorm hundreds of kilometres away in Valencia. I still wouldn’t have cared much had I not been caught in it on our way to dinner.
We would have made a different decision if we had known about the coming rain.
So, risk was a function of impact and knowledge. The more impactful an event is, the more we should care about it. The less knowledge we have about it, the less confident we should feel about it.
Take the price in the example above:
Through my calculations, I know price impacts my business pretty heavily. It affects monthly revenue directly and materially. I don’t want to go too high or too low.
But is the price too high or too low? How much do I know about it? I did some research on similar services and found out that they were similarly priced. The knowledge I had collected eliminated some of the risks around price.
I can do the same assessment for all assumptions on my list. In this case, I assigned the lowest impact and knowledge to be 1 and the highest to be 5. The exact numbers don’t matter that much. I don’t have any exact formula to calculate a 4 for knowledge or a 3.67 for impact. Instead, I use the numbers to compare the impact and knowledge ratings across assumptions.
For example, I know that Price per Audit impacts revenue much more than Work Hrs per Week. Respectively, their ratings have to reflect my subjective understanding their impact.
To take the idea of subjectively ranking hypotheses across the dimensions of impact and knowledge, I can put them on a matrix like below:
Looking at the matrix, I can clearly see that the biggest risk is around monthly audits. I have to get 29 monthly audits at my set price, but I have no idea if this is possible. My next step would be to test the demand for my service and confirm if 29 audits is a continuously achievable number.
The lesson learned
Collective product management wisdom tells you that you should always start by validating a new product's desirability. The assumptions around desirability are often the riskiest.
However, a quick assessment of viability can help you determine whether that new product is worth developing.
Secondly, having some sense of the target numbers helps us write better hypotheses about desirability. I couldn’t have known I needed to validate a demand for 29 monthly audits until I did some viability math. Good hypothesis statements are measurable. The target measures we set shouldn’t be random but based on achieving a higher-level goal, e.g., revenue or income target.
Even the most basic financial modelling forces us to think of the key business drivers and make assumptions about them. It also pushes us to exercise a basic form of systems thinking by exploring how these assumptions affect one another and, in turn, the key goals we’ve set for our product.
So, what happened in the end?
I moved on to validate whether I could consistently attract 29 new customers every month. I received strong signals that it wasn’t likely to maintain this kind of volume for a long time.
This business idea failed the viability test. Also, it wasn’t a good strategic fit with my current consulting work in product and finance, so I decided to pass it.