Could it be that your description of Zuora as a simple USP/single driving change business is actually a testament to the simple way they tell their story? I'm the author of the post, and every business I consult with is, as you say, "complex...addressing multiple trends or with multiple layers of innovation..." That hasn't stopped any of them from crafting a similarly simple story -- starting with a single change. Usually that means either (a) focusing on the most important one; or (b) naming a change that subsumes many of the others. Getting leadership teams to align around one change isn't easy, but I'm getting better at it :)
After I published the post, Zuora released a version of the deck that I assembled from their public slides at https://www.zuora.com/resource/best-sales-deck-ever/. It's not the deck I got from their ex-salesperson, but IMO what you can learn from it is similar enough.
IMO, pointing out the similarity between what Lilly preaches and what was — love it or hate it — a successful strategy in another field (that happens to be politics) is relevant and apolitical.
I've mainly been using Invoicely (free if you just create invoices and send them as PDFs), but now feeling bad about it because: https://medium.com/@prabhaths/invoicely-a-hiveage-rip-off-b9... I really like free, though, so thinking about switching to InvoicePlane.
I was asked to solve this puzzle once during a project management interview. The solution here says "work backwards," but I found that "work recursively" was a more helpful (and instructive) way to think about it.
Applying the maximization of benefit logic, "work backwards" is very meaningful to a very large population of readers, "work recursively" is somewhat more meaningful to a very small population.
The are very similar. Recursion is expressing a problem in terms of a smaller case of the same problem. Working backwards/induction is building up from a base case.
Recursion is exactly the same (as induction) because it also requires specifying what to do in a base case. I guess I think recursion is a more instructive term than "working backwards" because it speaks to a rigorous programmatic approach.
They could have explained it differently instead of going backwards. I tried to explain the backwards part to my mum and she didn't quite grok it.
Then I explained it from perspective of A, B, C and so on.
Wow, thank you for that link. Never saw it before. Perlis really did deliver on his intention to give us a "pou sto to last the student for 40 years, not a handbook for tomorrow’s employment." Every time I've encountered a new language or framework (Java, Ruby, Rails, whatever), I've been grateful to him. He also delivered on his intention to keep us "on the computer early and often." I didn't get much sleep that semester -- now I see that was by design :)
Edit: I had to look up pou sto. Turns out it's Archimedes' "place to stand" from which he could move the earth. In other words, the best possible foundation. A high aspiration for a programming language course.
In my opinion, it's fair to consider API-connected services — and maybe even the Web itself (which did not exist when Perlis first said this) — as "computer programs." In that sense, we're all building this cathedral together.
