This is my final article in the series on building a mobile App. This is the fifth article in my series on building Apps. Part I covered the basics of vision and marketing. Part II was a discussion on the importance of reviewing App store guildelines. Part III covered writing requirements and Part IV was about prioritising those requirements. Part V discussed the critical task of choosing a development team.
In this post, I will write about your commitment to your App as it develops and how you can help make it great.
All great products have an owner. The Product Owner is the person who loves the product. The Product Owner is the person who is proud of the product. The Product Owner is the person who is responsible for the product. For your App, that person is you!
You should never delegate that responsibility to anyone else. You can delegate the work of building your App, designing the look and feel of your App, even choosing which features to include in your App. You should never delegate the responsibility though!
A strong Product Owner will ensure that the right App gets built and that the team remains focussed on doing a great job!
One of your commitments as Product Owner is likely to be testing the App. Your developers will prepare a new version of your App every day or two for you to review. They will tell you what they have been working on. You will probably want to check the new features and the existing ones too to make sure that everything is as you want it.
This might take a few minutes or a few hours depending on your App. You need to be prepared to spend this time examining the App as part of your daily work! It will be critical in ensuring that your development team build the App that you want.
You will probably have feedback for your developers based on your testing. This comes in various forms:
- Bug reports
- Change requests
- New feature ideas
Bug reports are things you have noticed that are not working as required. This could be an incorrect calculation, an App crash or something similar. These tend to be high priority items that need to be fixed.
Change Requests are things that are working as you asked, but on reflection and after testing you decide that they should work differently. For