More on this book
Community
Kindle Notes & Highlights
more than 40 percent of the users would be “very disappointed,” then there's a good chance you're at product/market fit.
it's an empty victory if the product that results is not good.
users choose their devices and platforms because they value what's different, not what's the same.
favorite techniques for building a team of missionaries rather than mercenaries. The engineers,
one or more product risks (value, usability, feasibility, or viability) in discovery;
Act like a parrot. This helps in many ways. First, it helps avoid leading. If they're quiet and you really can't stand it because you're uncomfortable, tell them what they're doing: “I see that you're looking at the list on the right.”
User behavior analytics (click paths, engagement) Business analytics (active users, conversion rate, lifetime value, retention) Financial analytics (ASP, billings, time to close)
They also rewrote the billing system to handle the monthly subscription model (a funny little side story is that they launched without this, as they had the 30‐day free trial month, which bought them the extra time they needed).
A discovery sprint is a one‐week time box of product discovery work, designed to tackle a substantial problem or risk your product team is
It is all too easy to institute processes that govern how you produce products that can bring innovation to a grinding halt.
In contrast, high‐fidelity user prototypes are ideal for this. I plead with product managers in larger companies to not trust a sign‐off on anything other than a high‐fidelity prototype. I have seen far too many times where
The new people you hire are often from those large, brand‐name companies that have stopped growing, have long since lost their ability to innovate, and have been living off their brand for many years. Because of this, they're not on the trajectory they once were, and people leave.
There is little question that most organizations become worse in their ability to rapidly deliver consistent innovation as they grow,
yet most
people attribute this to staff quality, process, and communicat...
This highlight has been truncated due to consecutive passage length restrictions.
Even worse, they often then proceed to hire people that want to work in those ways.
“big company person,” but this is less about being from a big company and more about being from a company that's not strong at product.
because of their mind and their talents, and of course they wouldn't want to bring with them the bad practices of their former company.
The big learnings are important to share broadly, especially when things don't go as hoped.
Good teams have a compelling product vision that they pursue with a missionary‐like passion. Bad teams are mercenaries.
Bad teams gather requirements from stakeholders.
Good teams are skilled in the many techniques to rapidly try out product ideas to determine which ones are truly worth building. Bad teams hold meetings to generate prioritized roadmaps.
Bad teams get offended when someone outside their team dares to suggest they do something.
Good teams obsess over their reference customers. Bad teams obsess over their competitors.
Good teams celebrate when they achieve a significant impact to the business results. Bad teams celebrate when they finally release something.
“Customers are always beautifully, wonderfully dissatisfied, even when they report being happy and business is great. Even when they don't yet know it, customers want something better, and your desire to delight customers will drive you to invent on their behalf.”
original product vision is now largely realized, and the team is struggling to understand what's next. This is often compounded because the original founders may have moved on,
At scale, it's very possible that your product teams are entirely consumed just doing what we call keep the lights on activities. Fixing bugs, implementing capabilities for different parts of the business, addressing technical debt, and more.
Your team should release no less frequently than every two weeks (very good teams release multiple times per day). Correcting this typically means getting serious about
test automation and release automation so the team can move quickly and release with confidence.
