5 ms·
This is becoming so widespread, it’s no longer just a byproduct of how a project or a product is managed. It’s an explicit guidance that is explicitly stated in
by eddythompson80 3y ago
This is becoming so widespread, it’s no longer just a byproduct of how a project or a product is managed. It’s an explicit guidance that is explicitly stated in the form of “No feature should take more than 1-2 months. 3 months feature work is the longest term we should plan and consider. Everything we work on from planning to design to implementation to deployment needs to be in the hand of a customer at most in 2-3 months max” I even had this hilarious conversation with my manager once.
I asked: “You know how broken this feature is, right? Like if you even deviate from the simple announcement example in any way, you’ll probably be broken in a completely unknown way. We’re providing an ‘alternative’ that only implements a 1/10 of the scenarios but nonetheless exposes the same interface to users”
He said: “yeah, that’s fine. The most important thing is to deliver something for users to use. To even know if anyone wants this at all or if no one will use it”
I perplexedly asked: “but how would you know if people are not using it because they don’t want it, or if they are using it because they try and it’s hopelessly broken?”
He said: “We’ll fix it. If they are not using it because it rough or broken, then we’ll fix it. We will wait for feedback about what’s broken and fix the problem they run into. If people want to use something and they find issues, they’ll just report it.”
I said: “… do you do that? You try a feature in a new product or a tool or a feature, and when it doesn’t work at all, do you start file feedback items and work with that company to make sure their feature work? I know i don’t. I just move on until they fix it or find a competitor who has a better alternative”
He said: “no, most people will report problems and we can fix them as they come. Also we should tell from telemetry what people are trying and what’s not working and what we should fix vs not”
I said: “yeah, that makes sense.“, knowing that our telemetry is also generally broken because it’s implemented in the same way and generally we do the work when business folks come back asking for some data or complaining how the data we provide doesn’t add up.
Oh fun times.
- ImPostingOnHN 3y agothis sounds like a conversation wherein someone learns about lean startup / agile methodologies for the first time (build an MVP and get it in front of people ASAP to get feedback, don't perfect it first)
- def_true_false 3y agoShipping obviously broken stuff is a good way to discourage users from giving any feedback at all.
- ImPostingOnHN 3y ago"obviously broken" isn't the only option besides perfect, so we'll just use the term "not perfect" here, and believe me, some of them will let you know what isn't perfect about it when you ask. then you focus on that.
- eddythompson80 3y ago“Not perfect” is a straw man because obviously nothing ever is perfect or 100% complete. When shipping something becomes the priority, then “obviously broken” stuff just gets re-dubbed “not perfect” which is exactly the problem. If your users are forced to use your platform because you mainly sell to CTOs who only need a list of checkboxes checked, and they strike a deal with you, then yeah. It’s a great business model to check as many boxes as possible, get that contract, then figure out what those boxes actually mean later.
- ImPostingOnHN 3y ago"obviously broken" is a straw man because we're just discussing anything that doesn't satisfy everything you want (which you listed). indeed, the concept of an "obviously broken" MVP is an oxymoron, since V stands for "viable" when giving everybody everything they want becomes the priority, then "not perfect" stuff just gets re-dubbed "obviously broken" by 1 random person, which is actually the problem: it's better to ship something and get feedback and iterate on it than to ship nothing or to ship the wrong thing after a long development time or to ship at the end of however long it takes to satisfy everybody's desires