[Terr_]

With respect to "highjacking roadmaps", recycling a comment from a few days ago [0]...

____

> > So many vendors are focused on charging money for customer specific features or adding new features to win new tenders.

> In turn, this enterprisey anti-pattern creates unfocused products which can be configured to sort-of-solve every niche customer requirement that might block the sale.

> The result is a massive ball of muddy configurations and feature-flags, so that learning isn't very portable and backend integrations are very painful.

[0] https://news.ycombinator.com/item?id=39188090

[wmf]

In my experience this "anti-pattern" is the enterprise software business. If you don't want to do that just don't try to go enterprise.

[pm90]

Well it’s possible to support enterprise features as part of your product roadmap without it being “hijacked” but this requires building an understanding with the client that they can’t get everything that they’re asking for right away, that they should be open to a back and forth when it comes to new product features.

Often the account managers have a Golden Goose attitude and don’t want to say no. But it’s possible to build healthy relationships that allow this to work.

[23B1]

Unfortunately it's never this simple.

PMF is a bit of a lie in that sense; there's no such thing as perfect fit, and sometimes we might have to solve for one or two major customers before we have enough runway to built the perfectly-focused roadmap product desires.

[em-bee]

that's my thought. first customer: build anything they want. second customer: add everything they want, and pay attention to what they don't want. third customer: ok, now we are starting to see a pattern. see if we can satisfy them without any custom features. fourth: ok, this is our product, take it or leave it. new features only if more than half of all customers want it. fifth: by now the first customer may be the odd one out. need to find a strategy to deal with that.

[23B1]

I mean I hate to say this but it's the stuff they teach in CS and PMI: modularity, abstraction, loose coupling, thorough documentation, version control, and design-for-change.

It's 2023 and there's a long ton of off-the-shelf tooling that makes all of this much easier than it was ten years ago.

[Terr_]

Modularity and abstraction come up against some limits when different customers have incompatible domain models, and thus different ideas of what your product ought to be.

While I've seen its historical accuracy questioned, something about this satire from Pentagon Wars still resonates: https://m.youtube.com/watch?v=aXQ2lO3ieBA

[em-bee]

not in the undergrad courses that i have taken. but that was a few decades ago when computer science covered anything related, and the degrees have diversified since then.

the problem with modularity and abstraction is that in order to make that work you need to step back and be able to build tools and frameworks that are completely independent of customer requirements.

ruby on rails is a successful example of doing that, and other frameworks that came out of some industry need. but a startup who is just getting their first customers doesn't have the resources for that, but also in my opinion are 5 customers not enough to make that move. maybe after 10, or after a few years of working you have accumulated enough experience that you are able to create something like ruby on rails that is modular and abstract enough to really be able to handle every need a potential customer might have.

(basecamp was founded 1999, RoR was released 2004. basecamp as a product came out in 2005. so it took roughly 5 years of consulting work for RoR to emerge)