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.