MIT OpenCourseWareSession 8: Diffusion with Endogenous Scope and Quality
MIT OpenCourseWare
Problem and model 0:00
Hazhir Rahmandad frames an endogenous diffusion model built from Jack Homer’s work. The example is a pacemaker market that changes over time. New features expand use, while bugs and negative findings can shrink it. Research matters because it reveals safety, effectiveness, and problems that customers may discover and spread by word of mouth.
Modeling choices 3:30
Students say they struggled with how to represent bugs, how scope of use relates to technology advance, and whether to build the model in small steps or by first laying out the whole picture. He says the first iteration needs that big picture, even if you leave some dynamics out. He also reviews several class models, noting common stocks for adopters, features, and discovered or undiscovered bugs.
Scope and utility 23:01
The discussion tightens the adoption side first. A negative flow can make sense if side effects later push a feature out of scope, but the speaker warns that adding max zero can hide a real problem such as negative potential adopters. He also says the adoption-gap idea may double-count what the Bass diffusion structure already handles. On the supply side, the model uses R&D effort to create technological capabilities, and those capabilities raise utility with diminishing returns. The suggested fix is to keep the concepts aligned with their units, and to use a smooth curve or derivative for marginal utility instead of forcing utility to jump to one.
Scope and adoption links 42:30
Two ways of wiring scope and adoption are treated as acceptable. You can combine the effects and let one adoption flow hit both the addressable market and the move into actual use. Or you can split them, with one gate bringing people into scope and a second gate moving them to adoption. The second form is clearer and easier to follow, so that is the one he would lean toward. On bugs, the key point is that undiscovered bugs should be a coflow with feature development. If a poor release reaches the market, it enters the undiscovered bug stock. Discovery should then depend on adoption, and recent adoption may be better than total adoption because new users expose problems faster. Bugs should be unique, not double-counted across users. He also says fixing bugs and adding features are separate resource choices, and bug fixing can be treated as the priority first.
Budget and bug fixes 1:01:00
Bug discovery should come from the recent adoption rate, not the total stock. Bugs can be treated as buggy features or an error fraction, which keeps the model cleaner. The discussion then turns to budget rules. R&D should be prioritized first and bug fixing second, but the opportunity measure for spending is too tied to a capped parameter. Normalizing it now keeps the scale stable and easier to use.
Ross's scope formulation 1:06:32
Ross’s model starts with users, potential users, and scope of use. The current scope factor is normalized by initial features, so it can rise above 1 and create trouble later. A better start would use maximum features as the normalizing factor. The time-to-adopt and user flows otherwise make sense, because indicated users can fall and push people back the other way when perceived utility drops.
Scope and feature flow 1:22:00
Scope is treated as moving toward a maximum, with investment slowing as the gap closes. Hazhir says the simple version is only a switch: above a threshold you develop features, below it you stop. A richer version uses time compression diseconomies, where packing too many features into one project makes development more costly and makes marginal value matter.
Adoption and bug issues 1:28:01
Adoption comes from the gap between current adopters and the maximum, scaled by perceived utility. Known issues can lower utility, and unknown issues may matter too for online products. He also pushes for consistent units: scope should be in features, bugs should not be compared to adopters, and normalization should reflect features so the model stays clear and general.
Feature utility and scope 1:41:31
The discussion starts with a feature model built around a maximum number of features. Features rise quickly at first and then more slowly, with R&D pressure feeding back into the time to add them. The speaker questions the use of marginal utility as both a derivative and an input to utility, but accepts the trick if you need to compute total utility from a known marginal curve. He recommends folding the extra “strength” term into the main utility effect so the model stays simpler. He also pushes for an initial utility value that is calculated from the feature limits, so the indicated fraction stays between 0 and 1.
Scope and quality links 2:04:31
Scope and perceived quality both feed perceived utility, and that utility then drives Bass diffusion. Because scope and quality stay above zero, the model keeps adoption moving unless quality perception falls all the way to zero. The speaker questions a quality measure based on unfixed issues divided by fixed issues. It breaks early in a project and scales badly over time.
R D and adoption 2:09:30
R&D investment should be in dollars per unit time, not divided by average time to develop apps. Scope growth is driven by the gap between maximum capability and current scope, then translated into a fraction of population served. Perceived utility comes from usefulness and problems, and adoption time falls when perceived utility is high. Alban's version adds asymmetric adoption and abandonment, but bugs need normalization.
Policy analysis questions 2:29:00
Matching markets, novice entry, and supply-demand balance are the policy levers to think about. If demand outruns supply, novices may do low-quality work and hurt reputation. If work dries up, novices leave and experts disengage. He does not think you need full cost-benefit analysis for this exercise.
AI-generated summary. It can be wrong or incomplete - check anything that matters against the original.
