The main obstacle to rapid delivery is often technical debt, and it is the responsibility of the CTO to ensure that the company is keeping this at a manageable level and not allowing the problem to cripple the organization's ability to deliver and compete, which is discussed next. (link)
We need design—not just as a service to make our product beautiful—but to discover the right product. (link)
the biggest loss of all usually turns out to be the opportunity cost (link)
And then I point out to them that they are trying out ideas in one of the most expensive, slowest ways we know (link)
customer validation happens way too late. (link)
Unfortunately, projects are output and product is all about outcome. (link)
We say if you're just using your engineers to code, you're only getting about half their value. The little secret in product is that engineers are typically the best single source of innovation; yet, they are not even invited to the party in this process. (link)
the second inconvenient truth is that even with the ideas that do prove to have potential, it typically takes several iterations to get the implementation of this idea to the point where it delivers the necessary business value. We call that time to money. (link)
The first truth is that at least half of our ideas are just not going to work (link)
In any case, one of the most critical lessons in product is knowing what we can't know, and we just can't know at this stage how much money we'll make. (link)
. In fairness to the engineers, they're typically doing about as much Agile as they can, given the broader waterfall context (link)
Finally, it's all about solving problems, not implementing features (link)
Products are defined and designed collaboratively, rather than sequentially (link)
Risks are tackled up front, rather than at the end. (link)
I realized that the state of the art was very different from the state of the practice. (link)
Our young team learned something very profound—something many teams have discovered the hard way: It doesn't matter how good your engineering team is if they are not given something worthwhile to build. (link)
Frankly, there are already a wide variety of readily accessible resources for non‐tech products such as most consumer packaged goods, and for product managers of these non‐tech products. (link)
Further, this product management role is very distinct from the design, engineering, marketing, or project manager roles.
This book is intended for these people. (link)
Be sure to staff these common services teams with strong and highly technical product managers (often called platform product managers). (link)
Vikram: [can there be a integration platform product manager]
Working at a startup—racing toward product/market fit—is usually stressful, exhausting, and risky. But it can also be an amazingly positive experience, and if things go well, a financially rewarding one too (link)
The few that succeed are usually those that are really good at product discovery, which is a major topic of this book. (link)
The MVP should be a prototype, not a product. (link)
The Lean Startup by Eric Ries in 2011.
Eric's book did a great deal to help product teams, and to me, it is a must‐read book for all product people. (link)
product/market fit.
This is the smallest possible actual product that meets the needs of a specific market of customers. (link)
The purpose of all these prototypes and experiments in discovery is to quickly come up with something that provides some evidence it is worth building (link)
they're all about learning fast and cheap. (link)
To set your expectations, strong teams normally test many product ideas each week—on the order of 10 to 20 or more per week. (link)
discovery is a validated product backlog. (link)
Will the user buy this (or choose to use it)? Can the user figure out how to use this? Can our engineers build this? Can our stakeholders support this? (link)
We need to discover the product to be built, and we need to deliver that product to market. (link)
In general, for e‐commerce businesses, product includes everything except the actual merchandise being sold. (link)
To be absolutely clear, the product manager is not the boss of anyone on the product team. (link)
John Doerr, the famous Silicon Valley venture capitalist: “We need teams of missionaries, not teams of mercenaries.” (link)
A product team is a group of people who bring together different specialized skills and responsibilities and feel real ownership for a product or at least a substantial piece of a larger product (link)
It's all about the product team. (link)
A good general marketing course will often cover these topics as well. The key is to make sure you gain a big‐picture understanding of how businesses work. (link)
It normally takes about two to three months of dedicated work for a new product manager to get up to speed. This assumes you have a manager who can give you the help and access you need to gain this expertise, including lots of access to customers, access to data (and when necessary, training in the tools to access that data), access to key stakeholders, and time to learn your product and industry inside and out (link)
You can start to see why this role is a proving ground for future CEOs and why the best VCs only want to invest in a company that has one of these proven product people as one of the co‐founders (link)
Every business depends on customers. And what customers buy—or choose to use—is your product. The product is the result of what the product team builds, and the product manager is responsible for what the product team will build.
So, this is why the product manager is the person we hold responsible and accountable for the success of the product. (link)
The honest truth is that the product manager needs to be among the strongest talent in the company. If the product manager doesn't have the technology sophistication, doesn't have the business savvy, doesn't have the credibility with the key executives, doesn't have the deep customer knowledge, doesn't have the passion for the product, or doesn't have the respect of their product team, then it's a sure recipe for failure (link)
The systems always seem to grow in complexity and size much faster than anyone can document (link)
putting up so many obstacles to new ideas that few people are willing or able to drive the company in a new direction. (link)
Not just tweaking and optimizing existing products (referred to as value capture) but, rather, developing each product to reach its full potential. (link)