This is a guest post by Dorian Taylor, with whom I’ve been having a thought-provoking Twitter conversation about design. Here is an interesting pecha-kucha talk by Dorian that kinda explains where he’s coming from.
When I first encountered the phrase minimum viable product, I thought to myself here is a term that is ripe for misinterpretation by droves of hyperpragmatic undergrad-aged startup founders with a cheque from Paul Graham and more energy than sense
. Admittedly it’s an appealing concept even if you don’t fall into that category, but it’s in my nature to take things apart and play with them.
My understanding of the goal of the minimum viable product is to arrive at something you can sell in as short a period as possible. Its purpose is to get answers to empirical questions that can only come from customers and users, while at the same time getting paid. Awesome idea. Just a couple of questions:
What exactly is viable?
I’m going to use the definition of a viable product as one that you can sell and eventually profit from. It’s worth noting that the appeal of software to customers is inextricably connected to, but distinct from desirability, the appeal to users.
One of the first things a user experience designer will point out is that customers and users are not necessarily the same people, such as with enterprise or educational software. For a hosted app vendor, such as where MVP got its 15 minutes, it’s the users who are often the customers, primarily paying attention, which I’m told is tantamount to paying money.
Whereas a conventional business has customers first and users second, a software company, especially a Web-based software company, has users first and customers second, due among other things to a protracted period of trying-before-buying — but I’m probably not telling you anything new here, so moving right along.
If users have primacy, then the path to viability is through desirability to have an ongoing relationship with the product, or at least glean substantive value from its output. But the central empirical question that only your users can answer is indeed if they want to use the product, which they can only do by using it. Which makes sense if the product is novel. After all, you can’t do market research if the market doesn’t exist yet.
Software tends to exhibit the following pattern: there’s a pittance of business logic, which is what you’re trying to test, surrounded by a profusion of cladding that enables people to put it to work for them. The problem I see here is that just about every programmer I’ve ever met considers the latter, at best, slightly less important than the former.
While you may not yet know what is desirable to users, you can probably compose a decent list of what is undesirable. I’ll get you started: Non-functioning UI elements, alert boxes, dummy text, stack dumps, data loss — just off the top of my head. Unless your target users are patient developers, it might make sense to have your macro-level implementation priorities set by someone who considers the product from the outside in.
What counts as minimum?
In Notes on the Synthesis of Form, Christopher Alexander remarks that while it is fairly easy to get consensus in a group on what constitutes a valid requirement, it is nearly impossible to get people to agree on their priority. In fact, that entire book is all about rescuing the generic design process from the vagaries of human whim, bias and self-consciousness.
This is what originally raised my eyebrows about the MVP: the thought of a room full of developers bickering over what work not to do. Actually, it’s more than a thought. It’s a compilation of far too many memories.
If the goal of the MVP is to get selling quickly, the fact that you can have a protracted argument about whether or not a particular unit of work is part of the minimum set flies in its face. Often it’s faster just to do the work, minimum or not. This isn’t just an issue for teams either, unless you are immune to lying awake at night vacillating over whether to work on one aspect of a system or another, or do something else entirely.
This situation is exacerbated by the fact that a programmer is actually an executive. That’s right: every line of code you write can be considered your own executive microdecision. While you may be getting told what results are expected, your articulation of the solution is going to be your own. You know this because these decisions can turn out to be business-critical, and because you invariably have the most information about what you are working on. If this wasn’t the case, the person who did could probably do a better job, and faster.
If, as an executive, you contravene your own better judgment, especially at the behest of somebody else, ugly things start to happen. You lose trust in your work. You risk becoming cynical or apathetic from consciously proceeding in a way you don’t support. Your ability to estimate goes out the window, assuming it was ever there in the first place. And if the endeavour fails, the finger will probably still be pointed at you. But even if it isn’t, you knew better but were complicit anyway.
So whatever putatively superfluous effort you value, you’re going to want to do it. You’ll sneak it in after hours; pull an all-nighter if you have to. If you don’t, you’re going to obsess about it. If you’re a security nut, spend the time to sanitize your inputs or it’s going to drive you bonkers. If the database is your thing, you’ll kick yourself every day you don’t properly normalize it. If you’re a stickler for code indentation, stop stewing over it and just fix it. Worrying about whether or not what you’re about to do is part of the minimum set is categorically a waste of time. If it’s expedient, do it now.
As for behaviour that is desirable to users but not challenging to programmers, at least it’s easy. Let’s face it: bugs like the order in which buttons appear on a screen get triaged into orbit, so it’s easier on everybody just to get them right the first time, or as close to it as possible.
Expedient Desirable Product
There is valuable work you can complete and deliver today that is not part of the minimum set. To confirm its absence from the set or to discuss it with your colleagues would take time, potentially more time than it would take to do the work. To omit it would deprive the product of its value. Rather than argue about it, do the work and capitalize on it.
There is also work which is not on the main program but still valuable: a tool, a document, record-keeping, even tidying your work environment. Again, if you have all the means and the motivation to complete it now, do it now. And if it produces an artifact you can sell, all the better. If you can’t sell it but it can augment your colleagues’ productivity as well as yours, remember to share it with them.
The question I expect to be asked at this point is how do I deliver a product on a deadline with all these diversions? How do I propose to keep a schedule if I’m constantly going off-task? The answer is I don’t.
At least, I don’t in the conventional, Gantt-chart sense. Well-understood deliverables that result from well-trodden processes conform nicely to a schedule, but how much of that are you really doing? Your productivity as a knowledge worker of any kind is predicated on your ability to solve problems, and that can’t happen without the right inputs. At the same time, you may experience an eureka moment with a different problem entirely, and it would be wise to capture it while it’s hot. Some might call this procrastination, but I prefer to think of it as opportunism.
Besides, the only time you have to worry about being on-task and on schedule is if you have some other kind of obligation to which you’ve committed. Oh, right.
That Whole Management/Financing Thing
The kind of deal we typically strike in a business endeavour is to produce Result X, such as the archetypal MVP, by Date Y, which is reified by a dollar figure from a departmental budget or a round of funding — a throwback to the methods of manufacturing or construction. This is fine if you have solved the problem already and it only remains to execute it. But software is nearly always novel by definition, which means there are many unknown unknowns and unprecedented decisions that will need to be weighed and executed.
Realizing modern software doesn’t normally take big lump sums of cash. The currency of software acquisition and similar novel and complex problems is contiguous blocks of time in which individuals can concentrate — literally fetching disparate pieces of information from all over, organizing them in one place and synthesizing new information from them.
The rub is that information is infungible. You cannot substitute the bit that depicts whether or not I like crème brulée for the one that indicates my preference for sea urchin any more than you can swap those ingredients themselves. Acquiring specific bits of information takes a wildly arbitrary period of time, especially when you don’t yet even know you need to acquire them. And to echo the admonitions of Fred Brooks, your Result X won’t be achieved until you have the full complement of relevant bits in your possession.
Note however that this is not necessarily a long time, it’s arbitrary. Finding a missing clue could take seconds, a lifetime, or never occur. I’m told in the Real World™, however, things need to get done, and that means compromise. But as we saw, how can we tell which compromises are cosmetic and can eventually be buffed out, and which will lie dormant only to cripple the product a year or two later?
And the purpose is what again? Time to market? So you can get a few more days, weeks or months on the front of the product’s lifespan in trade for potentially years on the rear? If, at the cost of your health, you went on a coding binge that made EA look civil in order to heroically power-slide into the deadline, you would certainly have something when the dust settles. Why not shed the pretense that something is going to resemble Result X as originally conceived, take your time, and release something else instead?
When we focus too intently on Result X, we become blind to the notion that some piece of the intellectual capital we generate on a daily basis is bound to be within a degree or two of merchantability, which we can handily have ready to ship today, let alone Date Y.
The conventional method of financing and managing software, however, appears to be to say we want Result X by Date Y, here is the money to build it
. The problem is that there’s no building going on. Once you have concentrated the information relevant to the problem and synthesized a solution you can articulate to sufficient precision, that’s it, you’re done. The code is written. If there’s any part of the method of production shared by manufacturing and construction that software acquisition actually resembles, it’s the copious research and planning that happens before the capital is allocated to build.
As an entrepreneur, you could argue that a huge parcel of VC financing is sure to see you to profitability, but the stakes on that bet are pretty high. It’d be harder to convince yourself of that on your Series G round, assuming you hadn’t gotten the boot by then. But the task isn’t to build a factory or launch a comprehensive marketing campaign or any of the other expensive things you do with big capital investments. We’re talking about keeping a small group of people off the street long enough to realize a product that will cover their expenses and then some, and from there they can take care of themselves. Arbitrary indeed, but probably trivial. Once their product works, they can dock with the big-capital mothership for the means to make it scale (i.e. marketing, sales, support).
The micro-VCs have the right idea about the scale of the investment (and concomitant equity stake) but still appear to cast the deal as an all-or-nothing construction project. A profitable business can easily pay somebody to just invent things all day, but I’m not sure how that would translate to equity financing. Patronage 2.0, perhaps? Might be worth a try.
Though if you’re contemplating one of these ventures yourself, it’s a good chance you already earn a great deal of money relative to your time commitments. You could realistically slash your obligations to sequester as much contiguous time as you can to solve your problem, and keep an eye out for opportunities to cap off old, unfinished problems, or to execute those you’ve already solved. They may come sooner than you expect.
The Real Enemy is the Vacuum
Software is made of information and uses it as raw material, and we know that information cannot be substituted. A certain quantity of it will indeed have to come from customers and users. Much more of it is available from numerous other sources that do not require promising a product. A surprising amount is lying around close by, in varying degrees of conspicuity.
The most important factor for keeping the pace of a software or indeed any other creative or problem-solving endeavour seems to be to get specific answers as quickly as possible. With that the rationale behind the MVP is clear.
Though we may do our best to facilitate the inbound flow of information, there will invariably be service interruptions. When we are focused and committed to a single objective, this shortfall of information poses a quandary when it comes time to make a decision, in which we either vacillate or commit to a suboptimal solution.
It’s hard to say which is more hazardous, no decision or an arbitrary one. I recall a Teddy Roosevelt quote recently co-opted by some Agile evangelist or other: In any moment of decision the best thing you can do is the right thing, the next best thing is the wrong thing, and the worst thing you can do is nothing.
Rallying words for the early 20th century, when the keystroke wasn’t quite as potent.
When a vacuum forms around one objective, we would do well with the discipline, freedom and support to switch to another. After all, who really cares, honestly, what you work on, as long as you deliver something?
- Your customers or users?
- Not if you don’t promise them anything specific.
- Your investors or employers?
- Not if you’re busy making them rich.
- You?
- ???
About Venkatesh Rao
Dorian: I think you are critiquing more than MVP. You are critiquing the notion of goals and outcome descriptions entirely. This, I whole-heartedly agree with. Also, great Glengarry Glen Ross ref :)
If you don’t really have a clue what’s hard and what’s not in getting a product vision implemented (true if you are trying to pull of a truly innovative concept), without trying to actually do it, then getting married to a product vision is stupid because you may realize at the end that you’ve won a Pyrrhic victory: the shortest, cheapest path to that vision might still be “not worth it.” The product should be “whatever useful place you can get to cheaply, with the most bang for your development bucks.” If in following this philosophy, your next generation tax planning software ends up as a 3D game, so be it. That said, this process needs to be conscious, and the customer development process needs to track and even run ahead of it a bit, or you’ll be trying to sell 3D games to people looking for tax software.
So yes, in that case, I am a big believer in expediency. I’d state it as “build whatever you discover seems most valuable.” And valuable here is in terms of the leverage of effort.
That said, though goals (and goal set) features are not completely controllable, the degree of influence of user feedback IS. Here, the ideas of controllability and observability from systems and control theory is valuable. If a bit of work is never (or rarely) observable in the UX and/or cannot be meaningfully impacted by anything the user does, putting in too much effort there simply because it scratches a personal itch, is not justified. Fortunately, most good product builders (s/w or h/w) usually end up with itches that DO impact the UX, even if only for a very small class of users for a very small, but important proportion of their time. The priority computation becomes very easy if it is mainly about probability and magnitude adjusted UX impact. Input sanitation doesn’t affect 99% of users, but does affect hackers, so it is worth paying attention to, since a security hole COULD mess up the UX for all 100% with a nonzero probability. Ditto things like scaling and load-balancing work. Not observable in the UX under normal circumstances, but if you ever get that nice-to-have spike of traffic, 100% of users will be impacted (which may actually be 1000% with respect to the pre-spike base). Even apparently user-unrelated features like a good admin panel for the product team, matter, because if that doesn’t exist, response time when things break skyrockets, impacting the affected users.
All that said, there is something of real value in the MVP idea that I think we might be missing here. Eric Ries’ truly extreme examples, like running an AdWords campaign pointing towards a vaporware page… I think that’s a brilliant idea. Maybe it ought to be called “desirability testing” or something, instead of MVP.
Venkat
First, thanks Venkat for airing this post.
I guess the thing I was really trying to capture was that software, to me at least, is really crystallized method. The code I write is my articulation of my opinion of how a certain problem ought to be solved.
But a product, even a tiny one, is still a really big problem. And I’m almost completely convinced that you can’t have an opinion of a method for solving a problem you can’t at least circumscribe if not fully, deeply, intrinsically understand it (grok, as Heinlein intended). Once you have the problem fenced off, you can start mapping out its innards.
If you can’t circumscribe the whole problem (but somebody has to, that’s pretty much conceptual integrity defined) you at least have to circumscribe your part of it, certainly before you start promising delivery dates. Otherwise you get mud.
Within that process, though, arises this anatomy of fenced-off problems and corresponding solutions. These problems almost certainly generalize and thus their solutions will almost certainly have different applications that could be put to use right away.
Furthermore, when I look at my own stash of IC, I have more stuff lying around than I could even realistically find or identify. If I had organized my work as a mapping of discrete problems and solutions, I would probably be doing much less duplicate effort and more importantly putting more of it to economic use. It’s also worth noting that these units are fundamentally smaller than the conventional notion of a product. Take Ted Nelson or Doug Engelbart’s attitude with respect to files as a basic unit of data storage and apply that to business deliverables.
I chose input sanitation as an example of quasi-superfluous effort because in my experience it is much more likely that you are going to incur a failure due to malformed input (especially in a client-server model) than malice. Therefore if you took the time to do it, you could troubleshoot much quicker, and it would be orders of magnitude cheaper to clean up.
I’ll give you an example: I worked somewhere that dealt with customers in 15 languages and the desktop client developers didn’t normalize the encoding on their client so data was entered in whatever native character set the user’s computer was set to. The result was an Oracle database full of years of UGC that was illegible and we (er, I) had to clean it up. While I have a black belt in charset-fu, a significant portion of it was unrecoverable and it wasn’t like we could go knocking on thousands of users’ doors to ask them in whatever language we think they’re speaking to please reenter their data. In that case we’re talking about a fix that would maybe take a few minutes on the inside and on the outside a day, and who knows what the total cost was of not doing it. It’s safe to say that the client developers didn’t take character sets into account but if I was in charge of that team and and consciously struck that from the to-do list, I’d feel like a bit of a (soon-to-be justifiably unemployed) knob.
Ries’ method of buying AdWords as a way of soliciting votes for a product is pretty innovative. Only I wonder how it scales. I can see it being effective if the message is “would you like an X that does Y?”, where X is something familiar and Y is something new, but I’d wager it wouldn’t work for something totally alien. Maybe he’ll show up and can chime in on that.
Also, this is 2010. I mean come on, doing your taxes should be like playing Tetris.
Often it’s faster just to do the work, minimum or not.
ROFLMAO
Yes indeed!
Reminds me of days of yore (1980’s personal anecdote), being a consultant on medium sized project ($8m) I once asked for a fairly simple change in the specs, a given timeout had to be increased from 100ms to 200ms, covering two sampling cycles instead of one.
Instant bickering response from various contractors, that’s a MAJOR change, we could never have expected that, this needs a contract addendum, more money, more delay and blah, blah, blah and several ensuing meetings with tech people, legal people and project managers of the involved subsystems (there were some hardware and multiple software components) lasting for hours with a lot of highly expensive people, including me.
As a representative of the project owner, though, I had some ways of retorsion and all finally caved to implement the change.
It happened that I personally knew the developer in charge of the piece of code to be amended and asked him:
– How long did it take you to make the change?
– Oh, about half an hour…
It seems that this article also touches on Ward Cunningham’s notion of “technical debt”. This metaphor is a nice way to explain to a client the importance of doing it right, and gives you a business case to address it (ie. that the debt will gain interest and you will have to pay it off in the future).
Yes, that certainly seems to belong in this discussion somehow. I only heard about the tech debt concept last year, and though I haven’t properly wrapped my mind around it, it seems like a very useful one. In a sense, it is an operationalization of Knuth’s old saw about ‘premature optimization is the root of all evil.’ Tech debt is the punishment/burden of that necessary evil.
I used to think the tech debt effects are bigger in manufacturing than in software (eg. design changes after the assembly line tooling is complete, and inventories have been stocked up and the first production run is underway). But now I am starting to believe that for complex software, the tech debt effect can exceed the hardware manufacturing cases.
Venkat
Technical debt can bedevil you in non-obvious ways. Any non-trivial amount of technical debt is difficult for the developer who “charged” it to measure, and more difficult for most others. Worse, the cost can explode (the developer who “charged” it left just before the performance hit it embodied became catastrophic, and the new developer doesn’t understand his code after reading through it 5 times) or even evaporate (the company abandons the product that uses the code).
Good point. One person’s technical debt is another’s irreversible technical entropy!
Venkat
The main comment I have on the notion of technical debt is that it isn’t exclusively technical. It is at least as much about politics within and between business entities, and likewise about economics.
We can understand any segment of code as being a reflection of how its author understands the problem, and his or her capability to express it. It also reflects the amount of attention the author is willing or politically able to devote. Likewise, some decisions that contravene the author’s best judgments get handed down arbitrarily by authority, cultural norm (e.g. a “Java/MS/LAMP/whatever shop”) or just by default.
This, of course, happens all the way up the stack, which manifests as the entropy of which you speak. From what little I understand of physics, any reduction in entropy in one place merely creates it in another. With information entropy, however, we seem to be able to generate it in geometric proportions. Merely moving it around is about the best we can hope to do. More importantly, a lot of the entropy is completely unnecessary, but just like real debt it comes from a perceived scarcity of resources in the short term to understand and express, that is to characterize, the problems that we’re trying to solve.
This is part of the reason I’m skeptical about many of the Agile practices, because while they have the right idea about responding to reality instead of trying to prescribe it, they still have a tendency to cast conceptual problems as those of technical implementation. While I acknowledge there is plenty of information you can’t get without empirical research and experimentation, I think the allure is often too great to try to incorporate the (executable) results of those experiments into the final product, and that is a huge source of entropy right there. In the past I have advocated strict policies around disposing prototypes, even intentionally prototyping in languages other than the one you intend to ship.
The ability to cheaply implement something right away is almost always a siren song. Especially if you ship it, because that is at least a tacit if not explicit promise to customers and users to deliver some kind of utility, and a star-burst BETA badge isn’t an especially adequate disclaimer. The principal failure mode I’ve observed with respect to any process intended to acquire a technology is that it gets oversold by sales and marketing and reverts to a death march, usually with the help of the developers, whether they are aware of it or not.
There is one reality that any software development process, including the Agile ones, still attempt to prescribe, and that is when the product is going to be delivered. This is part of my inspiration for the expedient desirable product. The problem, to me, with attempting to prescribe a schedule of any kind when it comes to any sufficiently novel endeavour is that it does not account for the fact that it reduces to individual people gaining comprehension of a set of concepts and how they interact with one another and then articulating that in preferably some concrete form. But information is infungible, and you can’t predict when or how you are going to acquire any particular piece of it. But one thing is certain, you won’t succeed until you acquire the information you need to continue, or find yourself a bagholder. I think we see way too much of the latter, frankly.
Despite all this, I know that if I sit down for a few hours in front of a computer, I’m very likely to create something of value. As long as the little red record light is on, even data gathered from a Web-surfing expedition (right Venkat? ;) can be useful in abridging the uptake of the same body of knowledge for somebody else. At least half of my work is learning new stuff. I’m also pretty confident about the amount of time to devote at once.
I may not be able to prognosticate when a certain problem is going to be solved, but I can count how much it costs to purchase four hours of a creative professional’s attention, and I can likewise observe what he or she generates, as it is added to an inventory of understanding. I can also recombine the contents of that inventory to create more sophisticated results, and recursively feed them back in. So the value of any individual’s half-day stint is completely arbitrary, as is the net value of his or her contribution. Likewise, this process of technology and product acquisition is not linear and continuous, but discrete, recursive, and ultimately fractal.
@Dorian Taylor
Cool down, all this philosophy is useless.
As a 63 old retired software engineer I can tell you, software development is a mess, has always been and will always be.
On any project you have 3 constraints, functionality, schedule and budget, you can control any two of them but not all 3.
Happy exceptions are just that: a stroke of luck due to chance circumstances.
@jld,
Philosophy is useless if and only if you’re sure about what you’re doing. If you don’t have that, your project triangle is irrelevant. In my (albeit limited, 31-year-old, retired software engineer) experience, engineering is what you do when you know what to do. Every single project I’ve ever worked on, the main challenge has been to establish exactly that.
Thanks for your comment.
Every single project I’ve ever worked on, the main challenge has been to establish exactly that.
Yes, your experience is right on!
The trouble isn’t mainly technical it comes from the clients, they don’t know what they want even less so what they really need, you have to outguess them.
With a bit of skill it may work.
For the anecdote, I was working in Belgium for a medium sized company when they introduced the VAT.
I went to the head of accounting who, strangely enough, was overseeing IT and told him: from now on you better record the tax rates for every item sold.
Response: All that shitty tax business has nothing to do with “real” accounting, I don’t want to see anything about VAT in my accounting files.
Fortunately, at least for invoicing, the tax rates had to be entered for each item, so I managed to store them in a “hidden” file which would never show up on any report or “official” file list.
Surprise, surprise, by the end of the year the fiscal administration required various detailed sales reports per tax rate.
Too bad, the accountants would have to reprocess all sales inputs for the whole year in order to sort sales amounts per tax rate.
After the heat built up a bit I suggested a miracle solution to come up with the desired data without ever explaining about the hidden file.
Per your anecdote, it’s most accurate to say that I’m completely uninterested in doing business that way. Furthermore I believe there are other ways to do this kind of business. Much of what I’ve been about for the last few years has been to find ways to achieve complex goals without incurring an all-or-nothing risk. In short I refuse to guess and especially to outguess anybody about anything.
What I found, however, was that all-or-nothing risk is inescapable. What I can do, though, is bash one big risk into a number of very small ones. The whole idea about an expedient desirable product, which is an intentional play on Eric Ries’ minimum viable product, is that it is what one person or a small group can deliver in a single business day. But it’s important to recognize that I’m not talking about delivering software in a day, not specifically. I’m talking about creating a feedback loop in which many kinds of artifacts can accumulate and be recombined with one another in successive levels of complexity. This extends the conventional product calculus by a dimension, such that I can achieve fast, cheap and good all at once, but I can’t say what I’m going to end up with at the end of the day.
I recognize, and I believe I accounted for, the fact that this turns conventional project management and likewise product marketing, fiscal behaviour and financing methods upside down. The other contention I hear often is that if you don’t apply a priori constraints on time and resources, the project will never get done. Consider me jaded, but I have experienced way too many projects that did operate under significant resource constraints, and they never got done. This is why I have gone in search of an alternative.
Possibly the most important thing I realized was that the conventional notions of product and project are just deals. Between people. There is no physical law that ordains how they ought to be laid out, with one possible exception: complex objects decompose into sets of simple objects, and complex processes decompose into series of simple processes. But it is important to recognize that their respective scopes are finite. This means that we don’t have to worry about doneness, because it is built in.
The deal we are used to is to add up the cost of materials, work out how many people it will take over how long, and tender a bid (or in the case of startups, a business plan). I submit that anything that can be called an engineering project is about the upper bound of complexity for which this model works. Building: start at the bottom, end at the top. Railroad: start here, end there. Freighter: start with the hull, end with the bridge. Et cetera.
I can say two things about this category of project: First, they have an explicit orientation, and that progress is readily observable by stakeholders. They have a bottom/top/back/front/whatever. Post-industrial projects do not. The second, which actually applies to all projects, is that a dearth of working materials will choke them. Industrial projects use commodities as materials: steel, concrete, wood. These are fungible. If one source dries up there is a good chance you can find another. Post-industrial projects use information as material. This is infungible. Even so much as a single bit of a critical decision missing can choke a project. This I have witnessed numerous times, and it blows all hope of a rational, sequential decomposition of tasks and division of labour out of the water.
A way I see to get around this infungibility of information is to work on whatever is present and handy at the time. The cost of fetching new information is arbitrary, so I might as well not put myself on the hook to deliver something that depends on the timely sourcing a material that is so wild in character.
What I am suggesting is precisely to change the deal from the delivery of a monolith of arbitrary complexity for a best-guess cost, to the delivery of a generator of useful material which uses its own produce as fuel, and of which a fraction will be viable.
I should also note that I had zero intention of becoming a philosopher, and I chuckle every time I’m compared to one. I’m really honestly just looking for a practical way to carry on with my craft without screwing myself.
the delivery of a generator of useful material which uses its own produce as fuel
Turpentine?
I think I saw something move under that bridge over there.
The point of MVP is not time to “market” as in winning a race or getting profitable, it’s time to “finding out whether your idea is marketable or not”. The biggest technical debt is spending extra time refining a product which nobody wants (hellooo OSAF Chandler). Which, in my experience, is the most-likely outcome in software startups.
Also, I don’t think the MVP-police will lock you up if you spend some time doing something that isn’t obviously M. It’s a vision/direction rather than a binary, at least in my mind.