Candidate: Matheus Leite Divino

Date: 03/26/2024
Intended Position: Product Owner
Challenge: Create an analysis of the following situation: Your client needs a form to register
participants for the event, where the participant can select the ticket and the date they will
attend. In the end, your client will need to know how many customers registered, which tickets
were purchased, and for which days.

As Product Owner of the team responsible for developing the product, I would conduct the
following actions:

1. Understanding Customer Requirements:

Initially, I would have a meeting with the client to fully understand the requirements and
objectives of the registration form. Together with stakeholders, I would clarify which
information is essential for the product, such as the total number of participants, types of
tickets sold, and selected dates, thus defining the necessary functionalities to create the
Product Backlog.

Examples of functionalities that could be defined:

• Registration Form with fields for name, email, optional phone number, ticket selection,
and event date.

• Data validation to ensure that mandatory information is provided correctly.

• Automatic counting of registered participants.

• Detailed reports on the number of participants, types of tickets, and selected dates.

2. Prioritizing Functionalities:
I would prioritize the functionalities that have been identified and included in the Product
Backlog, based on customer requirements and user needs. I would develop user stories and
prioritize the product backlog to organize functionalities in order of importance (I particularly
use the MoSCoW technique for prioritizing the product backlog).

Example of Prioritized Product Backlog, using the MoSCoW technique:

1. Development of the basic registration form.

2. Implementation of data validation and automatic participant counting.

3. Creation of basic reports on registered participants.

4. Refinement of the user interface for better usability.

5. Integration of security and compliance measures.

3. Definition of Acceptance Criteria:
I would define acceptance criteria to ensure that all functionalities and requirements expected
by the customer are adequately met in the delivery of the final product.

Example of acceptance criteria that I would adopt:

Participant Registration:

Acceptance Criterion: The form allows participants to fill in all mandatory fields, and
the data is correctly stored in the system.

Data Validation:

Acceptance Criterion: All mandatory fields are properly validated, ensuring the
integrity of the data provided by the participants.

Automatic Participant Counting:

Acceptance Criterion: The system maintains an accurate count of the total number of
registered participants, updating automatically as new registrations are made.

Detailed Reports:

Acceptance Criterion: The generated reports present clear and accurate information
about the number of participants per ticket type and per event date.

Usability:

Acceptance Criterion: Participants can fill out the form intuitively, without
encountering difficulties in navigation or field completion.

Security and Compliance:

Acceptance Criterion: The system ensures the security of participant data and complies
with privacy regulations, such as LGPD.

4.Transparency and Communication with the Team:

I would work closely with the development team to ensure a clear understanding of the project
requirements and priorities. I would hold regular planning and review meetings to align
expectations and ensure development progress.

5. Incremental Iterations:
I would adopt an iterative approach, releasing incremental versions of the form for continuous
feedback from customers and users. I would prioritize delivering high-value functionalities first
and iterate based on feedback from users and customers.

6. Product Validation:
I would continuously test the product in development to ensure it meets customer
requirements and user expectations. I would conduct usability tests and collect user feedback
to identify areas for improvement.
7. Change Management:
I would be prepared to deal with changes in customer requirements as the project progresses. I
would assess the impact of proposed changes and collaborate with the team to adjust the
product plan as necessary.

8. Metrics and Continuous Improvement:

I would define success metrics to evaluate the performance of the registration form, such as
the number of completed registrations and user satisfaction. I would regularly monitor these
metrics and adjust the product based on results to ensure a process of continuous
improvement.

9. Conclusion:
Following this analysis, it would be possible to create a product that effectively meets the
customer's needs. By fully understanding customer requirements, prioritizing functionalities
based on business value, and defining clear acceptance criteria, I believe that as a Product
Owner, I would be able to guide the development team in creating a registration form for
events that is intuitive, functional, and capable of providing valuable information to the
customer. By adopting an iterative and collaborative approach, with continuous feedback from
customers and users, the product could be adjusted and improved over time to meet emerging
needs. This ensures that the final product is successful and delivers tangible value to the
customer.
MoSCoW Technique
The MoSCoW technique is a prioritization approach used to determine the relative importance
of requirements or functionalities in a project. The term "MoSCoW" is an acronym representing
the four prioritization categories: Must have, Should have, Could have, and Won't have. Here's
a detailed explanation of each of these categories:

1. Must have: These are the requirements essential for the success of the project. If these
requirements are not met, the product will not be functional or will not meet the
needs of the customer.

2. Should have: These are important requirements, but not essential for the initial
release of the product. They add significant value to the product, but their absence will
not prevent delivery.

3. Could have: These are desirable requirements, but not critical to the success of the
project. They can be included in the product if time and resources allow, but they are
not considered priorities for the first version.

4. Won't have: These are the requirements that will not be included in the scope of the
current project. They may be considered for future iterations or versions of the
product, but they are not an immediate priority.

I have been using the MoSCoW technique for prioritization for about a year, and it has always
worked very well for me.