Hacker News Reader

Comment by danShumway | Hacker News Reader

Huh, that's really interesting.

I don't have anything against mockups, but that's almost the opposite of what I and engineers I know think of when we say MVP. The point of an MVP as we use it is to not plan in excessive detail about what your final feature-set will be, because you don't know what customers will and won't find valuable until you have a product in their hands. Get the smallest, most specific version of a useful product released, and then after that you can figure out what future iterations should do.

How are you going to release an MVP to customers that doesn't actually do anything? Why would anyone download or use it?

View on HN

I think the point here is that your MVP should behave like the actual product in the eyes of the customer, but you do not have to actually build the functionality. By providing a lot of the service manually, you can get your initial customers quickly. Having customers means getting feedback from the product's target audience. Getting this feedback before actually heavily investing in automating the product means when you do automate, you have a much better idea of what the final product should look like and which features you should prioritize, wasting less time and money on building the wrong things.

Just to make sure I understand what you're saying, let me try to think of an example.

A number of AI companies start out by outsourcing the "AI" to something like Amazon Turk or remote contractors. From the customer perspective, the system is working as intended. The system transcribes their videos, or schedules their appointment, or whatever.

In the backend, the system doesn't exist. It's just a bunch of people manually transcribing videos and manually creating Calendar links. And those companies are validating that customers will want to use the fake version before they spend the time building an AI-driven real version.

Do I understand correctly, or is that different from what you were trying to say?

But in that case, you're still building a product that does a thing. It's just that the product doesn't currently scale, and the business isn't being up-front telling any of its customers what they're actually buying. I wouldn't say you built a mockup in that situation, I would say you built a call-center, and you're thinking about whether or not to automate it based on demand.

First things first, I think companies should be up-front with their customers. That means not marketing non-AI solutions as AI. However, lots of companies do not sell AI, they sell a service. And as long as that service is good, it should not matter to the customers if part of that process is manual, as long as you do not lie about it.

I am not saying this is the best way to handle things; it's just the way I interpreted the "MVP as mock up" idea.

Too much software mindset. You can build a no-code solution, see how potential users interact with it, and learn from that. You can gage interest just by presenting something to a focus group in a somewhat interactive way. MVP could even just be a poll. No need for a "product" or even a demo.

If you can build a prototype fast and deliver fast, that could be valuable, but is often waay before evaluating what to build in the first place. There are success stories building something and iterating on that. If you yourself is multi-talented, have the time, clout and love your software, there might be some odds others might like/need it too. The latter is associated with most failures though.

So be a business, not a software delivery function.

Sure, you don't need to code anything. You can build a no-code solution, see how potential users interact with it, and learn from that. But your no-code solution still needs to be a minimal feature set that people can actually use.

If I'm building an MVP for a restaurant, maybe there's no code at all in that system. Maybe I'm manually taking everyone's orders and serving at most one or two dishes on a street corner. But I'm not just showing people pictures of food.

Your no-code solution still needs to be a solution, it can't just be a promise that there will be a solution at some point in the future. An MVP doesn't mean code, it means: Build the smallest possible product (whether that involves code or not) that actually solves someone's problems in the real world, and then put that product in their hands so you can see what they do with it.

A poll is not a product. No customer is going to pay you so that they can take a poll.

You may not generate much income with initial MVP, or whatever you want to call it. The point is to learn while minimizing costs, risks and time to market. To expect greatness without work, is folly..

Your example with the restaurant is a perfect example: Have someone execute the MVP manually. Map routines that works great, optimize and document outcomes. This becomes spec for initial automations.

The alternative could be someone in a corner office applying systems thinking and predicting everything required in the system. This tend to overcomplicate system designs and make them less amenable to adapt over time.

> MVP could even just be a poll. No need for a "product" or even a demo.

A poll or a demo may be a great step, but it isn't viable, and isn't a product, so it's no kind of MVP.

How can a poll be a MVP? Sure we can say MVP can be anything, but 'No need for a "product"' when the word product is right there in the name seems wrong to me.

You don't need to do a MVP to do market/customer research, sure, but a mockup or a poll isn't a MVP, I'm sorry. Otherwise a blog post is a MVP, an image in IG is a MVP, etc.

Reply on news.ycombinator.com