Envisioning the product – most insightful highlights from Roman Pichler’s book

Some weeks ago I’ve read a book: “Agile Product Management with Scrum“, by Roman Pichler. It is a small but brilliant practical book focusing on agile Product Management with Scrum, with a focus on the the Product Owner’s tasks.

After going trough several other books and references in the past weeks, and I recon that there are lots of books out there where the author just offers a looong list of options, still leaving me confused. Not so with this book. So I decided to review my kindle highlights on this book

I remember I went on this book to get more insight about agile product management from a Big of the movement. And, actually, it was incredibly useful and full of inspiration. It didn’t give me only a clearest idea abut how to groom the product backlog, how to focus on a shipable product and manage emerging requirements properly.

BUT what was surprises me is that most of my highlight on the book regards the product vision. The product vision is the ground of each project. This chapter provide me a clear understating of the importance of creating a compelling product vision to galvanize and guide the team and stakeholders.

Here the most interesting insight form the kindle highlights:

An effective vision should answer the following questions:
  • Who is going ti buy the product? Who is the target customer? Who is going to use the product? Who are its target users?
  • Which needs will the product address? What value does the product add?
  • Which product attributes are critical fro meeting the needs selected and therefore for the success of the product? What will the product roughly look like and do? In which areas is the product going to excel?
  • How does the product compare against existing products, from both competitors and the same company? What are the product’s unique selling points? What is its target price?
  • How will the the company make money from selling the product? What are the sources of revenue and what is the business model?
  • Is the product feasible?  Can the company develop and sell the product?
(…)
The vision should communicate the essence of the future product in a concise manner and describe a shared goal that provides direction but is broad enough to facilitate creativity.
(…)
A vision is truly shared when you an I have a similar picture and are committed to one other having it, not just to each of us, individually, having it.
(…)
Resist the temptation to provide too much detail or to over-specify the product. More functionality is discovered and captured in the product backlog as the project progress.
(…)
When it comes to the product vision, less is more. The vision should be brief and concise. It should contain only information critical to the success of the product.
(…)
Coming up with fifteen or twenty product capabilities or features proves to be easy. Selecting the three or four that would incent someone to buy the product is difficult.
(…)
Most successful products have a clear and simple value proposition. Buyers typically make their choice between competing products on the basis of three or four key factors.
(…)
As our ability to predict the future is limited, our best chance of success is to Envision the minimal marketable product, a product with minimum functionality that meets the selected customer needs.
(…)
The product is launched more quickly and time to market is reduced; functionality is released in a more timely manner. The product is developed at a lower cost and generates a higher return on investment.
(…)
Simplicity facilitates creating a product with the minimum functionality that is easy to use. Don’t mistake simplicity for creating simplistic products. As Leonardo da Vinci said, “Simplicity is the ultimate sophistication”.
(…)
Common sense seem to suggest that beating the competition requires a superior product with more functionality. We tend to equate more features with being better and more desiderable. Not so.
(…)
By stating customer needs and detailing a minimum st of product attributes, we connect needs to the technical solution, placing the customer at the center of our development
(…)
Product roadmap simply states how we believe the product is likely to evolve based on our current understanding of the market. Product road maps are living documents; the evolve and changes.
(…)
Grow the platform organically as the need for product variants arises, and carefully guard the platform’s functionality. This approach i likely to result in architecture refactoring, but it mitigates the danger of overengineering the Platform.
(…)
To minimize any potential loss or damage from an inaccurate forecast, select a narrow set of customer needs and quickly release a product increment.
(…)
Some companies gravitate toward the other extreme and close themself off from the market. They rely solely on management intuition or the technical brilliance of their developers. These companies believe they know best what’s good for their customers. The big risk, of course, is that the company invests time and money in developing a product that nobody wants. The best way to prevent innovating in an ivory tower is to incorporate customers and users into the development process by inviting them to sprint review meetings and by releasing software early and frequently.