Plan B - Pivoting to a B2B Product

Last year, I had an idea to turn the framework that powers Stories by Gus on the Go into a B2B product. The idea would be to enable others to create their own interactive children story apps. When I told Alice, she said she had been thinking the same thing. But we decided it was plan B. Always have a plan B

Earlier this year, I was reminded of this idea while listening to one of my favorite podcasts. Release Notes had an episode that hinted at why it might be a good idea to focus on selling our framework as a product to other businesses instead of selling interactive story apps to consumers.

But, again, we are still working on getting Stories to be financially viable. It is early days and we have several options in flight to help improve downloads and sales.

So I kept the idea on the back burner. Until a couple of days ago. For some reason I started thinking about it again. I wanted to record my ideas, as a reminder in case one day we enact plan B.

Sales options

There are several ways to turn this framework into a product.

Sell an application

Going this route would mean creating an application to sell to businesses or anyone who wants to create their own interactive stories.

Ideally, this application would generate a brand new iOS or Android app that is ready to be uploaded to the App Store. Alternatively, the app could generate an Xcode or Android Studio project, which the customer would then have to compile themselves. This may come down to whether or not customers want a turn key application or if they prefer some level of control.

Remember, the target customer is not a consumer, but another business or author looking to get into apps.

The application would require a simple interface to create the interactive stories. The framework itself is driven by a database behind the scenes. Currently, this is how I create the data for the stories:

Screenshot of spreadsheet to generate database
Screenshot of spreadsheet used to generate database

After manually entering in all the necessary fields for each scene, I run custom python scripts to generate the databases.

Clearly, this is not something we could sell to anyone else. I can see the marketing copy now:

Product dependencies: Must know Python.[1]

The process needs to be greatly simplified to be a product. It would need a nice drag and drop GUI that walks the customer through the entire story creation scene by scene.

Features could be added over time and upgrade pricing could be introduced to help sustainability. I know upgrade pricing has long since fallen out of favor with the consumer market, but the business market is more likely to be ok with it. This product will help them make money, so it makes sense for them to want to keep it up to date.

Contract the app creation

Using this option, we would keep the framework ourselves and create interactive story apps for clients.

This option could have custom pricing depending on story length and how much work the client has already put into it.

Clients would supply audio, text, and graphics. The more they supply, the lower the price. If we have to contract out the graphics or audio creation, then it would cost more. Obviously.

It would still be very handy to have the GUI to generate the databases for this option. It would improve my productivity by decreasing the amount of time required to generate the stories. Additionally, it would also allow Alice to create products for clients. If we were to become popular enough, it would give us the option to grow by hiring employees to create products for clients.

At that point, though, we could also potentially become a digital interactive story publisher.

Digital interactive story publisher

Under this option, we would, again, keep the product in-house. Authors who wanted to self publish interactive stories would do so through us. Some sort of revenue sharing agreement would be in place between us and the authors.

I don’t know how I feel about this, though. Our friends at tapStory App have a similar business model. I would want to talk to them first to make sure we’re not stepping on any toes. Some people say it’s just business, but I prefer maintaining friendships and good relationships.


But, again, all of this hypothetical anyway.

There’s a good chance I will create this application for in-house use at some point. I am quickly getting tired of manual database entry.

Do you know anyone who would be interested in an easy way to create interactive children story apps? I would love to find out if there is a market for something like this.

Does your business have a plan B?

If you want, follow me on Twitter. I’m @yonomitt.

Have a nice day,
Yono


  1. Python 3, of course.  ↩