Hacker News Reader

Comment by MaknMoreGtnLess | Hacker News Reader

> IMHO its better to start with a UI prototype

Right - I am assuming you are comparing to vs. starting with a backend heavy prototype where it could get very expensive before exposing to customers?

> It's much faster and cheaper while still being effective

Effective as in effective in getting customer feedback as to whether the product makes sense to them?

but what if there were faster, cheaper and effective ways to get customer feedback than a UI prototype for a fresh startup just a few days old?

View on HN

This looks like a trap to me. An MVP whether it's functional or a UI prototype (i.e. has no or fake back-end) should be built as quickly and crudely as possible while maintaining a semblance of what it is used for.

When I see scope reduced from a functional minimal-product to a non-functional one. I usually see accompanied with that more time spent on producing a higher-fidelity UI-'prototype' which is clearly not a better use of time/resources.

I see your point and want to follow up:

> while maintaining a semblance of what it is used for.

and how do you know how it will be used for and by who without actually talking to users and understanding if, why and how they will actually use it?

said differently, would you agree that market risk (there's no one who cares about the product at all) is higher than the product risk (we can't build the product)?

I think describing what I mean (or think people in general often mean) by the terms will help explain this.

The main goal is to find Product-Market fit as a first priority. This is done through prototyping, mockups, user-testing, etc, etc. Often this will be considered/called 'making an MVP'. This is an ongoing iterative process and the phase ends when you know what the core function or value proposition of the product is and who it is for.

At that point you move to the phase of building a higher quality (hopefully still very feature limited) v1.0 product.

> The main goal is to find Product-Market fit as a first priority

Agreed.

I want to see whether you realize that in the "Product-Market fit", the only thing you control is Product - you can manage/change/affect it as a builder.

However, you do not control the Market.

So, would it stand to logic that reducing the thing that you do not control - Market Risk (there's no one who cares about the product, we are going to build, at all) should be much higher priority than the Product Risk (we can't build the product)?

> However, you do not control the Market.

Not entirely true. Part of finding Product-Market fit isn't only to shape your product, it's also to possibly redefine your target user as well. Often you will discover a use-case that is stronger than the one you set out with at the start with only minor changes to the original product idea.

Overworking the prototype is a real risk, that's why experienced devs should work on it. Sometimes its enough to do it on paper. Whats important is to capture the product in an objective form as quickly as possible and then show it to users.

Don't you think that iterating on a software MVP is more wasteful than iterating on a prototype? By the time you finish to setup the dev environment for your MVP you could've finished the prototype. And you don't have to carry any technical debt going forward.

I think there's should be a difference between customer feedback and user feedback. UI prototype is effective only in finding what users want. To get customer feedback you probably need a full fledged MVP and ask for money or other kind of commitment.

> but what if there were faster, cheaper and effective ways to get customer feedback than a UI prototype for a fresh startup just a few days old?

Like what?

Reply on news.ycombinator.com