Author: Meredith

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

– Kate Hopkins in “How to Spot a Partial Product Manager”

a great product manager understands customer feedback first and foremost. But an exceptional PM knows how to contextualize that customer need within the broader company vision and strategy, and then decide whether or not to implement what the customer is asking for.

– Andy Johns, from “What Makes for a Good Product Manager“

Engineering work is novel and intrinsically requires human judgment. It produces a permanent improvement in your service, and is guided by a strategy. It is frequently creative and innovative, taking a design-driven approach to solving a problem—the more generalized, the better. Engineering work helps your team or the SRE organization handle a larger service, or more services, with the same level of staffing.

Eliminating Toil, from Google’s SRE blog