MediaBox

Free. In-app. Ad-supported. Paid install. So many business models, but which one to choose?

As we mentioned in a previous post, our #1 goal wasn’t about making money. I suppose we’d be silly to turn down an opportunity, but we didn’t want to have our product idea selection driven completely by dollar signs. This wasn’t out of some keen interest in copying Valley startups (i.e. no revenue can be good for early valuations), we just didn’t think our first project was the right place to start mounting pressure on the team.

Choose the model early. It was helpful that we knew we wanted to go free early in the product design process. You’ll want to define your business model early in the product lifecycle, as the model you choose will influence the way you design and build the product. For example, a freemium app needs to be designed such that both the free and paid user have a rich experience with the application.

1. Free is so easy. Low expectations and high(er) customer reach. There are benefits to free. As a team, it makes things simple because there’s no real business to split up. We can work on the product without any real feel for who on the team has the most commitment, because there are no profits to share. It also ensures that we maximize the user base since there is no paywall before using the app. We really hope that a free app will enjoy high user growth and will be easier to market. This is great for us, because we’re more interested in the exposure from the app than in direct revenue. As a simple app experiement, MediaBox is the perfect place to work on the mechanics of building and launching an app, rather than focusing on how to extract financial value.

2. Free does not mean $0 revenue. Oh yeah, we do have a chance to earn, though our expectations are low. MediaBox offers customers the chance to buy their listed media on iTunes. This is a feature that can earn us affiliate revenue from iTunes to the tune of 5-7% on every dollar the user spends in iTunes/iBooks after linking from our app. None of us have ever experimented with affiliate programs before, so we’re pretty excited to see how this goes.

3. Why not Freemium: In-App Purchase? We did entertain the idea of having an in-app purchase revenue stream but decided against it. In MediaBox, you have a separate list for each media type: movies, tv, books and music. One option, would have been to restrict access to certain media types and have an in-app purchase for full media access. This might work, but we were concerned with how much it would degrade the user experience, and we didn’t believe that it would really drive that much revenue. Apple recommends that you should only consider going freemium if your app can provide great value to both free and paid users. We weren’t sure this would be the case for a freemium MediaBox. Though the most popular revenue model at the moment, in-app just didn’t feel like a fit for our app.

4. Why not iAd? Thought we didn’t discuss this at length, I still think iAd might work in an app like ours. Problem is that a non-trivial % of prospective users really hate ads, though I bet that number reduces with iAds because of their polish. Still, showing ads seemed like a pretty big risk to the product, and I have yet to read any good case studies on apps which have used iAds as an effective revenue stream. Something I’m keeping an eye on though, because I’d love to experiment with the Apple ad platform and see for myself.

5. Affiliate Revenue. We settled on affiliate revenue, though MediaBox lends itself quite nicely to this approach. With MediaBox, customers are keeping lists of media that they plan to read/listen/watch in the future. When the future arrives, they’ll likely want to buy that media, and that’s where MediaBox can help (and earn a little $). When a customer uses MediaBox to ‘buy’ their media from iTunes, Apple will pay us through their affiliate program. In this article, David Smith does a great job of explaining how the Affiliate program works. Currently, our account shows that we’re pulling in 7% commisions through the affiliate program. Not bad.

All of MediaBox is an experiment, and we really have little to lose. Affiliate revenue seemed like a great place to start because we didn’t have to sacrifice the user experience at all, and we get to learn something about the iTunes Affiliate Program. Win win.

Next up: LAUNCH! (in two weeks)

As mentioned in a previous post, MediaBox is an experimentation platform for us. We use it to gain experience in areas of product design in which we haven’t previously dabbled. One such area, is Customer Driven Development (CDD). To us, CDD means that we work closely with prospective customers of the product and collaborate toward a more finely tuned solution. They drive the vision of what we build.

It works! Turns out this approach was quite successful for a number of reasons.

Problem Spots. Customers helped us redefine the user interface by observing where they got stuck. There was nothing more valuable than seeing a pattern in which different people got hung up on the same issue. Often times, they’d even have common suggestions for how to fix it, making our job even easier.

Suggestions. Wow, just a flurry of great suggestions from every user we interviewed. Many of which we included in the final product. Some were colour suggestions and other user interface refinements and many were fantastic feature requests. After just a few minutes with the app, users could immediately tell us what they felt was missing from the experience. Many more of these customer-driven ideas sit on the MediaBox backlog today, just waiting to be built.

Iterate with New and Experienced Customers. Each time we did a set of interviews, we’d iterate the product and then test again. Ensuring that problem spots were cleared up and the experience was improved. Adding new people to each iteration is a smart idea, because otherwise you run the risk of the previous users being biased by earlier versions of the app. Not a bad thing entirely, but you don’t get the truly critical feedback that you do from a fresh set of eyes. Next time, I think we’d perform each beta test with a planned mix of new and experienced users. This will give us a nice blend of feedback that is representative of how App Store updates would be used in practice.

Built in advocates. Everyone you test with, provided you treat them well and listen to their feedback, will be built in advocates for your application (hopefully). Don’t forget to reward them for their work, because they’re an important part of the team! We gave out $10 Starbucks gift cards to our beta testers… a little light on the reward side, but a little something to say thanks!

Who else practices Customer Driven Development? All of the triple-A mobile shops practice this sort of development approach. Facebook and Twitter do this, although a lot of their product feedback can be gathered at scale, which is even more powerful.

Why not Data Driven Development? I love driving product decisions based on data usage collected (via Google Analytics, for example). However, these early product stages don’t really offer that kind of analysis because of the small number of customers. Instead, talking to each customer one on one provides more valuable info to an early stage product. Later, we’ll use this technique alongside big’ish data to drive our important product decisions. I believe the best product managers use a blend of instinct, team feedback, customer interviews and usage data, to drive each and every product decision.

After the experience with MediaBox, I’m completely sold on the value of customer driven development. The customer can’t always tell you exactly what to build, but they can often tell you what’s wrong with what you have so far. I recommend giving this a try. Talk to your customers, it’s never too late to get started.

Next Week: “Why is MediaBox free?”

The toughest thing about a side project is finding the time to give it the attention your future customers deserve. That’s tricky enough when it’s just you, but when forming a team, the time constraint issue is amplified. How will we find time to meet? What if certain people can contribute more time than others? In the end, all of these concerns melt away if the goals of the project are made clear at the outset.

Here, I’ll quickly walk you through our team building and how it all turned out as we near build completion on MediaBox.

Before we Started. Here are the ground rules that we set in the initial email that went out to prospective team members. Something of a project 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 Fundamentals. 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 responsive to the idea of building a new app. We knew we wanted it to be an iPhone app, but didn’t really care if the team had deep iOS development talent. Our goal was to learn something new, so it didn’t matter how good we were at the craft. We were there to get better.

Team Size. We wanted more than 2 and less than 10; anything in between would work. The goal was to have a team large enough to have a flow of creative ideas and be able to withstand having a few people drop off (more on that later). More than 10 would have been too difficult to coordinate and tough to fit on a small iOS project. Our goal was to have a team that could work closely together and share in all aspects of design, build, test and market. We settled on 5 people.

Collaboration Tools. Right away, we started collaborating on the Google apps suite: Calendar, Docs, Drive, Spreadsheet and Hangouts for some remote sessions. Product meetings were scheduled in Calendar and conducted in-person or over Hangouts. During the build phase, Github was great for source control, and also for issue tracking (private repository, of course). We also used the issue tracker to manage the product features/scope that would define the various beta releases that we tested with prospective customers.

Initial Steps. After assembling the team, the first thing we did was select a product idea. We’ll talk about product selection in a future post, but essentially we selected something we knew we could build successfully and something we felt would at least be useful to us – this meant we’d have at least 5 customers! After selecting the product idea, we completed a document that defined our product. What’s really cool is that this document still describes our product accurately some 7 months later.

Team Size Now? As we round out development on MediaBox, 7 months have passed. We find ourselves down to two active team members. Although it would have been great to have everyone along for the ride, it just wasn’t possible for everyone to commit enough time to feel that they’re helping the effort. Despite our app’s simple scope, there is still a lot of work that goes into a shipping product: design, customer testing, communication, development, testing, marketing, and landing site construction. It’s not easy to balance perfectly against professional and personal life, which is important to us. Though the team has slimmed over time, we do still feel great that our original product definition document still defines the product we’ll soon be shipping (in 4 weeks!).

Next Tuesday: “Customer-Driven Development”

So with a million 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 inside look at product creation or you have an app idea and aren’t sure where to start, then this series of posts may be interesting to you.

In this post, and several more, we’ll cover many aspects of creating and launching an app for iOS. We’ll leave coding details to the reader, but we’ll cover the interesting macro bits like team building, idea creation, product definition, and marketing. On the MediaBox team, we’re learning as we go and want to share all of it with you. We’ll talk openly about issues that we ran into, how much time and money we spent on the project, and share recommendations on tools and product development approaches. The number one goal here is to share information from behind the scenes.

Below, is an early design concept that we created using a great wireframing tool called Balsamiq. See the rest of the very basic design concept here. When we launch, you’ll see how far we deviated from these early concepts. Despite straying from the original sketches, they served as an important guideline and a few of the design concepts did stand the test of time.

Here are some project metrics I thought might be interesting. 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 experiment and catch all of our free content as we march toward the launch date of MediaBox!

Next Tuesday: “Building a Side Project Team”