Feasibility: a new way of looking at it

Unpacking the famous 'feasible, desirable and viable'-model, part 1.

In this edition

  • Three tips on assessing the feasibility of your solution

  • A new mindset when to comes to feasibility

Experiment: Watch this newsletter as a video

Watch on YouTube

The written article and 3 content tips (not in the video):

Do you have a good idea?

Most of you either are founders or working closely with founders. A question that pops up here is: Is this startup idea a good idea? It's a very relevant question. Well, what is a good idea? A good idea is likely to succeed. You want to know as soon as possible if your idea has the potential to succeed. How can we check this?

You might have seen this diagram. It's a simple model—by IDEO, a famous design firm—that helps you to check if your idea is any good. They say: to be successful, your solution needs to be feasible, desirable, and viable. This might sound a bit vague. These three words actually are prompts for the following three questions:

  • Feasibility: Can your solution be realized by your team?

  • Desirability: Do people want your solution?

  • Viability: Do you have a profitable, scalable business model for it?

Answering these questions, however, is harder than raising them. In the coming weeks, I will give three crash courses in answering them. In this edition, we zoom in on feasibility.


It's about you

Feasibility is all about "Can you build it?" Two years ago, I coached a team that had an idea of a new travel app. They had well-designed clickable mockups, people loved it in their experiments. The issue: they didn't have any developers, they were not able to get a developer to join the founding team and they were not able to raise capital to hire developers. The question is not 'Can it be build?' but 'Can your team realise it?' The app was not complicated, it was feasible to build, but not by this team.

Stand-alone does not imply scale nor implementation

What can you do with your team? Prototyping helps a lot with generating proof for feasibility. The nice thing about prototyping is that you can do it in your garage. The bad thing about prototyping is that you do it in your garage. Your customer does not live in your garage unless you have some new type of garage-based AirBnB startup. I did a project for a big beer brand once that wanted to have a fridge that could see how many beers were inside.

It's not only about your solution

The latest batch of my startup course featured a solution to plastic pollution: Shampoo and soap in a can (Frisse Blikken). Cans are better recycled and will have a deposit by Dutch law in the future. Great opportunity?

This startup 3D printed a cap, combined it with the pump of a general soap bottle, and mounted it on soda cans to test it with customers. Customers were positive, but furthermore, this proved that it can be done on a small scale. The remaining question was: could they scale up? The supply chain was a challenge to set up. Which supplier was willing to do this experimental setup of soap and cans? Which supplier didn't require a minimum order quantity of 50.000 units?

Feasibility is not only about showing that your solution works. It is also about your capability to pull off the entire system to produce your solutions. This is what the travel app startup face: if you don't have the means to create a team or supply chain that produces your solution, you are unlikely to succeed. Ask yourself, what are other things that need to be in place for your solution to be built? Can you realize all that?

Treat feasibility as a scale

I sometimes see people treat feasibility as a boolean: either it’s feasible or it’s not feasible. I think it's better if you treat feasibility as a scale. Moving to the right means to de-risk the feasibility of your solution (or supply chain). You want to keep moving to the right as you develop your startup. How much proof of feasibility should you have? That is relative to where you are in your journey. In your first few weeks, a sketch could be enough. After a couple of months, you probably want something testable. Understand why you need each of these steps. Prototypes are means, not ends.

Quick reads

Jeroen's take

In this edition I tried two new things:

  • To be a lot more concise, based on some feedback I got from you. Thank you for your feedback, please keep it coming.

  • A video version of it. Might keep doing that in the future.

Did you like this edition? Let me know by voting below.

How would you rate this week's newsletter?

Great - Good - Meh

It takes 1 second and makes me happy in my tummy.