6 ms·

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 developmen

by 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.

by borski 5y ago

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.