When I first start working with an Agile product team, one of the most common situations I find is where the teams have long and frustrating Sprint planning meetings because backlog items are poorly defined and not well understood; they have slow velocity as well as poor design because details are still being worked out during the Sprint; and the amount of waste and rework is very high because backlog items have not been validated.
I find that most tech product companies out there are struggling to find enough very strong product managers. I have written many times in various ways about how critical it is to put very strong people in this role, and I meet execs every week that tell me that they need more. Great products are the result of a strong product team, and the anchor of that strong product team is a very strong product manager.
In my last article I talked about one technique for applying Scrum concepts to product discovery – the opportunity backlog. In this article, I wanted to talk about another, which is to time-box product discovery.
Recently I was with my friend Jeff Patton, one of the pioneers in applying Agile to product organizations, and he told that he has been advocating the term "Opportunity Backlog" as an alternative to the product roadmap.
Many companies I meet are confused about roles and responsibilities. They're not sure the difference between product managers and project managers, or between product managers and product marketing, or between product managers and interaction designers, as just a few common examples.
One thing I love to do when I visit with companies is collect their favorite quotes and mantras. It helps me to understand their culture and their values. We all deal with certain truths about building technology products, and I find that certain quotes resonate strongly with people and help them internalize important concepts or ideas. For this article, I thought I'd share my current list of favorites.
Normally I like to keep my newsletters to discussions of organization, process and best practices that I believe apply to nearly all technology companies, and I limit the number of product-specific techniques I discuss because of that. I save the product-specific techniques for my direct work with companies so that I can be sure it's relevant.
Jane is supporting the launch of Product X, a new release her company is really excited about. She is on the marketing team. Armed with her launch checklist, she schedules a meeting with John, the product manager. At the meeting, John answers all of her questions, draws a market segmentation on the white board, and talks about the key features and why they are important. Jane takes lots of notes and asks John to review what she sends him.
I consistently get asked questions like the following: "Just look at Facebook/Amazon/Google (usually one of those three). Don't you think they have a terrible product? How could they possibly be so successful?"
I have written earlier about the differences between user prototypes (simulations intended to test the user experience), and live-data prototypes (actual code intended to send live traffic to in order to test real behavior). See http://www.svpg.com/product-discovery-with-live-data-prototypes/