This is the 2nd post of my ideations toward Drives (Google Drive, Dropbox, iCloud, etc.). I’ll publish one additional posts in this series;
 
Post 1: An Intro to Data Ownership Concept and Some Problems in the Market
Post 2: The Vision and its Roadmap (this post)
Post 3: Challenges and Conclusion of the Vision

In this post, I’ll walk through the roadmap of how to change the paradigm. I hope the future posts in this series will draw an integral Picture that combines the points made to you.

A. Vision

As a Drive platform owner, we want to create a data management infrastructure (DMI) which;

  • will allow end users to;
    • backup, manage, and migrate their own data from the apps they use
    • choose between alternative applications easily without worrying about the tool’s data export/import functionality
    • pay the fee of the tool as an addition to their current storage subscription
  • will allow app-makers to;
    • develop apps faster without investing time in the backend
    • not to deal with privacy policy because they won’t own the customer data
    • not to deal with payments because we’ll provide that

Some Definitions

  • User: end-user
  • Platform: Our Drive solution
  • Maker: App maker who develops the tool
  • Tool: The application works like a client app by using our data management infrastructure.
  • DMI: The infrastructure we’re building.

B. Hypothesis

  1. Users will like data ownership, so with the first mover advantage, we can increase the loyalty of our individual users.
  2. Users will like the central subscription management feature.
  3. Users will have a higher willingness rather than the Tool’s price before DMI integration.
  4. Makers will develop Tools faster by using our infrastructure.
  5. Makers will be satisfied with DMI’s reliability and performance.

I won’t go into the details of the hypothesis much. Some of them require a survey or behavior analytics study, and some can be validated with technical reliability metrics.

C. User Research

Our hypothesis includes both makers and end-users. To gain insights from the preliminary user research, we should segment our studies. For makers, we can create a list of candidates from these;

  1. Our existing enterprise customers (makers);
    • we can check our internal resources for existing contracts
    • and we can retrieve initial insights from account managers if they have been asked for a similar thing before
  2. Our customers, who provide similar features (by our open or free APIs);
    • for example the ones who offer “Google Drive backup”, “Dropbox integration” etc.
    • We can crawl sources for the Tools. We can use a list of some keywords like “drive”, “backup”, “export”
    • Some sources: G2, and other listing stores; App and Extension Stores; Github etc.
  3. Our developer relations team and their records
  4. Our developer conference and we can have a dedicated or parallel session during the event with mock tutorials for our idea

It’s important to list a diverse range of Tool types here. If we’re just able to find note-taking Tools, we might just have developed a generic backend for note-taking apps, not a DMI. So even if the hypotheses are validated, if we cannot make this paradigm valid for a broader range, the business success will be less likely. So, the 0th hypothesis should be placed like this;

A significant portion of top makers (those in the top 20 in their category) will want to integrate with DMI.

&

We can deliver at least 1 case study with makers from each app category (which involved user data) in the application stores.

&

At least 3 makers from each category can promise to include DMI integration in their long-term plans.

For end users, we can have two segmented interviews;

  1. Our customers
    • Depending on our scale, we might not be able to have 1:1 interviews, so we can develop some observation-based methods.
    • Beta Users, if exists, is the best group to test the ideas. But to include them in this studies, a separate invitation should be sent, because we’re not releasing a beta feature to them, we’re releasing a beta idea.
  2. Generic user group
    • What are their practices for managing their data? Do they pay attention to ownership, or do they need to manage subscriptions or purchases from a central place? Web crawling and trend analysis are some of the ideas for gathering insight.

Interview Methods

Interviewing with makers is undoubtedly a sales and account management activity. So, the account manager’s involvement is crucial.

As a PM managing this transition, the most enormous effort will arise from the end-user. For the end user, the benefit might not be managing data, but other advantages originated from managing data, such as being sure about privacy, GDPR compliance, easy migrations, central management of payments, or having a universal search between apps, or involving with AI by putting all of his data without any pain. So, interviews should be focused more on these additional benefits.

I also don’t just believe in the power of interviews unless it’s an interview about a live product or it’s supported with a usability test. To test out these ideas, I think providing a computer or smartphone, like in the Apple Stores, installed with some existing demo data and apps, to the interviewee would create a perfect opportunity to test a concierge test. The interviewer can give the user some tasks and observe the user’s behavior.

To demonstrate in this stage, we can manipulate some apps’ local data and link (symbolically or directly) those data with a drive folder to simply show the apps’ data in the folder. Or mock data or some scripts to crawl data, etc. (I foresee 2-3 weeks to set up a test environment to demonstrate all of this roadmap’s UI’s and functions.)

D. Roadmap

The roadmap below will have some parallel items. Parallelization depends on the company and team structure, so I’ll list those as consecutive ones.

  1. Preliminary Interviews
  2. Releasing “App Data” View: a UI Update for end-user
    • with this development, the user should see folders in their Drive for the end-user tools provided by us (like note-taking and todo list apps)
    • these files can be hidden by users easily
    • when a user enters the UI, they should see a warning that this is a preview, and they should see a plainly formatted daily backup of their data.
    • Hypothesis to test: we can test the user’s liking and willingness to pay with these changes.
  3. Press Release for App Data
  4. User Interviews and Business Plan Revisions
  5. Release of Improved File Storage API for Makers under DMI API Family
    • should be easier to integrate than the current
    • should contain a sandbox access specific for the maker’s Tool
    • and can be called merged with login services when user login with their Drive account
    • Hypothesis to test: we can test the hypothesis related to the reliability metrics. Also, we can observe the business needs for accessing users’ files and replacing their cloud file storage efforts. Makers will probably ask for non-deletable and non-visible data/file/record types to users. These demands should be studied both for product development and policy-setting purposes.
    • Press Release for App Data
  6. The release of Synchronization API under DMI
    • will be similar to our existing Cloud APIs; the purpose is to make makers familiar with the DMI API Family.
    • This will be like a Firestore service, but with this release, the data type can be file, record, or any other data format. So, developers should use a unified common standard API.
    • This API should contain different synch methods like the latest version to oldest, the latest modification to oldest, or both old and new changes.
    • this API should have two modes;
      • single concurrent editor, which blocks other instances (web, mobile, etc.) of the tool than the active one
      • multiple concurrent editors, which combines the changes from both clients (like mobile and desktop at the same time)
    • The synchronization API should work under both REST- and file-storage-based methods. If a user is synching their drive into his computer, the data can be fetched from there easily. So, DMI APIs will be designed more like SDKs.
  7. Announcement Activities
    • Maker Interviews
    • Demonstrations and Publishing Sample Use Cases / Open-Sourced Skeleton Projects
    • After this point, all of the roadmap items will require a marketing effort, so those should be planned in the roadmap too.
  8. Enterprise Sales Agreements and Migration Projects
    • Providing hands-on support for enterprise customers to migrate to DMI infrastructure
    • The sales agreement includes the subscription price of the service and the resellability of the Tool. 
  9. Release of subscription management screens (DMI Store)
    • Users should be able to purchase or subscribe to the tools
    • User should be able to add a subscription price to their current subscription price
    • The user should be able to migrate data from one DMI-supported tool to another one.
  10. Co-existence with Application Stores (for Google and iCloud Especially)
    • Compliance studies for co-existing with stores.
    • For example, when a user would like to subscribe to an app, if that app is logged in with DMI login services, DMI payment screens should appear instead of the store’s payment system. Until this development, this was the maker’s responsibility. With this development, users will have a unified experience through DMI’s deeper integration with Google, Apple, or some Desktop environment stores. For instance, users can see DMI subscription details from app purchase history.
  11. Standardization of Data Types
    • To increase the migration ability of the data between apps, we can offer some formats of storage like markdown for texts.
    • A maker shouldn’t use custom data types unless so many specific conditions are required.
    • Migration assistants certainly won’t be avoidable; for example, most apps create a directory of assets and bind those assets in a single file. Full-DMI compliance would require standard storage. But even semi-DMI compliant apps can use a benefit from being in DMI. When the user migrates data from tool 1 to tool 2, DMI can display a universal migration UI. Data organization might differ between 1 and 2, but DMI has the schemas of both tools.
    • Files shouldn’t be encrypted by makers, or they should generate unencrypted versions of data, when migration assistant is used. Encryption, data security and integrity is part of our Drive and DMI system.
  12. Launch of Migration Assistant
    • As described above.
  13. Exploration Area: Blockchain Migration Tool
    • Since DMI provides data ownership to the user instead of the maker, DMI can provide and fetch data from the chain. If some customers are interested in blockchain compatibility, we might place some tools under DMI, or we can provide the same APIs in an agnostic way of technology. For example, If the end-user chooses blockchain storage, the maker might operate without knowing where the data is stored, thanks to DMI. DMI can share the environment, and the app-maker can display specific UIs. (for example, getting confirmation for the gas fee)

Last Addition:

Roadmap is nothing but Roadmapping is everything. In an agile way, after each experimentation, the priorities, orders, or scopes will certainly change. But in terms of this kind of paradigm-shifting change, total budget forecasts and marketing activities can be planned with this plan.