Kevin Shtofman asked teams to define the business system before they designed the technology. In his 2018 Constructrr interview, he called the first version a minimum viable ecosystem: the smallest group of participants needed for a meaningful transaction or pilot.
That phrase changes the unit of planning because the first deliverable is not code. It is a clear account of who must participate, what each party needs, and which rules they must share.
Draw the participants around one transaction
Kevin described real estate work involving owners, developers, brokers, lenders, managers, regulators, attorneys, and other parties. Not every use case needs every participant, but a pilot cannot ignore someone whose decision makes the transaction valid.
The minimum viable ecosystem is the group required for the bounded case. Their concerns, roles, and data responsibilities need to be understood before the team can decide what belongs in a shared system.
Run the fit filter before choosing the architecture
Kevin Shtofman gave a set of conditions for blockchain fit. His list included shared data, multiple parties, verification or trust concerns, intermediaries, and dependent transactions. He was also clear that ordinary automation or better data management could suit other problems.
Use the filter to make a choice, not to justify a technology already selected. If those conditions are absent, a blockchain may add complexity without addressing the source of the delay.
Settle the clauses before encoding them
Real estate transactions gave Kevin a second boundary. Deals contain conditions, legal clauses, and participant responsibilities that become harder to automate as their complexity grows.
Code can execute a defined rule, but it cannot resolve a business rule that the parties have left vague. When the exception still requires manual interpretation, the pilot should make that human review visible instead of pretending the entire transaction has been automated.
Let the first proof earn the next participant
Kevin Shtofman put his 2018 advice plainly: “Think big and then start small.” Prove one useful case, learn from it, and use that result to bring additional participants into a later stage.
For the first planning session, select one transaction and name the smallest group whose participation makes the proof honest. That gives the pilot a boundary, a reason to exist, and a clear point at which the team can decide whether another stage is warranted.
