MediaBox

Free. In-app. Ad-sup­por­ted. Paid in­stall. So many busi­ness mod­els, but which one to choose?

As we men­tioned in a pre­vi­ous post, our #1 goal wasn’t about mak­ing money. I sup­pose we’d be silly to turn down an op­por­tun­ity, but we didn’t want to have our product idea se­lec­tion driven com­pletely by dol­lar signs. This wasn’t out of some keen in­terest in copy­ing Val­ley star­tups (i.e. no rev­enue can be good for early valu­ations), we just didn’t think our first pro­ject was the right place to start mount­ing pres­sure on the team.

Choose the model early. It was help­ful that we knew we wanted to go free early in the product design pro­cess. You’ll want to define your busi­ness model early in the product li­fe­cycle, as the model you choose will in­flu­ence the way you design and build the product. For ex­ample, a freem­ium app needs to be de­signed such that both the free and paid user have a rich ex­per­i­ence with the ap­plic­a­tion.

1. Free is so easy. Low ex­pect­a­tions and high(er) cus­tomer reach. There are be­ne­fits to free. As a team, it makes things simple be­cause there’s no real busi­ness to split up. We can work on the product without any real feel for who on the team has the most com­mit­ment, be­cause there are no profits to share. It also en­sures that we max­im­ize the user base since there is no pay­wall be­fore using the app. We really hope that a free app will enjoy high user growth and will be easier to mar­ket. This is great for us, be­cause we’re more in­ter­ested in the ex­pos­ure from the app than in dir­ect rev­enue. As a simple app ex­periement, Me­di­aBox is the per­fect place to work on the mech­an­ics of build­ing and launch­ing an app, rather than fo­cus­ing on how to ex­tract fin­an­cial value.

2. Free does not mean $0 rev­enue. Oh yeah, we do have a chance to earn, though our ex­pect­a­tions are low. Me­di­aBox of­fers cus­tom­ers the chance to buy their lis­ted media on iTunes. This is a fea­ture that can earn us af­fil­i­ate rev­enue from iTunes to the tune of 5-7% on every dol­lar the user spends in iTunes/iBooks after link­ing from our app. None of us have ever ex­per­i­mented with af­fil­i­ate pro­grams be­fore, so we’re pretty ex­cited to see how this goes.

3. Why not Freem­ium: In-App Pur­chase? We did en­ter­tain the idea of hav­ing an in-app pur­chase rev­enue stream but de­cided against it. In Me­di­aBox, you have a sep­ar­ate list for each media type: movies, tv, books and music. One op­tion, would have been to re­strict ac­cess to cer­tain media types and have an in-app pur­chase for full media ac­cess. This might work, but we were con­cerned with how much it would de­grade the user ex­per­i­ence, and we didn’t be­lieve that it would really drive that much rev­enue. Apple re­com­mends that you should only con­sider going freem­ium if your app can provide great value to both free and paid users. We weren’t sure this would be the case for a freem­ium Me­di­aBox. Though the most pop­u­lar rev­enue model at the mo­ment, in-app just didn’t feel like a fit for our app.

4. Why not iAd? Thought we didn’t dis­cuss this at length, I still think iAd might work in an app like ours. Prob­lem is that a non-trivial % of pro­spect­ive users really hate ads, though I bet that num­ber re­duces with iAds be­cause of their pol­ish. Still, show­ing ads seemed like a pretty big risk to the product, and I have yet to read any good case stud­ies on apps which have used iAds as an ef­fect­ive rev­enue stream. Something I’m keep­ing an eye on though, be­cause I’d love to ex­per­i­ment with the Apple ad plat­form and see for my­self.

5. Af­fil­i­ate Rev­enue. We settled on af­fil­i­ate rev­enue, though Me­di­aBox lends it­self quite nicely to this ap­proach. With Me­di­aBox, cus­tom­ers are keep­ing lists of media that they plan to read/listen/watch in the fu­ture. When the fu­ture ar­rives, they’ll likely want to buy that media, and that’s where Me­di­aBox can help (and earn a little $). When a cus­tomer uses Me­di­aBox to ‘buy’ their media from iTunes, Apple will pay us through their af­fil­i­ate pro­gram. In this art­icle, David Smith does a great job of ex­plain­ing how the Af­fil­i­ate pro­gram works. Cur­rently, our ac­count shows that we’re pulling in 7% com­mi­s­ions through the af­fil­i­ate pro­gram. Not bad.

All of Me­di­aBox is an ex­per­i­ment, and we really have little to lose. Af­fil­i­ate rev­enue seemed like a great place to start be­cause we didn’t have to sac­ri­fice the user ex­per­i­ence at all, and we get to learn something about the iTunes Af­fil­i­ate Pro­gram. Win win.

Next up: LAUNCH! (in two weeks)

As men­tioned in a pre­vi­ous post, Me­di­aBox is an ex­per­i­ment­a­tion plat­form for us. We use it to gain ex­per­i­ence in areas of product design in which we haven’t pre­vi­ously dabbled. One such area, is Cus­tomer Driven De­vel­op­ment (CDD). To us, CDD means that we work closely with pro­spect­ive cus­tom­ers of the product and col­lab­or­ate to­ward a more finely tuned solu­tion. They drive the vis­ion of what we build.

It works! Turns out this ap­proach was quite suc­cess­ful for a num­ber of reas­ons.

Prob­lem Spots. Cus­tom­ers helped us re­define the user in­ter­face by ob­serving where they got stuck. There was noth­ing more valu­able than see­ing a pat­tern in which dif­fer­ent people got hung up on the same issue. Often times, they’d even have com­mon sug­ges­tions for how to fix it, mak­ing our job even easier.

Sug­ges­tions. Wow, just a flurry of great sug­ges­tions from every user we in­ter­viewed. Many of which we in­cluded in the final product. Some were col­our sug­ges­tions and other user in­ter­face re­fine­ments and many were fant­astic fea­ture re­quests. After just a few minutes with the app, users could im­me­di­ately tell us what they felt was miss­ing from the ex­per­i­ence. Many more of these cus­tomer-driven ideas sit on the Me­di­aBox back­log today, just wait­ing to be built.

It­er­ate with New and Ex­per­i­enced Cus­tom­ers. Each time we did a set of in­ter­views, we’d it­er­ate the product and then test again. En­sur­ing that prob­lem spots were cleared up and the ex­per­i­ence was im­proved. Adding new people to each it­er­a­tion is a smart idea, be­cause oth­er­wise you run the risk of the pre­vi­ous users being biased by earlier ver­sions of the app. Not a bad thing en­tirely, but you don’t get the truly crit­ical feed­back that you do from a fresh set of eyes. Next time, I think we’d per­form each beta test with a planned mix of new and ex­per­i­enced users. This will give us a nice blend of feed­back that is rep­res­ent­at­ive of how App Store up­dates would be used in prac­tice.

Built in ad­voc­ates. Every­one you test with, provided you treat them well and listen to their feed­back, will be built in ad­voc­ates for your ap­plic­a­tion (hope­fully). Don’t for­get to re­ward them for their work, be­cause they’re an im­port­ant part of the team! We gave out $10 Star­bucks gift cards to our beta test­ers… a little light on the re­ward side, but a little something to say thanks!

Who else prac­tices Cus­tomer Driven De­vel­op­ment? All of the triple-A mo­bile shops prac­tice this sort of de­vel­op­ment ap­proach. Face­book and Twit­ter do this, al­though a lot of their product feed­back can be gathered at scale, which is even more power­ful.

Why not Data Driven De­vel­op­ment? I love driv­ing product de­cisions based on data usage col­lec­ted (via Google Ana­lyt­ics, for ex­ample). However, these early product stages don’t really offer that kind of ana­lysis be­cause of the small num­ber of cus­tom­ers. In­stead, talk­ing to each cus­tomer one on one provides more valu­able info to an early stage product. Later, we’ll use this tech­nique along­side big’ish data to drive our im­port­ant product de­cisions. I be­lieve the best product man­agers use a blend of in­stinct, team feed­back, cus­tomer in­ter­views and usage data, to drive each and every product de­cision.

After the ex­per­i­ence with Me­di­aBox, I’m com­pletely sold on the value of cus­tomer driven de­vel­op­ment. The cus­tomer can’t al­ways tell you ex­actly what to build, but they can often tell you what’s wrong with what you have so far. I re­com­mend giv­ing this a try. Talk to your cus­tom­ers, it’s never too late to get star­ted.

Next Week: “Why is Me­di­aBox free?”

The toughest thing about a side pro­ject is find­ing the time to give it the at­ten­tion your fu­ture cus­tom­ers de­serve. That’s tricky enough when it’s just you, but when form­ing a team, the time con­straint issue is amp­li­fied. How will we find time to meet? What if cer­tain people can con­trib­ute more time than oth­ers? In the end, all of these con­cerns melt away if the goals of the pro­ject are made clear at the out­set.

Here, I’ll quickly walk you through our team build­ing and how it all turned out as we near build com­ple­tion on Me­di­aBox.

Be­fore we Star­ted. Here are the ground rules that we set in the ini­tial email that went out to pro­spect­ive team mem­bers. Something of a pro­ject charter, if you will:

• Absolutely no formal time commitment.
• Favour building something that’s fun for us, or does some societal good, over marketability.
• Keep it simple. Avoid the analysis paralysis that can accompany trying to come up with the “next big thing”.
• Something we can build a v1 of fairly quickly, but has potential for additional iterations/features.
• Majority rules on product decisions.

App/Team Fun­da­ment­als. As we set out to build the team, the first thing we thought about was who we wanted to work with and who would be most re­spons­ive to the idea of build­ing a new app. We knew we wanted it to be an iPhone app, but didn’t really care if the team had deep iOS de­vel­op­ment tal­ent. Our goal was to learn something new, so it didn’t mat­ter how good we were at the craft. We were there to get bet­ter.

Team Size. We wanted more than 2 and less than 10; any­thing in between would work. The goal was to have a team large enough to have a flow of cre­at­ive ideas and be able to with­stand hav­ing a few people drop off (more on that later). More than 10 would have been too dif­fi­cult to co­ordin­ate and tough to fit on a small iOS pro­ject. Our goal was to have a team that could work closely to­gether and share in all as­pects of design, build, test and mar­ket. We settled on 5 people.

Col­lab­or­a­tion Tools. Right away, we star­ted col­lab­or­at­ing on the Google apps suite: Cal­en­dar, Docs, Drive, Spread­sheet and Hangouts for some re­mote ses­sions. Product meet­ings were sched­uled in Cal­en­dar and con­duc­ted in-per­son or over Hangouts. Dur­ing the build phase, Git­hub was great for source con­trol, and also for issue track­ing (private re­pos­it­ory, of course). We also used the issue tracker to man­age the product fea­tures/scope that would define the vari­ous beta re­leases that we tested with pro­spect­ive cus­tom­ers.

Ini­tial Steps. After as­sem­bling the team, the first thing we did was se­lect a product idea. We’ll talk about product se­lec­tion in a fu­ture post, but es­sen­tially we se­lec­ted something we knew we could build suc­cess­fully and something we felt would at least be use­ful to us – this meant we’d have at least 5 cus­tom­ers! After se­lect­ing the product idea, we com­pleted a doc­u­ment that defined our product. What’s really cool is that this doc­u­ment still de­scribes our product ac­cur­ately some 7 months later.

Team Size Now? As we round out de­vel­op­ment on Me­di­aBox, 7 months have passed. We find ourselves down to two act­ive team mem­bers. Al­though it would have been great to have every­one along for the ride, it just wasn’t pos­sible for every­one to com­mit enough time to feel that they’re help­ing the ef­fort. Des­pite our app’s simple scope, there is still a lot of work that goes into a ship­ping product: design, cus­tomer test­ing, com­mu­nic­a­tion, de­vel­op­ment, test­ing, mar­ket­ing, and land­ing site con­struc­tion. It’s not easy to bal­ance per­fectly against pro­fes­sional and per­sonal life, which is im­port­ant to us. Though the team has slimmed over time, we do still feel great that our ori­ginal product defin­i­tion doc­u­ment still defines the product we’ll soon be ship­ping (in 4 weeks!).

Next Tues­day: “Cus­tomer-Driven De­vel­op­ment”

So with a mil­lion apps in the App Store, it’s clear that a lot of people out there already know how to build an iPhone app. However, if you enjoy an in­side look at product cre­ation or you have an app idea and aren’t sure where to start, then this series of posts may be in­ter­est­ing to you.

In this post, and sev­eral more, we’ll cover many as­pects of cre­at­ing and launch­ing an app for iOS. We’ll leave cod­ing de­tails to the reader, but we’ll cover the in­ter­est­ing macro bits like team build­ing, idea cre­ation, product defin­i­tion, and mar­ket­ing. On the Me­di­aBox team, we’re learn­ing as we go and want to share all of it with you. We’ll talk openly about is­sues that we ran into, how much time and money we spent on the pro­ject, and share re­com­mend­a­tions on tools and product de­vel­op­ment ap­proaches. The num­ber one goal here is to share in­form­a­tion from be­hind the scenes.

Below, is an early design concept that we cre­ated using a great wire­fram­ing tool called Bal­samiq. See the rest of the very basic design concept here. When we launch, you’ll see how far we de­vi­ated from these early con­cepts. Des­pite stray­ing from the ori­ginal sketches, they served as an im­port­ant guideline and a few of the design con­cepts did stand the test of time.

Here are some pro­ject met­rics I thought might be in­ter­est­ing. More to come!

• Team members at project start: 5
• Team members currently: 2
• Alpha testing group: 6
• Commits on Github: 170
• Month with most commits: June 2013 (44)
• Project start date: March 2013
• Elapsed time planning: 2 months
• Elapsed time development: 7 months
• Elapsed time to first alpha: 5 months
• Lines of code: 3920
• When we usually code: 8-11PM
• % team with iOS experience: 50%
• Business model: Affiliate Revenue
• Budget to date: $70
• Launch date: soon

Be a part of our iOS app ex­per­i­ment and catch all of our free con­tent as we march to­ward the launch date of Me­di­aBox!

Next Tues­day: “Build­ing a Side Pro­ject Team”