Inspired: How to Create Tech Products Customers Love (Silicon Valley Product Group)

by Marty Cagan

The team next narrows down and fleshes out the different potential solutions, then creates a high‐fidelity user prototype—finally, putting that prototype in front of actual target users and observing their reactions.

every time you reference a product roadmap item, or discuss it in a presentation or meeting, be sure to include a reminder of the actual business outcome that feature is intended to help.

The goal is that over time (it can take as long as a year), the organization moves its focus from specific features launching on specific dates to business results.

Teams work on the prioritized business objectives determined by the leaders;

One practical test of whether a person is considered a stakeholder is whether or not they have veto power, or can otherwise prevent your work from launching.

In discovery, you are not only making sure that your solutions are valuable and usable (with customers), and feasible (with engineers), but you are also making sure your stakeholders will support the proposed solution.

the stakeholder usually wins because he or she is usually more senior. However, as we've already discussed many times before, the key is to change the game by quickly running a test and collecting some evidence.

presentations are notoriously terrible for testing business viability. The reason is that they are far too ambiguous. A lawyer needs to see the actual proposed screens, pages, and wording. A marketing leader wants to see the actual product design. A security leader needs to see exactly what the product is trying to do. Presentations are terrible for this. In contrast, high‐fidelity user prototypes are ideal for this.

a group setting is not the forum for designing strong products. It results in design by committee, which yields mediocre results at best. Instead, meet privately with each stakeholder, show them the high‐fidelity prototype, and give them the chance to raise any concerns.

Good teams get their inspiration and product ideas from their vision and objectives, from observing customers' struggle, from analyzing the data customers generate from using their product, and from constantly seeking to apply new technology to solve real problems. Bad teams gather requirements from sales and customers.

Good teams obsess over their reference customers. Bad teams obsess over their competitors.

In an IT‐mindset organization, the product teams exist to serve the needs of the business. In contrast, in a product‐mind set organization, the product teams exist to serve the company's customers in ways that meet the needs of the business. The resulting differences between these mind sets are many and profound.

The impact of a weak product manager shows up in many ways, but it shows up very visibly as a team of mercenaries rather than missionaries. The product manager has not inspired or evangelized to the team, or the team has lost confidence in their product manager.