> An example of too much minimalism would be failing to implement UI pagination and your UI falling over with more than 20 objects, because you didn’t think about the use case. Maybe you haven’t thought about scale-out or upgrades or you can install on only one operating system. A serious buyer can sniff out this incompleteness and won’t take you seriously, and only serious domain experience can fill in these gaps. You can’t expect your buyer to be like “hey, nice try with this prototype but I can tell this won’t scale to more than 20 objects”. They are looking to you to be the expert.
IME this part is completely wrong, unless it's defining "serious buyer" in such a way that most of your market isn't one.
> Time is short, funding is short (especially if you are running on your own money), and you don’t want to waste time.
> Your company shouldn’t be in search of a business model, you should know what you need to build. Wait until you see the exact right thing, because you are about to put too much of your lifeforce into it, and if you don’t, you have a much harder road ahead. You want to know it will work, and this requires cultivated instinct. When the time is right and you know enough, that’s when you decide to have a product.
Ok so what is the author advocating doing until then? Sitting around twiddling your thumbs until inspiration strikes?
The whole point of the MVP is: build just enough to find out whether this is a viable business or not. And nothing in the article seems to be contrary to that. It's a whole lot of words but the only advice seems to be to have better instincts (how?) and just make a better product bro.
> IME this part is completely wrong, unless it's defining "serious buyer" in such a way that most of your market isn't one.
I used to be such a "serious buyer". I represented a large government agency with over 2,000 sites and several hundred thousand employees.
Vendors would turn up with "cute" web apps that used drop downs to select objects like security groups or user accounts. This works great when you're developing in a toy environment in your dev lab.
In the real world, merely clicking something like that will make both the server and client use gigabytes of memory until either one or both crash.
Here's the thing though: if you can put just a modicum of engineering effort into making your software suitable for non-toy scenarios, then winning even just one enterprise customer like this could make your rich. Win two or three similar orgs in other states or countries and you can start subscribing to Superyacht Owners' Quarterly.
But there will be no yacht because you used a drop-down. A simple control that can be implemented in minutes instead of a search box that takes a few extra lines of code.
Sorry...
PS: On a more serious note, I had a checklist that wasn't long or all that difficult to implement, and 90% of vendors would fail outright on most/all points.
1. Search-for-select
2. A provisioning API of some sort (REST, PowerShell, whatever)
3. Hierarchical permissions & delegation
4. Hierarchical policy & preferences
5. Single-sign-on support
6. Central audit & error logging
7. Clone-to-deploy and/or highly automated setup.
8. Don't demand Domain Admin rights for setup.
9. No quadratic (or worse) scaling issues. (USE INDEXES in the DB!!)
For large organisations the amount of entries in the dropdown is probably very large. To fill the dropdown would then require significant work on the server, and to build up and show the dropdown would require significant work on the client.
Edit, of course a proper solution would be well-thought out and would not crash, but that solution would also not be using a single dropdown to show all possible values because that is not usable when it is more than 20 entries.
Modern backends and frontends can surely handle way more than 20 entries in a dropdown without sweating.
But in case you do have a LOT of entries that modern hardware cannot handle efficiently, just switch to a selector based on a search box (perhaps with autocomplete), instead of a dropdown.
Since it's an easy modification in the UI, perhaps these startups used a dropdown for simplicity, knowing they can change to a selector search box quickly, if it becomes an issue.
> Modern backends and frontends can surely handle way more than 20 entries in a dropdown without sweating.
I agree. I meant that I as a user will not find it usable enough if I often have to search the correct value in lists of 20 or more.
The discussion of the load on the frontend and backend was about amounts large enough to create problems if the developer wrote naive code, but we did not get in to a specific amount.
because toy apps that use dropdowns like the OP mentioned will do a "SELECT * FROM security_groups" at the backend (requiring RAM for the whole thing to format the response) and then send it down to the frontend which will then spend eternities formatting the list in the DOM as a complete UL/LI of objects that will blow up the front end.
Drop-downs for unconstrained lists are just flat wrong, they become unusable at a mere few hundred entries. Even with just a few thousand, you'll see only a tiny subset of accounts/groups/objects and it'll look like this:
AADEN
AADIT
AADVIK
AAIDEN
AARAV
AARIZ
AARON
AARUSH
AARYAN
AAYAN
AAYDEN
ABDEL
ABDIEL
ABDUL
ABDULLAH
...
The rest of the list will be cut off past the bottom of the screen, or have a tiny down-arrow that will scroll down... one... item... at... a... time.
I would do the "look at the server RAM disappear like a magic trick! ...and now the whole server is gone!" demo to really drive the point home, but that happens around the 200K-1M object level (depending on the software).
About 50% of the time there would be a senior developer there who would just slowly blink at me and suggest the "solution" of cutting down the directory to a more manageable size, like 50 users.
Like... yeah buddy. We'll just delete 99.975% of the user accounts in the directory system because you learned programming from a "4 Dummies" book.
Sure, you can roll the dice on a handful of big organisational buyers, and you may find that good engineering is what they're after. But there's a whole lot of politics (organisational and other), relationships, and other stuff in play; having a heavily engineered product is not remotely a guarantee of winning that kind of contract.
Well, 2 of them are hard, the others are the kind of thing you get if you let a developer take a week or two to solve them at the beginning, but almost impossible to create after the system is built.
So, 3 months of up-front work. It very likely won't break any project/company, but it's enough of a drag that most people will say "fuck it" and not target large enterprises. And, well, there are plenty of other reasons not to target enterprises that the GP isn't talking about, so it may be a good choice.
Having worked at a large enterprise I agree that there are many good reasons not to target 'us'. However far too many companies are rocking up to sales meetings with large enterprises and have no idea about their actual needs and the scale and problems of selling to large enterprises.
Having also sold to large enterprises, you have to be willing to sometimes spend 3-6 month developing a really obscure feature that will only be used by that one customer to get the sale.
Exactly. Their advice essentially is – don't build an MVP, instead have a perfect working product with all features and a perfect market fit and huge demand with an years-long rigid roadmap on day one. Like...okay? And how do you do all this exactly?
IME this part is completely wrong, unless it's defining "serious buyer" in such a way that most of your market isn't one.
> Time is short, funding is short (especially if you are running on your own money), and you don’t want to waste time.
> Your company shouldn’t be in search of a business model, you should know what you need to build. Wait until you see the exact right thing, because you are about to put too much of your lifeforce into it, and if you don’t, you have a much harder road ahead. You want to know it will work, and this requires cultivated instinct. When the time is right and you know enough, that’s when you decide to have a product.
Ok so what is the author advocating doing until then? Sitting around twiddling your thumbs until inspiration strikes?
The whole point of the MVP is: build just enough to find out whether this is a viable business or not. And nothing in the article seems to be contrary to that. It's a whole lot of words but the only advice seems to be to have better instincts (how?) and just make a better product bro.