This is the 3rd and last post of my ideations toward Drives (Google Drive, Dropbox, iCloud, etc.).
Post 1: An Intro to Data Ownership Concept and Some Problems in the Market
Post 2: The Vision and its Roadmap
Post 3: Challenges and Conclusion of the Vision (this post)In this post, I’ll mention the challenges and difficulties of transitioning to a DMI paradigm. Previous posts in this series have cascaded down the details and opportunities. This post is dedicated to the risks and challenges that weren’t mentioned before.
| Challenge / Difficulty | Remarks | |
Trends |
||
| 1 | DMI is against the current trends. | Which will require additional efforts to shift the paradigm, for instance a marketing budget should be planned too.* |
| 2 | Similar terms and understandings of the DMI concept are spoken by non-mainstream evangelists. | From the examples of the last 20 years, cannot we say that contrarians become the mainstream? |
| 3 | Pre-DMI examples (some tools that store on the drive and fetch the project data from it) are not user-friendly. | DMI should be designed to create minimum lovable interfaces. It cannot work like an MVP while aiming for scale. |
Business Layer |
||
| 4 | Convincing first adopters if they are not willing from day 0. | Especially none of the makers will prefer an infrastructure that will reduce friction for their users to switch. |
| 5 | DMI only targets B2B makers and their tools. | Because DMI for B2B tools means “on-premise” directly. (Even this might be opportunity for the SAASes who ant to target enterprise customers.) |
| 6 | Only specific tools and makers could create use cases for DMI logic. | If we aim for photo editor/viewer or note-taking apps, data can be owned easily. But for other products, market research should be done. |
Technical |
||
| 7 | Increased complexity of our systems. | But, in the end, we can create a scalable system, too because our servers were successful enough to manage both the Drive business and managed backend services of our customers. So, the risks depend on the execution. |
| 8 | Standard vs Customized trade-off (Complete data type standardization is not possible. So if makers used to customize the types, investment in the common types would be a loss.) |
For makers, writing extensions -like in some programming languages- should be a way of DMI. But the clues to managing this trade-off heavily rely on execution and zeitgeist. |
Legal |
||
| 9 | Data Security Investigations will increase the cost. | Before DMI, there were many backend systems to hack into. With DMI, hackers can exploit one vulnerability, which will affect all DMI-integrated apps. |
| 10 | Increased legal demands by regulators. | When we announce DMI, we’ll own the makers’ previous obligations. We’ll contain all categories of data types in regulations, so regulators’ audits might become intense. |
| 11 | Competition Laws This DMI system will give the Drive platform owners more central powers, equal to being a monopoly. |
There is even one possibility to shift this paradigm; like e-mail and web accessibility standards, the DMI system can be a separate institution that sets the standards. So DMI should be designed so that if regulators mandate decentralization, the business should also have a B plan for creating a benefit for building the roots of the DMI. |
*There are some contrarian voices who desire the quality of pre-internet software. Pre-broadband era tools were working under the user’s data-ownership principle. Because there was no ability to manage user data remotely. This method did not allow agile product management opportunities. But DMI allows agile. DMI is not a re-awakening of yesterday’s paradigm. Actually, it’s a simplification that makes users owners. So, data ownership is not contrary to the high-growth world.
PS: Before broadband access, there were no unnecessary updates, and the software design was extensive to manage the distribution cha__llenges_. A while ago, engineers were not good at forecasting the life of the design, so they designed products with higher safety margins. Today, our simulation abilities allow us to design products that will last to a designated time, such as planned obsolescence._
Yesterday’s method did not allow an agile world because redistributing the newer versions was a significant task and cost.
A Note about Blockchain
Blockchain’s distributed structure cannot be a direct competitor. But if DMI becomes a trending topic, as long as we allow users to switch tools, our platform will become a switchable place. While we’re doing a change for makers, we can be replaced as a maker of DMI. However, the competition is never restricted by friction and the cost of switching apps. So blockchain or another drive provider is no different; the DMI paradigm would create an agnostic data ownership, and we can only provide convincing stories to our end-users to choose us. Even one of the benefits might be an easy transition to blockchain.
Last Thought
When my current product, the Wewalk mobile app, entered the market, a North Star application was available and used by almost every power user. The app was the status quo, the best practice. But, when we delivered a better experience, our new users wanted to migrate their data from that north star. We quickly prepared a script to migrate the data and migrated a few users’ data while doing user interviews. We even consider releasing this script by covering up with a UI and publicly announcing it to accelerate acquisition.
We have yet to receive a good signal to make this script an end-user feature in the production environment. There were a lot of reasons;
- The users are not strongly requesting; even they didn’t know that the previous app allows data migration. In short, they are not aware that they can own their data.
- We were acquiring lots of users without offering a migration tool.
- When they switched to our application, they could generate the data quickly and wouldn’t bring dirty data from the previous app.
- Data from the previous apps was required because of the lack of some of the features we provide. So, our features removed the need to generate more data. Users would reach universal and generic data sources, so our product design didn’t require a must-have personalization to benefit the app. Our app was more straightforward and with less friction when used with the default setup.
In summary, we didn’t see a benefit to utilizing the data from the previous tool.
This is a vision statement. I cannot and wouldn’t encourage my teams to comply with these principles in a product I manage. I would attempt to implement these principles if I were building a personal cloud & drive infrastructure. Sometimes, we cannot adapt to the ideas earlier than required; ultimately, we should assess ideas and trends according to our product sense and market situation.
The current best practice of app making, redirects app makers to implement their own standards. Cloud storage options are just valid for backup apps and some MVP-like apps prefer these methods.
I personally wouldn’t design a product on DMI because it requires additional steps to set up and comes with some usability problems today. This is the paradigm we’re breathing with. But I also believe in the power of setting new standards and best practices. Who knows, DMI and data ownership will someday be a new (or renewed) golden standard, such as in the times before broadband internet access.