After defining our product personas and before proceeding with other product development activities, we want to make sure that the problem or the desire we are addressing at the feature, product or company level exists! Otherwise, we will end up with a software or features that nobody cares about.

As a product manager, you want to avoid just adding features to the product because you will run into many situations where every stakeholder has a “killing” feature to add and will make your product awesome, specially salespeople 🙂

The alternative is being diligent and observant about our users and what they really care about, and to create problem scenarios and alternatives pairs. To illustrate, I will give an example from my current position at work:

I needed to board new technical talents to my product development team and I had to approach an outsourcing company. So I sent them clear and precise job descriptions for the positions I would like to fill. This process took many weeks and exhausted me and my supplier because they were not able to do proper screening as per my criteria. They also didn’t have enough technical knowledge to understand the nuances between resumes.

What are the problem scenarios in this case? I would say:

CK the supplier recruitment manager:

Trouble reading through hundreds of resumes which results in overlooking good candidates.

Lacking technical expertise which caused unqualified candidates to be sent to the client.

Marlin the client resource pool manager:

Qualifying the shortlisted candidates to make sure only relevant ones are passed to the functional manager.

Do you notice how a problem scenario should be simple, clear and up to the point?
Next, we have to state the alternatives which means describing how things are being done currently. For example:

CK the supplier recruitment manager:

Sift through resumes, call applicants, book meetings, and fill in the roles and responsibilities matrix to score the applicants.

Marlin the client resource pool manager:

Conduct online quiz and preliminary interviews to further filter the candidates.

In future posts I will explain how to develop user stories. But for now, we need to break down the alternatives into smaller activities to prepare for linking them with user stories. This linking keeps us aligned to business needs and allows to debug backwards when something goes wrong with our product features.

CK the supplier recruitment manager screens resumes based on a certain criteria or job description.

CK the supplier recruitment manager populates the responsibilities matrix for the shortlisted candidates to find out their score.

CK the supplier recruitment manager sends the shortlist to Marlin the client resource pool manager.

Marlin the client resource pool manager prepares online quiz based on the job description.

Marlin the client resource pool manager sends out interview requests to the successful candidates.

These tasks work as the antecedents to user stories and lead us to specific interactions that the user wants to have along with testable rewards.

Finally, it is worth noting that problem scenarios are not only problems the user has, they can also be needs, desires or habits. For instance, in Facebook case:

Stay in touch with friends and family