-
@gwenshap What I learned so far is that MVP can mean a variety of things People can claim #NoCode, Monolith, and all in between We mainly assume that we do an MVP to validate a business hypothesis. Yet, we fail to recognize that a product is build from several hypothesis and proved MVPsOn twitter.com
♻️ 1 Retweets ❤️ 2 Favorites Mood -1 🙁
-
@gwenshap We fail to recognize that not all business hypothesis can be validated without software. At some point, you need to code if the learnings drive in that direction We need to be humble enough to not give those learnings as "Hypothesis Succeed! Full speed ahead Microservices!"Permalink On twitter.com
-
@gwenshap I think you are talking about the latter. A lot of dimensions in order to make educated decisions. Today, I'm learning a lot from this book goodreads.com/book/show/55782292-strategic-microservices-and-monolithsPermalink On twitter.com
-
@gwenshap My heuristic has been to delegate as much as you can into infrastructure - Rely on your IaaS as AWS a LOT - Worth investing on CI for automated deployments - Feature Toggles are a commodity, worth for fast experimentation👈 Make decisions that boost experimentation and learningPermalink On twitter.com
-
@gwenshap Another great resource is Lean Inception from @paulocaroli I like the idea of him of a product is build from small increments, in this case small MVPs Product = reduce(FirstMVP, (product, nextMVP) => product.increment(nextMVP)); goodreads.com/book/show/38590594-lean-inceptionPermalink On twitter.com
-
@gwenshap @paulocaroli Too geek? 🤣Permalink On twitter.com