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.
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.
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.
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.
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.
It’s fitting that I’m writing this from the exit row of an MD-80 this evening on the way home from a customer visit. I almost didn’t get the exit row, but I did. I tried for an upgrade to first class, but I was 15th in line – it was a busy flight with a lot of high-status frequent fliers ahead of me. But I’m thrilled to be in the exit row, with the lap-room available to type up these tips that will help you travel.