Just Product Management Things - Issue #4

Writing Better One-Pagers, Why you should avoid (Feature) Prioritization Frameworks and others

and

Feb 13, 2022

Often, the same growth tactics do not apply to frequent usage products and infrequent usage products. ICED (Infrequency, Control, Engagement, Distinctiveness) is a framework proposed and used successfully for growing infrequent usage products.

The Challenges of Growing Infrequent Products

Gain knowledge on the users and product in such a short duration
Monetize users well
Establish a sustainable acquisition engine
Turn the product into a viable and scalable business

ICED Theory

I = Degree of Infrequency

C = Degree of Control Over the User Experience

E = Degree of Engagement Before, After, and During The Transaction

D = Distinctiveness of The Product
To grow infrequent products, deploy strategies to move from the left to the right side of the spectrum for any of these dimensions.

Read more on Reforge (Do read the 2-part article series to learn more about the ICED theory with examples.)

How to Listen Better as a Product Manager

Listening isn’t about just hearing intently and seeking to get the other person’s opinion, but (in product building process), it also about participating and actively seeking to listen more. From listening to being a teacher to listening to being a student; this is a great piece on listening for executives, leaders, product managers, designers and other product sub-functions.

The most relevant ones for Product Managers are:

Keep your own bias at bay: Ask open ended questions when talking to customers and stakeholders alike. Closed-ended questions can really keep you from getting real, valuable feedback.
Influencing internal stakeholders: When trying to influence, listening is more important than talking. Instead of driving your points up against a wall of objections; listen for the underlying objections, motivations, challenges; that can truly help you tailor your communication for convergence.
Maximizing what you can learn from users: When listening to users / customers in research; instead of presuming that their questions are due to lack of context or that they are seeking help; help them help you understand why they are asking questions or making certain comments.
Match your mode to the moment [For Managers]: In 1:1s; match your listening mode to the direct report you are dealing with and their specific need at the moment - do they want a meditating listening mode or do they need a validating listening mode.
Deepen the conversation to avoid the doorknob moment [For Managers]: More often than not, your subordinates are going to end up using the entire 1:1 to muster enough courage to speak about the most important thing and eventually mention it as a passing comment towards the end. Look to go deeper earlier in the conversation
Watch out for when you are getting emotional: Everyone in the product org has different context and understanding of customer’s needs and are likely to thus provide feedback on your work - designs, product documentation, strategy, etc. Instead of allowing yourself to react emotionally and defending it; listen to understand their underlying context better and use it to tie back to your product.

The Psychology of User Decisions

People usually make decisions based on the following well-established and predictable subconscious patterns. The article talks about these patterns and how to use them build better products:

Satisficing: People are looking to settle on the first reasonable option.
Usage: Make it easier for users to consume information using more graphics, easier to consume copy, etc.
Loss Aversion: People fear losses more than they are enticed by the gains.
Usage: Use copy and UX to give users more control on decisions they make such as confirmations, affordances to undo, etc.
Availability: People tend to make decisions based on what is easily available.
Usage: Limit the number of things trying to draw attention to simplify user’s focus and decision making
Decision Fatigue: If people are forced to make too many decisions, they are likely to get tired and end up making suboptimal decisions or defer decision making.
Usage: Reduce decisions per page or per job for the user.
Reference Dependence: People are dependent on a reference point to be able to understand value.
Usage: Make it easier to make decisions by telling how the cost of it is in comparison with the cost of a common item they purchase.
Status Quo Bias: People need a strong incentive to move away from status quo.
Usage: Predict user needs and help them with defaults to reduce the number of decisions

Why you should avoid (Feature) Prioritization Frameworks

The central idea is to prioritize problems / opportunities using frameworks and not features / tasks. The various reasons cited for this idea (and I am adding some of my own) are:

Prioritizing features can easily lead you into losing sight of the most important problems / opportunities and you might end up trading off a “must have” for a “good to have”
Frameworks depend on guesstimates (probabilities) and while all guesstimates can be equally wrong, some can be more wrong than the others. Also, 2 uncertainties are not similar in nature and comparing them might not be appropriate
Most frameworks put too much emphasis on “effort” and it might swing your prioritization away from real priorities
Not everything can be captured well in the frameworks; especially things like the needs of a large, anchor customer (in B2B) can sometimes be much more than a few smaller ones

Writing Better One-Pagers

A one-pager lies somewhere between the spark of an idea and coming up with a detailed plan for the product. It’s a document created after research and sets the tone for a product or key feature early in the process. With one-pagers, you can:

Collaborate: Invite other stakeholders to understand the current state and the desired inputs from them so they can easily contribute
Drive decision making: or other intermediate outcomes in the product building process

A one-pager should be:

Simple Yet Self-sustaining: Link to detailed research, concept notes, data, but aim to simplify in 1-2 sentences every core construct and current-state and desired outcome.
Humble: Surfaces assumptions, unknowns, questions, risks, etc.
Succinct: Minimal fluff, and concise. Be clear about the decision / inputs you are seeking
Inspiring: Gets people excited to collaborate with you on the problem
Convincing: A one-pager has to be inherently convincing (despite the humility) and it should clarify your position vs possible options / directions / inputs; to be able to make faster decisions.

The very nature of the one-pager is for it to be open (within the organization) and quick (in both creating and collaborating) and hence, it should be created quickly yet carefully.

Read more on Medium (Some one-pager templates inside)

Just Product Management Things