6 ms·

Your company shouldn’t be in search of a business model, you should know what you need to build. This is exactly what killed my first startup. We believed we f

Your company shouldn’t be in search of a business model, you should know what you need to build. This is exactly what killed my first startup. We believed we fully understood what the customer needs and that we should build the right product before we started selling. We were actually trying to build the minimum viable product, but we were hilariously (with hindsight) wrong about what the customers wanted. Almost all our ideas were just wrong enough to make the product fail to solve the customers pains. They solved the pains we'd had in the past brilliantly, but sadly that wasn't relevant. We weren't buying our product. Starting out with the notion that you already know everything you need to know will kill your startup. Running a startup is as much about spotting and understanding the signals that you discover along the way as it is about building what you think you customers need. A minimum viable product is not "selling the least effort product you can get away with", it's spending the least amount of time you can to build something that you can use to gather more data than you can use to focus your product on what the customer wants rather than what you think they want. Building what you think the customer wants will very likely be wrong - customers lie, they're deluded, they don't understand their own problems, and they can't see value in solutions. But they do start to understand the problem when they see a solution to it, even if it's the minimum viable solution. And then they start having ideas about what else they can pay for to make it better...

borski 5y ago
I came here to say this. The author of the article does not understand what an MVP is. An MVP is the eventual answer to a metric fuckton of customer development, not what you go into customer development with. If you think you already know what the customer wants, I wish you luck at your next startup after this one fails; you don’t know that, and neither does your customer, or they would have built / bought it already. It’s your job to find the real problems they’re facing, and then build a solution that makes them rip it out of your hands before it’s even done. then, iterate.
- rwmj 5y ago
  With Ansible, Mike already had a successful prototype (func) which had been developed and used by the Fedora infrastructure team for a while. He then left Red Hat and worked on Ansible. So he did in fact already know what the customer wanted! However that's an unusual case for a start-up. https://opensource.com/article/21/2/ansible-origin-story https://opensource.com/article/21/2/ansible-origin-story
  - onion2k 5y ago
    I think in that case you're not building a minimum viable product because that's already happened. The MVP was what Ansible was when the Fedora team were using it. When Mike left to form a company around the product it was much more than that - because there was already a really good understanding of what people would pay for.
    - rwmj 5y ago
      Mike is also a great developer and infrastructure person so in a sense he is his own customer.
  - throwaway5752 5y ago
    Based on my experience func and ansible aren't very comparable and it's hard to call func a prototype for ansible. My recollection is that it was much more of a disruption to puppet, chef, and saltstack that had all become much more complicated and heavyweight by that time. What I took away from this article is that an expert in that space (DeHaan) knew there was a gap and opportunity in this area, and the point of this article is that because he was able to capitalize on that opportunity because of his existing expertise and familiarity. It's an interesting view compared to some interpretations of lean startups.
- throwaway5752 5y ago
  "The author of the article does not understand what an MVP is" - it feels like that's not the case, based on their background? Reading the comments here, I see a lot of people with their own (and conflicting) ideas of what MVP is in the context of a startup. I also didn't get the idea from reading the article you are disagreeing with their point, and that they weren't opposing iterative learning.
- jandrewrogers 5y ago
  Some startups are created by experienced customers, and in these cases you often absolutely do know what the customer wants. Empirically, these can succeed without any significant customer development. Customer development becomes much more important if the startup lacks real domain and market expertise. Also, while customer development might work well for web apps and such, there are classes of software where customers have no desire to interact with you until the product is almost fully baked. Trying to do customer development in these markets is often an exercise in futility. It is a different kind of process to arrive at an MVP, and in these cases it requires that the founders have strong domain and market expertise.
  - borski 5y ago
    Customer development is always important. What constitutes an MVP may change, based on the industry or the customer, but the concept of talking to your customers regularly, understanding their problems, and iterating quickly doesn’t change. As much as a founder would like to say they are the customer… they aren’t. They are a customer, and finding the commonalities amongst potential customers so you can build something they want is important. The founder being a customer just kickstarts that process and means the founder can ask better (aka “the right”) questions. Which markets are you referring to? Gov requires customer dev, which is why there are often grants. Med requires customer dev, as building simply a better device rarely wins - it needs to be much better than existing solutions, and the only way you get there is by finding out what the problems are with existing solutions. Same goes for banking, etc Domain and market expertise is always a benefit, but rarely a strict requirement for success. The ability to listen carefully, and iterate quickly, is much more important.
    - Shindi 5y ago
      Agreed, super super important to do customer dev. What I haven't seen mentioned here is that if you do customer dev right, you get a leg up on sales. One of the slickest founders I know would get conversations with his target customers to ask about their jobs + workflows. He'd learn from everyone but he kept note of the people who shared the same problem he was targeting. He now has a list of dozens of people who he has a relationship with who would make great first customers. He didn't need to build a landing page or even a prototype in figma because he was just talking to people to learn about what they do.
- winternett 5y ago
  Agreed. The management of requirements in building anything needs to be structured properly to manage client expectations because it's often the first point of failure on development projects. MVP is a concept that is implemented on mission critical projects in order to insure a minimally acceptable point of project success, not to "be" project success... Anything else that can be added (within the implementation time frame) after base goals are met is a bonus. Scope and schedule creep are 2 of the biggest threats to any major project, and it takes technical oversight just as much as managerial oversight... Technical Architects usually bridge this gap on projects. An MVP is meant to be something that is generalized enough to fit KEY customer needs in a limited time frame, not ALL of the customer's needs, and customers inherently try to squeeze changes in during execution in large-scale projects. MVP for small-scale and startup projects may not mesh well, unless needs are well defined by an accountable customer. An MVP is a contractual deliverable, so it shouldn't be delivered or even started before that contract is properly written and signed off. Key aspects of a successful MVP - It needs to be scale-able and mindful of future integrations and functionality. It needs to be able to pivot and adjust to change, especially changes outside of your control (e.g. The Pandemic). The data therein needs to maintain integrity and transfer-ability. This is why experienced IT/Business architects are necessary on key projects. They incorporate business drivers, requirements, project management objectives, and technical teams into meaningful language, documentation, and project outcomes. When you struggle on without an architect, projects suffer from a lack of direction, mixed communication, and often waste lots of money on back tracking solutions. MVP is also a "version control" and project/client management concept/methodology, not a development language. The author broke down the title based on the words used. Taking time out to really investigate an understand why so many credible people use the term is a better move than declaring it obsolete.
phphphphp 5y ago
I think there's some degree of nuance that isn't captured with comments like yours. I agree with your comment in principle, but there are interpretations of this method that are too extreme and that's where most of the bad MVPisms come from (and what I assume this blog post is a response to). As with any process, what most people are doing is not what was intended, and so we have to discuss what people are doing more so than the theory. Data is only as valuable as the insight, understanding and intuition at the disposal of those gathering and actioning the data. There are organisations that truly embrace this idea of "we know nothing, the data will guide us" and they get lost because they're chasing a bunch of numbers for the sake of numbers on weak experiments that don't marry up to anything of meaning. You need some amount of difficult-to-define "understanding" and "intuition" to be able to turn any learnings (whether gathered from experience or data) into a product: without it, you'll fail, regardless of process. There are many successful products that started out as someone absolutely committed to a belief in what is needed by the market, there are many successful products that were developed by following the data from day one, and likewise there are many unsuccessful products following both patterns. My personal disdain for MVP-ing is exactly because it is so difficult to get right, and is very easy to get wrong, and it leaves little room for corrective action: I'm sure we all have experience with zombie startups, years old, still frantically "MVPing" everything under the sun. Personally, I'd much rather work within an organisation that has a clear vision about the problem they're trying to solve with flexibility around how it is to be solved, even if it ultimately leads to failure. Customers lie, but so does data.
- onion2k 5y ago
  it leaves little room for corrective action Building an MVP means getting something in front of customers as soon as possible, in order to test your product works for customers and change it if you're wrong. The entire point of an MVP is to give you as much time to change things as possible. Everything you do prior to putting your product in front of someone might be wrong. The only validation that counts is the customer handing you their money. The longer you spend building before getting something out there the more expensive any mistakes might be. Consequently, making an MVP and only building the absolute minimum viable solution to a problem, give you as much correction time as possible. I'd much rather work within an organisation that has a clear vision about the problem they're trying to solve with flexibility around how it is to be solved We all would. The question is about how the org goes about getting clarity about the problem. If they think they fully understand it without talking to customers or putting something in front of customers in order to give the customer something to talk about, run the hell away. Those discussions will happen as soon as the customer sees something. If you've built a full product that you think is ideal, and then the customer doesn't agree, then you either lose the customer or you have to do a ton of work to change the product. Those are expensive mistakes that kill a startup. Having those conversations as early as possible is how you avoid that cost.
matwood 5y ago
The other big reason for an MVP is to get from 'customers told us they want this' to 'customers are actually paying for this' as quickly as possible. All to often potential customers say they want X, but really have no idea what they want. The only surefire way to know if a product is on the right path is to have customers using and paying for the product.
- dagw 5y ago
  All to often potential customers say they want X, but really have no idea what they want. Or they actually do really want and need X _right now_. However when you come back with X in 18 month then the customer has already solved X themselves, found another company that can do X or don't really need X any more.
  - borski 5y ago
    It’s quite rare that a customer knows exactly what they need; often, if they do, they build it. The wins happen when a customer knows what problems they have, and you can present a solution that solves them better than they could otherwise get elsewhere. Otherwise, as you say, they will build it or buy it elsewhere.
mizzao 5y ago
It seems like a lot of YC companies are just drinking the MVP kool-aid. And there are 400 companies per batch now because they can just play the numbers game: throw them all at the wall and see who sticks. It's a very interesting and nuanced distinction between: "just build something and launch it as soon as possible" ...vs... "think really hard about how to solve a particular problem in a novel way, then build the simplest possible solution that lets you iterate, but no simpler" The most apt analogy for me has been multivariate optimization of a nonconvex function: the MVP is the initialization conditions. If you start near a local maximum then there is no way that hill-climbing (SGD, L-BFGS) will get you to a global maximum. So you need to make sure your starting point (MVP) lets you actually iterate to the global maximum through small local optimizations. A product pivot is basically a random jump in the objective function hoping to get closer to a point where the function's gradient can lead you to a global maximum. We did that with our product and thankfully the new initialization conditions are way better, and we are at a point where we can iterate to PMF. But there was no way we could have done that with our old product. (Here's the story of that pivot: https://parsnip.substack.com/p/a-new-hope https://parsnip.substack.com/p/a-new-hope)
- marcosdumay 5y ago
  The MVP strategy is entirely about validating your product. Unless you decide it has a good market fit, there is nothing in it telling you how to look for alternatives. There's nothing telling you to go by hill-climbing, or even by any gradient based search at all. What it says is that once you find product-market fit, you don't destroy it by jumping around at random. But at this point, it's about disruption and the Innovator's Dilemma, where you are the incumbent. It's not about starting-up anymore.
- rileyphone 5y ago
  This is a great analogy, basically plotting startup success on an evolutionary NK landscape [0]. Finding optima rests on a healthy balance of exploration and exploitation, as in the behavior of ant colonies searching for food. Apple has been a good historical model of this in business, though for a startup it's often necessary to keep the chips all in on one product. Ideally though, a pivot isn't a random jump, but is rather guided by an incomplete map of the landscape. Herein lies the value of the MVP, but it's curse is being difficult to throw away, especially once it has some traction. [0] https://en.wikipedia.org/wiki/NK_model https://en.wikipedia.org/wiki/NK_model
deleted 5y ago
[deleted]
jrochkind1 5y ago
In your story you thought you knew what to build, but didn't. The "MVP" theory is that the MVP is part of validating that you really know what to build, as you say. OP author disagrees. (I'm not sure OP author says anything about when you "start selling" exactly). Clearly a lot more can be said about how you know what to build if not an "MVP" approach. OP suggests a few things: "cultivated instinct" (which as a phrase alone isn't too useful, how do you get it?); Spending a lot of time talking to potential customers, and not necessarily taking what they say at face value but "averaging" it, and mixing with that "cultivated instinct"; and maybe most specifically/operationalizable -- spend some time working in the industry/market before starting the company at all, so you've seen "how 5 other companies have built something and know all the things that they’ve done wrong, and it will be a lot easier." "Domain expertise" might be the main thing he's talking about, arguing agianst the idea that you can start a company without somebody involved having significant domain expertise/experience in the industry, but instead develop that market knowledge as you go, through an "MVP" approach. I'm curious how those ideas relate to your company, how much industry/domain experience you had before starting the company.
- zerkten 5y ago
  >> "Domain expertise" might be the main thing he's talking about This is clearly what he is talking about. When he is talking about his experience with the "Senior Design project course in Computer Science at my alma mater" he is really talking about how people can "MVP their way into getting domain expertise" at some level. This is a fundamental problem with the "startup industry". Groups of people from a computing (I want to be broader than CS) that have reasonably strong technical skills and a lot of enthusiasm for applying those skills want to build successful startups. They generally lack domain expertise outside of technology-adjacent products for the most part. It's not completely absent because there is some success, but there isn't a balance for the most part. Where does the domain expertise come from then? It could come from a slow development process involving the founders immersing themselves in the area. That's really only something that's going to be feasible before the founders create the company. Once the company has been founded, it becomes a scramble to interpret some ideas and build an MVP that can be sold to some of the advisors that the founders could get time with. It's only now that the foundational work is happening. If the right people see the MVP, or the founders make the right connections, it's possible to catapult forward from here, but it's a predictable failure point.

borski 5y ago

I came here to say this. The author of the article does not understand what an MVP is. An MVP is the eventual answer to a metric fuckton of customer development, not what you go into customer development with. If you think you already know what the customer wants, I wish you luck at your next startup after this one fails; you don’t know that, and neither does your customer, or they would have built / bought it already. It’s your job to find the real problems they’re facing, and then build a solution that makes them rip it out of your hands before it’s even done. then, iterate.

rwmj 5y ago
With Ansible, Mike already had a successful prototype (func) which had been developed and used by the Fedora infrastructure team for a while. He then left Red Hat and worked on Ansible. So he did in fact already know what the customer wanted! However that's an unusual case for a start-up. https://opensource.com/article/21/2/ansible-origin-story https://opensource.com/article/21/2/ansible-origin-story
- onion2k 5y ago
  I think in that case you're not building a minimum viable product because that's already happened. The MVP was what Ansible was when the Fedora team were using it. When Mike left to form a company around the product it was much more than that - because there was already a really good understanding of what people would pay for.
  - rwmj 5y ago
    Mike is also a great developer and infrastructure person so in a sense he is his own customer.
- throwaway5752 5y ago
  Based on my experience func and ansible aren't very comparable and it's hard to call func a prototype for ansible. My recollection is that it was much more of a disruption to puppet, chef, and saltstack that had all become much more complicated and heavyweight by that time. What I took away from this article is that an expert in that space (DeHaan) knew there was a gap and opportunity in this area, and the point of this article is that because he was able to capitalize on that opportunity because of his existing expertise and familiarity. It's an interesting view compared to some interpretations of lean startups.
throwaway5752 5y ago
"The author of the article does not understand what an MVP is" - it feels like that's not the case, based on their background? Reading the comments here, I see a lot of people with their own (and conflicting) ideas of what MVP is in the context of a startup. I also didn't get the idea from reading the article you are disagreeing with their point, and that they weren't opposing iterative learning.
jandrewrogers 5y ago
Some startups are created by experienced customers, and in these cases you often absolutely do know what the customer wants. Empirically, these can succeed without any significant customer development. Customer development becomes much more important if the startup lacks real domain and market expertise. Also, while customer development might work well for web apps and such, there are classes of software where customers have no desire to interact with you until the product is almost fully baked. Trying to do customer development in these markets is often an exercise in futility. It is a different kind of process to arrive at an MVP, and in these cases it requires that the founders have strong domain and market expertise.
- borski 5y ago
  Customer development is always important. What constitutes an MVP may change, based on the industry or the customer, but the concept of talking to your customers regularly, understanding their problems, and iterating quickly doesn’t change. As much as a founder would like to say they are the customer… they aren’t. They are a customer, and finding the commonalities amongst potential customers so you can build something they want is important. The founder being a customer just kickstarts that process and means the founder can ask better (aka “the right”) questions. Which markets are you referring to? Gov requires customer dev, which is why there are often grants. Med requires customer dev, as building simply a better device rarely wins - it needs to be much better than existing solutions, and the only way you get there is by finding out what the problems are with existing solutions. Same goes for banking, etc Domain and market expertise is always a benefit, but rarely a strict requirement for success. The ability to listen carefully, and iterate quickly, is much more important.
  - Shindi 5y ago
    Agreed, super super important to do customer dev. What I haven't seen mentioned here is that if you do customer dev right, you get a leg up on sales. One of the slickest founders I know would get conversations with his target customers to ask about their jobs + workflows. He'd learn from everyone but he kept note of the people who shared the same problem he was targeting. He now has a list of dozens of people who he has a relationship with who would make great first customers. He didn't need to build a landing page or even a prototype in figma because he was just talking to people to learn about what they do.
winternett 5y ago
Agreed. The management of requirements in building anything needs to be structured properly to manage client expectations because it's often the first point of failure on development projects. MVP is a concept that is implemented on mission critical projects in order to insure a minimally acceptable point of project success, not to "be" project success... Anything else that can be added (within the implementation time frame) after base goals are met is a bonus. Scope and schedule creep are 2 of the biggest threats to any major project, and it takes technical oversight just as much as managerial oversight... Technical Architects usually bridge this gap on projects. An MVP is meant to be something that is generalized enough to fit KEY customer needs in a limited time frame, not ALL of the customer's needs, and customers inherently try to squeeze changes in during execution in large-scale projects. MVP for small-scale and startup projects may not mesh well, unless needs are well defined by an accountable customer. An MVP is a contractual deliverable, so it shouldn't be delivered or even started before that contract is properly written and signed off. Key aspects of a successful MVP - It needs to be scale-able and mindful of future integrations and functionality. It needs to be able to pivot and adjust to change, especially changes outside of your control (e.g. The Pandemic). The data therein needs to maintain integrity and transfer-ability. This is why experienced IT/Business architects are necessary on key projects. They incorporate business drivers, requirements, project management objectives, and technical teams into meaningful language, documentation, and project outcomes. When you struggle on without an architect, projects suffer from a lack of direction, mixed communication, and often waste lots of money on back tracking solutions. MVP is also a "version control" and project/client management concept/methodology, not a development language. The author broke down the title based on the words used. Taking time out to really investigate an understand why so many credible people use the term is a better move than declaring it obsolete.

phphphphp 5y ago

I think there's some degree of nuance that isn't captured with comments like yours. I agree with your comment in principle, but there are interpretations of this method that are too extreme and that's where most of the bad MVPisms come from (and what I assume this blog post is a response to). As with any process, what most people are doing is not what was intended, and so we have to discuss what people are doing more so than the theory. Data is only as valuable as the insight, understanding and intuition at the disposal of those gathering and actioning the data. There are organisations that truly embrace this idea of "we know nothing, the data will guide us" and they get lost because they're chasing a bunch of numbers for the sake of numbers on weak experiments that don't marry up to anything of meaning. You need some amount of difficult-to-define "understanding" and "intuition" to be able to turn any learnings (whether gathered from experience or data) into a product: without it, you'll fail, regardless of process. There are many successful products that started out as someone absolutely committed to a belief in what is needed by the market, there are many successful products that were developed by following the data from day one, and likewise there are many unsuccessful products following both patterns. My personal disdain for MVP-ing is exactly because it is so difficult to get right, and is very easy to get wrong, and it leaves little room for corrective action: I'm sure we all have experience with zombie startups, years old, still frantically "MVPing" everything under the sun. Personally, I'd much rather work within an organisation that has a clear vision about the problem they're trying to solve with flexibility around how it is to be solved, even if it ultimately leads to failure. Customers lie, but so does data.

onion2k 5y ago
it leaves little room for corrective action Building an MVP means getting something in front of customers as soon as possible, in order to test your product works for customers and change it if you're wrong. The entire point of an MVP is to give you as much time to change things as possible. Everything you do prior to putting your product in front of someone might be wrong. The only validation that counts is the customer handing you their money. The longer you spend building before getting something out there the more expensive any mistakes might be. Consequently, making an MVP and only building the absolute minimum viable solution to a problem, give you as much correction time as possible. I'd much rather work within an organisation that has a clear vision about the problem they're trying to solve with flexibility around how it is to be solved We all would. The question is about how the org goes about getting clarity about the problem. If they think they fully understand it without talking to customers or putting something in front of customers in order to give the customer something to talk about, run the hell away. Those discussions will happen as soon as the customer sees something. If you've built a full product that you think is ideal, and then the customer doesn't agree, then you either lose the customer or you have to do a ton of work to change the product. Those are expensive mistakes that kill a startup. Having those conversations as early as possible is how you avoid that cost.

matwood 5y ago

The other big reason for an MVP is to get from 'customers told us they want this' to 'customers are actually paying for this' as quickly as possible. All to often potential customers say they want X, but really have no idea what they want. The only surefire way to know if a product is on the right path is to have customers using and paying for the product.

dagw 5y ago
All to often potential customers say they want X, but really have no idea what they want. Or they actually do really want and need X _right now_. However when you come back with X in 18 month then the customer has already solved X themselves, found another company that can do X or don't really need X any more.
- borski 5y ago
  It’s quite rare that a customer knows exactly what they need; often, if they do, they build it. The wins happen when a customer knows what problems they have, and you can present a solution that solves them better than they could otherwise get elsewhere. Otherwise, as you say, they will build it or buy it elsewhere.

mizzao 5y ago

It seems like a lot of YC companies are just drinking the MVP kool-aid. And there are 400 companies per batch now because they can just play the numbers game: throw them all at the wall and see who sticks. It's a very interesting and nuanced distinction between: "just build something and launch it as soon as possible" ...vs... "think really hard about how to solve a particular problem in a novel way, then build the simplest possible solution that lets you iterate, but no simpler" The most apt analogy for me has been multivariate optimization of a nonconvex function: the MVP is the initialization conditions. If you start near a local maximum then there is no way that hill-climbing (SGD, L-BFGS) will get you to a global maximum. So you need to make sure your starting point (MVP) lets you actually iterate to the global maximum through small local optimizations. A product pivot is basically a random jump in the objective function hoping to get closer to a point where the function's gradient can lead you to a global maximum. We did that with our product and thankfully the new initialization conditions are way better, and we are at a point where we can iterate to PMF. But there was no way we could have done that with our old product. (Here's the story of that pivot: https://parsnip.substack.com/p/a-new-hope https://parsnip.substack.com/p/a-new-hope)

marcosdumay 5y ago
The MVP strategy is entirely about validating your product. Unless you decide it has a good market fit, there is nothing in it telling you how to look for alternatives. There's nothing telling you to go by hill-climbing, or even by any gradient based search at all. What it says is that once you find product-market fit, you don't destroy it by jumping around at random. But at this point, it's about disruption and the Innovator's Dilemma, where you are the incumbent. It's not about starting-up anymore.
rileyphone 5y ago
This is a great analogy, basically plotting startup success on an evolutionary NK landscape [0]. Finding optima rests on a healthy balance of exploration and exploitation, as in the behavior of ant colonies searching for food. Apple has been a good historical model of this in business, though for a startup it's often necessary to keep the chips all in on one product. Ideally though, a pivot isn't a random jump, but is rather guided by an incomplete map of the landscape. Herein lies the value of the MVP, but it's curse is being difficult to throw away, especially once it has some traction. [0] https://en.wikipedia.org/wiki/NK_model https://en.wikipedia.org/wiki/NK_model

deleted 5y ago

[deleted]

jrochkind1 5y ago

In your story you thought you knew what to build, but didn't. The "MVP" theory is that the MVP is part of validating that you really know what to build, as you say. OP author disagrees. (I'm not sure OP author says anything about when you "start selling" exactly). Clearly a lot more can be said about how you know what to build if not an "MVP" approach. OP suggests a few things: "cultivated instinct" (which as a phrase alone isn't too useful, how do you get it?); Spending a lot of time talking to potential customers, and not necessarily taking what they say at face value but "averaging" it, and mixing with that "cultivated instinct"; and maybe most specifically/operationalizable -- spend some time working in the industry/market before starting the company at all, so you've seen "how 5 other companies have built something and know all the things that they’ve done wrong, and it will be a lot easier." "Domain expertise" might be the main thing he's talking about, arguing agianst the idea that you can start a company without somebody involved having significant domain expertise/experience in the industry, but instead develop that market knowledge as you go, through an "MVP" approach. I'm curious how those ideas relate to your company, how much industry/domain experience you had before starting the company.

zerkten 5y ago
>> "Domain expertise" might be the main thing he's talking about This is clearly what he is talking about. When he is talking about his experience with the "Senior Design project course in Computer Science at my alma mater" he is really talking about how people can "MVP their way into getting domain expertise" at some level. This is a fundamental problem with the "startup industry". Groups of people from a computing (I want to be broader than CS) that have reasonably strong technical skills and a lot of enthusiasm for applying those skills want to build successful startups. They generally lack domain expertise outside of technology-adjacent products for the most part. It's not completely absent because there is some success, but there isn't a balance for the most part. Where does the domain expertise come from then? It could come from a slow development process involving the founders immersing themselves in the area. That's really only something that's going to be feasible before the founders create the company. Once the company has been founded, it becomes a scramble to interpret some ideas and build an MVP that can be sold to some of the advisors that the founders could get time with. It's only now that the foundational work is happening. If the right people see the MVP, or the founders make the right connections, it's possible to catapult forward from here, but it's a predictable failure point.