4 ms·

"It's always better" - words like this make me think "unchallenged accepted wisdom". Accepted wisdom remains accepted until eventually people start to realize

by hoodoof 10y ago

"It's always better" - words like this make me think "unchallenged accepted wisdom". Accepted wisdom remains accepted until eventually people start to realize that it's not entirely correct.

zmitri 10y ago
As someone who has gone through YC, I think a lot of the kind of absolute talk you are pointing out has to do with consistent messaging and providing general advice to an entire group of people who might not have the experience to understand for themselves what the best way to proceed is. Obviously in reality, things are a lot more nuanced than 'always', but when your goal is to help as many companies at once, where the degree of experience varies, it often help to simplify the problem. In one-on-one situations, the partners can give you more personalized insights and in general are quite insightful.
tlb 10y ago
There is considerable experience with doing large software projects in one shot. Many corporate and government software projects are done, or at least used to be done, that way. Results were pretty bad. It's hard to be positive of causation, but correlation (long time to initial customer contact <=> software doesn't make customers happy) is pretty strong. If you want to challenge it, you could try to deliver a successful large multi-year software projects with no prior customer engagement, and document the process. People can then make informed comparisons against the accepted wisdom.
tedmiston 10y ago
Sure, one counterpoint, or at least nuance, is when you give too much focus to the wrong users. Then wrong users can oversteer your product. For example, BigCo wants Feature X and will pay $100k/year for it, you add it but it complicates the experience for others and delays the rest of your roadmap. Another is knowing when your users are wrong, they request Feature Y, but really what they want is Benefit Z. Of course there's also nuance around how exactly you define minimum viable product (i.e., the part built before you start exposing it to users). I've seen experienced non-startup business people describe an entire app with every feature that they envision, then claim that's the MVP. It can be a hard model to adjust to.

by hoodoof 10y ago

"It's always better" - words like this make me think "unchallenged accepted wisdom". Accepted wisdom remains accepted until eventually people start to realize that it's not entirely correct.

zmitri 10y ago

As someone who has gone through YC, I think a lot of the kind of absolute talk you are pointing out has to do with consistent messaging and providing general advice to an entire group of people who might not have the experience to understand for themselves what the best way to proceed is. Obviously in reality, things are a lot more nuanced than 'always', but when your goal is to help as many companies at once, where the degree of experience varies, it often help to simplify the problem. In one-on-one situations, the partners can give you more personalized insights and in general are quite insightful.

tlb 10y ago

There is considerable experience with doing large software projects in one shot. Many corporate and government software projects are done, or at least used to be done, that way. Results were pretty bad. It's hard to be positive of causation, but correlation (long time to initial customer contact <=> software doesn't make customers happy) is pretty strong. If you want to challenge it, you could try to deliver a successful large multi-year software projects with no prior customer engagement, and document the process. People can then make informed comparisons against the accepted wisdom.

tedmiston 10y ago

Sure, one counterpoint, or at least nuance, is when you give too much focus to the wrong users. Then wrong users can oversteer your product. For example, BigCo wants Feature X and will pay $100k/year for it, you add it but it complicates the experience for others and delays the rest of your roadmap. Another is knowing when your users are wrong, they request Feature Y, but really what they want is Benefit Z. Of course there's also nuance around how exactly you define minimum viable product (i.e., the part built before you start exposing it to users). I've seen experienced non-startup business people describe an entire app with every feature that they envision, then claim that's the MVP. It can be a hard model to adjust to.