Practicing product minimalism
On my first day of work at Microsoft as a PM six years ago, I sat down with my first manager for our first one-on-one and at the end she asked, Are there any questions? I said yes -- one last one: "When do we decide to remove features?"
She was flustered. It was not a question she or probably any PMs were used to answering. I clarified: "Well, features aren't always right. Sometimes they're done wrong, or they don't really fit what the user really wants. Do we ever remove features?" She remained dumbfounded at the question, and feeling like a n00b, I decided not to press further. In time, I realized why she was flustered. As a program manager, you spent so much time trying to get features in that it seems nuts to want to remove them. We made huge spreadsheets of feature lists, prioritized by P1, P2, P0 and sometimes P-1. Yes, negative 1. Because it gets sorted higher, right? Features got removed in other ways though. If nobody really used them, they were obviously chopped out and memorialized as a bullet point in the release notes. But that wasn't really my question. Those are the easy ones to chop. A product gets bloated not because the obviously bad features stick around. They're bloated because there are features that are barely OK in there. They're not complete. They aren't done correctly. Maybe the UI is wrong, or the internal states aren't thought out well enough, or don't match what the user expects. And there are egos attached, too. A poor PM's ego, at the least,and maybe a dev and a tester's self worth too. An entire feature team might have emotional stakes in that feature.So you can't chop it. And you don't have time to fix it, so it festers. You can never remove features. You have to fix them, painfully, over time.
This can be avoided. Go deep on the things that matter. Do less with less. Be minimal in scope and maximal in completeness. If you're a startup, don't hire. Make it happen with who you've got. Don't get a PM to sit in meetings or create meetings. Only hire do-ers / creators. Do more yourself. If you're a big company, give a skunk-works-sized team a whole shit-ton of power (and really mean it).
Be less. Do less. And you'll somehow end up with more.You should follow me on twitter here.
27 comments
Also, I can't believe there are P-1s...
Jason -- thanks for the story idea. I think it comes down to needing an auteur who has final cut. Someone who says "hell no" to things. Unfortunately I fear it has to come from the top.
Apple hires engineers, and engineers advance until they become mangers of products. The role of *project* manager exists at Apple, but it's more scheduling and no product.
Apple's method makes sense. Microsoft's does not, unless they get someone like you :)
This was my first role on a mobile / desktop app, and it was such a different experience!
It was HARD. Our post about it got dozens of comments- most were positive and encourage but several people were pretty pissed off. End result: a little courage went a long way. Since the release, retention is up, signups are up, revenue growth is accelerating.
It's weird-- you sometimes have to piss of some of the customers you have for the customers you WANT to have in 5 years.
Come to think of it, my most successful projects have been ones with an exact, clear objective. One action that helps benefit the customer immediately and directly. Things that have garnered critiques saying "that's too simple; it's stupid."
Well said Garry :)
http://fred.ipod.to/blog/?post;1952
You really of the point about how unnecessary features were kept, I (as a former PM) couldn't agree more on the consequences the excessive features give supposedly good product designs.
I also mentioned Posterous's design in accordance with the "minimalism" you've mentioned (that's part of the idea, right? :P). It's a good but also tough try in the crowded microblog/sideblog market. Good luck.
When I was a product manager, we moved from P0-P4 priorities to a simpler Must (for which we would delay release), Optional (for which we would not accommodate through a schedule change) and Wish (which had to be trivial) categories.
Eric Ries and Steven Blank have been talking about similar concepts. There are a bunch of good resources from these two guys. There is an interview of Eric on Venture Hacks and Steven has a series of lectures in the Stanford Entrepreneurship Corner that begin with "Rethinking The Product Development Process". He also has a blog and a book.
In our startup, this is exactly what we are doing. We are ruthless about prioritizing and cutting out stuff.
Leave a comment...
