Viewing a single comment thread. View all comments

-UltraAverageJoe- t1_jbu40d1 wrote

Do you? Developers rarely decide what features stay or go or come back again.

6

CntrldChaos t1_jbusl8z wrote

A product owner and company does. As a developer or any of those roles you will understand what it means to hit MVP where you then build out what your users want. Building out all features to 100% is actually the exact model that failed day in and day out before the MVP and priority based model. You’d know that if you delivered software for a living

−2

AmalgamDragon t1_jbuu2e8 wrote

Microsoft/Windows isn't a startup. They don't need an MVP for their start menu. It's already been around for decades and been used by billions.

> Building out all features to 100% is actually the exact model that failed day in and day out before the MVP and priority based model. You’d know that if you delivered software for a living

I do. I also know you are dead wrong that there is a single best way to deliver software.

Enjoy all your well deserved downvotes.

7

CntrldChaos t1_jbuuwq6 wrote

This entire chain of messages stemmed from a dude saying all software added later to a product was a failure. His assessment is that it’s never ok to release a product missing a feature and add it back in a later release. It’s flat out wrong. Companies have limited cycles to do work and they release it when it makes sense. Sometimes features that exist shouldn’t exist right away because it’s limited benefit. I’m literally saying it’s not one size fits all. Downvotes are people feeling like big company bad and I know what’s best.

−3

UrbanFlash t1_jbw3hei wrote

My downvote is for you completely misrepresenting what the other guy said.

5

CntrldChaos t1_jbxgslr wrote

>If a company ever has to "bring back" a feature that customers wanted and used, it screwed up. Period. Looking at you, Apple.

He said in no questionable terms that a company screwed up if they don’t release a feature that existed in a previous version of a product, and bring it back. I’m saying this happens for very good reasons. The team knows some users use it but they don’t feel it’s necessary for launch because the product they rebuilt is better than it was and is worth a “beta” launch as is. They throw the feature on the backlog and prioritize it accordingly. This happens on any project where you are rebuilding from the ground up.

Users of products don’t always equate to dollars. For that software to exist they need customers who spend money and will focus on features for those customers first. They will then launch when the features that will keep the customers who matter happy are done. Most people think of software as free overall and think of what they will do to said company, but in reality software from companies is built to make someone money in some manner. A user who pays nothing is entitled to nothing. Many companies bend over backwards for free loaders. That can work out but it can also drive your product down a road that prevents it from surviving as long as it should.

No one person can definitively say what is right or wrong for a team and what they are building. Even the people who ultimately make the calls are guessing a bit which path to take. I am pointing out very specifically that in some paths a team can build an existing feature later and it’s not a screw up of any kind. It was a well thought out choice of value to their overarching users and not the people who use the feature in a silo.

1

corut t1_jbv9b4u wrote

As a Product Owner, the concept of an MVP is a stupid. The only time it's of benefit is if there is no completion or existing product in the market. If there is, you're first release needs to at least match the features of the competition or the previous product.

Otherwise you have MVP, but it has no value.

2