Posts tagged iPhone
ngmoco:) recently launched a new mobile social game for iPhone called “We Rule”. It relies on a freemium revenue model allowing users the option to accelerate their in-game success purchasing “mojo”. Mojo is We Rule’s in-game virtual currency that allows users to instantly perform actions – rather than waiting a specified period of time – that result in gaining coins, a secondary form of in-game currency that is used to purchase new items. ngmoco used a similar revenue model (centered around saving time) in their last game, Eliminate Pro.
We Rule has a built-in social layer, which is actually pretty good for users that have already found their friends. However, finding friends and other gamers isn’t easy. As Canadians join the “We Rule” beta, many gamers are left looking to find other users and have turned to forum sites and paid sites to exchange data (gamernames, current levels, businesses owned and open) on becoming in-game friends to help one another outperform the competition.
Better than turning to forums, which require signing up (and sometimes associated fees), feel free to use the comments section below to list your information to exchange with others.
This is the preferred format for exchange:
Plus+ ID: sook
Open Businesses: 16
Gamers: Please feel free to check back in and leave a new comment (or exchange request) as you find your number of customers decreasing.
As an aspiring tech CEO, I have been told numerous times that being an “A+” Product Manager will provide the experience, understanding and discipline to become a great CEO and to lead an accomplished company.
I often provide strategy and product development guidance to some of our portfolio companies; however, I wanted a more immersive experience and to be part of the excitement of startup life. So over the last several months, I increased my assistance to a particular portfolio company in the Toronto area, which I believe is well positioned in the marketplace. Strategy discussions with management of this company led to a conversation to bring me on-board as Product Manager of a new mobile social game at the idea stage. Eager to help the company succeed and to gain additional experience, I undertook a more formal responsibility on evenings and weekends as Product Manager. It was a perfect fit for both the company (lacked product management capabilities) and my career ambitions.
As part of the team, I faced my first challenge: Figure out the best way to manage the development team and the product. I evaluated several methods of product development and eventually settled on SCRUM since it is ideal for agile development with rapid iterations and incremental updates — perfect for an iPhone game.
For product managers that are new to SCRUM, be sure to check out the SCRUM Reference Card (great overview) and beginners SCRUM Guide (fairly basic). These were helpful resources in my quest to better understand this product development process.
It was my next goal to conceive of a process to coordinate everyone’s collective efforts on the team to come up with ideas and potential features for the game and to convert that list into the Initial Release Plan and Product Backlog for the game. I created a spreadsheet in Google Docs and shared it with the team. I wanted to be a very transparent Product Manager and show the team everything that I saw — idea list, resource planning, timeline estimates, business value associations to product features, etc… I did this because I believe that transparency will help the team better understand my points of view and decision-making rationale.
Since I am continuing to learn, I invite you to have a look at the Initial Release and Version planning spreadsheets that I created to manage the product development process. Naturally, I stripped out any game-specific information, removed the names of people involved and altered values so that it would no longer represent our plan in any fashion. Other small changes to this public version include:
- For the idea list tab, each item should be a minimum of 4 hours to a maximum of 16 hours only; tasks less than 4 hours should be placed on each developers Scratch Pad and aggregated into an item on the list; tasks greater than 16 hours should be broken down into components (if possible) to fit within the 4 – 16 hours window for ideal planning purposes.
- Each developer would have his or her own “Scratch Pad” (the demo version only shows 2).
- The only tab that was completely removed was the method by which we determine business value for each product feature.
- The “Product Backlog” tab is dynamically driven from the “Idea List” tab and broken-down into version and sprint for each assessment; a tip for collecting the unique “Groups” is to export the long list of Groups from the “Idea List” into Excel and create a Pivot Table, then select the grouping and extract the unique elements to import back into Google Docs.
- In the “Product Backlog” tab, you should determine your own complexity factor for the project (a guide to determining this factor can be found in the SCRUM Guide linked above).
I would love to hear your questions, comments and (hopefully) suggestions to further improve what I have already created in hopes of making this effort more successful. If you would like a copy of my example spreadsheet, please let me know and leave me your email address in the comments section below; I’ll make sure to get you a copy either on Google Docs or as an export to MS Excel.
My next post will discuss putting this plan into action.
In the early days of the gold rush to create location aware and contextually relevant mobile applications for smartphones, I was constantly bombarded with business plans that showed revenue models driven from advertising. Although advertising is a plausible way of earning revenue, there is a high level of inherent risk since those businesses are largely at the mercy of market rate CPMs/eCPMs and available ad inventory (unless you have a rockstar in-house ad sales team). Ad inventories are beginning to improve as advertisers are becoming more and more aware of the high interaction and engagement rates of mobile ads. However, for startups looking to differentiate in their niche, monetizing solely through ads is a risky road to travel. That being said, I believe that ads are still relevant for *lite* versions of apps that supplement a paid model of some form and for monetizing certain consumers that would not otherwise become a paying customer.
Tim O’Reilly wrote a short article last week on the convergence of Advertising and E-commerce and I thought he hit the nail right on the head. He says that “E-commerce is the killer app of the phone world. Anyone whose business is now based on advertising had better be prepared to link payment and fulfillment directly to search, making buying anything in the world into a one-click purchase. Real time payment from the phone is in your future.” I completely agree. Square is a great example of real-time point-of-sale (POS) coming to iPhone.
In the article, O’Reilly arrives at this conclusion by making a few theories about what can be expected from the marketplace based on some recent announcements and common sense:
- Google, Apple, and Microsoft will announce e-commerce programs akin to AdSense, in which retailers will register with “app stores” to allow physical goods and services to be bought as easily as apps
- We can expect announcements of partnerships between phone providers and Amazon or Wal-Mart to fulfill mobile e-commerce requests
There are a number of mobile apps that are positioned well to capitalize on some of these trends such as foursquare and other mashups of local and geocoded information. IMHO, there is a more exciting category that is only starting to gain excitement. Companies like Layar, Tonchidot (Sekai Camera), Mobilizy (Wikitude) and TAT (Recognizr) are creating augmented reality browsers and applications that use location data and combine it with image recognition technology to recognize specific people or places in the physical world and allow the application user to interact with them in some capacity. I strongly believe that these are some of the fundamental technologies that will make this category of future applications possible. By linking interaction of location-aware data through to payment and fulfillment functions, one can point a phone at a local pizza restaurant and order a pizza to their home en route. Another example may be pointing a phone at a friend and performing a money transfer with only a few clicks.
What killer apps can you think of that combine hyperlocal, e-commerce and fulfillment?
As an after thought to my last post on virtual goods, I published a comment discussing Eliminate Pro’s innovative play (or “experiment” says MTV Interactive) on Apple’s changes to the App Store to allow for in-app billing on certain items. It’s been a successful experiment. As of yesterday, the game has been downloaded 500,000 times so far at a rate of about 25,000 an hour, currently making it the top free app in iTunes (via TechCrunch).
After some successful digging, playing the game and reviewing Apple’s Developer Agreement. Some red flags were raised…
Eliminate Pro, a game developed by ng:moco, is an action-packed first person shooter (FPS) game that progresses very slowly. The game uses this tactic to charge impatient users to play and progress through the game at a faster pace. The game allows users to buy more battery packs or cases (Power Cells) through the In-App billing system. This allows users to recharge faster, compete to earn more “credits” so that they can upgrade their fighter’s armor, weapons and other items (virtual goods). Power cells are the currency of the game.
What I want to know is where Apple is drawing the line in the sand in terms of what is considered a virtual currency and what isn’t. As per Apple’s iPhone Developer Program License Agreement (the “Agreement”), Apple states:
Additional Restrictions 2.1 You may not use the In App Purchase API to enable an end user to set up a pre-paid account to be used for subsequent purchases of content, functionality, or services, or otherwise create balances or credits that end users can redeem or use to make purchases at a later time. 2.2 You may not enable end users to purchase Currency of any kind through the In App Purchase API, including but not limited to any Currency for exchange, gifting, redemption, transfer, trading or use in purchasing or obtaining anything within or outside of Your Application. "Currency" means any form of currency, point, credits, resources, content or other items or units recognized by a group of individuals or entities as representing a particular value and that can be transferred or circulated as a medium of exchange.
Specifically, item 2.2 of ‘Additional Restrictions’ within ‘Attachment 2′ of the Agreement raises some obvious questions about how Eliminate Pro got approved. Eliminate Pro uses Power Cells (the virtual good that they sell) to buy additional energy (a resource) that they can use in a game to earn credits, which are redeemable for weapons, armor and other inventory items.
This seems to be in direct violation to the Agreement. Unless, however, Apple is okay with allowing “indirect” forms of currencies to work (Buy Energy > Spend Energy for Time > Use Time to gain Credits > Use Credits to buy Virtual Goods (weapons, etc…)). Some clarity please?
It would be great if some people (Apple execs, developers, anyone) could weigh-in on this matter. What types of “economies” or “currencies” can be established while still being compliant with Apple’s policies?
Please share your perspective below.