There is a big trap when managing an early-stage product. I like to call this the “feature plateau trap.”
When you have a product that is relatively new in the market there is a strong temptation to not stop building. It’s exciting to add new features – I totally understand. Everything appears sexy, and when you first start off, it’s easy to get caught up in, “well this next release is looking sparse compared to the last two or three – we better throw more stuff in there.”
As soon as you catch yourself, or your organization doing / saying this, you need a full stop.
There are some key things I think we can all take away from, and acknowledge about product management – many of which I have talked to death here. That is, you want to build products people want. You can’t build a product that is all things to all people – they don’t exist and attempts to create such a monster typically will fail.
So how do you know you have reached this plateau. For me, I like to constant evaluate against my roadmap. Where is the product today in comparison to where it was 6 months ago? What did we define as being important 6 months ago, and are those things in the product today? How is your current roadmap different from your previous 2 iterations on that roadmap?
If you start to see a lot of variance, you may be in starting to slide down a slippery slope.
Remember, folks – being market driven is so much more than responding to every feature request that comes in and making it a reality. Even when they are coming from really important people.
For example, would I act faster if Bill Gates asked me to implement a feature than I would if someone in Texas asked for a different feature? No.
But, would I take notice (not necessarily implement – but take notice) if both someone in Texas and Bill Gates requested the same feature? Yes. Much more so than a single opinion on what will make the product I’m managing the “best ever.”
But, this type of thinking has to start from the top. The PM can only do so much before they will be run down and just start writing requirements for whatever the CEO wants. You can push back and push back — but eventually, if the CEO wants the features they want and you aren’t willing to give them to him or her, they will find someone who is. That’s what makes this tricky.
All things aside, the feature plateau trap is very real and a very common problem in start-ups. There is a very fine line between building out a robust / complete product that solves a problem and just adding features. Maintain your perspective and don’t be afraid to put something new in, even when you aren’t getting the user feedback early on (because it’s hard to come by when you are building out your user base) and don’t be afraid to curtail feature development later in the product lifecycle.
It has to happen eventually, even if you look like an idiot for being the first to suggest it. You can’t always develop features at the pace you do the first year or so of the product’s existence. The thing has to breath, even if Bill G makes that “need to have” feature request. All of them should be evaluated equally and evenly and against the core product definition.
Otherwise, you are just building a group of features that happen to show up together and nothing cohesive.
{ 1 trackback }