Theodore Levitt may have developed the whole product model to help companies compete more effectively with their products. We wrote about the whole product game based on Mr. Levitt’s work. Recently, I’ve been using a variant of this model as a way to view a product and upcoming roadmap items. It is a powerful way to share a perspective on your product with the rest of the team, and frame conversations about where best to invest.
Continue reading Classifying Market Problems
Agile is not magical. Changing from a waterfall process to an agile process changes how your team works, and helps eliminate inefficiencies. . What makes agile powerful is also makes it dangerous.
Continue reading Agile Cadabra
Paddy Barrett in Ireland is preparing his Master’s thesis on Product Management and would like to interview (USA) state-side product managers for his primary research. It would be awesome if you could help him, and help us all.
Continue reading How is SaaS Changing Product Management – A Research Thesis
How can Theodore Levitt’s classic Whole Product approach help with defining a product roadmap? I’ve been revisiting his concepts and their use recently, thinking about how to revise them for some exercises I’ve been doing with product teams.
Continue reading Whole Product Game
There are several ways to answer the question “is agile cheaper than waterfall?” Here are two of my favorites:
“It depends. Agile done well is cheaper, as long as you measure correctly.”
“You’re asking the wrong question. The right question is: is agile better?”
Continue reading Is Agile Really Cheaper?
Is your team focusing on the mechanics of creating good software, without understanding the connections from your efforts to your goals? Are you primarily focused on the structure of use cases, the syntax of user stories, and the cardinality of your domain diagrams? All of these things are important to effective communication – but if this is your primary focus, you may be in a cargo-cult environment.
Continue reading Cargo Cult Requirements
Wrapping up the your product failed because you didn’t enable your users to realize value branch of the root causes of product failure, is this article on the context in which your user is using your product. If you ignore your user’s context, they won’t be able to realize the value you provide – or won’t be interested in solving those particular problems at that particular time.
This article continues the series exploring the root causes of product failure. Even when you target the right users, and identify which of their problems are important to solve, you may still fail to solve the problems sufficiently.
Continue reading Why Do Products Fail? – Incomplete Solutions
Having an outside-in bias as a product manager is important – you need to understand how your customers (or your customer’s customers) would value capabilities you might build into your product. When running a workshop to collect that information, playing some “serious games” is a great way to get more and better information. We ran a few 20/20 Vision games last week, to great effect.
Continue reading 20/20 Vision – Innovation Game in Action
Continuing the series on root causes of product failure, this article looks at the impact of focusing on the wrong user goals. Even if you have picked the right users, you may have picked the wrong goals – creating a product your customers don’t really need, or solving problems that your customers don’t care about solving.
Continue reading Why Do Products Fail? – Picking the Wrong User Goals