Stochastic refers to a variable process where the outcome involves some randomness and has some uncertainty. It is a mathematical term and is closely related to “*randomness*” and “*probabilistic*” and can be contrasted to the idea of “*deterministic*.”
Rules of engagement are simply an agreement with the teams on what type of visibility the leader needs in order to give the teams the space they need to work. What information does the leader need in order to trust? What context does the team need to understand to be successful? What does the team need to feel safe in surfacing risks and problems early or asking for help? It's important to emphasize that these rules of engagement typically evolve as the trust and learning is built over time, but establishing some agreement around what information to communicate when, can help both the leader and the teams to work out effective ways for each party to get their needs met.
Most people coming from a feature team‐style company are surprised to see the differences in terms of recruiting, the seriousness of the interview process, how much time they devote to new employee onboarding, and most important, the ongoing effort in coaching and developing their people to reach their potential.
If the decision is primarily about enabling technology, if at all possible, we defer to our tech lead. If the decision is primarily about the user or customer experience, if at all possible, we defer to our product designer. And if the decision is primarily about business viability, we will depend on the product manager collaborating with the relevant stakeholders. The hardest decisions are usually around value, as value is a function of the whole.
the four big risks that every product team needs to consider are: Will the customer buy it, or choose to use it? (Value risk) Can the user figure out how to use it? (Usability risk) Can we build it? (Feasibility risk) Can the stakeholders support this solution? (Business viability risk)
Your highest‐order contribution and responsibility as product manager is to make sure that what the engineers are asked to build will be worth building. That it will deliver the necessary results. This means working with designers and engineers to come up with solutions that are valuable, usable, feasible, and viable. That is product discovery, and that is what takes on the order of four solid hours a day.
As former Netscape engineer and longtime Amazonian Brad Porter puts it, “Speed and scale are weapons, and Amazon has already told everyone its secret … if only they have the discipline to implement it.”
a roughly six‐page document that describes in narrative form the problem you're trying to solve, why this will be valuable for your customers and for your business, and your strategy for solving the problem.
At the core, I see three critically important differences between the strongest product companies and the rest: The first is how the company views the role of technology. The second is the role their product leaders play. The third is how the company views the purpose of the product teams—the product managers, product designers, and engineers.
