Product Requirements
Document Case Study
Nicholas Estibar
Overview – Photo Sharing app: Aperture
Career Foundy Product Management Task Simulation:
Aperture is a photo-sharing application that is free to use, the company brings in revenue by selling advertising space. Recently, the number of active users has declined as users interact with the app less and less. Some have stopped using it altogether. As a product manager we were tasked with improving interaction and interest back into the App
As a product manager we were tasked with improving interaction and interest back into the App
Context
CareerFoundy Product Management Task Simulation:
This project was a part of a Product Management course to demonstrate skills of a product manager. For this simulation, I was tasked in increasing user interaction and interest back into the app. To do so, a Product Requirements Document is required to organize a plan of approach for app improvement.
Product Requirements documents are essential to product development because it defines the product we are to build. It aligns stakeholders, organizes data and testing, and establishes timeframes
Interpreting Data and Designing the Problem Statement
Analyzing and interpreting relevant data available is needed to diagnose the issue and verify the underlying reasons why there’s a problem. This was an important step in the process that sets the direction that we need to take our product and make improvements.
Tools: Microsoft office and Miro to organize ideas
Overall, the data charts correlated with user reviews but if there were a possible way to extract more data. It would have been beneficial to my research.
Please click Data Interpretation to see my Key Insights.
Problem Statement:
Based on our user research, over half of exit interviews for
Aperture’s younger users are due to lack of features as well as
reliability. We have seen a decline in the number of our active users
and user interaction and we need to revitalize interest back into our
app.
Developing product goals
Once we establish our problem statement, our next step is creating an approach towards a solution. We want to make sure that we address our user needs with awareness to our market competitors services and features as well.
Hypothesis: If users able to browse and download filters, they will display higher rates of engagement
Product Goal: To create a feature that makes filters easier to use and to make a seamless transition for our current users to adopt.
Three metrics: Increase of Users, Rate of Usage and User Feedback.
The hardest objective in this task was to develop the metrics since numbers doesn’t always quite tell the full story, so I wanted to measure something more qualitative to understand the user’s feeling toward the product since it may be a possibility that some one is using the app for hours but in those hours, they are confused or frustrated with our product
Prototyping:
Voice Command
Success Criteria
I followed a “Single Feature” Minimum Viable Product format, because we were aiming to focus on the voice activation feature to access the filter mode.
Criteria: Our MVP will be the voice activation feature that will allow the user to say the word “Open” in the language the app is set to for the user and the command can be confirmed by a dimmed screen that will be titled “accessing filters” until the filter is loaded.
● Success will be measured by rating at least 7 out 10 average on the enjoyability question per the help survey and feedback once the feature has been live for two quarters.
● Another success criteria will be measured ultimately by the amount of successful first attempts.
● We want to see an Increase in user base by 10% and user’s app usage by 10% after 2 quarters post-launch.
Tools: Miro, Figma and Microsoft Office
The prototype testing and creating the success criteria was a bit complex because I couldn’t physically obtain user feedback from the prototype. If this were a real product more accurate date would lead do different reiterations of subsequent prototypes until we feel confident, we could meet our success criteria confidently instead of taking an educated assumption of what our users may feel.
Team Roles and Assignments
See link for detail of Team roles, timeline and budget.
This step in creation of the PRD is essential because it lists responsibilities for stakeholders following Agile methodology for the product’s continuous development in both development and post-launch phases. It also provides timelines to finish objectives by and a rough budget of how much resource it may take.
Tools: Microsoft Office
The most difficult element here was developing a budget, I’m not too familiar with average rates each stakeholder would make including the amount of time they will need to accomplish their tasks is something that with more familiarity of these positions I can give a more accurate estimate of budget.