Author: Meredith

A career ladder is merely a guidebook for your career journey, not the be-all-end-all. At the end of the day, it’s your job to define your own career aspirations/goals, and the manager’s job is to help you get there using the career ladder as a general guidebook. If we were to use travel as an analogy, you must determine your final destination on the map while managers act as guides who set milestones to help you get there. Don’t expect your managers to set the destination for you.

Helena Seo, in “‘Designing’ a Career Ladder for Product Design“

The way I define the product leader’s job is to delight customers, in margin-enhancing, hard-to-copy ways. Your product strategy should define your key hypotheses about how you plan to deliver on these three dimensions. The metrics are how you measure your progress, and the tactics are simply projects or experiments against each of your key strategies.

Gibson Biddle, in How to Run a Quarterly Product Strategy Meeting: A Board Meeting for Product

This is especially true when faced with a multitude of different modes of data: open-end, scale, and rich media like videos. But when your analysis window is tight, you’re likely to fly past that meaty “who-they-are-data,” and scour for the flashy “clear-business-impact-data.”

Kyli Herzberg, Lindsey Brinkworth, Karen Eisenhauer, and Ben Wiedmaier in Foolproof Qualitative Analysis Tactics—For Whether You Have a Month or an Afternoon

The “who” tells you the why, which lets you foster the change management necessary to drive product success. A product that nails the “business impact” without fitting into the workflow and motivations, the “who they are,” of real humans, yields no impact.

What we don’t want to do is to create an easy-to-use system that can amplify bias and deepen racial disparities.

– Anne Quito, in “How UX Design Can Counter Racial Bias“

It doesn’t matter how right you are if you can’t get someone who disagrees with you to listen. You won’t make it far at all if you don’t understand why they disagree.

The opposite of a Know-It-All is a Learn-It-All

Kit Merker in “The Curse of the Know-It-All Product Manager“

But I actually think the hill looks more like this:

Recall that in product there are always four risks:

* Value risk (will people buy it, or choose to use it?)
* Usability risk (can users figure out how to use it?)
* Feasibility risk (can we build it with the time, skills, and technology we have?)
* Business Viability risk (will this solution work for the various dimensions of our business?)

In an empowered product team, the product manager is explicitly responsible for ensuring value and viability; the designer is responsible for ensuring usability; and the tech lead is responsible for ensuring feasibility.  The team does this by truly collaborating in an intense, give and take, in order to discover a solution that work for all of us.

Marty Cagan, “Product vs. Feature Teams“

we have to acknowledge that our ideas are grounded in paradigms we know. this creates lacunae, or areas of unknown.

if we fix ourselves to a destination, and ignore signs along the way, we might get somewhere, but it may be the wrong place.

if we set our sights on problems, not solutions, we remain flexible and able to take in new information at every step.

This is why I promote the mindset of Experiment Pairing during the validation phase of Product Discovery. Because, as some of you probably know, users tend to lie about your product subconsciously. At the same time, quantitative metrics only tell you what people are doing, but not why.

Tim Herbig, herbig.co