Author: Marcus Bointon

Posted on

…and after the MVP?

You may be familiar with this triangle representation of a “Minimum Viable Product”, or MVP. The idea is that you have a product that contains just enough of all its critical components to be actually sellable, and the pink shaded area represents the amount of work or resources required to bring it to fruition, out of the “full” range of possibilities if budget/resources were not an issue. This diagram is usually presented side-by-side with this one that shows a contrasting “bottom up” approach:

The same amount of resources just fills the bottom layer, giving you lots of functionality but no way of using it, making it unsellable.

That’s where the analogies generally stop. I’ve encountered several misunderstandings of what happens next. Firstly, “the same, but bigger”, where more budget arrives, accompanied by a matching expansion of the spec:

Sure, you get “more” built, but it’s still the same proportion of what you’re aiming for, so it has not really progressed beyond the MVP.

Next we have the “expanded spec”, where the intended implementation is increased, but the MVP implementation stays where it is (i.e. no additional outlay). While management might want the MVP proportion to scale with the spec, of course that doesn’t happen – you have just made your MVP proportionally smaller rather than bigger, likely breaking its “viable” status:

Next up, is “do the same again, because scaleable”!

This is clearly a management disaster, and might be illustrated by jumping straight into a basic project using kubernetes and microservices, or perhaps writing the first page of all the chapters in a book. You will drown in complexity while achieving less than the intended MVP.

The missing image is very simple, I’ve just never seen it actually drawn; it’s this:

Stick to your plan, implement more of it as resources and budget permit. This may involve rebuilding some of the things you did earlier but bigger/better/differently, not just adding. There is another common set of these diagrams that uses a skateboard / scooter / bike / motorbike / car progression analogy that does work a bit better to convey that (e.g. both skateboards and cars have wheels, but skateboard wheels are not good enough for a car). That’s all.

Posted on

Should I build a PHPMailer video training course?

I spend a lot of time working on PHPMailer, and even more answering questions about it on Stack Overflow, yet gain very little from doing so. There is a certain amount of professional pride and reputation involved, but that doesn’t pay the bills. I am lucky enough to have a few GitHub and Patreon sponsors (thank you!), but that doesn’t amount to much. The same questions come up again and again, and repeating the same answers over and over, to people who are convinced that they must be the very first person ever to have had trouble sending email through GoDaddy, gets dull and tiring. I also run Smartmessages.net (a privacy-first email marketing service), so I am continuously exposed to large-scale email issues that small senders never have to worry about, but that are near-impossible to find advice about.

Email is a funny thing; it’s been around forever and is absolutely taken for granted, but it’s horribly complicated (way more so than, say, HTTP), and many developers, especially new ones, have absolutely no idea how it works – hence the repeated mistakes. Email grows more complex by the year, with the addition of things like SPF, DKIM, DMARC, ARC, MTA-STS and more. Some of it is really quite tricky yet the resources available for it either suck or are decades old. I’ve previously pitched book proposals to popular publishers (including O’Reilly and Packt) on “Modern email”, but have always been rejected on the basis that it’s not of interest or “outdated”, even though email usage is forever growing and changing.

So I’ve been thinking about putting together a training video course on using PHPMailer, diagnosing related problems, and using email in general. Such courses are apparently very popular, though I have to admit to not using them much myself, preferring text. I’ve been heartened by the success of projects such as Christoph Rumpel’s Laravel Core Adventures, along with his valuable advice on how he built that. I’ve been impressed by the lovely Jeff Geerling‘s dedication to his ansible book and audience, and have contemplated going the self-publishing route, but a book is a really big commitment, especially on such an enormous subject as email. Video courses are a bit more flexible, though keeping them up to date has its own issues, as Jeffrey Way has said about his amazing output on Laracasts.

The big issue is my audience. I know that it’s going to be primarily junior and novice developers with little experience needing help putting together their first contact form, so it needs to be pitched quite low, at least to start with. I gather that the primary feeder for video courses is social media, but my social media profile (principally Twitter; being a privacy advocate means I really don’t want to go anywhere near Facebook) is mainly more experienced developers, who are probably not the ones who need this kind of help, though you never know – it may just be my impostor syndrome assuming that all these clever people already know about this stuff!

In summary: there is fertile ground for such content, there’s little competition, I’ve got all the experience, equipment, and position needed to do it, but I need some help and encouragement with putting together a platform and reaching my audience. Finally, since I really need to dogfood this sort of thing, please sign up to my PHPMailer mailing list!