Context 🧪#

When I first considered the Digital Bulletin Board (DBB) for cities, I thought testing it would simply mean building a prototype and asking for feedback. But reading LeanStack’s guidance on The Art of the Scientist and The Art of the Innovator completely reframed my approach.

Testing isn’t just running experiments—it’s a structured way of learning under uncertainty, inspired by the scientific method.

The Art of the Scientist 🔬#

Science isn’t about random experiments. Nobel-prize-winning physicist Richard Feynman describes it as:

1. Formulate a theory
2. Make predictions based on the theory
3. Validate or invalidate those predictions through experiments

Crucially, if a theory lacks a good explanation, we often reject it without testing because resources are limited. For example, a theory that eating a kilogram of grass cures the common cold is testable—but not worth testing.

Einstein’s theory of relativity shows the opposite. Even without immediate experiments, his theory gained attention because:

• It offered a plausible explanation of the universe beyond Newtonian physics
• It could predict outcomes, like the bending of light during the 1919 solar eclipse
• He developed the theory through thought experiments, not empirical tests

For DBB, this means I don’t have to launch a fully working system to test whether it’s valuable. I can start by:

• Building simple models of city compliance workflows
• Running thought experiments to see if DBB reduces risk or improves transparency
• Prioritizing assumptions that make or break adoption

The Art of the Innovator 💡#

Many people oversimplify startups as either:

• “Rush to build a product”
• “Execute a perfect plan”

Both are myths. Most early products fail, and a perfect plan rarely exists. Lean Startup principles suggest:

1. Sketch a Plan A or business model
2. Identify the riskiest assumptions
3. Run experiments to validate or invalidate the idea

But, like in science, testing too early can waste precious resources. If I blindly test DBB without first checking my assumptions, I might invest in the wrong features or misunderstand city needs.

Instead, LeanStack recommends stress-testing business models first:

• Use logic and thought experiments to challenge assumptions
• Check if the explanation makes sense before empirical testing
• Only then run small experiments to validate predictions

For DBB, I can simulate city compliance scenarios, estimate the cost and time savings, and see if my proposed solution logically delivers value—all before coding a single line of software.

Insights & Takeaways ✨#

• Testing a business model is about stress-testing explanations first, not jumping straight to experiments
• Thought experiments save time, money, and risk
• For DBB, my first experiments focus on assumptions about compliance anxiety, adoption, and accountability, not features

Open Questions ❓#

• Which assumptions should I prioritize in thought experiments for DBB?
• Can I simulate city workflows accurately enough to identify weak points in the model?
• How do I know when a model is strong enough to warrant a real-world pilot?

By approaching testing like a scientist and innovator, I can learn faster, reduce wasted effort, and improve the odds of creating a solution cities actually adopt.