Defining and buildingÂ a good minimum viable product is much harder than it sounds. Â Finding that “one thing” you can do, which people want, is really about a lot more than picking one thing. Â It is a combination of solving the minimumÂ valuable problem and all of the other things that go with it. Â Solving for bothÂ the outside-in needs andÂ the inside-out goalsÂ is critical.
Continue reading Minimum Valuable Problem
Your product roadmap is a view of what you areÂ building right now, in the near future, and in the more distant future. Â Or is your roadmap a view ofÂ why you are building whatever you’re building right now, in the near future, and in the more distant future?
Your roadmap is both – but one is more important than the other – and product managers need to be able to view the roadmap both ways.
Continue reading Opposite Views of a Product Roadmap
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
The industrial age is behind us. It was surpassed by the knowledge economy, rapidly evolved into the attention economy. Successful companies realize that attention comes as a result of conversation. We’re now in the conversation economy.
Continue reading The Conversation Economy
Pictures can convey messages much more powerfully than words. Â In a recent discussion about writing whitepapers, I suggested combining the idea-creation advice from Made To Stick with the image-creation advice from Back of The Napkin. Â Check out this article to see some concrete examples.
Blue Ocean Strategy provides an interesting reactive analysis of companies and markets. Â Personas are used to understand your customer’s needs. Â Combining the two provides powerful proactive insights when positioning your product for market success.
We spend a lot of time (rightly) on the capabilities of our products – identifying valuable problems and compelling solutions. Â This focus is ideal for addressing the needs of our users. Â But what if people abandon our products before trying them? Â First impressions matter – both for buyers and users.
There’s really only one way to travel down a waterfall – in a barrel.Â A lot of people died this way, but some survived.Â Software projects have been predominantly waterfall projects since the start of software projects.Â And stakeholders rode down those projects, basically in a barrel.Â The people riding Niagara Falls 100 years ago didn’t know if they would survive until they got to the end.Â Stakeholders in waterfall projects don’t know if they will succeed until the end.
An agile project is dependent upon tight interaction (and feedback) with stakeholders.
If you’re running an agile project, and your stakeholders are old-school barrel-riders, how do you make it work?
A picture is worth a thousand words.Â Agile values working software over comprehensive documentation, and it values customer collaboration over contract negotiation.Â With that in mind, how much is a picture of a model worth?Â Check out a simple example, how it helped, and what we didn’t do.
Continue reading Simple Agile Model Example
Business rules are often hidden in processes as hidden decisions.Â Once you discover that hidden decision, how do you communicate the impact of exposing and managing the decision?
Continue reading The Impact of a Hidden Decision