Composable software is key. “Do one thing, and do it well.”
Then, build products out of these strong, reliable building blocks.
That philosophy is the fulcrum that gives the Internet of Things so much potential: a world filled with simple devices, communicating intelligently together.
Today, our project trains have rightly been asked to take a step back to find concrete product ideas with tangible markets. This is important. But we have had great difficulty in coming up with inspiring product ideas that don’t sound completely infeasible for Mozilla. Why? Here’s one reason:
Achieving the Impossible
Grand ideas are composed of less-grand ideas. Big problems are composed of smaller problems.
If we wanted to build an “intelligent assistant”, we must first solve a number of largely independent subproblems:
- Speech recognition
- User Intent parsing
- An abstraction layer over supported IoT devices and services
- Algorithms for building “intelligence”, such as a basic IFTTT engine or machine-learning behavior
Building an “intelligent assistant”-like product becomes more feasible when good solutions to these subproblems already exist. Eventually, big ideas don’t seem quite so unapproachable after all.
Building products out of reusable, loosely-coupled pieces gives us the flexibility to quickly explore and execute on new products and ideas.
Mozilla is at a values-driven disadvantage, unfortunately. State-of-the-art proprietary services from Amazon and Google greatly simplify building powerful products. Many of the product ideas we’ve tossed around would be much more achievable if those services were available to us. However, because we stand for user control and privacy, we must take a different path: for some cases (and often the hard ones), building blocks that support our values do not yet exist.
Trains can’t solve Foundational Problems
Many problems don’t require a dedicated team. A product train can produce a reusable component that, in the open source tradition, other trains can use independently. But for an important subset of the problems we face in Connected Devices, casual code reuse is not enough.
Some problems are truly, deeply difficult. I often use “speech recognition” as an example, because speech is a difficult, hairy, but foundational aspect of IoT now and in the years ahead.
“Product Trains” are a wonderful idea for quickly testing new product ideas, but they cannot solve important, hard problems in a sustainable way. Product trains should be lean, agile, and focused, quickly proving the worthiness of a specific product idea. They don’t have time to dive into foundational problems without distracting themselves from their product.
Product Trains cannot build great products without proper building blocks. Dedicated teams can turn foundational problems into building blocks; trains alone cannot.
What about dependencies? Failure?
Leaders have expressed concerns that we should not place dependencies between trains. Indeed, having a “Speech Team” would place trains’ speech capabilities into the hands of one team: a capable, responsive, dedicated team who understands how to solve one problem well.
Granted, dependencies are points of vulnerability; that’s why defining clear, focused interfaces is so important when building software from decoupled pieces. Ultimately, the benefits of building products out of reusable, focused components far outweigh the inherent risks. Failure, in some ways, is the bread and butter of building blocks: when one fails or becomes obsolete, it can be replaced with less hassle.
Put simply:
- Great products are built out of composable building blocks.
- Proprietary competitors have powerful building blocks at their disposal; we have fewer.
- Solving foundational problems requires sustained investment. Product trains are insufficient.
- Dedicated teams can turn foundational problems into reusable building blocks.
