It’s been a while since my lats post on the subject…sounds like the start of a teenage journal or diary entry….but in any case, it has been a while.  Which I think is to be expected while this project remains a hobby more than a business.

But the important thing is, I think, progress has been made.  And I am here to report it!

To set the progress in context, I recap the basics of the progress.  My friends and I are working on a mobile app.  Our lead off platform for the mobile app will be the iPhone, however since starting on this project, Android has really become an interesting player in the market and BlackBerry is never to be discounted.  Plus, as we consider the use case for our app, as well as the target market, we expect to need to provide it in all three platforms.

But first is iPhone, of course.

As the the lead off iPhone app, the basics of the mobile app are written.  I can login to the app on the iPhone and perform some basic functions that are the foundation to the app’s value proposition.  That’s about it for today.  But it’s a good start!  I think with these sorts of side projects, just getting some code down that actually works is a huge first step.  It’s the first step that then provides a driver for future steps in that you think, “since I allready did the first step, I can’t let that go to waste!”  But if you don’t do the first step, then you never commit to any real degree, and nothing ever gets started.

So, we have our first step.

Maybe more exciting is the progress we’ve made with graphic design.  My buddy Matt Rhodes, of Denver Colorado is working on that side of the project for us.  Matt was my roommate in college.  Honestly, I had no idea he was such an artist in college.  I mean I saw the doodling in the margins of his notebooks from time to time, but didn’t have a concept for how he would be making a living off that talent when we grew up.  Well, I’m stoked he’s working with us on this one, because he’s pretty good at it!  I thought I’d share the app logo here…for the first time….tada!

Now, the logo may raise a lot of questions about what kind of app we’re building.  Well, for the purposes of remaining sufficiently ambiguous at this point (acknowledging there is really no technical barrier to entry on this one ) let’s just say, we’re building a mobile app that facilitates micro financial transactions between peers in small social networks while incorporating some elements of game design to make it fun.

The other big news for this project is the inclusion of Don Canoy.  Don is going to be working on the web side of the app, while Tim continues to tackle the mobile side.  Don worked with me on Famplosion, and so I’m very excited to be working together on this project going forward!  For those who are curious, the web side, including the components accessed by the app on the web are being built using Ruby on Rails…just like Famplosion.  The iPhone app is native Objective C, which I understand Apple announce last week that the native part is now a requirement as they continue to position against Adobe and Flash.  Apple’s interest in limiting the flexibility available to developing mobile apps is a little frustrating, but hey, it’s their ecosystem, we’re just trying to live in it, right…

This is my 6th post about the ongoing process toward building, launching and monetizing a mobile app in today’s market.  This post is about how we’re building the team, and specifically what skills we’re putting together to flesh it out.

I guess it’s worth stating up front that a team seems necessary.  There are a couple stories out there of the lone coder building an app, putting it on the shelf in the App Store, and maybe even discerning a marketing strategy that results in significant short term cash.  But by in large, the personality types and skills necessary to do all that is required to really pursue this stuff is not often found in the same person.  Hence a team is required.  At the most basic level, someone needs to write software and someone needs to sell software.  This is probably true not just in the mobile app business right now, in fact, when the broader economy is like it is right now, I always feel safer in a pure Sales role than in roles that do not interact directly with customers or carry some level of Quota.  I think that’s because when times are tough, it’s critical to know how I am adding quantifiable value.  But I digress.

This is a post about the mobile app team, and what skills we think need to be on that team.

So, here’s what we think:

1. Sales guy- in our case, the Sales will be done mostly through Internet Marketing strategies, so it’s kind of a Marketer’s role, but we’ll know whether our Marketing is successful by virtue of hard numbers that translate to cash.  The Sales guy also gets to vet various prospective revenue models since the Sales guy is usually the one with more experience around which sales strategies work, and how well, and most importantly, how much effort is required for any given Sales Strategy.  The value of any Sales strategy is in part a function of the level of effort required to execute that strategy.  Herculean efforts are not often scalable or repeatable, and Sales strategies ought to be scalable and repeatable.

2. Mobile App developer- This is obviously the most important role.  Without a product getting built, there’s nothing to sell.

3. Graphic Designer- This is critical for us since we’re building a Consumer App here, and consumers like excellent graphic design a lot!  Of course it’s more than just colors and lines though.  User Interface and Experience are critical aspects of whatever design we end up employing.

4. Server side developer- This role depends on the app you’re building.  Most Apps seem to be software that sits on the device and doesn’t need to talk to a server for anything in particular.  Our app actually has a social networking aspect to it, and that social networking function will be managed ultimately by our Server.  So, we’re really building a Mobile Social Networking App that may require a couple engineers instead of just the one building the Mobile App.

Now, in our case, Tim, who’s building the mobile app is totally capable of doing anything needed on the server side as well.  But, we want another friend to be involved because, well, I just think it would be fun to work together!

And that’s probably the most crucial aspect to putting the team together.  Skills need to be represented, but most importantly it needs to be fun to work together.  There’s really no assurance of financial success in this business as far as I can tell, so if it’s not fun, then there’s really very little point to doing it.

My blog is about a few things, but a couple of those things are Integrated Marketing and Mobile.  On both fronts, I’m becoming a huge Flurry fan.

First, on the Marketing front, Flurry is a perfect example of how to write a Company Blog.  What I mean to say is that Flurry does an amazing job of providing extremely useful information to the community rather than just hyping their own products and news all day long on the blog.  I did some keyword searches in Google on the topics of mobile app economics and stuff like that.  The Flurry blog returned high in the search result and for good reason!  The information I clicked through to was relevant, well researched and very well written.  Bottom line, those guys know how to use their Blog in the context of Search Engine Marketing and not just as a personal PR wire.

The other reason I’m digging on Flurry so much right now has to do with the Mobile specific stuff.  My blog is in part dedicated to the process of building a mobile app I’m working on with a partner.  We think there’s at least a small business to be built around the app.  The kind of industry information I’m gleaning from the Flurry blog is helping to better position the app and discern potential business models.  It’s just so comforting to know there’s a tool out there that can enable me to gather the kind of quantitative penetration and usage data that makes me want to stay up all night looking at charts and spreadsheets!

So, if you’re a Marketer, check out the Flurry blog from a best practices perspective.  If you’re into Mobile, check it out for some really great mobile app industry data.

I’ve been digging back into the mobile arena after taking a couple years off to launch Famplosion.  When I left the technologies required for delivering a meaningful TV experience on a mobile phone were, well let’s just say, not very compelling.  But what made the situation worse was that the industry was controlled by the wireless carriers which had a nasty habit of making it extremely challenging for any new startup to try and provide an improvement on the technology.  Such improvements cost a ton to develop.  The risk associated with making that investment and effort and then being at the mercy of the mobile carrier before it can be dropped into the consumer mainstream was simply too great.  Companies like Qualcomm could make a run at it, but not many others.

Until now it seems.  Love ‘em of hate’em, Apple forced on the industry the concept of the App Store, and this route to market has dramatically shifted the risk scenario associated with developing new technologies for the mobile phone.  It’s freekin awesome!

I got a link to this video from a friend today who is involved with this startup, so I thought I’d pass it on.  This video appears to be a step in the majorly right direction.

Check it out!

I’d like to use this blog, in part, to chronicle the process toward building and launching the Mobile App I’m working on with my partner Tim Jones.

This post is “Post 5″ because I’ve already written 4 prior posts on the subject, i.e: A new idea hatching, Mobile App wireframe slides, Wireframing the app, Now working on the revenue model

Here’s my disclaimer.  Anytime you do something new, you might succeed or you might fail.  But you will undoubtedly figure out how to do it better next time.  That is likely to be the case for me as well with regards to this Mobile App business.  I’ve built a Digital Media business, and have been the Sales/BD guy on teams building enterprise software businesses.  In each case I’ve learned a lot.  But honestly, I’m not sure if the balance of my learning is more about what wrong steps to avoid than what rights steps to take.

This is the first time for me building a mobile app business, so I think it’s likely these posts might more often than not be an embarrassing example of my fumbling inexperience on the subject.  However, this doesn’t bug me.  There is really no shortage of blogs out there telling the entrepreneurs of the world how to do everything right.  It’s possible this blog may end up being more about what to avoid than anything else.  Regardless, if that personal embarrassment can serve as something that emboldens some readers to start something up, build something new, create something on their own, then I’ll count this as a contribution to the greater good.

My goal here is to create and to learn.  If it also results in financial success, well then bonus!

So, on to the latest…

Yesterday I met with Tim to walk through the wireframes & use cases for the app, discuss the revenue models supported by the app and talk about higher level stuff like what do we want out of this partnership and how should it be structured.

First, I’ve learned it’s very important for partners to be sure they are on the same page from the beginning regarding what they want out of this new venture.  It’s kind of like asking your serious girlfriend whether she wants kids, 2 kids, 3 kids, etc before getting engaged.  Often you may not know if you’re going to be “1 and done,” “2 and through,” or “3 and free” so far ahead of time.  Plus, life stuff comes up that may change your views over time.  But talking about it is key.  If you get engaged and then have the conversation for the first time…complications.  Worse, if you get married and then have the conversation for the first time, worst case.  Or, it’s like asking her how big of a house she expects to live in when you do have kids.  You gotta know these things up front as they can create all kinds of unneeded and complicating stress down the road.

Same with partnerships.  Are we building something we expect will change the world?  Or is this going to be a cool little lifestyle business than never gets us famous, but pays the rent.

Tim and I talked about that stuff and felt comfortable with the sense that we’re pretty much on the same page.  I think it helps that both of us have been in the Valley for a while now, so maybe lack some of the extreme idealism of our younger entrepreneurial friends in the start up community.  I’m not knocking idealism, but I do know how it complicates things sometimes uneccessarily.

So, next we talked about what form of incorporation makes the most sense.  Should we just file an LLC or should we do an S-Corp or go ahead and create a C Corp?  For us, this is a function of how we expect to grow the business over time.  And whether we expect to sell the business at some point.

In terms of growing the business, it’s important to us that we be in a position to give future employees a stake in the game through some form of Option Plan.  That makes an LLC complicated.  Also, Tim and I are inclined toward the concept of F Class Equity, which at this point, I think might mean we need to go ahead with forming a C Corp.  (Here’s a post by John Bautista explaining Founder’s F Shares) I’m no accountant/lawyer, so I may be wrong here.  But I think in order for us to have F Class Equity in addition to Common, we’ll need to form a C Corp.  The down side here is the way C Corps are taxed relative to S Corps and LLCs.

I’ve done LLCs…probably won’t do that again.  It got way too messy way too early in the the business’s financing.

I’ve done C Corps, but those were companies we expected to raise large VC money for, and I don’t have that expectation here.

So, the question really is whether we need a C Corp to do F Class Equity for me and Tim, or if we can do that in an S Corp and gain the tax benefits from that form of incorporation.

I’ll do some research and let you know.

Today I spent a couple hours playing with the revenue model for the mobile app I’m interested in building.  I mentioned the revenue model in a previous post, and thought it looked a little too good, which usually means it’s off base in some fundamental way.  Well, I decided to build a completely different model based on a new set of assumptions, and sure enough the revenue potential projects into the future much differently than in the previous model.

This is good.

It means the modeling exercise is winding it’s way toward finding some semblance of anticipated reality.  Which is very good.  The worst thing in the world is to build out a new venture fueled by the hope of a phantom revenue model.

Many folks around here, in the Silicon Valley, have experienced that one for sure.  As have I.  Famplosion was started when conventional wisdom thought well of pursuing an audience for the sake of an advertising monetization strategy.  Well, just like in 2000-2001 the world shifted a little bit during 2007-2009 making the advertising revenue model a much more challenging proposition.

There’s really no shortage of thoughts in the blogosphere on why the advertising market shifted so greatly over the last couple years.  But I think the bottom line is totally a supply and demand imbalance.  As great as it is to advertise online, with the ability to track efficacy and everything, the supply of advertising inventory has increased more than the demand can muster.

And I don’t really see the trajectory of those supply and demand vectors changing anytime soon.

So, my new biz is going to chase mobile advertising!

Well, not really, that’s seriously a joke.  In fact, I’m somewhat committed at this point never to build something that requires building an audience before figuring out how to monetize.  That is like voodoo to me now.  From now on, I want to build stuff that can be sold to people who derive immediate value from the purchase.

And that’s kind of the model for my new app.  It’s a bit more complicated in that the app is actually likely to be free, but the service it provides will drive itty bitty financial transactions and the idea is to take an itty bitty fee for facilitating those transactions.

So there will still be plenty of opportunity for consumer marketing, which will be awesome and will keep me young.  But the name of the game will be to drive transaction volume by providing a solid customer experience with the app.

That model looks pretty good at this point also…not as good as the one I built a few days ago…that’s usually a good sign.  But, if I build another model that shows this is a dog that won’t hunt, I’ll let you know.

Related articles by Zemanta

• Making Digital Advertising Effective (slideshare.net)

I spent a few more hours today working on the wireframes for the mobile app I’ve been thinking about, and I have to say it’s pretty fun.  There’s just something gratifying about giving at least a graphical reality to an application idea.  I love the way the process forces a rigor of logic in understanding the work flow of even a relatively simple app.  One pane leads to two or three potential additional panes…it’s kind of like those old books, Choose Your Own Adventure.  Finding the intersections and ensuring the thing never gets so complicated it becomes unwieldy is critical.  In fact, I think I knew that the process could possibly reveal the application made no sense or was circular, or something like that.

Fortunately, having finished up the wireframes I don’t think I found any hanging chads, so to speak.

Next step, run it all by a real engineer and figure out how we’re going to build this thing!  Oh, and spend some more time on the revenue model!

Related articles by Zemanta

• Media Vehicle For The Future? (ubergizmo.com)
• Interactive iPhone Game Gets… Book Deal [IPhone] (kotaku.com)

I spent some time today get started on wireframing out the new mobile app.  I have to say this is going to be a very fun process!  In describing the app and process, I’ll have to be a little circumspect, because unlike the tech companies I’ve worked for in the past, this product, being a total app, doesn’t have much by way of strong barriers to entry from potential competitors.  So, if I’m right and this is a sweet little mobile app for lots of folks to enjoy, the name of the game will be speed of marketing and a viral distribution model for the app.  The only lasting value I’m going to create is a large base of users.  If I can’t do that fast enough, well, the jig is up as they say.

Regardless, this post is about the wireframing process not the marketing plan.

Never having done it myself, I asked a few friends for tools they may have used in wireframing out mobile apps and specifically iPhone apps.  Given that there are somewhere around 70 thousand iPhone app developers out there, I assumed there was a power point presentation floating around somewhere with slides that included iPhone images I could use to make the wireframes of the app look a whole lot better.

Well, my friends never seem to fail.  At least as far as simple stuff like this is concerned.  I had a couple options sent to me, and settled in on a deck from MockApp.  Their deck is freeware, which is awesome.  All they ask is that if you use their deck, you tweet about it…which makes it tweetware, yet another addition to our ever growing app crowd vernacular.  So I did.  I tweeted.  And I thought I’d do one better and Blog about it!  But when I think about it, I have more followers in Twitter than people reading this blog at this point, so, I’m actually not sure what’s better.

In any case, if you’re reading this, and interested in wireframing out a sweet iPhone app, then I encourage you to check out MockApp.com.

I’ve been spending a lot of time thinking about mobile lately.  I had a feeling I might when I started this blog, but I didn’t realize I’d be thinking about it this much.

The result of all this thinking (and some researching) is a new app idea that may end up proving to be a pretty cool little business as well.

I can’t say the idea is composed of land breaking technology, but I’d really like to use this blog to report on progress we make toward building the app, launching the app and growing the business if we discover there is actually a business to grow.

First step, bounce the idea off a real engineer.  I did that yesterday, and I’m pleased to report, some of my basic product software assumptions were validated by someone with credibility.  We met, white boarded it out and talked about partnering up on it.  Which stokes me.

Today I talked to another engineer friend about getting involved, and he seems to be game as well.  With those two guys, I think we could build this thing pretty quick.

Also today, I spent considerable time building various revenue models.  This is always the starting point for me as I like to see what the variables are for making money before getting started.  The model usually tells me something I didn’t think of intuitively, so is a critical step to figuring out whether it’s a good money making idea.

My models look good….real good.  In fact, maybe a little too good, which sometimes means the model is bad.

More modeling tomorrow.  And maybe some wireframing…which I’ll write about tomorrow.

Today Verizon and Motorola launched the first Android phone.  Here’s news from a guy who was there, Saul Hansell.

The sure-to-follow-marketing effort will leave us all wondering when Android will become self aware and decide to enslave the human race.

Regardless, I’m pretty darn excited about the launch actually.  Granted, not being a gadget guy, ironically enough, I’m not racing out to buy a new phone from Verizon any time soon.  But I am very excited about the implications.

One implication is that we’ll really need a framework for cross platform mobile app development if we didn’t already.  Winners here are likely to be Rhomobile who offers an open source moble app framework that allows developers to write once and work on iPhone, Android, BlackBerry, Windows and Symbian.  They are focused on enterprise software though.  It’s unclear as to there being demand in the enterprise for frameworks, but I’m rootin’ for ‘em!  The other likely winner is Nitobi who offers an open source framework called Phonegap.  It’s similar to Rhomobile but more geared toward consumer apps.  Useful?  Uh, totally/extremely/yup.  Monetizable? Jury out there as well.

Google and Apple will duke it out in the market.  I believe RIM will stay in the game.  Microsoft will spend a fortune trying to convince itself it is still in the game.  All this activity brews opportunity for the entrepreneurial class in Silicon Valley.  When titans fight, stuff falls out of the ring that can turn into awesome businesses.

That’s what I’m excited about.  I’ll keep my eye open and let you know if I find something.