Hi, i have been asked to submit a Proof of Concept Document before working on the iphone app (for my college) which would include the feasibility of the project, the working of the app and so on. i've never done this before and need a template of a POC for my reference. couldn't find much on the web.
+1
A:
'Proof of Concept' usually refers to a very simple prototype application that delivers very little functionality while proving that your idea is feasible.
As far as a document to illustrate proof of concept, you will need to explore your ideas in relation to the iOS API and its capabilities on your form factor (iPhone 4, 3GS, iPad).
You won't find any templates for this document, and your professor was most likely asking for a simple and relatively abstract document to support your claims - not a piece of formal documentation. My advice is to write up a page or two exploring the more complicated parts of your idea and your ability to create them on the device.
Good Luck!
Brandon
2010-07-07 18:09:49
+2
A:
The two terms are almost contradictory, so you should definitely clarify the scope. 'Proof of concept' to me implies that you're showing a scaled down prototype of an app that has been conceptualized, to prove that it can work, with running code. 'Document' on the other hand is a listing of requirements, the positioning of the product in the market, resources required and a plan of action.
Based on your description, the 'proof' here isn't that the app will work efficiently at a technical level, it's that you've done the research to know what you're getting into and have a well defined path that you'll be taking when you develop it. It's a great strategy to take, especially because it makes sure that you're not simply focused on the code, but understand the larger context that you're app will exist in among the iPhone/App Store ecosystem as a whole. In a larger team, this is what a product manager does, but indie app developers often have to wear multiple hats.
Some things to consider:
- Break the app down into multiple milestones. What will the first release do, what features would be added at a later stage?
- What technologies (frameworks, web services, stock artwork) can you reuse from the community at large to reduce development time/costs?
- Why should this app be developed 'in house' (if applicable) and not outsourced entirely (or vice versa)
- Who is the target user? How will you reach this target user?
- What is the first time user experience like? How will you train the user to use your app?
- Where can you promote your app, either for free or at cost?
- What's your pricing strategy? If you made a more feature rich, advanced product, can you still make as much money, if this means pricing the app higher to recover the time spent on it?
- Contrast your app against others in the same field and explain how it would stand out. Will this app be relevant in the long term (6 months, 2 years from now).
- What are the risks involved (App Store rejection, scaling, technical complexity...)
- Should this even be a native iPhone app? Why not a web app?
- What happens post release? What are the benefits of simply making minor updates and moving on to a new project vs. releasing major revisions (considering you can't currently charge for new versions in the App Store)
- What other monetization options exist (in-game purchases of extra features? subscriptions? ads?) How do each of these impact your potential adoption rate?
- Should there be a free/lite version?
- After release of the app, what additional infrastructure is needed? Who provides customer support? Are there any data feeds that the app consumes that will need to be updated?
Also check out some of the prototyping apps out there, like Interface andBriefs or MockApp. Other tips here.
Joost Schuur
2010-07-07 19:08:28