Speed vs quality
jasonleow • 22 Oct 2024 •
Maybe it’s not about choosing between shipping a fast but crappy product, versus shipping slow but quality stuff.
It’s about the market context.
If idea is same as and already validated by existing competitors, then sure, ship slow, build for quality, and slowly climb up in SEO and carve out your slice of the pie.
Time is your ally here.
If idea is unique, not yet validated by market yet, then ship fast, ship a lovable MVP, to decide if the idea has potential before you even commit too much time/effort into it.
Time is opportunity cost here.
In both, it’s about validating a business. The approach is just a tool to be used in different contexts.
You don’t have to go either/or between speed versus quality. Don’t get caught in dogma or false dichotomies.
Comments
Yeah agree, switching back and forth is the way. The challenge is knowing when.
It definitely depends on context and there’s usually confusion around the M in MVP. It’s not about having something to offer, fast. It’s about making the feature/service people are eager to have and pay for made available in a way they’d be willing to pay for it. Would additional features/polish increase sales or simply delay sales? Focus on what matters for the users.
@haideralmosawi Some people believe functionality is not even part of the MVP. “Just put up a website and see if people click the Buy button.” 🤔
@Winkletter That’s true! But I would consider that only validating demand, not the actual “product” people are paying for. Once you deliver the product/service people pressed the Buy button for, what’s their experience like? Are they happy with its current version AS the current version (they might suggest future improvements or wait for features to improve, but they’re still willing to pay for what’s available because it offers functionality/a solution other products/services don’t).
@haideralmosawi Oh nice, love that diagram! I love this other one too:
@jasonleow I like that one, too!
This reminds me of the problem space series I was doing. On one end you have reasons to produce quantity, and on the other end you have reasons to produce better quality. Both take effort and are in conflict, so you usually have to optimize for one or the other. You can neglect both equally (low effort), focus on one or the other, or switch back and forth (medium effort) or optimize for both (high effort.) The switching back and forth seems like a good strategy when you want to validate a product before doubling down on the winning bet. Like you said, though, it depends on your context.