Product Management Playbook — Part 2/6 — Definition

The question we ask in this segment is “How do we define user problems or needs from all our research so that all the stakeholders are on the same page?”

In my series “Product Management Playbook — 6 Part Series”, I focus on how product managers can build awesome products that users will actually love and use. In the First Part, we understood the users and their problems. In this Second Part, we will look at how do we combine all the research and define where the problem’s exist.

The goal of this phase is to define user problems and needs in a standard organizational format so that everyone within the organization understands the same thing as you.

If the user and the company are not on the same page for key problem or need, there will be lots of wasted time, effort and resources. Now that we have identified what the pain points of the users are, we need to define them such that all the stakeholders have the same understanding as you.

The things we need to define are as follows:

• Who are the users?
• What are their problems and needs?
• Why are the users facing the identified problems?
• When are the problems occurring?
• Where are the problems occurring?

Remember the iconic image above which flooded the internet? This image above represents what happens when the requirements (needs) of the users are not defined properly. Therefore, it is important that you document the observations according to the necessary standards so that all the stakeholders understand what you understood.

Definition Framework

Below framework can be used for defining your understanding regarding user needs:

1. Business Problem — This is where you actually define the problem faced by your target users. It should be in the following format — “The <User> is facing a <Challenge> in doing certain <Action> which is resulting in a <Business Problem>”
2. SMART Goals — The product manager should have SMART goals in mind while defining the user needs or problems. This means the goals should be Specific, Measurable, Achievable, Realistic and Time-Bound.
3. Product Scope — Product scope deals with the functionality which is in-scope and out-of-scope. Product scope is defined as the functionality and features that are part of your intended product. Here, product manager defines what part of the business problem will be addressed.
4. Assumptions, Constraints & Dependencies — An assumption is something that you believe to be true. An assumption can be that you think a user will behave in a certain way. Constraints can be internal or external and can be in the form of cost, time and effort. Dependencies describe the relationship between two or more sequential attributes. This might mean that your product might be dependent of some other feature or product or system.
5. Timelines/Milestones — This will contain the timelines of when the product should be available to your users. If the product or feature is big enough, it should be broken down into sizable milestones.
6. Success Criteria — This is the part which will determine if the product you built is successful or not. Product managers need to have a clear view of what will define the success of the product.

The most important thing to remember is that in definition phase, we only define what we understood regarding user needs and requirements and nothing related to a potential solution.

“The “P” in PM is as much about ‘PEOPLE’ management as it is about ‘PROJECT’ management.” — Cornelius Fichtner, The Project Management Podcast

What am I missing here? Let me know in the comments, and don’t forget to share your ideas too!

Enjoyed what you read? Hit the CLAP below and share it, so that others can read it too.